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: Williams, Stuart \(HP Labs, Bristol\) <skw@hp.com>
Date: Fri, 1 Dec 2006 14:46:50 -0000
Message-ID: <C4B3FB61F7970A4391A5C10BAA1C3F0D440726@sdcexc04.emea.cpqcorp.net>
To: "Bernard Vatant" <bernard.vatant@mondeca.com>
Cc: "Alistair Miles" <a.j.miles@rl.ac.uk>, <public-esw-thes@w3.org>

Bernard,

At the time I previously responded [1] I had not quite groked your new
proposal at the end of your message, I'd also missed the existence of
the SKOS Mapping vocabulary that your proposal uses.

> 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?

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.

> Bernard

Stuart
--
[1]
http://lists.w3.org/Archives/Public/public-esw-thes/2006Nov/0063.html
Received on Friday, 1 December 2006 14:47:13 GMT

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