W3C home > Mailing lists > Public > public-esw-thes@w3.org > October 2008

Re: exact match

From: Dan Brickley <danbri@danbri.org>
Date: Wed, 01 Oct 2008 13:13:24 +0200
Message-ID: <48E35B54.3060701@danbri.org>
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 

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.



Received on Wednesday, 1 October 2008 11:14:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:45:50 UTC