- From: Dan Brickley <danbri@danbri.org>
- Date: Wed, 01 Oct 2008 13:13:24 +0200
- To: Rob Tice <rob.tice@k-int.com>
- Cc: public-esw-thes@w3.org
Rob Tice wrote: > Dear all > >>From the previous thread, it appears that exactMatch is allowable between > concepts in the same concept scheme, however the documentation (unless I > have missed something obvious) appears to suggest that it should be used > only between concepts in different schemes (for mapping). > > So my question is, if it is allowable, what is the use case for exactMatch > between concepts in the same scheme? Often in these circumstances, I think it's best to leave options open if they're not causing pain. One possible scenario for allowing this in same scheme might be data merging. Imaging I have a little set of SKOS concepts (with URIs for sake of neutrality that looked like uuid:123412341234) and I decide to merge it into a second set I've created in another tool (perhaps with same style URIs, it doesn't matter). Conceptually, this merger could be accomplished incrementally by declaring each Concept to be in the same scheme (perhaps some new URI identifying the composite scheme) and then making tweaks over time, eg. adding new links, editing concepts. At which point, previously-identified exact matches between concepts from the two collections of concepts would still be representable with 'exactMatch'. There is probably value in not changing concept-level URIs needlessly, since external data may use them, so 'two schemes become one scheme' could be a handy pattern. I'm not saying that this is the best way to manage SKOS data evolution and merging, just that scenarios such as this might be enough to justify allowing exactMatch within the same scheme. cheers, Dan -- http://danbri.org/
Received on Wednesday, 1 October 2008 11:14:03 UTC