w3c
Inconsistencies around prohibition, prohibition and obligation in a Policy
The definition of the Policy Class defines, among others:
A Policy MUST have at least one permission, prohibition, or obligation property values of type Rule
The ODRL Profile Mechanism defines, among others:
Additional Rule class: Create a subclass of the Rule class and define it as disjoint with all other Rule subclasses.
That does not fit:
- The Policy Class specification lists 3 properties, all must be of type Rule, but the use of a specific subclass of Rules is not defined. The mentioned Permission, Prohibition and Obligation Class specifications don't defined details of what class must/should/can be used with one of these properties ...
- ... but the ODRL Core Vocabulary is more precise: e.g. the term Has Permission, covering the property permission, defines as Range the Rule subclass Permission, semantically the same is defined for prohibition and obligation.
- Profile ABC defines a subclass of Rule, the SuperProhibition
- By these specifications it is NOT allowed to use this SuperProhibition as the three listed Policy Class properties must only be used with another specific Rule subclass - and it is not allowed to add new properties - at least I conclude this from the ODRL specs ...
- ... and if defining and using a property superProhibition is allowed it is still mandatory to use one of permission/prohibition/obligation too. Defining a subclass of Policy does not help profile ABC: as subclasses inherit properties (and their rules) the use of one out of permission/prohibition/obligation cannot be prevented ...
- ... or can it? A formally tricky thing is that OWL does not support natively a cardinality of properties, this "at least one of permission/prohibition/obligation must be used" cannot be defined with OWL means. Do we assume that the free-text specifications of the ODRL Information Model provides the cardinality ...
- ... but the free-text of the ODRL Information Model defines only that permission/prohibition/obligation must be used with a Rule class (or subclass) but not that permission must be an instance of the Permission class. This formally allows to use the property prohibition with the SuperProhibition class ...
- ... so the ODRL Recommendation is running is circles between the free-text and the OWL specifications.
Conclusion: the ODRL Information Model has internal inconsistencies.
(Added on behalf of @simonstey) fwiw, I also pointed this out some time ago ->
| ODRL Profile Definition | Example |
|---|---|
| Additional Policy Subclasses: Create a subclass the ODRL Policy class. | ex:myPolicyType rdfs:subClassOf odrl:Policy . |
| ... | ... |
| Additional Rule class: Create a subclass of the Rule class and define it as disjoint with the other Rule subclasses. | ex:myRule rdfs:subClassOf odrl:Rule ; owl:disjointWith odrl:Prohibition, odrl:Duty, odrl:Permission . |
that's inconsistent wrt. to the vocab, where we also state that all policy types are mutually disjoint. more on that -> w3c/poe#280 Originally posted by @simonstey in w3c/poe#271 (comment)
looking back, I probably should have followed up on the proposed resolution for this issue.
In the ODRL Community teleconference on 2 March 2020 this change of the Information Model was raised to solve this issue:
The current specification of the Policy class includes:
A Policy MUST have at least one permission, prohibition, or obligation property values of type Rule. (See the Permission, Prohibition, and Obligation sections for more details.)
Note - the ODRL Vocabulary specifies for these three properties: the value of a permission must be an instance of Permission, the value of a prohibition must be an instance of Prohibition, the value of an obligation must be an instance of Duty.
The basic intention behind this "Policy MUST have ..." definition was: a Policy MUST relate to least one Rule. At the time of defining that the Rule sub-classes Permission, Prohibition and Duty were defined and the Policy class was related to them by these three listed properties. The feature "a profile may define its own sub-classes of Rule and may relate them to a Policy" was not defined at this point in time as defining the features of a Profile was done in the last round of development work. Therefore this issue is an Erratum.
Therefore a solution of this issue should stick to the basic intention but open the options to any related sub-class of Rule.
Suggested wording: A Policy MUST have at least one property with a value of type Rule. This is satisfied by the permission, prohibition, and obligation properties or properties defined by a Profile and requiring a value of type Rule.
To be more specific, should the first line be "A Policy MUST have at least one property, in which the property has a range of a subclass of Rule."
Action agreed in CG meeting on July 10th See https://lists.w3.org/Archives/Public/public-odrl/2020Jul/0003.html
Summary: In Section 2.1, the second bullet item is too specific in mentioning the three property values. More generally, the item should state: "A Policy MUST have at least one property, in which the property has a range of a subclass of Rule."