Re: Concept Equivalence, IFPs, skos:subjectIndicator and owl:sameAs (was Re: SKOS Guide and owl:sameAs)

Stuart

You know Alistair just challenged me to sum up the issue in no more than 
three sentences ...
I think your answer below is the closest to the target we've achieved so 
far.
So let me leverage it and have a try to make it as short as possible 
(well, a bit more than three sentences, but barely) :

Issue:
skos:subjectIndicator being an IFP is likely to cause unwanted merging, 
whenever skos:Concept designed to be formally different representations 
of a similar (unformal) concept are inferred to be the same individual 
(owl:sameAs), based on a common subject indicator value.

Possible answers:
1. Drop skos:subjectIndicator as an IFP.
2. Keep skos:subjectIndicator an IFP, but make recommendations about how 
to use it to prevent unwanted merging.

<!--End of the contractual three sentences summing up the issue-->

<!--Discussion-->

Option 1 is like dropping subjectIndicator altogether. All the point of 
this property is to be the basis for "same-ness" of a subject (concept). 
If it's not an IFP, what does it indicate?

Option 2 can have several variants, among which to use subjectIndicator 
only for blank concepts, not identified in any concept scheme, to allow 
indexing assertions of the form: "The subject of this resource is a 
concept indicated by that other resource".
    a:thisResource       skos:subject         _:b0
    _:b0                     skos:subjectIndicator         b:thatResource

<!--End of sum up of discussion so far-->

More discussion (NEW)

The above option does not solve the original issue, to express that 
formally different concepts are somehow representing the same unformal one.

Side option to solve this issue : use a skos/mapping:broadMatch blank 
concept, and put the common subject indicator on this broad match

a:Concept1           skos/mapping:broadMatch       _:b1
b:Concept2           skos/mapping:broadMatch       _:b1
_:b1                     skos:subjectIndicator              b:thatResource

Avoiding merging of the two concepts, while providing a way to merge 
indexing pointers, and answer queries like : find all resources indexed 
by the concepts "broadly indicated" by b:thatResource.

How's that?

Bernard


Williams, Stuart (HP Labs, Bristol) a écrit :
> [At Alistair's request I'm reposting this earlier response on-list]
>
> Hello Alistair,
>
> Thanks... as a SKOS newbie, the thread was useful to me from a learning
> pov.
>
> One thing you'll spot, if you make it to the end of the thread, is that
> I missed the presense of a blank node in the skos:subjectIndicator
> example in the guide. The guide presents the example only in RDF/XML
> without a diagram - or real mention of the use of a blank node.
>
> FWIW I think I came to a tentative conclusion along the following lines:
>
> There are two (maybe more) kinds of skos:Concepts: 
> 1) A 'localised' URI named skos:Concept that one wants to maintain as
> distinct from similar concepts in other Thesaurii - because, amongst
> other things, they have different pasts and futures. Even at a given
> instant they may have subtle difference. In general one wouldn't use
> skos:subjectIndicator with this kind of concept (because of its
> potential to generate equivalences).
>
> 2) A conceptualisation of some published subject (eg. the Isaac Newton
> example in the OASIS published subjects document). There could be many
> published subject indicator documents for a given subject and in this
> case you do indeed want skos:subjectIndicator to be an IFP and bring
> about Concept merging (and an effective 'cloning' all the subject
> indicators for a given subject). In general the skos:Concept whose
> subject is indicated would be a blank node - this would avoid generation
> of equivalences between URI named skos:Concepts (by not giving them URI
> names :-).
>
> I think that with care, those that want to use published subject
> indicator can do so without generating unintended equivalences - but it
> probably needs clearer motivational examples in the guide.
>
> BR
>
> Stuart
>
>   
>> -----Original Message-----
>> From: Alistair Miles [mailto:a.j.miles@rl.ac.uk]
>> Sent: 23 November 2006 14:59
>> To: Williams, Stuart (HP Labs, Bristol)
>> Cc: public-esw-thes@w3.org
>> Subject: Re: Concept Equivalence, IFPs, skos:subjectIndicator and 
>> owl:sameAs (was Re: SKOS Guide and owl:sameAs)
>>
>> Hi Stuart,
>>
>> Quick comment without having read the subsequent thread in detail ...
>>
>> I think you have revealed a potential inconsistency in the design of 
>> SKOS. Certainly worthy of an item in the issues list - I'll do that 
>> when I get a chance.
>>
>> Cheers,
>>
>> Alistair.
>>
>>     
>
>
>   

-- 

*Bernard Vatant
*Knowledge Engineering
----------------------------------------------------
*Mondeca**
*3, cité Nollez 75018 Paris France
Web:    www.mondeca.com <http://www.mondeca.com>
----------------------------------------------------
Tel:       +33 (0) 871 488 459
Mail:     bernard.vatant@mondeca.com <mailto:bernard.vatant@mondeca.com>
Blog:    Leçons de Choses <http://mondeca.wordpress.com/>

Received on Monday, 27 November 2006 18:18:28 UTC