- From: Stephen Bounds <km@bounds.net.au>
- Date: Wed, 30 Jul 2008 07:27:57 +1000
- To: public-esw-thes@w3.org
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 Tuesday, 29 July 2008 21:28:29 UTC