Re: ISSUE-71: ParallelMappingVocabulary

Hello,

By the way I think may mail for ISSUE-74 [1] (at least the last part of 
it) also concerns this issue:

> About the last part of your issue, questioning the choice not to have a 
> separate vocabulary for concept mapping relations and for semantic 
> relations. I had proposed [4] before [1], and I've rarely seen so much 
> consensus between SKOS list's people *against* something ;-)
>
> Cheers,
>
> Antoine
>
> [1] http://lists.w3.org/Archives/Public/public-swd-wg/2007Dec/0083.html
> [2] http://lists.w3.org/Archives/Public/public-swd-wg/2007Dec/0116.html
> [3] http://www.w3.org/2006/07/SWD/wiki/SKOS/DraftPrimer
> [4] 
> http://www.w3.org/2006/07/SWD/wiki/SkosDesign/ConceptualMapping/ProposalOne

Cheers,

Antoine

[1] http://lists.w3.org/Archives/Public/public-swd-wg/2008Jan/0141.html

> ISSUE-71: ParallelMappingVocabulary
>
> http://www.w3.org/2006/07/SWD/track/issues/71
>
> Raised by: Alistair Miles
> On product: SKOS
>
> Currently, the SKOS vocabulary includes two "parallel" sets of URIs vocabulary
> for hierarchical and associative links between conceptual resources. The
> semantic relation properties skos:semanticRelation, skos:broader, skos:narrower
> and skos:related are mirrored in skos:mappingRelation, skos:broadMatch,
> skos:narrowMatch and skos:relatedMatch.
>
> A separate, parallel mapping vocabulary provides a convenient way to
> differentiate links *within* a scheme from links *between* a scheme (given that
> certain conventions of practice are followed). However, there may also be other
> mechanisms for making such a differentiation that do not require a separate
> vocabulary, by e.g. keeping links between concepts within a scheme in a separate
> RDF graph from mapping links. 
>
> With a separate vocabulary for mapping relations, a number of interactions
> between the parallel vocabularies then have to be considered, which increases
> the size and complexity of the SKOS data model. Many of these interactions have
> not yet been considered by the Working Group, and as such the model currently
> leads to a number of counter-intuitive results. E.g. 
>
> <A> skos:broader <B> .
> <A> skos:exactMatch <B> .
>
> is consistent with the SKOS data model (this is one of a number of similar
> scenarios). 
>
> Should we keep skos:broadMatch, skos:narrowMatch and skos:relatedMatch? 
>
> Or should we drop them, and use skos:broader, skos:narrower and skos:related for
> mapping, providing guidance on how to make a distinction between intra-scheme
> and inter-scheme links by managing RDF graphs (or some other mechanism)?
>
>
>
>
>

Received on Monday, 21 January 2008 20:51:24 UTC