How to define terms of a profile in a machine-readable way?

[nitmws]

While fine tuning the JSON-LD context for IPTC's RightsML (see https://iptc.org/std/RightsML/odrl-profile/rightsml.jsonld) I came across this issue:

• An ODRL Policy in JSON-LD has to included the JSON-LD context defined by ODRL (http://www.w3.org/ns/odrl.jsonld)
• This context includes all terms (Things) defined by the ODRL 2.2 Information Model ...
• ... and also terms defined by the ODRL 2.2 Common Vocabulary (https://www.w3.org/TR/odrl-vocab/#vocab-common). These terms are NOT defined by the ODRL 2.2 Recommendation, therefore if the action "play" should be used in a permission an ODRL profile defining this term is required.
• As a result a JSON-LD Policy using a profile must include the context of the profile AND the ODRL context.
• This raises the essential question: what really "defines" which terms are valid in a Policy?
  ** If the action "play" is not adopted/defined by a profile it still can be found in the ODRL context. How can it be told: the action "play" should not be used with this Policy?
  ** A variant which can be used by humans is to refer to a document defining a profile in a human readable way. But as far as I know there is no machine readable variant available for ODRL.

A confusing detail: the ODRL context document includes many of the actions listed in the ODRL Common Vocabulary but not all ...

[nitmws]

Pondering round 2:

The formally most relevant document specifying which Things relate to a data model is in the ODRL context an ontology. Unfortunately the ODRL ontology raises some issues:

• The ODRL ontology (e.g. in Turtle: https://www.w3.org/ns/odrl/2/ODRL22.ttl) includes both the normative Things, like the actions odrl:use and odrl:transfer , and non-normative Things from the Common Vocabulary, like the action odrl:play.
• A distinction between both kinds of Things is made in two ways:
  -- terms, including actions, from the non-normative Common Vocabulary have a skos:scopeNote "Non-Normative"@en, the normative terms don't have a skos:scopeNote.
  -- the normative actions are members of the collection http://www.w3.org/ns/odrl/2/#actions, while the non-normative actions are members of http://www.w3.org/ns/odrl/2/#actionsCommon. Similar ....Common collections exist for other Things too.
• The formal issue is: both "earmarks" are nowhere defined in the ODRL Recommendation. In fact only some human pondering can currently infer which Things or normative and which not.
• Footnote: having a language tag for the scopeNote makes things even more tricky: if a software displays the ontology to human eyes and if this user interface is set to the language Spanish the reader will not see "Non-Normative"!

If an ODRL profile defines its ontology and if this profile adopts Common Vocabulary terms its an open issue how these terms should be included in the profile's ontology:

• should the skos:scopeNote "Non-Normative" be adopted too?
  Is a profile setting additional normative Things or are Things defined by a profile as Non-Normative as the terms of the Common Vocabulary? Or does ODRL need to make a distinction between Normative/Non-Normative and Relevant-for-validation/Not-relevant-for-validation, which is the semantic highly required by an ODRL validation and evaluation software!
• should the ...Common collection ids from the ODRL ontology be used again, but with different members for this profile?

[vroddon]

Michael, Ivan(?), The W3C should make an internal ontology some day ,with elements such as "w3c:nonNormative", "w3c:Recommendation" or "w3c:Note". As for the immediate things to do, I believe things are ok as they are: I think that the non-normative things said by a normalizer institution tend to be considered as normative as the truly normative; namely, adopters will also consider seriously the nonNormative parts... Víctor El 07/08/2018 a las 15:39, Michael Steidl escribió:

…

Pondering round 2: The formally most relevant document specifying which Things relate to a data model is in the ODRL context an ontology. Unfortunately the ODRL ontology raises some issues: * The ODRL ontology (e.g. in Turtle: https://www.w3.org/ns/odrl/2/ODRL22.ttl) includes both the normative Things, like the actions |odrl:use| and |odrl:transfer| , and non-normative Things from the Common Vocabulary, like the action |odrl:play|. * A distinction between both kinds of Things is made in two ways: -- terms, including actions, from the non-normative Common Vocabulary have a skos:scopeNote ***@***.*** <https://github.com/en>, the normative terms don't have a skos:scopeNote. -- the normative actions are members of the collection http://www.w3.org/ns/odrl/2/#actions, while the non-normative actions are members of http://www.w3.org/ns/odrl/2/#actionsCommon. Similar ....Common collections exist for other Things too. * The formal issue is: both "earmarks" are nowhere defined in the ODRL Recommendation. In fact only some human pondering can currently infer which Things or normative and which not. * Footnote: having a language tag for the scopeNote makes things even more tricky: if a software displays the ontology to human eyes and if this user interface is set to the language Spanish the reader will not see "Non-Normative"! If an ODRL profile defines its ontology and if this profile adopts Common Vocabulary terms its an open issue how these terms should be included in the profile's ontology: * should the skos:scopeNote "Non-Normative" be adopted too? Is a profile setting additional normative Things or are Things defined by a profile as Non-Normative as the terms of the Common Vocabulary? Or does ODRL need to make a distinction between Normative/Non-Normative and Relevant-for-validation/Not-relevant-for-validation, which is the semantic highly required by an ODRL validation and evaluation software! * should the ...Common collection ids from the ODRL ontology be used again, but with different members for this profile? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFLs5SLGXgk5Cc-IgW5AZdFm4FzrU13kks5uOZiugaJpZM4VwJZf>.

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

[riannella]

The official line from W3C is that the Spec defines the normative parts (ie human readable text).

Perhaps we need to develop some "template ontologies" with the normative concepts, that a community can then start to add in the terms that want (or reuse common odrl terms)

[nitmws]

@vroddon and @riannella I think we need an interim solution for ODRL.

I suggest to consider that:

The Information Model defines an ODRL core profile with the id http://www.w3.org/ns/odrl/2/core.
What about such a SKOS collection of all terms which are a member of this profile:

<http://www.w3.org/ns/odrl/2/core>
    a skos:Collection ;
    skos:prefLabel "ODRL Core Profile" ;
    skos:scopeNote "All members of this collection make the ODRL Core Profile" ;
    skos:member :... (many) .

(Formal issue: where does this Collection exist: the official ODRL ontology must be changed, somewhere else as "profile ontology"?)

This could be a template for the ontologies of other profiles:

• the ontology includes all Things defined by this profile in the typical OWL way
• the ontology must also include a SKOS collection with the id of the profile and all Things defined by it as members.

A validator could check then:

• an action, a constraint LeftOperand, etc should be validated
• first check: is this Thing a member of the ODRL Core Profile
• if: this Things is valid; if not, checks for each applied profile: is this Thing a member of the checked profile
• if not: this Thing is invalid, if: this Thing is valid.

[riannella]

If we create the ontology, we should be able to ask Ivan to publish it at this location: http://www.w3.org/ns/odrl/2/core

[riannella]

I will create the core ontology and send to group for comment

[riannella]

I've added the first attempt at the Core Profile on github:
https://github.com/w3c/odrl/blob/master/core/odrl-core-profile-22.ttl

Please review and update !

[vroddon]

I have just read it.
Looks good.

[riannella]

So can we test out the approach of using this Core Profile to build a community Profile...and document this in the Best Practices guide???

[vroddon]

I think this is a nice code for others to start copy&pasting.
But even better if illustrated with another example (the real terms of an specific profile), perhaps documented with two colours in the documentation...

[nitmws]

I had a look into https://github.com/w3c/odrl/blob/master/core/odrl-core-profile-22.ttl
The approach to include there only concepts which are defined by the ODRL 2.2 Recommendation as normative is a step ahead, clarifying what is the Core Profile mentioned in https://www.w3.org/TR/odrl-model/#profile-core.

A basic consideration: a clear distinction should be made between an ontology covering the ODRL namespace (= it covers all concepts with a URI starting with http://www.w3.org/ns/odrl/2/) and an ontology covering a ODRL profile (= it covers all concepts defined by this profile, these concepts may be from the ODRL namespace, but also from other namespaces). This may raise the implicit requirement that a non-ODRL namespace used by a profile should have also its namespace-ontology.

Comments on details:

• Do we need a concept for the Core SKOS collection with the URI http://www.w3.org/ns/odrl/2/core in the ODDRL 2.2 namespace ontology?
• the dct:description "The ODRL Core Profile. Community Profiles can use this Core profile to extend and add new concepts." does not fit very well:
  a) a Community Profile has to complement the Core profile - the wording above sounds like a Community Profile can add concepts to the Core profile.
  b) the term Community Profile sounds good but we need its explanation on an ODRL CG page - the ODRL Recommendation does not use it.
• How members of the SKOS collection are defined: as skos:member odrl:Policy ; or as skos:member :uid ;
  I think the first syntax is correct, the second one is wrong as the default namespace of the ontology is http://www.w3.org/ns/odrl/2/core (row 2 of the document) and therefore the uid would have the URI http://www.w3.org/ns/odrl/2/coreuid - which is different from http://www.w3.org/ns/odrl/2/uid!
• This document does not include any concept definitions which is ok at a formal level (see my basic consideration above). But I suggest to add a note that all concepts can be found in the ODRL 2.2 ontology at https://www.w3.org/ns/odrl/2/ . (Another option is to copy and paste all Core concepts from the ODRL ontology into this Core profile ontology.)
• The ODRL CG page about profiles should mention/define that a SKOS collection is required to define all members of a profile.

[vroddon]

Hi, why https://www.w3.org/ns/odrl/2/ renders a poor HTML compared to https://www.w3.org/ns/odrl/2/ODRL21 ?? What Michael says about the rest looks reasonable... Víctor

…

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#7 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFLs5b-YqVbifcl2CSb3-jpopRDxsaJJks5ueIWogaJpZM4VwJZf>.

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

[ench0]

@vroddon do you know how are these 2 generated or where the source is rendered from? I have some experience in producing properly generated html/json so would like to help. Also noticed that https://www.w3.org/ns/odrl/2/ODRL22.json and https://www.w3.org/ns/odrl/2/ODRL21.json have completely different logic (21 incomplete?).

[nitmws]

@ench0 the ODRL 2.1 page was generated by a PHP script from the ontology, the ODRL 2.2 page not by the same PHP but some other script, @riannella may know the details.
The information model of ODRL 2.2 inherits many things from ODRL 2.1 but is not the continuous development, therefore the ontologies look different. Example: the Common Vocabulary of ODRL 2.1 including all terms defined for this version was split up into a normative Core vocabulary and a non-normative Common Vocabulary.

[riannella]

@nitmws Yes, all the members of the collection should have odrl: namespace (my copy/paste error).

Feel free to make those changes in your comments above...

[riannella]

I think that @iherman created the JSON from the Turtle using some common transform script...

[iherman]

@riannella I do not think so... The README file says "These files need to be manually maintained to keep up with changes:" (referring to xsd and json files).

:-(

[riannella]

The JSON context file is manually updated: https://www.w3.org/ns/odrl.jsonld

But the JSON ontology encoding at: https://www.w3.org/ns/odrl/2/ODRL22.json
is auto-generated from the ttl ??

[iherman]

Ah! Yes, I just (mis)used (I believe) an RDFLib based processor[1]: although the goal of this processor is to do an OWL RL processing, it can also be done without any OWL RL and simply as a format processor. AFAIK there are other syntax processors around, too.

[1] https://github.com/RDFLib/OWL-RL

[iherman]

Because, down the line, any updates on /ns has to be done by me, I also perform that step as part of it...:-)

[aisaac]

Hi everyone,
I've cross-referenced this issue from the DXWG work where we expect to be aligned with you.
But I must say that the discussion here is not so clear to me. Would it be possible to have a diagram that shows the relatioships between the Recommended part of ODRL, the Common Vocabulary, the Core Profile and the various (present and future) JSON-LD contexts and OWL ontologies that are floating around them? And how a more specific profile would extend (some of) them?

[nitmws]

Hi @aisaac , I'll create a diagram in the next days.

[nitmws]

As I just had some free time I've created a first attempt to visualize the relationships of ODRL Recommendation, vocabularies and profiles in this diagram

To clarify some details:

• All terms/concepts defined by the ODRL 2.2 Recommendation are members of the ODRL Core Vocabulary and of the ODRL Core Profile. All these concepts reside in the ODRL namespace
• The ODRL Common Vocabulary defines non-normative terms/concepts - which also reside in the ODRL namespace. (That comes from splitting up a single ODRL 2.1 vocabulary into two 2.2 vocabularies)
• ODRL profiles are defined in the Information Model, only 1 profile is normative: the Core Profile. An unlimited count of other profiles may be defined.
• Any other ODRL profile MAY use terms/concepts from 1 to many vocabularies.
• Any other ODRL profile MAY use terms/concepts from the ODRL Common Vocabulary
• Any other ODRL profile MUST NOT use terms/concepts from the ODRL Core Vocabulary/Profile
• Any other ODRL profile does not have to use any term/concept from the ODRL Common Vocabulary
• Namespaces have URIs as identifier, shown in the boxes of the diagram
• Vocabularies have URIs as identifier, shown in the boxes of the diagram, their members are defined by a SKOS Collection using this identifier
• Profiles have URIs as identifier, shown in the boxes of the diagram, their members are defined by a SKOS Collection using this identifier
• If all terms of a namespace are a member of a vocabulary the namespace and the vocabulary may use the same identifier (This was not deeply discussed before, I hope this is ok.)

[aisaac]

Thanks @nitmws ! The diagram helps a lot, it raises questions though:

• the box for ODRL 2.2 Recommendation (normative) looks as if it includes more than the ODRL Core Voc and Profile. You say in your github comment that "All terms/concepts defined by the ODRL 2.2 Recommendation are members of the ODRL Core Vocabulary and of the ODRL Core Profile". I guess this means that (1) ODRL 2.2 Rec doesn't include more than ODRL Core Voc and ODRL Core Profile; (2) Actually ODRL 2.2 Rec is exactly the elements of the Core Voc, as the Core Profile is a subset of the Core Voc (according to the diagram)

• in fact the diagram puzzles me a bit about the relationship between the Core Profile and the Core Voc: there are elements from the Core Voc that the Core Profile does not re-use?

• I'm surprised by "Any other ODRL profile MUST NOT use terms/concepts from the ODRL Core Vocabulary/Profile". And that the ABC Profile would be an ODRL profile (according to its URI) if it doesn't re-use either the core Voc/Profile, nor even the Common Voc?
  I've had expected something like
  "Any other ODRL profile MUST use terms/concepts from the ODRL Core Vocabulary/Profile".
  Or perhaps
  "Any other ODRL profile MUST use terms/concepts from the ODRL Core Vocabulary/Profile or the ODRL Common Vocabulary"

• doesn't the RightsML profile re-use elements from the Core Vocabulary (or Core Profile)?

[aisaac]

@nitmws told me he's going to be on holidays from tomorrow on, maybe I'm too late. I couldn't react earlier, sorry.
And sorry for the hijacking of the original thread with something that's growing bigger. I'm happy to create another ticket if people here think it's more appropriate.

[nitmws]

Thanks for your comments @aisaac

• re "the box ...": ok, I tried to make the boxes fit together tightly, apparently not tightly enough. Your conclusions are correct - and ODRL Core Profile has the same members as the ODRL Core Vocabulary.
• To improve the diagram I have created a slightly modified version:
  ODRL22-terms-grouping-MS_2018-10b.pdf
  Removing most of the written names and descriptions helps to set boxes more tightly inside an outer box to indicate: both boxes have the same members - but at a very precise level it is impossible to express this by a diagram - at some level of preciseness we need written statements.
  And I have changed the sequence of boxes: vocabularies are inside profiles now to express members of this vocabulary are also members of that profile (and profiles may have members of multiple vocabularies).
• re "in fact ...": I hope the new diagram helps
• Re "I'm surprised ...": a basic requirement of ODRL policies is: it uses implicitly the ODRL Core Profile, the URI of the Core Profile doesn't have to be applied to the profile property, but it may be applied. Creating an object which claims to comply with the ODRL 2.2 Recommendation implicitly requires the use of the ODRL Core Profile, as it includes e.g. the Policy, the Rules, the Assets ...
  Therefore any other ODRL profile needs to define only terms which are NOT in the ODRL Core Profile. In other words: other profiles always define terms in addition to the Core Profile.
  See https://www.w3.org/TR/odrl-model/#profile
• re "doesn't the RightsML ...": no, as it should not. See above.

My conclusion: we need a very precise Best Practice for creating ODRL profiles.

(From tonight on I'm away for holidays :-) )