Re: SKOS transitive hierarchical relations

Constructing BT/NT relations from the Transitive expansions, is like 
reconstructing the causes from the effects.

In this case, you need to be absolutely sure to have ALL transitive 
relations to be able to discover the basic BT/NT relations.
Rather hefty and error prone.
It happens too often that existing thesaurus management software 
produces "SKOS files" too far from "regular practices":
http://en.thesaurus.gc.ca/EAEAD1E6-7DD2-4997-BE7F-40BFB1CBE8A2/CST20111208.rdf

May be we need some "application profiles" for SKOS, one being for the 
exchange of controlled vocabularies without ontological considerations 
(a.k. without need for a reasoner).

CKAN is doing a nice job for LinkedData, SKOS should have a similar 
approach (eventually integrated in CKAN framework).
I am trying to this with JITA using SKOS and VoID...
http://thedatahub.org/dataset/jita

Am I right to think that SKOS without some kind of "management" 
(validation tools, directory, search engine, best practices discussions, 
etc.) will not achieve interoperability of controlled vocabularies?

WISHING A VERY NICE 2012 TO ALL SKOSTCH ADDICTS!

Christophe

Le 4/01/2012 17:24, Christian Mader a écrit :
> Hi Antoine!
>
> Thanks for clarifying this! I found thesauri defining concepts related 
> only with skos:broaderTransitive (and not with skos:broader) in the 
> SKOS output of some proprietary thesaurus management tool. Also, I 
> could spot some resources (like http://umbel.org/umbel/rc/Delicacy.rdf 
> and http://lod.geospecies.org/ses/lEGJh?format=rdf) that only assert 
> transitive hierarchical relations.
> This might just be "outdated" or incomplete datasets, nevertheless 
> they brought up the question. I think I will need to search for more 
> examples in other publicly available vocabularies.
>
> Christian
>
> On 01/04/2012 03:26 PM, Antoine Isaac wrote:
>> Hi Christian,
>>
>>
>>>
>>> Based on the discussions on this mailing list and the SKOS
>>> reference/model documentation, my understanding of the
>>> broader/narrower properties is that it is up to the application
>>> (processing a SKOS vocabulary) to interpret the hierarchical
>>> properties skos:broader and skos:narrower as transitive or not. Thus I
>>> can understand why "By convention, skos:broaderTransitive is not used
>>> to make assertions" (from the SKOS ontology).
>>> However, there are vocabularies published on the Web that relate their
>>> concepts using only skos:broaderTransitive (and not skos:broader).
>>> Although these are valid statements, I wonder if, for interoperability
>>> reasons, these vocabularies should additionally include skos:broader
>>> relations alongside with the already contained skos:broaderTransitive
>>> relations.
>>> This way, e.g., SPARQL queries involving SKOS vocabularies of
>>> different origin, might return a more complete result set if relying
>>> on the convention mentioned above and only query for skos:broader.
>>> Would it be, in your opinion, a useful feature for a thesaurus
>>> management software to detect concepts that are only related by
>>> skos:broaderTransitive and notify the user whether to automatically
>>> add the skos:broader relation?
>>
>>
>> In fact having thesauri published with only skos:broaderTransitive (and
>> not skos:broader) is quite bad practice. Where have you seen this?
>>
>> Indeed, the original idea is that the vocabulary providers would start
>> publish assertions with skos:broader/narrower.
>> Then broader/narrowerTransitive statements could be infered, and
>> materialized either by the thesaurus publisher or by a data consumer.
>> Note that there is no real interpretation freedom here. The transitive
>> properties are defined as super-properties of the unspecified ones. This
>> means that everytime you have a skos:broader statement between two
>> concepts, the semantics of SKOS imply that there is a
>> skos:broaderTransitive statement holding as well.
>> There is some more detail on this kind of inference at
>> http://www.w3.org/TR/skos-primer/#sectransitivebroader.
>>
>> I hope this helps,
>>
>> Antoine
>>
>>
>

Received on Wednesday, 4 January 2012 16:49:22 UTC