RE: narrowerThan leftOperands

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!

-          The ODRL22.ttl (of today) defines that :actions are a skos:ConceptScheme. By that definition all SKOS relationships (object properties) can be applied to the concepts of this scheme.

-          :use and :transfer (the two normative actions) are both defined a skos:Concept.

-          All the other actions are also defined as a skos:Concept

-          So I see no reason why not to use skos relationships like skos:broader, skos:narrower or skos:broaderTransitive and skos:narrowerTransitive

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

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

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

 

I propose to use only skos object properties for defining narrower and broader relationships between ODRL actions and …

 

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

:absoluteSpatialPosition

                a :LeftOperand, owl:NamedIndividual ;

                rdfs:isDefinedBy odrl: ;

                skos:broaderTransitive :absolutePosition;

                rdfs:label "Absolute Spatial Asset Position"@en ;

                skos:definition "The absolute spatial positions of four corners of a rectangle on a 2D-canvas or the eight corners of a cubiod in a 3D-space the Asset has to fit in after the Action."@en ;

                skos:note "Example: May be used with a natural language contract saying the the upper left corner of a picture may be constrainted to a specific position of the canvas rendiering it. Note: see also the Left Operand Relative Spatial Asset Position. "@en ;

   skos:scopeNote "Non-Normative"@en .

 

… as the class LeftOperand is an rdfs:class rdfs:label can be used, but not skos:…

(Note: SKOS object properties could be added to the LeftOperand class – but then let’s make it a skos:Concept too)

 

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?

-          And the use of skos:Collections

o   What exactly is their purpose (making a distinction between normative and non-normative makes sense)

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> skos:member :Constraint” the class :Constraint is definitely neither a skos:Cocept nor a skos:Collection making this “membership” invalid.

 

These are tripwires I stumbled across, I don’t claim they are the only ones.

 

Best,

Michael

 

 

From: Renato Iannella [mailto:renato.iannella@monegraph.com] 
Sent: Friday, June 2, 2017 7:04 AM
To: POE WG <public-poe-wg@w3.org>
Subject: narrowerThan leftOperands

 

We have discussed “odrl:narrowerThan” Actions (to form a hierarchy and for conflict detection) which we now have added support for.

(which will replace the current skos:broaderTransitive property in the ontology for Actions.)

 

We also have a hierarchy in the Constraint Left Operands:

  https://w3c.github.io/poe/vocab/#constraintLeftOperandCommon

 

Such as:

  :absoluteSpatialPosition skos:broaderTransitive :absolutePosition;

 

We have 3 options now:

1 - re-use odrl:narrowerThan

2 - define a a new property

3 - keep using skos

 

We will not be evaluating Left Operands for conflict detection, so the relationship we are expressing is less critical (and more “semantic”).

 

I recommend we keep using skos for Left Operand relationships.

 

Comments and views?

 

Renato Iannella, Monegraph

Co-Chair, W3C Permissions & Obligations Expression (POE) Working Group