RE : [SKOS] the return of transitive and subproperty (was Re: SKOS comment: change of namespace (ISSUE-117)) from Antoine Isaac on 2008-07-31 (public-esw-thes@w3.org from July 2008)

From: Antoine Isaac <Antoine.Isaac@KB.nl>
Date: Thu, 31 Jul 2008 10:10:50 +0200
To: "Stephen Bounds" <km@bounds.net.au>, <public-esw-thes@w3.org>
Message-ID: <68C22185DB90CA41A5ACBD8E834C5ECD04953E0D@goofy.wpakb.kb.nl>
Dear Stephen,

Just to be sure, when you're in favor "of the change to <skos:broader> and <skos:broaderTransitive>", that means that you're in favour of the current SKOS version, as opposed to the previous (2005) one?

As some people in this thread have proposed to make various changes to these two properties, everything gets a bit confused ;-)

The current version of SKOS has skos:broader represent the asserted statement, and skos:broaderTransitive represent the infered hierarchy, as you describe it in your queries.
So the current version should fit your needs...

Best

Antoine


-------- Message d'origine--------
De: public-esw-thes-request@w3.org de la part de Stephen Bounds
Date: mar. 29/07/2008 23:27
À: public-esw-thes@w3.org
Objet : Re: [SKOS] the return of transitive and subproperty (was Re: SKOS   comment:  change of namespace (ISSUE-117))
 

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 Thursday, 31 July 2008 08:15:55 UTC