Closed nitmws closed 3 years ago
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:
odrl:use
and odrl:transfer
, and non-normative Things from the Common Vocabulary, like the action odrl:play
.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:
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 "Non-Normative"@en 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 https://github.com/w3c/odrl/issues/7#issuecomment-411059491, 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
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)
@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:
A validator could check then:
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
I will create the core ontology and send to group for comment
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 !
I have just read it. Looks good.
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???
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...
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:
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 https://github.com/w3c/odrl/issues/7#issuecomment-423891629, 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
@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?).
@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.
@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...
I think that @iherman created the JSON from the Turtle using some common transform script...
@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).
:-(
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 ??
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.
Because, down the line, any updates on /ns has to be done by me, I also perform that step as part of it...:-)
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?
Hi @aisaac , I'll create a diagram in the next days.
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:
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)?
@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.
Thanks for your comments @aisaac
My conclusion: we need a very precise Best Practice for creating ODRL profiles.
(From tonight on I'm away for holidays :-) )
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:
A confusing detail: the ODRL context document includes many of the actions listed in the ODRL Common Vocabulary but not all ...