W3C home > Mailing lists > Public > public-esw-thes@w3.org > July 2008

RE: RE : [SKOS] the return of transitive and subproperty (was Re: SKOS comment: change of namespace (ISSUE-117))

From: Antoine Isaac <Antoine.Isaac@KB.nl>
Date: Thu, 31 Jul 2008 18:00:50 +0200
Message-ID: <68C22185DB90CA41A5ACBD8E834C5ECD04953E0E@goofy.wpakb.kb.nl>
To: "Simon Spero" <ses@unc.edu>, "Stephen Bounds" <km@bounds.net.au>
Cc: "SKOS" <public-esw-thes@w3.org>
Yes, but it would not be good practice not to inference.
If we specify semantics of SKOS, that's precisely to tell users what they should expect from published SKOS data. Or what they know how they are allowed to interpret the data safely.
And not "what they could interpret from the data at their own risk, because the data publisher did not really intend its data to be interpreted according to the SKOS semantics (and himself does not, indeed)"

So *if broader was transitive* and if Stephen had published "A broader B" and "B broader C", then anyone could tell that Stephen has also published the information "A broader C". Which is not what Stephen wants.

Antoine

-------- Message d'origine--------
De: Simon Spero de la part de Simon Spero
Date: jeu. 31/07/2008 16:10
: Stephen Bounds
Cc: Antoine Isaac; SKOS
Objet : Re: RE : [SKOS] the return of transitive and subproperty (was Re: SKOS   comment:  change of namespace (ISSUE-117))
 
If you don't inference all you will see are the direct links; it's an  
application specific inferencing issue. Polly hierarchy doesn't affect  
this (see Soergel , etc

If all links are BT, it must be the case that everything about Emus  
must be about Animals. Otherwise at least one link on the path *must*  
be associative.

Simon

Sent from my iPhone

On Jul 31, 2008, at 9:43 AM, Stephen Bounds <km@bounds.net.au> wrote:

> G'day Simon,
>
> I understand what you're saying, but that is not really my objection.
>
> If someone wants to implement a polyhierarchical thesaurus, then  
> this kind of structure is quite common:
>
>       Animals
>          |
>          |
>        Birds
>         |  \
>         |   \
>         |   Australian Birds
>         |    |       |
>         |    |       |
>        Cockatoos    Emus
>
> If <skos:broader> is non-transitive, then there is a single,  
> unambiguous way to represent this hierarchy.
>
> But if <skos:broader> is transitive, then asserting
>
>  Cockatoos skos:broader Birds
>
> does *not* tell us whether the author intends a direct link between  
> Cockatoos and Birds in the hierarchy.
>
> Now, from a semantic reasoning point of view, the presence or  
> absence of this parent-child link is irrelevant:  'Birds' is broader  
> than 'Cockatoos' in either case.
>
> But it's *not* irrelevant in terms of how the thesaurus gets  
> presented to an end-user, and that's precisely my point.
>
> Regards,
>
> -- Stephen.
>
> Simon Spero wrote:
>> Stephen-
>> If you aren't using a reasoner, then you don't need to start doing  
>> so to introspect and undo the effects of using... a reasoner.
>> If you are working with an rdf suite like Redland, and don't hook  
>> it up to an inference engine, you just get the direct assertions.
>> You don't have to draw every conclusion entailed by ones knowledge  
>> base; the black lump lying on my feet is ki-chan. I do not need to  
>> access the fact that he is a eukaryote to know he's being friendly  
>> because he wants second breakfast; I only need to know that he's a  
>> cat.
>> It's when you *publish* data that you need to take care not to use  
>> hierarchical relations in cases where the link is not truly  
>> hierarchic.
>> Simon
>> Sent from my iPhone
>> On Jul 31, 2008, at 5:22 AM, Stephen Bounds <km@bounds.net.au> wrote:
>>>
>>> Hi Antoine,
>>>
>>> Yes, I am in favour of the current SKOS version.
>>>
>>> I strongly believe SKOS is most likely to see broad uptake if  
>>> people *don't* need SPARQL or some other RDF query dialect to do  
>>> useful things with it.
>>>
>>> Cheers,
>>>
>>> -- Stephen.
>>>
Received on Thursday, 31 July 2008 16:01:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:39:00 GMT