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

HI all,

I excuse my participation today, as I have teaching duties.

I would like to report some activity wrt ODLR:

*1. Mapping of data licenses to ODRL**
*We are renewing our effort to map licenses to ODRL:
a) Licenses are published as independent files in an open github repo. 
Anyone can discuss the mapping, changes are traceable. See our progress 
here: https://github.com/Pret-a-LLOD/pddm/tree/develop/data/licenses
b) Licenses will be updated to the newest schema (the previous effort is 
outdated)
c) Licenses specific to the language resources domain will be added. Of 
special value, as they will be validated by the domain experts.
d) We are observant of related offorts, such as this: 
https://github.com/spdx/license-list-data. They do have a structed JSON. 
See an example here: https://spdx.github.io/license-list-data/NASA-1.3.json
We can also build on their effort, as the effort has CC-BY license.
Question to the ODRL community group? Should I approach the authors 
suggesting them to use the ODRL schema and have JSON-LD instead of their 
JSON?

*2. ODRL-related services**
*We are also developing ODRL-related services. Will report in subsequent 
efforts.

*3. Today's debate.**
*I am mildly in favor of Option 1, but I am not sure I understand the 
consequences of either choice.

Regards,
Víctor

El 05/10/2020 a las 11:30, Michael Steidl (NIT) escribió:
>
> 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:
>
>  1. 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?
>  2. 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.
>  3. 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.
>  4. 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) 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//) 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)*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 1^st 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
>


-- 
Víctor Rodríguez-Doncel
D3205 - Ontology Engineering Group (OEG)
Departamento de Inteligencia Artificial
ETS de Ingenieros Informáticos
Universidad Politécnica de Madrid

Campus de Montegancedo s/n
Boadilla del Monte-28660 Madrid, Spain
Tel. (+34) 910672914
Skype: vroddon3
http://cosasbuenas.es