ODRL Ontology: formal definition and design issues

[nitmws]

Having a deeper look at the whole ODRL Ontology - http://w3c.github.io/poe/vocab/ODRL22.ttl as of 2 June - I noticed these issues:

1. Formal use of SKOS
   a) The atomic particles of SKOS are skos:Concepts and the containers skos:ConceptScheme or skos:Collection can include skos:Concepts only. Only the skos:Collection's #actions and #actionsCommon include skos:Concepts, all others don't include any - this is a bug.
   b) Use of skos:ConceptScheme (currently only actions are a Concept Scheme)
   b.1) ... requires that all concepts assigned to a scheme indicate that by using skos:inSchema. None of the actions does that - - this is a bug.
   b.2) the scheme :actions lists multiple concepts as skos:hasTopConcept. This is only right for :use and :transfer, all other concepts are narrower than one of these two and therefore not a TopConcept - this is a bug

2. hasPolicy property: a policy does NOT have a "target Asset" therefore the definition is wrong - and the rdfs:range :policy needs a better definition. (E.g. that the related Policy includes at least one Permission or Prohibition with this Asset as target.)

3. using both rdfs:Class and owl:Class as type. http://www.w3.org/TR/owl-rdf-based-semantics defines
   rdfs:Class rdfs:subClassOf owl:Class .
   My view: rdfs:Class only is sufficient.

4. using both rdf:Property and owl:ObjectProperty: http://www.w3.org/TR/owl-rdf-based-semantics defines
   rdf:Property rdfs:subClassOf owl:ObjectProperty .
   My view: rdf:Property only is sufficient.

5. Design of defining individuals
   Note: the SKOS specification makes a statement about "SKOS Concept Schemes and OWL Ontologies" - https://www.w3.org/TR/skos-reference/#L1170 - declaring a graph can be both, a SKOS Concept Scheme and an OWL Ontology.
   The SKOS Recommendation explains that SKOS Concept individuals are equivalent to OWL individuals - https://www.w3.org/TR/skos-reference/#L1045
   a) Why are only the ODRL-defined individuals of the Action class a skos:Concept and the individuals of the LeftOperand and Operator class are owl:NamedIndividuals? They all have the same role as individuals of a class. I propose to harmonise them - preferred: making them skos:Concepts.
   b) Currently ODRL defines for all individuals of Action a single Concept Scheme with the identifier http://www.w3.org/ns/odrl/2/actions. The normative and non-normative concepts are sorted out only by SKOS Collections with the IRIs http://www.w3.org/ns/odrl/2/#actions and http://www.w3.org/ns/odrl/2/#actionsCommon - these IRIs are very close to the scheme IRI. I propose to split them into 2 schemes: http://www.w3.org/ns/odrl/2/actionsCommon and to drop the use of Collections.
   c) For what purpose are skos:Collections used beyond the purpose above? If they should show the "building blocks" of a class they are not complete, e.g. http://www.w3.org/ns/odrl/2/#ruleConcepts includes only :Rule, :relation and :function - but no :permission, :prohibition or :constraint. And as pointed out above: the class and the properties are formally invalid in a SKOS Collection.

[vroddon]

using both rdfs:Class and owl:Class as type. http://www.w3.org/TR/owl-rdf-based-semantics defines
rdfs:Class rdfs:subClassOf owl:Class .
My view: rdfs:Class only is sufficient.

Whereas under OWL Full both owl:Class and rdfs:subClassOf are totally equivalent, OWL DL classes are subject to some restrictions that grant that some reasoning processes can be computed. I made the small experiment of implementing your proposal, and my reasoner apparently does not complain and says everything stays within low complexity. I also could not find additional discussions on the web about this, but in any case I'd be cautious. Any other opinion?

[vroddon]

using both rdf:Property and owl:ObjectProperty: http://www.w3.org/TR/owl-rdf-based-semantics defines
rdf:Property rdfs:subClassOf owl:ObjectProperty .
My view: rdf:Property only is sufficient.

My opinion is that this would not harm, but we would be at risk of underspecifying.
In two different implementations, I'd rather see either class individuals or literals as the values of my properties. I am in favor of keeping the distinction.

