W3C home > Mailing lists > Public > public-swd-wg@w3.org > January 2008

ISSUE-71: ParallelMappingVocabulary

From: SWD Issue Tracker <dean+cgi@w3.org>
Date: Wed, 16 Jan 2008 17:42:49 +0000 (GMT)
To: public-swd-wg@w3.org
Message-Id: <20080116174249.CC3356B5EA@tibor.w3.org>


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 Wednesday, 16 January 2008 17:42:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:52 UTC