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

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

-- 

*Bernard Vatant
*Knowledge Engineering
----------------------------------------------------
*Mondeca**
*3, cité Nollez 75018 Paris France
Web:    www.mondeca.com <http://www.mondeca.com>
----------------------------------------------------
Tel:       +33 (0) 971 488 459
Mail:     bernard.vatant@mondeca.com <mailto:bernard.vatant@mondeca.com>
Blog:    Leçons de Choses <http://mondeca.wordpress.com/>

Received on Wednesday, 30 July 2008 07:58:55 UTC