[riannella]

1. I agree - we need to assert all terms in the ODRL Ontology as skos:Concept
   (so that we can use the skos collections, and definition, note, etc)

I do not know why we have defined an "actions" skos:ConceptScheme ?
Why do we need to ?

2. The inference from using hasPolicy is that the asset you are describing/identifying is the target Asset of the identified policy (and makes no other assumptions about the policy..could be a Set, or empty or....)

3. I don't have an issue with both rdfs:Classs and owl:Class
   Nothing breaks, so lets leave it

4. We should use owl property types as well.

5a) Agree - see 1)

5b/c) We need skos:collections as that is used by the script to create the Vocab specification sections.

We can reorder any terms in any collection....

I am suggesting we drop the actions skos:ConceptScheme completely as I can't see who will use it?

commit: 3db6469

[larsgsvensson]

Regarding the use of rdfs:Class vs owl:Class I found this post by Antoine Zimmermann most helpful:
https://lists.w3.org/Archives/Public/public-sdw-wg/2016Nov/0069.html

[riannella]

Great: "My advice would be to type the classes using both rdfs:Class and owl:Class"

[nitmws]

Re rdfs:Class vs owl:Class
The not so nice statements by Antoine in the email were:
"OWL is a very complicated beast" and
"Warning: the explanations below are pretty long and detailed and brain damaging."

My conclusion: this group should have a focus on well formulated and correct free-text specifications, a thing like the OWL ontology could help experts but can't tell the story about ODRL to newbies.

[nitmws]

re @riannella 's comments:

re 1a) to narrow down "all terms": the individuals/instances of the classes Action, LeftOperand and Operator defined by ODRL - right?

re 1b, 5a, 5b) the use of SKOS Concept Scheme needs some practical considerations:

• it is a typical container of concepts making them a Controlled Vocabulary, taxonomy ...
• but how to organise it: a/ different containers for different groups of concepts or b/ a single container for all Concepts defined by ODRL and the grouping of sets of concepts with shared semantics could be done by SKOS Collections - this would fit the needs of the specification script
• ... but this script raises also strange things: to be able to show a list of e.g. Policy Subclasses or Party Functions in the free-text specifications the ODRL ontology needs to have a Concept Collection for both despite the members are no Concepts. This is formally wrong. The minimal action would be to wrap such Collections inside the ontology document with a clear comment that these Collections only exist for the purpose of generating the specification document but in terms of SKOS they are wrong.
• a practical facet of using Concept Scheme is to make all ODRL Concepts accessible: accessing a scheme should be the starting point for retrieving the data of all included concepts.

re 2) sorry again: a policy does NOT have a target asset, only Permission and Prohibition have one and a policy with 10 Permissions could have 10 different target assets. Therefore the current wording is wrong, we must define that at least one of the Permissions/Prohibitions (maybe we can focus the design on Permission, see #187 ) has this asset as target.

[riannella]

@nitmws I agree with your conclusion above - the ontology is something that a newbie would not look at (or should not ;-) until they are comfortable with understanding the Spec first.

In fact, the word "owl" does not even appear in any Vocab term in the Spec.

[riannella]

The Vocab spec does not mention anything about the SKOS "actions" ConceptScheme (for example).

I don't think we (even as the Community Group) understood what we wanted from SKOS :-(

Perhaps the best option is to remove the SKOS actions conceptScheme from the ontology and, if there is a demand, we create a NOTE on the proper SKOS-i-fication of ODRL ??

As for the current SKOS collections (use to drive the script to create the spec) - I think we label these as such operational collections, not so much a vocab collection ?
(can we use skos:hiddenLabel ?)

[riannella]

Re: 2) Sorry, understand now... will update to:

...the Asset being described/identified must be inferred to be the target Asset of the Rules of the Policy.

[nitmws]

@riannella ... be careful: "... be the target Asset of the Rules ..." will make people think that the Asset must be the target of all rules - but a single Rule in a Policy with this asset as target is sufficient.

[nitmws]

