Re: narrowerThan leftOperands

> On 5 Jun 2017, at 10:39, Michael Steidl (IPTC) <mdirector@iptc.org <mailto:mdirector@iptc.org>> wrote:
> 
> Hi Ivan, Renato and all,
> 
> First about the semantics of narrowerThan: its current specification in the Information Model is “The narrowerThan property defines vertical relationships between Actions, and the implies property defines horizontal relationships between Actions.” “Vertical relationship” is defined as e.g. “The hierarchical relationship of the whole to its parts and the parts to the whole” (MARC 21). And SKOS defines skos:broader and skos:narrower as “used to assert a direct hierarchical link between two SKOS concepts”.
> What does the ODRL specification tell more than the SKOS definition??
> So if this property should tell more than the SKOS properties then we need an extended, more explicit definition.

I fully agree with this. As far as I could see and understand the intention, the more explicit, operational definition should be given, with an underpinning by the formal semantics' considerations. But my feeling was that such additional definition is, or will be provided.

> 
> Re what terms to be used (parts of that were in Renato’s email, skipped by Ivan): The statement “Hence, odrl:narrowerThan asserts stronger semantic implications than skos:narrower (ie actions terms are more than just a hierarchy of concepts)” already shows the problem, in terms of semantics odrl:narrowerThan and skos:broader have to be matched!
> I suggest to combine the hierarchical direction and the (basic) term as defined by SKOS and similar systems:
> odrl:stream odrl:broaderAction odrl:use .
> odrl:user odrl:narrowerAction odrl:stream .
> 
> Re Ivan’s note about SKOS:
> That sounds a bit like  “mindset A against mindset B”
> 
> IPTC has decided to adopt SKOS for all of its about 200 vocabularies in 2014 and we didn’t run into troubles since then.
> (The IPTC News Architecture has been built using the idea of Concepts already 10 years ago, adopting SKOS was more a change in managing concepts than a change in thinking.)
> And IPTC has three basic types of concepts:
> -          For categorizing news content, like the Media Topics (http://cv.iptc.org/newscodes/mediatopic/ <http://cv.iptc.org/newscodes/mediatopic/>) or Genre (http://cv.iptc.org/newscodes/genre/ <http://cv.iptc.org/newscodes/genre/>)
> -          For reflecting technical/functional features, like audio codecs (http://cv.iptc.org/newscodes/audiocodec/ <http://cv.iptc.org/newscodes/audiocodec/>) or the Publishing Status (http://cv.iptc.org/newscodes/pubstatusg2/ <http://cv.iptc.org/newscodes/pubstatusg2/>)
> -          For refining/adjusting the semantics of a statement by an IPTC news exchange format. Examples: refined semantics of a description property (http://cv.iptc.org/newscodes/descriptionrole/ <http://cv.iptc.org/newscodes/descriptionrole/>), type of the party being the triple-object with infoSource as predicate (http://cv.iptc.org/newscodes/infosourcerole/ <http://cv.iptc.org/newscodes/infosourcerole/>)
> All are managed as generic Concept, how a set of concepts (defined as scheme) impacts a statement is defined by the specification of the news exchange format (usually be the spec of the property). And we have to be aware: not all details of an ontology design can be directly serialized into XML or JSON, having a child property or attribute with a value from a concept scheme is a good solution in many cases.
> By my experience ontologies help to define the relationships between Things but to define OWL is the only language which can be used to define relationships and thinking in terms of Concepts is nonsense is disagreed by me.

As I said in my previous mail: if there are historical reasons (or similar) then it is fine with me. What you describe about IPTC's decision is good enough for me:-)

Ivan


> 
> (Now I’m away from my computer – excuse not to join the call today, it’s a sunny holiday here in Vienna.)
> 
> Best,
> Michael
> 
> From: Ivan Herman [mailto:ivan@w3.org <mailto:ivan@w3.org>]
> Sent: Monday, June 5, 2017 9:24 AM
> To: Dr. Renato Iannella <renato.iannella@monegraph.com <mailto:renato.iannella@monegraph.com>>
> Cc: W3C POE WG <public-poe-wg@w3.org <mailto:public-poe-wg@w3.org>>
> Subject: Re: narrowerThan leftOperands
> 
> Hi Renato,
> 
> <skip>
> 
> 
>> 
>> 
>>> -          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).
> 
> That is absolutely correct. The SKOS relations do not carry any further semantics beyond stating them, and we need more than those. Because we want to attach an additional, and very specific semantics to the relationship, we need a distinct on.
> 
> Let me be, actually, very heretic here (I was not part of the original ODRL discussions, remember?): I wonder what the embedding of ODRL into SKOS term bring us in the first place. SKOS is perfect for, say, library related vocabularies (this was one of the primary inspirations for SKOS after all), but for a more, say, "operational" vocabulary like ODRL I fail to see the advantage of having them. On the other hand, it seems to complicate the ontology.
> 
> I am not against keeping SKOS if the majority of the group wants to keep it (for, e.g., historical reasons), but I think it is a valid question…
> 
> Ivan
> 
> P.S. I hope Antoine will still accept to talk to me after this remark:-)
> 
> ----
> Ivan Herman, W3C
> Publishing@W3C Technical Lead
> Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>

----
Ivan Herman, W3C
Publishing@W3C Technical Lead
Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>