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.

[nitmws]

(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 -> #280
Originally posted by @simonstey in #271 (comment)

looking back, I probably should have followed up on the proposed resolution for this issue.

[nitmws]

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.

[riannella]

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

[DavidFatDavidF]

Action agreed in CG meeting on July 10th
See https://lists.w3.org/Archives/Public/public-odrl/2020Jul/0003.html

[riannella]

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