- From: Williams, Stuart \(HP Labs, Bristol\) <skw@hp.com>
- Date: Fri, 1 Dec 2006 14:46:50 -0000
- 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 UTC