Re: narrowerThan leftOperands

> On 2 Jun 2017, at 19:20, Michael Steidl (IPTC) <mdirector@iptc.org> wrote:
> 
> This posting raises again my not so feeling well about narrowerThan.
> -          First a formal note: I’ve downloaded the ODRL22.ttl files multiple times recently, today too, and versions from May and today show dct:issued "2017-05-17" but the contents are different!

Disregard the date in the actual ontology, as we always forget to update it :-)
Refer to the date that GitHub records.


> -          In other words: what makes odrl:narrowerThan different from skos:broader(Transitive)? 

I think the key difference is (and @Ivan and others  can chime in if I am wrong) is that skos:narrower is only used to assert a direct (i.e., immediate) hierarchical link between two SKOS concepts.

But in our case, we are asserting more than this. For example, when we say:
  odrl:stream odrl:narrowerThan odrl:use

Even though - conceptually - odrl:use is a direct hierarchical link to odrl:stream, skos:narrower does not capture the implications of this link.
That is, these terms are operational actions, and their linkage may mean that one invalidates the other (eg conflict detection).
(ie you are allowed to stream but prohibited to use)

Hence, odrl:narrowerThan asserts stronger semantic implications than skos:narrower (ie actions terms are more than just a hierarchy of concepts).


> -          It is also the wording I’m not happy about: it is common in the taxonomy community since many years to use “broader” (BT) for pointing from the terms with narrower semantics to the term with broader semantics – and “narrower” (NT) the other way round. Creating a term “narrowerThan” expressing in fact the same relationship as “broader” will not be understood by many people familiar with taxonomies and would be even misleading.’

Are you proposing we swap from narrowerThan to broaderThan?
(given that most ODRL Profiles will be defining narrower actions).

> -          Simple question: is it impossible to use skos:broader/skos:narrower for conflict detection?

No, I don't think so - see above example.

> … uuh, the LeftOperands are not in a skos:ConceptScheme! Therefore it does not work to use skos without any further specification.

Ok, we can make all the leftOperands also skos:Concepts

> An IPTC-internal discussion about ontologies let me dig into RDFS and OWL etc recently and with that background my feeling is that the design of the ODRL ontology is not very consistent:
> -          Why are operators and leftOperands an owl:namedIndividual of the classes Operator or LeftOperand while the actions are a skos:Concept and all actions make a skos:ConceptScheme?

I am not sure why!

> -          And the use of skos:Collections
> o   What exactly is their purpose (making a distinction between normative and non-normative makes sense)

We primarily use skos:Collection to create the groupings of terms for the specification document (used by the auto-script).


> o   The use of skos:member does not align with the SKOS specs:
> “The rdfs:range of skos:member is the union of classes skos:Concept and skos:Collection”
> … but in the assertion e.g. „<http://www.w3.org/ns/odrl/2/#constraints <http://www.w3.org/ns/odrl/2/#constraints>> skos:member :Constraint” the class :Constraint is definitely neither a skos:Cocept nor a skos:Collection making this “membership” invalid.

So, everything on the ODRL Ontology needs to be defined as a skos:Concept?

Renato