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 22:28:20 +1000
Message-ID: <48905E64.3090306@bounds.net.au>
To: SKOS <public-esw-thes@w3.org>

One other observation which may or may not be accurate from the point of 
view of the broader SKOS community.

I've always seen SKOS as being primarily a tool for vocabulary 
representation, *not* as a universal semantic reasoning tool.

In other words, the goal of SKOS is to to accurately represent a 
thesaurus-like hierarchy in an easily understood manner using a common 
XML dialect.

So I think having to do something like this:

 > 1. Declare only the direct broader assertions
 > 3. Compute the transitive closure of broader
 > 4. Compute the minimalBroader for each concept
 > 5. Check if 4. matches 1.

just to establish a parent-child relationship between nodes in the 
hierarchy greatly compromises the effectiveness of SKOS as a simple, 
expressive, declarative language.

At the moment in SKOS, I can establish the parents and children of a 
node by doing a simple XPath test on <skos:broader> and <skos:narrower>. 
  I don't want to lose that by reverting <skos:broader> back to a 
transitive property.


-- Stephen.

Bernard Vatant wrote:
> Hi Antoine
> Antoine Isaac a écrit :
>> Hi Bernard,
>> Thanks for this contribution, which renews the debate
>> There are three problems which make me feel reluctant towards it:
> I'll try to addres them all :-)
>> 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.
> I don't want to hide things under the carpet, simply avoid to present 
> them with a counter-intuitive, misleading vocabulary. It has nothing to 
> do with SKOS or OWL or anything, but with definition of transitivity and 
> subproperties, that a subproperty of a transitive property is generally 
> not transitive. It does not have to be hidden, but explained, and not 
> obfuscated by the terminology. An it's easy to explain on simple 
> examples provided the vocabulary is not misleading. Anybody in its right 
> mind will understand without problem that "ancestor" is transitive, that 
> "grandmother" is a subproperty of "ancestor", but that "grandmother" is 
> not transitive!
> So why is the "broader" and "broader transitive" terminology 
> counter-intuitive? Because the general "natural" understanding of a 
> qualifier (here, "transitive") is that it conveys a restriction, not a 
> generalisation. People understand naturally that "emerald green" is a 
> specification (subproperty) of "green". Suppose you decide to use 
> "green" for some specific shade of green (like emerald) and use "general 
> green" for the more general colour, and then declare that "green" is a 
> specification of "general green", people would be generally confused.
>> 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.
> That's a stronger argument. But it's the same case with any asserted vs 
> computed assertions situation, and RDF stotes have now tools to mark 
> triples by their source.
> OTOH most of the time I think computing will find out that the 
> 'minimalBroader' are the originally asserted 'broader'. Or if not, will 
> point at redundancy in original assertions
> Try on the following example
> :cats      BT    :mammals
> :cats      BT      :pets
> :mammals   BT   :animals
> :pets      BT      :housewares 
> You'll certainly rarely find the following directly asserted ...
> :cats      BT    :animals
> So I could change the recoomendation in :
> 1. Declare only the direct broader assertions
> 3. Compute the transitive closure of broader
> 4. Compute the minimalBroader for each concept
> 5. Check if 4. matches 1.
>> Note by the way that I have met vocabularies for which the asserted 
>> broader does not match your 'minimal' one. 
> The above computing can pinpoint those exceptions. And then up to the 
> vocabulary manager to figure if they are bugs or features ...
>> 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...
> They are not ruled out by my proposal as long as RDF tools can trace the 
> source of the triples, and singularly the asserted vs computed 
> distinction among other ones.
> Another point. Suppose I merge the above vocabulary with another one 
> where I have
> :cats     BT   :fur pets
> :fur pets   BT   :pets
> The broader closure computation will not break, and all original broader 
> assertions are merged smoothly in the merged vocabulary. But :pets is no 
> more a minimal broader of :cats in the merged vocabulary.
> If I had declared the minimal broader to begin with, I could not merge 
> those two vocabularies consistently ...
>> 3. I'm afraid the formal definition of the minimal broader will not be 
>> intuitive
> I don't know of any formal definition being "intuitive". But the notion 
> of minimal element of an ordered set is quite generic, and we can 
> illustrate it with many examples.
>> , and further, difficult to implement in OWL (I've not thought about 
>> it, but it might even be impossible)... 
> Definitely I think it is impossible because OWL declarations are all 
> about open world classes. As said in the previous message, and as the 
> above example shows, the minimal broader notion is relative to a closed 
> world, dealing with an actual *set* of asserted triples. I don't think 
> the notion of minimal element can be defined in class theory, because of 
> the open world assumption.
>> 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.
> Sure. The more so that negative queries in SPARQL are all but intuitive, 
> using unbound variables. But doable. Would look like something like the 
> following, if I got it right :
> CONSTRUCT {?x    skos:minimalBroader   ?y}
> {
>                   ?x     skos:broader  ?z.
>                   ?z     skos:broader  ?y.
>                    FILTER (!bound(?z))
> }
> Despite thisnon-intuitive form, SPARQL queries are indeed the way to 
> deal with rules applicable in closed worlds.
> Bernard
>>> 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
Received on Wednesday, 30 July 2008 12:43:58 UTC

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