Re SKOS Concept Scheme / Collection:
The SKOS Collection specification - https://www.w3.org/TR/skos-reference/#collections - defines them as "SKOS concept collections are labeled and/or ordered groups of SKOS concepts." The spec does not require that the "collected" concepts are in a Concept Scheme. Therefore it is formally ok to use only Collection. (Informally I still think that for handing over a set of concepts a Concept Scheme is a better tool.)

Re skos:hiddenLabel: @riannella do you mean such labels applied to a formally incorrect Collection should tell "Do not formally validate this Collection"?

[riannella]

1. hasPolicy -> we can't tell how many Rules there are in the Policy. So we can only say the Asset is the target for all the Rules. Will update narrative.

2. So technically we are using skos:collection correctly ;-)
   I added some ## comments just before the skos:collections.
   And removed the "actions" ConceptScheme (as we have no skos hierarchy defined for them).

commit 385734b

[vroddon]

I fully agree with Antoine about " My advice would be to type the classes using both rdfs:Class and owl:Class and to try to keep things within OWL 2 DL because in most cases" Víctor El 07/06/2017 8:23, Michael Steidl escribió:

…

Re rdfs:Class vs owl:Class The not so nice statements by Antoine in the email were: "OWL is a very complicated beast" and "Warning: the explanations below are pretty long and detailed and brain damaging." My conclusion: this group should have a focus on well formulated and correct free-text specifications, a thing like the OWL ontology could help experts but can't tell the story about ODRL to newbies. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#188 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFLs5RIEgNFvhxqwKKUHRVNUQsdUqF7rks5sBkHcgaJpZM4NvcRp>.

-- Víctor Rodríguez-Doncel D3205 - Ontology Engineering Group (OEG) Departamento de Inteligencia Artificial Facultad de Informática Universidad Politécnica de Madrid Campus de Montegancedo s/n Boadilla del Monte-28660 Madrid, Spain Tel. (+34) 91336 3672 Skype: vroddon3

[nitmws]

I come back to the hasPolicy definition: despite it is not defined anywhere explicitly a Policy must have at least one Rule, this is what can be said about a Policy. And that at least one of the Rules has the entity using hasProperty as target asset.
I'm aware that potential ODRL/RightsML users want to keep the number of Policies low, the restriction that all Rules have to use the entity as target asset would increase this number.

[simonstey]

despite it is not defined anywhere explicitly a Policy must have at least one Rule, this is what can be said about a Policy.

it's stated explicitly (but weirdly formulated) in http://w3c.github.io/poe/model/#policy :

A Policy must include the permission and/or prohibition Rule. (See the Permission and Prohibition sections for more details.)

[nitmws]

... I've read that statement, but an explicit statement with a weird formulation does not fit.
Better would be "A Policy must include at least one permission and/or prohibition Rule."

[riannella]

We define the term Policy here:
https://w3c.github.io/poe/model/#terminology

and here:
https://w3c.github.io/poe/vocab/#term-Policy

@nitmws - is that ok?

[simonstey]

@nitmws - is that ok?

it's actually not.. according to:

Policy -> A non-empty group of Permissions and/or Prohibitions

following ODRL policy of type Set doesn't qualify as a Policy anymore:

<http://example.com/set:notapolicyanymore> 
    a odrl:Set ;   
    odrl:duty <someduty> .

Long story short
-> "A Policy must include at least one Rule."
-> "Policy = A non-empty group of Rules" (I'm kinda missing hints to additional stuff like conflict/inheritance etc. here)

[riannella]

So you propose to update the definition of Policy (discussed in #74) to "A Group of Rules"?

Then we need to agree on how to deal with:

A Duty must only be associated with a Permission.

[simonstey]

Then we need to agree on how to deal with:
A Duty must only be associated with a Permission.

this part needs to be fixed anyway, as duties can be associated with policies too if respective policies are of type odrl:Set.

I would suggest to delete this sentence as a whole.

[riannella]

Are you saying that with a Set, you can have a single Duty, but with Offer and Agreement, a Duty must be with a Permission..or...a Duty can be with any Policy?

[simonstey]

the former.

a duty must have at least one Rule

all other types can only have perm/proh

duties can be used with both policies and perms (unless the policy type prohibts it)

[riannella]

Also being discussed at #162

[riannella]

Will be addressed by outcome of #162