Re: [SKOS]: [ISSUE 44] BroaderNarrowerSemantics

By the way,

>
> Regarding your "locally transitive specialization pattern", see [1] . There the design pattern has the *super-property* as transitive, and the *sub-property* as "direct", where the notion of "directness" is necessarily subjective.
>   

Yes, my pattern goes into the other direction! It's because in my 
example, I assume John really wants skos:broader to behave as a transitive 
property in his concept scheme, but without asserting skos:broader 
rdf:type owl:Transitive (more precisely he would like to do this, but he 
cannot, because the SKOS docs says it's very nasty to add formal axioms 
to the standard SKOS properties).
He might for instance not grant any importance to hierarchical display, 
but be just interested in query reformulation along the complete 
hierarchy, because he things his structure is clean enough for this. And 
he might want to use a standard SKOS query reformulation service 
(plugged on his RDFS-enabled semantic store) based on skos:broader, and 
not to create his own.

Of course, if he wants to have both a transitive and an non-transitive 
broader working on his concept scheme at a same time, he has no choice 
but to use the pattern of [1]. But again this is a concern he might not 
have.

Antoine

> I think your concern about John & Mary is justified. I'm not sure what to do about it.
>
> I don't think your "locally transitive" pattern is completely "safe". Although it would avoid skos:broader becoming transitive in Mary's thesaurus, skos:broader would be effectively transitive for John's thesaurus. Therefore when Mary attempts to process John's thesaurus, if she expects skos:broader to be intransitive she will interpret the data as inconsistent.
>
> Here are two choices that occur to me.
>
> (1) We leave skos:broader as neither transitive or intransitive. If we do this, then people who want to interpret skos:broader as *intransitive* will need to know how to deal with any transitivity they may find (i.e. Mary needs strategies for dealing with situations like the one you describe). I don't know how simple it is to "filter out" triples to create an intransitive graph ... I'll look into that. If it's not simple, then this option is probably not viable, as you suggest.
>
> (2) State skos:broader to be transitive. Then, either (a) define a design pattern for declaring a "direct" sub-property of skos:broader, or (b) go even further in the same direction and declare skos:broaderDirect ourselves for which people can have a strong-ish expectation to be intransitive. 
>
> However, note that even with option (2b), you will still need strategies for dealing with transitivity in the "direct" broader relation, because of it's subjectivity (see [1]) - what one person considers "direct" may be several steps (i.e. indirect) to another person. 
>
> Cheers,
>
> Alistair.
>
> [1] http://www.w3.org/2001/sw/BestPractices/OEP/SimplePartWhole/ section "General issues / Transitive relations - parts and direct parts"
>
> --
> Alistair Miles
> Research Associate
> Science and Technology Facilities Council
> Rutherford Appleton Laboratory
> Harwell Science and Innovation Campus
> Didcot
> Oxfordshire OX11 0QX
> United Kingdom
> Web: http://purl.org/net/aliman
> Email: a.j.miles@rl.ac.uk
> Tel: +44 (0)1235 445440  
>
>   
>> -----Original Message-----
>> From: Antoine Isaac [mailto:aisaac@few.vu.nl] 
>> Sent: 26 November 2007 18:09
>> To: Reul, Q. H.
>> Cc: public-swd-wg@w3.org; public-esw-thes@w3.org; Miles, AJ (Alistair)
>> Subject: Re: [SKOS]: [ISSUE 44] BroaderNarrowerSemantics
>>
>> Hello Quentin, Alistair
>>
>> The way I would treat "transitive broader" would be to 1. 
>> create a specialization of skos:broader (let's say, 
>> my:transitiveBroader) 2. declare it transitive 
>> (my:transitiveBroader rdf:type
>> owl:TransitiveProperty)
>>
>> This way, for the concepts involved in transitiveBroader 
>> statements, there will be some "locally transitive" broader.
>> If we have (ex:A,my:transitiveBroader,ex:B),
>> (ex:B,my:transitiveBroader,ex:C) then we'll have
>> (ex:A,my:transitiveBroader,ex:C) and hence (ex:A,skos:broader,ex:C)
>>
>> Notice that in my mind this is very different from 
>> interpreting skos:broader as transitive, which would be 
>> skos:broader rdf:type owl:TransitiveProperty And notice also 
>> that I *really object* to saying that, as Alistair writes it 
>> in the reference [1]
>>
>>     
>>> Interpreting skos:broader as a Transitive Property would be 
>>>       
>> consistent 
>>     
>>> with the SKOS semantics. Alternatively, interpreting 
>>>       
>> skos:broader as 
>>     
>>> an Intransitive Property would also be consistent with the 
>>>       
>> SKOS semantics.
>>
>> If we have one case somewhere where skos:broader is not 
>> transitive, then *nobody on semantic web can assert that it 
>> is transitive*. Just consider the following case:
>> - John has a thesaurus for which broader is not transitive
>> - Mary has a thesaurus for which broader is transitive and, 
>> "interpreting skos:braoder as transitive", puts the infamous 
>> triple skos:broader rdf:type owl:TransitiveProperty in here 
>> knowledge base.
>> Then whenever a Semantic Web tool loads Mary's knowledge base 
>> at the same time as John's one, it would propagate unintended 
>> skos:broader statements (between the concepts of John's 
>> thesaurus) With respect to this kind of problem, only the 
>> "locally transitive" 
>> specialization pattern I've proposed is safe.
>>
>> Cheers,
>>
>> Antoine
>>
>> [1] http://www.w3.org/2006/07/SWD/wiki/SKOS/Reference
>>
>>     
>>> Hi all,
>>>
>>> I think [ISSUE 44] might have been resolved at the f2f in 
>>>       
>> Amsterdam a 
>>     
>>> few months ago as I think to remember that we would allow people to 
>>> use skos:broader/skos:narrower as both transitive and intransitive.
>>>
>>> However, I believe that these semantic relations should be made 
>>> transitive. For each skos:ConceptScheme, there might have 
>>>       
>> one or more 
>>     
>>> top concept and there might have several subconcepts available for 
>>> each of them.
>>>
>>> Example:
>>> skos:ConceptScheme W
>>> W skos:hasTopConcept X
>>> X skos:narrower Y
>>> Y skos:narrower Z
>>>
>>> The user might want to know that Z skos:broader X. Or would simple 
>>> graph operation be enough to find all the sub- or super- concepts?
>>>
>>> Furthermore, we have defined a skos:Concept rdf:type owl:Class and 
>>> hence skos:broader and skos:narrower could be used to describe 
>>> owl:Class in ontologies. I'm not sure that we want 
>>> skos:semanticRelation to be applied between owl:Class.
>>>
>>> I'm sorry if any of these issues have already been covered.
>>>
>>> Regards,
>>>   
>>> Quentin
>>>
>>> [ISSUE 44] http://www.w3.org/2006/07/SWD/track/issues/44
>>>
>>> ******************************************
>>> * Quentin H. Reul                        *
>>> * PhD Research Student                   *
>>> * Department of Computing Science        *
>>> * University of Aberdeen, King's College *
>>> * Room 238 in the Meston Building        *
>>> * ABERDEEN AB24 3UE                      *
>>> * Phone: +44 (0)1224 27 4485             *
>>> * http://www.csd.abdn.ac.uk/~qreul       *
>>> ******************************************
>>>
>>>
>>>
>>>
>>>   
>>>       
>>
>>     
>
>

Received on Tuesday, 4 December 2007 19:23:16 UTC