- From: Bernard Vatant <bernard.vatant@mondeca.com>
- Date: Fri, 01 Dec 2006 18:06:21 +0100
- 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 UTC