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

Hi Antoine,

Yes, I am in favour of the current SKOS version.

I strongly believe SKOS is most likely to see broad uptake if people 
*don't* need SPARQL or some other RDF query dialect to do useful things 
with it.

Cheers,

-- Stephen.

Antoine Isaac wrote:
> 
> Dear Stephen,
> 
> Just to be sure, when you're in favor "of the change to <skos:broader> 
> and <skos:broaderTransitive>", that means that you're in favour of the 
> current SKOS version, as opposed to the previous (2005) one?
> 
> As some people in this thread have proposed to make various changes to 
> these two properties, everything gets a bit confused ;-)
> 
> The current version of SKOS has skos:broader represent the asserted 
> statement, and skos:broaderTransitive represent the infered hierarchy, 
> as you describe it in your queries.
> So the current version should fit your needs...
> 
> Best
> 
> Antoine
> 
> 
> -------- Message d'origine--------
> De: public-esw-thes-request@w3.org de la part de Stephen Bounds
> Date: mar. 29/07/2008 23:27
> À: public-esw-thes@w3.org
> Objet : Re: [SKOS] the return of transitive and subproperty (was Re: 
> SKOS   comment:  change of namespace (ISSUE-117))
> 
> 
> 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 Thursday, 31 July 2008 09:23:00 UTC