RE: Profile Best Practice document with alternative text about Policy and subclasses of Rule

Hi all,

I’ve edited the ODRL Profile Best Practice page as agreed at the call:

- basic approach: don’t change the ODRL Recommendation, and if required only minimal.

- people should be reminded to check if the existing Permission, Prohibition and Duty classes meet their needs

- if not: they should consider to define subclasses of Permission, Prohibition and Duty as this does not require to define a new Policy subclass

- if not, again: advise them to create new subclass(es) of Rule and a new subclass of Policy – and remind them of “one of permission, prohibition or obligation properties MUST be used”.

* See the edited Note of https://w3c.github.io/odrl/profile-bp/#rule
* And of https://w3c.github.io/odrl/profile-bp/#policy

 

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) ?

 

It this “define it as disjoint” does not work I suggest to modify this requirement in the Profile Mechanism – less impact on the ODRL Recommendation than changing the Information Model or the Vocabulary.

 

Would be great to hear views on that by RDF/OWL experts.

 

Thanks,

Michael

 

From: Michael Steidl (NIT) <mwsteidl@newsit.biz> 
Sent: Monday, July 6, 2020 11:38 AM
To: 'Renato Iannella' <r@iannel.la>; public-odrl@w3.org
Subject: RE: Profile Best Practice document with alternative text about Policy and subclasses of Rule

 

… a good use case = a project persons of this Community Group work on and not setting a focus on licensing the use of a kind of asset, more about expressing something like rules of order (= what may be done, what must be done, what must not be done).

 

Best,

Michael

 

From: Renato Iannella <r@iannel.la <mailto:r@iannel.la> > 
Sent: Friday, July 3, 2020 1:53 PM
To: public-odrl@w3.org <mailto:public-odrl@w3.org>  Group <public-odrl@w3.org <mailto:public-odrl@w3.org> >
Subject: Re: Profile Best Practice document with alternative text about Policy and subclasses of Rule

 

Thanks for the in-depth analysis Michael….

 

I think the point raised by David also was that the ODRL Model is based on semantic web technologies, which implies the ‘open-world assumption’.

Hence, we cannot stop additional assertions being created.

 

That is, when we wrote:

   "A Policy MUST have at least one permission, prohibition, or obligation property values of type Rule”

We said nothing about what else a Policy could have.

 

So an ODRL Profile can create a new subclass of Rule, say “Safety" and related property “safety”, then a valid Policy would be one that has at least one of the "golden three” properties and the new “safety” property.

 

So, I think we are in a better place than we thought last month.

I think the current Spec is ok, and all we need to do in the Profile Best Practices is show a good use case for a new type of Rule.

 

Cheers - Renato

 

On 11 Jun 2020, at 00:58, Michael Steidl (NIT) <mwsteidl@newsit.biz <mailto:mwsteidl@newsit.biz> > wrote:

 

Hi all,

at the call on 8 June this raised erratum was discussed:  <https://github.com/w3c/poe/issues/303> https://github.com/w3c/poe/issues/303

Simply summary: the ODRL data model and vocabulary define that only a single specific subclass of Rule can be used as type for the Policy properties permission, prohibition  and obligation.

Open issue: how to use subclass of Rule defined by a Profile in a Policy? By the current Recommendation this is not easy:

 

At the call we discussed two options:

a. The data model and the vocabulary stay untouched, the only solution is creating a new property in a new subclass of Policy and to define the new Rule subclass as type of this new property.
Pro: no change of the Recommendation is required
Con: a kind of pointless rule dummy must be used with permission or prohibition or obligation if the goal of the news Profile is to use only new subclasses of Rule.
b. Currently the vocabulary defines for the Policy property permission [1]: its type (Range) is Permission [2], and Permission defines In Range of: permission.
(Corresponding definitions are applied to the properties prohibition [3] and obligation [4]).
This is changed to permission/prohibition/obligation have  as type (Range) Rule [5] – this opens the window of opportunity for applying any subclass of Rule as type.
Open issue: what about this “In Range Of” in the vocabulary, this is not reflected explicitly by the formal OWL documents of the vocabulary, may be generated from the range setting of properties. “In Range of” appears to be not a relationship defined for RDF or OWL.

 

General note: at the call David reminded us of sticking to the base design of ODRL, and this includes only permission, prohibitions and obligations should be expressed as Rule, not anything away from it. We may consider how to guarantee that. This is my suggestion:  <https://github.com/w3c/odrl/issues/10> https://github.com/w3c/odrl/issues/10

 

Based on this discussion I modified – as agreed at the call – the Profile Best Practice document  <https://w3c.github.io/odrl/profile-bp> https://w3c.github.io/odrl/profile-bp

* ALTERNATIVE TEXT is shown in the section Additional Rule Subclasses  <https://w3c.github.io/odrl/profile-bp/#rule> https://w3c.github.io/odrl/profile-bp/#rule
* ALTERNATIVE TEXT is shown in the section Additional Policy Subclasses  <https://w3c.github.io/odrl/profile-bp/#policy> https://w3c.github.io/odrl/profile-bp/#policy
* ALTERNATIVE TEXT is shown in the section What may be ignored, and what not  <https://w3c.github.io/odrl/profile-bp/#oos1> https://w3c.github.io/odrl/profile-bp/#oos1
* “ALTERNATIVE TEXT no change applied …” reflects option a) above
* “ALTERNATIVE TEXT constraint of types …” reflects option b) above

 

What’s next:

1. Please review if the created ALTERNATIVE TEXTs reflect options a) and b) in their context properly – prior to the next call on 6 July.
… and post any comments to this email list.
2. At the next call we should agree if we keep both alternatives in the Best Practice or if we select one of them as “the solution”.

 

Best,

Michael

 

 

[1]  <https://www.w3.org/TR/odrl-vocab/#term-permission> https://www.w3.org/TR/odrl-vocab/#term-permission

[2]  <https://www.w3.org/TR/odrl-vocab/#term-Permission> https://www.w3.org/TR/odrl-vocab/#term-Permission

[3]  <https://www.w3.org/TR/odrl-vocab/#term-prohibition> https://www.w3.org/TR/odrl-vocab/#term-prohibition

[4]  <https://www.w3.org/TR/odrl-vocab/#term-obligation> https://www.w3.org/TR/odrl-vocab/#term-obligation

[5]  <https://www.w3.org/TR/odrl-vocab/#term-Rule> https://www.w3.org/TR/odrl-vocab/#term-Rule

 

=============================================================

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