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

Renato,

thanks for your considerations. 

 

For the call later today I collect there some issues we should be aware of in addition to what Renato points at below:

a. Reminder: at the ODRL teleconference in July this was raised: should we (the ODRL CG) open the door for rules which may be not a permission, prohibition or duty? May this violate the basic design of ODRL?
b. Re Option 1: does a sub-class of Permission, Prohibition or Duty inherit all rules of the parent class written down in the Information Model? Or can such a sub-class modify rules – this would help to integrate the need of creating Rule sub-classes with special rules, not only special properties.
c. On selecting option 1 or 2 in the Profile BP document, NOTE on https://w3c.github.io/odrl/profile-bp/#rule, considered below by Renato:
- Option 1 follows the basic design of the Golden Three, but the required disjoint statement cannot be applied to parent class(es).
- Option 2 has no issues with the requirement of defining new Rule sub-classes as disjoint with others, but it may override the focus of ODRL on permissions, prohibitions and duties.
d. Impact on the Profile BP:
- in general: If one of these options is selected for the Profile BP should it explicitly exclude the other option?
- selecting Option 1: the BP documents has to say “for sub-classes of Permission, Prohibition and Duty the requirement to defining it as disjoint with all other Rule classes does not apply to its parent class(es)”. And it has to clarify if beyond the data structure also the rules defined in the Information Model are inherited.
- selecting Option 2: it must include a clear rule: only Rule sub-classes very close to the Golden Three should be defined. (But this “very close” leaves some doors open …)

 

More at the teleconference in about 2 hours,

Michael

 

 

From: Renato Iannella <r@iannel.la> 
Sent: Friday, October 2, 2020 2:04 PM
To: public-odrl@w3.org Group <public-odrl@w3.org>
Subject: 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 <mailto: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

 <http://www.linkedin.com/in/michaelwsteidl> www.linkedin.com/in/michaelwsteidl

Email: mwsteidl@ <http://www.newsit.biz/> newsit.biz

1180 Wien/Vienna – Österreich/Austria