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

Stephen-
If you aren't using a reasoner, then you don't need to start doing so  
to introspect and undo the effects of using... a reasoner.

If you are working with an rdf suite like Redland, and don't hook it  
up to an inference engine, you just get the direct assertions.

You don't have to draw every conclusion entailed by ones knowledge  
base; the black lump lying on my feet is ki-chan. I do not need to  
access the fact that he is a eukaryote to know he's being friendly  
because he wants second breakfast; I only need to know that he's a cat.

It's when you *publish* data that you need to take care not to use  
hierarchical relations in cases where the link is not truly hierarchic.

Simon

Sent from my iPhone

On Jul 31, 2008, at 5:22 AM, Stephen Bounds <km@bounds.net.au> wrote:

>
> 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 13:16:00 UTC