Re: Profiles Best Practice - how to deal with sub-classes of Rule - open until 5 October

For the issue Michael has highlighted in Section 4.9:

1) I think the original intent of the "Additional Rule class” (last row of Table in section 3.3 of https://www.w3.org/TR/odrl-model/#profile-mechanism) is aligned to Option 2 in the Profile BP document.
- A “subclass of Rule” literally only meant sub-classing directly the Rule class (not any of the Golden Three classes)
- Hence the disjoint requirement holds.

2) I don’t think we ever considered sub-classing the Golden Three classes (at the time)…but...
- I think if a community wanted to sub-class one of the Golden Three, then it would not create any issues.
- For example, I create “MyPermission” sub-class of Permission.
- This “MyPermission” class still “is-a” Permission class (and I can use the permission property)
- Hence my Policy will have one of the Golden Three classes (at least)
- I don’t believe you can disjoint classes in the same hierarchy

Cheers - Renato


> On 8 Sep 2020, at 02:06, Michael Steidl (NIT) <mwsteidl@newsit.biz> wrote:
> 
> Hi all,
> a short wrap up of this issue “how to deal with sub-classes of Rule” brought up at our teleconference today.
>  
> Section 4.9 of the Profile Best Practice document (https://w3c.github.io/odrl/profile-bp/#rule <https://w3c.github.io/odrl/profile-bp/#rule>) talks about additional Rule subclasses. It includes the NOTE (in green) with two options:
> Option 1: create subclasses of the Permission, or Prohibition or Duty class and use this subclass with the corresponding property of an ODRL Policy: permission, prohibition or obligation – one of them MUST be used by an instance of the ODRL Policy.
> Option 2: create a subclass of Rule and use it with a new property of an ODRL Policy – but: at least one of the properties permission, prohibition or obligation MUST be used by an instance of the ODRL Policy.
>  
> On 6 July in my email to this public ODRL email list I raised this question after editing this note:
> BUT there may be still the need to change the Recommendation:
> The Profile Mechanism (https://www.w3.org/TR/odrl-model/#profile-mechanism <https://www.w3.org/TR/odrl-model/#profile-mechanism>) defines: 
> “Additional Rule class: Create a subclass of the Rule class and define it as disjoint with all other Rule subclasses.”
> I think this “disjoint” requirement raises an issue: does creating a subclass of Permission/Prohibition/Duty (which are subclasses of Rule) require to meet this requirement?? (Formal detail: does “subclass of Rule” means only direct subclasses of Rule or also subclasses of subclasses or Rule.) 
> In other words: is it required to define a subclass of e.g. Permission as disjoint from Permission (I think this is formally impossible) ?
>  
> … but got no response to it so far.
>  
> Section 5.1 of the BP document (https://w3c.github.io/odrl/profile-bp/#oos1 <https://w3c.github.io/odrl/profile-bp/#oos1>) talks about “What my be ignored and what not”.
> The subsection about Rule(s) of a Policy shows two alternative texts:
> * the upper one: covers the “one of permission, prohibition or obligation MUST be used by an instance of the ODRL Policy” requirement – and this is what Options 1 and Option 2 describe in section 4.9. (Sorry, my statement that it covers only Option 1 at the teleconference today was wrong – I haven’t looked at the wording for 2 months.)
> * the lower one: builds on 1st level subclasses of Rule (and not on subclasses of Permission/Prohibition/Duty), they may be applied as alternatives to the properties permission, prohibition or obligation.
>  
> My conclusion of the re-reading today: the lower alternative has not been agreed by the group at the July teleconference already – let’s remove it. Therefore I have applied a strikethrough to this alternative text.
>  
> So the only open issue I see regarding “how to deal with sub-classes of Rule” is this disjoint-issue shown above.
>  
> I hope this can be clarified until the next teleconference on 5 October, frankly said I’m not an expert in applying disjoints to subclasses.
>  
>  
> Best,
> Michael
>  
> =============================================================
> Gesendet von / sent by:
> Michael W. Steidl
> www.linkedin.com/in/michaelwsteidl <http://www.linkedin.com/in/michaelwsteidl>
> Email: mwsteidl@newsit.biz <http://www.newsit.biz/>
> 1180 Wien/Vienna – Österreich/Austria