Inconsistencies around prohibition, prohibition and obligation in a Policy

[nitmws]

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.

[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..

[nitmws]

This ODRL CG issue was moved to POE Issue 303. Please add further comments there.