feat!: create Ratio and use it for aspectRatio and displayAspectRatio and frameRate

[MarcAntoine-Arnaud]

issue #332

[JuergenGrupp]

Thank you @MarcAntoine-Arnaud !
If the pull request is approved, it needs to be merged to the "dev" branch, not the "main".
Please see : https://github.com/ebu/ebucoreplus/wiki/04-Branching-policy-for-main,-dev-and-issue%E2%80%90branches

[aro-max]

typo : Represents

[aro-max]

Question about the restriction : xsd:minInclusive 1
Don't you think you should encapsulate this restriction within a datatype definition ? To be OWL 2 compliant ?

[JuergenGrupp]

Sorry for the long review time! During our last Editorial Committee meeting we have concluded to pack this into a new issue and use a new class Ratio for two of the three attributes mentioned above. I have now re-analysed the comments and would also use it for the Attribute frameRate.
But as I am starting to do this, I am stumbling across this question of aro-max. What do you think, @MarcAntoine-Arnaud ? Should you encapsulate the restriction within a datatype definitrion as proposed by @aro-max ? If we can resolve this question quickly, I might be able to review, merge and commit your pull request quickly as well.

[JuergenGrupp]

Currently the property displayAspectRatio has the range "ActiveFormatDescriptorCode" (which is a subclass of "Format"). It is probably intended to use the classification scheme "ebu_ActiveFormatDescriptorCodeCS" here, as defined in http://www.ebu.ch/metadata/cs/EBU_cs_p.zip.
Please note, this Format Descriptor Code expresses more than only a ratio. I fear we might lose important information if we reduce it to the class "Ratio".
I am not sure either about how to handle the property aspectRatio: should we better extend this to also use the "ActiveFormatDescriptorCode", should we change the range to the "Ratio" class or should we leave it as it is?

[JuergenGrupp]

Editorial Committee:

• we need both properties, one represents the recording format and the other representing the display format, because in rare cases they will be different
• but both properties should take the numerator/denominator style value.

Conclusion: we will create a separate issue on that

[JuergenGrupp]

Please do not delete ActiveFormatDescriptorCode.
Everything else is fine imho and can be approved.

[JuergenGrupp]

Please do not delete this subclass of Format (subclass of skos:concept): ActiveFormatDescriptorCode.
Even if it is currently not used in EBUCorePlus, we should not exclude any future use of it.