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

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

From: Stephen Bounds <km@bounds.net.au>
Date: Wed, 30 Jul 2008 07:27:57 +1000
Message-ID: <488F8B5D.4090201@bounds.net.au>
To: public-esw-thes@w3.org

My 2 cents,

I'm fully in favour of the change to <skos:broader> and
<skos:broaderTransitive>.

I actually believe that <skos:broader> and <skos:broaderTransitive> 
capture the BT and NT relationships expressed in most LCSH-style
thesauri *better* than the previous schema.

For example, the following thesaurus entries:

FURNITURE/FURNISHINGS
     NT FURNITURE
     NT HAMMOCK

FURNITURE
     BT FURNITURE/FURNISHINGS
     NT BED

BED
     RT HAMMOCK
     BT FURNITURE

HAMMOCK
     RT BED
     BT FURNITURE/FURNISHINGS

simply map in SKOS as:

<skos:Concept 
rdf:about="http://www.example.com/concepts#furniture-furnishings">
   <skos:prefLabel>furniture/furnishings<skos:prefLabel>
   <skos:narrower>furniture</skos:narrower>
   <skos:narrower>hammock</skos:narrower>
</skos:Concept>

<skos:Concept rdf:about="http://www.example.com/concepts#furniture">
   <skos:prefLabel>furniture<skos:prefLabel>
   <skos:broader>furniture/furnishings</skos:broader>
   <skos:narrower>bed</skos:narrower>
</skos:Concept>

<skos:Concept rdf:about="http://www.example.com/concepts#bed">
   <skos:prefLabel>bed<skos:prefLabel>
   <skos:related>hammock</skos:related>
   <skos:broader>furniture</skos:broader>
</skos:Concept>

<skos:Concept rdf:about="http://www.example.com/concepts#hammock">
   <skos:prefLabel>hammock<skos:prefLabel>
   <skos:related>bed</skos:related>
   <skos:broader>furniture/furnishings</skos:broader>
</skos:Concept>


I think everyone would agree that this is a simple and logical 
translation of the existing non-XML thesaurus syntax.  The only trick is 
that when searching for ancestor terms, the correct OWL term is the 
broaderTransitive predicate, i.e.


   bed skos:broaderTransitive ?x

     returns

   x
   ==
   furniture
   furniture/furnishings

or

   furniture/funishings skos:narrowerTransitive ?x

     returns

   x
   ==
   furniture
   bed
   hammock


While it's true that this requires some inferential "smarts" to be built 
into a SKOS interpretation engine, this would be true of any recursive 
lookup facility, and this method allows the creation of an RDF graph 
that cleanly separates "assertions" (<skos:broader>) from "inferences" 
(<skos:broaderTransitive).

Regards,

-- Stephen.

