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

Is any solution possible that would retain the previous semantics of SKOS Broader but also allow for the broadening of SKOS to include vocabularies where the relationship is definitely non-transitive.
 
As I understand it, the original SKOS Broader reflected the various standards where the relationship is considered (potentially) transitive but only applies to the direct parent (it is asserted). It would be desirable to retain the relationship name and basic meaning for the large number of vocabularies with this structure.
 
Would it be possible to retain this sense of SKOS Broader but introduce new relationships to cover
- Broader Non-transitive 
- A Transitive-closure relationship - if it is desired to return the complete chain
 
If this were possible, perhaps it would not be necessary to change the SKOS namespace for broader semantics reasons?
 
Doug
 
 

________________________________

From: public-esw-thes-request@w3.org on behalf of Antoine Isaac
Sent: Tue 29/07/2008 17:51
To: Bernard Vatant
Cc: Houghton,Andrew; public-swd-wg@w3.org; public-esw-thes@w3.org
Subject: Re: [SKOS] the return of transitive and subproperty (was Re: SKOS comment: change of namespace (ISSUE-117))




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 <http://www.avg.com/>  Version: 8.0.138 / Virus
>> Database: 270.5.6/1577 - Release Date: 28/07/2008 06:55
>>
>>
>>
>