- From: Stephen Bounds <km@bounds.net.au>
- Date: Wed, 30 Jul 2008 22:28:20 +1000
- 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.
Regards,
-- 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}
>
> WHERE
> {
> ?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