Versioning

Hi,

Following discussion with Nigel earlier this week, we like to make the following recommendations with respect to versioning the specification;


*         The standard should incorporate a three part version number and all uses of the standard should identify which version they relate to

*         Major version number changes are used for incompatible revisions to the standard.  We believe that those will be situations where we redefine an existing term in a manner which is less permissive than it was in the previous version.  There should be some wording encouraging future working groups to avoid doing this, but it shouldn't be ruled out as it would be undesirable to jump through hoops when revising the standard to avoid at all costs ever modifying an existing term

*         Minor version changes are used for additions to the standard.  ODRL interpreters may encounter run-time errors when presented with documents based on a newer minor version of the standard if the addition affects a clause in the document that they are required in context to evaluate

*         The last part of the numbering scheme (patch version) is used for non-material changes to the standard.  ODRL interpreters should be able to fully evaluate any document which differs in version number only in this regard

*         While in draft, the major version number will be "0", with the specification free to make breaking changes given there are no implementations deployed in production (this enables the finalized specification to be released as version 1.0.0)

*         Branches, beta releases, etc are represented by a suffix consisting of a hyphen and free-form qualifier, e.g. 1.2.1-beta

*         Deprecation of terms will be managed through existing OWL annotations<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_TR_owl-2Dref_-23Deprecation&d=DwMFAg&c=7563p3e2zaQw0AB1wrFVgyagb2IE5rTZOYPxLxfZlX4&r=ICXsYhIJDNDHN-MQBUh5Brxtp_NlKYKKYQj2IEeqZOo&m=JDFjAHzg08uJ_Yk0mrBSYhn-7Ujm-ln5Fc9_kSfj2Vs&s=LafZUspOY1d4WIzSMignm8pqwWPF3aXlpI35CQ6t4TE&e=> - editors should discourage usage of deprecated terms in new contracts, while the notion is irrelevant for an evaluator

*         Calculating the diff between old and new versions must be done on the semantic model (including terms imported from other ontologies) and not the literal document text


Points for further discussion;

Ideally ontology versioning would managed by build tooling, something like a git commit hook that would diff and automatically increment to the appropriate version - but this would require a complete set of rules governing backwards compatibility (still researching to see if there's any prior art that defines such rules for ontologies).

Additive changes in software are backward compatible as older implementations aren't aware of the new features - this is not true for ontologies, where an interpreter could encounter new terms.  This could be treated as a runtime concern; if a new action were added to the spec, and added as a contract's permission the implementation would only need to fail if there was an attempt to exercise that specific permission.
However the same does not appear to hold when the new action in a prohibition - without knowing where in the hierarchy this new action is, the implementation cannot allow anything - the contract cannot be evaluated at all.  E.g. a new action display-full-color is introduced as a subclass of display, and appears as a prohibition - as the implementation cannot be certain which use is prohibited, it does not know what's permitted.
This is problematic, as we want version compatibility rules that are agnostic of the Market Data and ORDL domains and just concerned with the language of RDF - otherwise we will revisit the notion of compatibility with every domain change.


Best regards,
Caspar

________________________________

Your Personal Data: We may collect and process information about you that may be subject to data protection laws. For more information about how we use and disclose your personal data, how we protect your information, our legal basis to use your information, your rights and who you can contact, please refer to: www.gs.com/privacy-notices<http://www.gs.com/privacy-notices>