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: Simon Spero <ses@unc.edu>
Date: Tue, 29 Jul 2008 10:50:15 -0400
Message-ID: <1af06bde0807290750u493b20abj3c34f7ccd982d2e0@mail.gmail.com>
To: "Bernard Vatant" <bernard.vatant@mondeca.com>
Cc: "Antoine Isaac" <aisaac@few.vu.nl>, "Houghton,Andrew" <houghtoa@oclc.org>, public-swd-wg@w3.org, public-esw-thes@w3.org

There's a pretty close relationship here with  broadMatch and narrowMatch,
since broadmatch is   the smallest concept containing the target concept,
and narrowMatch the largest concept contained by the the target (within the
closed  domain of a specific matching concept scheme).

If it would help, it  might still be possible to set up a session on this at


On Tue, Jul 29, 2008 at 10:09 AM, Bernard Vatant <bernard.vatant@mondeca.com
> wrote:

> 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
> --
> *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 Tuesday, 29 July 2008 14:50:58 UTC

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