Creating Rule subclasses being a Permission, Prohibition or Duty

[nitmws]

The discussion about issue #8 raised suggestions like:

• A new Profile can define a new subclass of Rule and a new subclass of Policy with a property having the new Rule subclass as type
• The constraint on the type of the Policy properties permission, prohibition and obligation should be lifted to allow more than a specific subclass of Rule as type.

On the other hand it was said the basic design of ODRL is to express only rules of kind permission, prohibition or obligation/duty, this should not be spoiled by opening up Policies to any - even awkward - kind of rule.

A suggestion how a) the design can be protected and b) opening up permission, prohibition and obligation to more than one specific subclass of Rule as type.

• Create new subclasses of Rule: SuperPermission, SuperProhibition, SuperDuty
• These classes inherit the Rule class as it is, nothing is omitted, nothing is added ...
• ... but each one has clear semantics of what kind of Rule it covers.
• The existing class Permission is made a subclass of SuperPermission, class Prohibition a subclass of SuperProhibition, Duty a subclass of SuperDuty.
• The type (Range) of these Policy properties is changed: permission rdf:type SuperPermission, prohibition rdf:type SuperProhibition, obligation rdf:type SuperDuty . (This permits to use an instance of Permission with permission, but no other property. The same for Prohibition and Duty.)
• The rules / best practice of a Profile is changed: only subclasses of SuperPermission, SuperProhibition or SuperDuty may be defined. As best practice: a subclass of SuperPermission means it can be used only with the property permission ... etc.

Changes to the Recommendation to fix this POE Erratum:

• Only changes to the ODRL Vocabulary
• Add 3 subclasses of Rule: SuperPermission, SuperProhibition, SuperDuty. Apply a skos:definition describing the characteristics of each of them.
• Make Permission a subclass of SuperPermission, Prohibition as subclass of SuperProhibition, Duty a subclass of SuperDuty
• Change the type/Range of permission, prohibition and obligation to the corresponding Super.... classes.

Compatibility considerations:

• Using an instance of Permission with permission. of Prohibition with prohibition, of Duty with obligation is fully backward compatible. No properties are removed, no processing rules are changed.
• Processing with RDF processor needs to be able to deal with two subclassing actions from Rule to Permission, Prohibition and Duty.
• Automated generation of programming code from the OWL document may require an additional step, but no properties of the created classes are different from the current state.

[nitmws]

Wrap up, 8 months later:

• The definition of the Policy properties permission, prohibition and duty in the ODRL Information Model SHOULD be improved: currently only a look into the ODRL vocabulary reveals that the Range of these attributes are the corresponding Rule subclasses Permission, Prohibition and Duty. This should be expressed already in the Information Model to avoid wrong interpretations. See POE issue 303.
• The definition of the "Additional Rule class" section of the Profile Mechanism in the ODRL Information Model SHOULD be rewritten: the CG discussions of the last months set a focus on "the basic model of an ODRL Policy is to contain Permission, Prohibition and/or Duty Rules and this should not be spoiled by creating subclasses of Rule with quite different semantics". The Profile Mechanism should be changed to set this focus. And the current requirement "... define it as disjoint with all other Rule subclasses" should be considered: if e.g. a subclass of Permission is defined by a Profile it actually cannot be defined as disjoint with its superclass Permission ...
• This focus of the ODRL design is expressed in the Profile Best Practices document:
  • The Note in the Additional Rule Subclasses section advises builders of a Profile to define only subclasses of Permission, Prohibition and/or Duty and not direct subclasses of Rule. (It can only be an advice as the Profile Mechanism of the Information model is less strict, see above. The CG hopes many readers take this seriously.)
  • The section What may be ignored, and what not tells Profile builders in its Regarding the Rule(s) of a Policy bullet to use only the Permission, Prohibition or Duty subclasses of Rule or a subclass of one of these three.

Based on this current status of this ODRL CG Issue I suggest to set the discussion about these topics on hold until a next version of the W3C ODRL Recommendation is created.

[riannella]

Thanks for the wrap-up summary Michael.
Some great insights for ODRL V 3 !

[vroddon]

Thanks a lot! Not myself, but the UPM team will be using your work for the next few weeks/months...