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

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:


     NT BED


     RT BED

simply map in SKOS as:


<skos:Concept rdf:about="http://www.example.com/concepts#furniture">

<skos:Concept rdf:about="http://www.example.com/concepts#bed">

<skos:Concept rdf:about="http://www.example.com/concepts#hammock">

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




   furniture/funishings skos:narrowerTransitive ?x



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" 


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:45:49 UTC