Antoine Isaac wrote:
> 
> Hi Bernard,
> 
> Thanks for this contribution, which renews the debate
> 
> There are three problems which make me feel reluctant towards it:
> 
> 1: even if you try to hide it under the carpet by changing the naming 
> policy, there will still be people who will go and check under the 
> carpet ;-) . And complain about a transitive super property having a sub 
> property that can be not transitive. That was what Andrew did, basically.
> 
> 2: you propose to use broader and minimalBroader, anf have 
> minimalBroader computed. But if broader is also computed (which is the 
> case if it is transitive) then we just have computed properties, and it 
> is less easy to find asserted relations back.
> Note by the way that I have met vocabularies for which the asserted 
> broader does not match your 'minimal' one. I know that these are 
> borderline examples. But they were introduced for UI reasons (for more 
> natural browsing), and as one important scenario for using SKOS to 
> represent KOS is navigation in concept spaces, I'd be uncomfortable with 
> ruling out that kind of considerations...
> 
> 3. I'm afraid the formal definition of the minimal broader will not be 
> intuitive, and further, difficult to implement in OWL (I've not thought 
> about it, but it might even be impossible)... You'd have to go via a 
> SPARQL query: that's not an ultimate case of rejection (there are 
> already a few similar things in SKOS), of course, but that does not help.
> 
> I don't know if that convinces someone, but well these were my two cents.
> 
> Cheers,
> 
> Antoine
> 
> 
>> Hello all
>>
>> Since this issue is back on the table, let me put here a (hopefully 
>> clear) proposal based on both the general "natural understanding" of 
>> broader and narrower, and its formal mathematical interpretation as 
>> "strict partial orders".See 
>> http://en.wikipedia.org/wiki/Partially_ordered_set#Strict_and_non-strict_partial_orders 
>>
>> Seems to me that there are backward compatibility, terminology, hence 
>> marketing issues here, beyond logical foundationn of the concepts. If 
>> "broader" and "narrower" do not convey the most intuitive semantics, 
>> we're bound to endless misunderstandings and have to explain again and 
>> again why it is specified in such a counter-intuitive way. People will 
>> buy more easily "closeRelative" defined as a subproperty of "relative" 
>> than "relative" being defined as a subproperty of "generalRelative", 
>> with small prints explaining that "relative" means actually "direct 
>> relative".
>>
>> Her is my proposal
>>
>> skos:broader and skos:narrower are the most generic relationships. 
>> They are irreflexive and transitive (in other words, they define 
>> strict partial orders).
>> It's bound to applications to figure how they implement the 
>> transitivity (asserted vs computed triples).
>>
>> skos:maximalNarrower  and  skos:minimalBroader  are used to define 
>> "direct" narrower and broader concepts
>>
>> A "minimalBroader" of X is indeed mathematically defined as being a 
>> minimal element, relative to the broader relationship, of the set of 
>> all broader concepts of X.
>> http://en.wikipedia.org/wiki/Minimal_element
>>
>> In other words    (X   skos:minimalBroader   Y)
>> iff    (X   skos:broader   Y)
>>    AND
>>    {Z | (X   skos:broader   Z) and (Z   skos:broader  Y)} is the empty 
>> set
>>
>> Similar definition for skos:maximalNarrower
>>
>> By definition :
>> skos:minimalBroader      rdfs:subPropertyOf       skos:broader
>> skos:maximalNarrower      rdfs:subPropertyOf       skos:narrower
>>
>> Although it conveys under different names the same idea as 
>> skos:broader   rdfs:subPropertyOf    skos:broaderTransitive, I think 
>> it's easier to swallow because of the names.  :-)
>>
>> Now something very important, and orthogonal to the terminological 
>> debate: the sets of minimalBroader and maximalNarrower concepts of a 
>> given X can only be entailed from the set of broader and narrower 
>> concepts *in a closed world*. IOW in a well-defined RDF graph (e.g. 
>> inside a declared Concept Scheme).
>> Actually the declaration of skos:minimalBroader or 
>> skos:maximalNarrower does not make much sense in an open world, where 
>> they can be easily be made inconsistent : one can always insert some 
>> concept between X and Y. The notion of empty set does not apply to an 
>> open world.
>>
>> So the recommandation could be that those properties should not be 
>> *declared* in vocabularies, but *computed* as necessary on the basis 
>> of available assertions at run time, that is, in the closed world of 
>> assertions available here and now.
>>
>> Bernard
>>
>> Antoine Isaac a écrit :
>>>
>>> Dear Andrew,
>>>
>>>> It also seems to me that there is a problem with this flip/flop of 
>>>> skos:broader and skos:narrower being transitive.  SKOS now specifies 
>>>> skos:broader and skos:narrower to be non-transitive, but 
>>>> skos:broaderTransitive and skos:narrowerTransitive are a 
>>>> sub-property of skos:broader and skos:narrower respectively.  This 
>>>> implies to me, not being an RDF/OWL expert, that 
>>>> skos:broaderTransitive and skos:narrowerTransitive inherit 
>>>> non-transtivity from skos:broader and skos:narrower respectively, 
>>>> and that just seems funky since you are saying that the relationship 
>>>> is transitive.
>>>>
>>>
>>> The problem of transitivity "inheritance" (or more precisely 
>>> non-inheritance) problem has been many times raised, and many mails 
>>> have been written about it.
>>> Cf http://lists.w3.org/Archives/Public/public-swd-wg/2008Jun/0102.html
>>>
>>> Now, I'm afraid we cannot do otherwise. Whatever being the naming 
>>> decisions in the end:
>>> - there is need non-transitive "broader-as-asserted" property 
>>> (skos:broader)
>>> - there is a need for a transitive "broader-as-get-me-all-ancestors" 
>>> (skos:broaderTransitive)
>>> - there is a need to infer that every asserted direct broader 
>>> statement shall be interpreted in a way that allows to get a 
>>> transitive version of the hierarchy (I assume that you too have this 
>>> requirement)
>>> And for the third you have no choice but to declare the first 
>>> property a subproperty of the second. That's just the way OWL is 
>>> made, even if it may appear counter-intuitive :-(
>>> The nice thing is that in OWL doing so does not enforce skos:broader 
>>> to be transitive...
>>>
>>> Best,
>>>
>>> Antoine
>>>
>>>
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus 
>>> Database: 270.5.6/1577 - Release Date: 28/07/2008 06:55
>>>
>>>
>>>
>>
> 
> 
> 
> 
Received on Tuesday, 29 July 2008 21:28:29 GMT

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