RE: exact match

Hi Dan

Thanks for the post and the use case, but is this not actually a 'work
around' for the constraints of the SKOS semantic relationship model.

Wouldn't SKOS benefit from an actual equivalence relationship for those
specific use cases when using labels for equivalence is not sufficient
(apologies if this has already been covered elsewhere :)). Wouldn't this
then be a more consistent model than exact match being utilised between
concepts in the same scheme.

Cheers

Rob



> -----Original Message-----
> From: Dan Brickley [mailto:danbri@danbri.org]
> Sent: 01 October 2008 12:13
> To: Rob Tice
> Cc: public-esw-thes@w3.org
> Subject: Re: exact match
> 
> 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/
> 
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.524 / Virus Database: 270.7.5/1701 - Release Date:
> 30/09/2008 19:08
> 

No virus found in this outgoing message.
Checked by AVG. 
Version: 7.5.524 / Virus Database: 270.7.5/1701 - Release Date: 30/09/2008
19:08

Received on Wednesday, 1 October 2008 11:59:01 UTC