W3C home > Mailing lists > Public > public-esw-thes@w3.org > December 2006

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

From: Bernard Vatant <bernard.vatant@mondeca.com>
Date: Fri, 01 Dec 2006 18:06:21 +0100
Message-ID: <4570610D.3080204@mondeca.com>
To: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>
Cc: Alistair Miles <a.j.miles@rl.ac.uk>, public-esw-thes@w3.org

Stuart

>> a:Concept1           skos/mapping:broadMatch       _:b1
>> b:Concept2           skos/mapping:broadMatch       _:b1
>> _:b1                     skos:subjectIndicator     b:thatResource
>>
>> How's that?
>>     
>
> Actually looks pretty appealing. 
>
> broadMatch does seem like the right property to use, however, I'm trying
> to decide whether there could be cases where the approximate match
> between named concept and the blank concept have the subset relation the
> otherway round - ie. a:Concept1 properly indexes *more* resources than
> _:b1. More generally it may be the case that whilst there is simply a
> significant intersection in properly indexed resource sets, however they
> may be overlapping rather than covering in which case a symmetric
> property like majorMatch (probably) or minorMatch (probably not) or
> simply a nondescript mappingRelation might be more appropriate
> properties to use. Just thinking aloud - but I like the general
> direction.
>   

Agreed. Actually broadMatch was just an example of property which could
be used this way. The most important in this idea is to have this blank
concept acting as both a *semantic buffer* avoiding the direct
conflating of named concepts using the same subject indicator, and a
*semantic hub* allowing to indirectly link them together and to their
common subject indicator. And also, on the other side of the buffer, to
bind several subject indicators the same way. The ways named concepts
can be linked to this buffer/hub are certainly many, and can leverage
all the expressivity of skos/mapping.

Bernard
Received on Friday, 1 December 2006 17:06:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:38:55 GMT