RE: [SKOS] on ISSUE-71 and ISSUE-74

re the tricky mapping relationships issue
 
I think there is justification for separate SKOS mapping relationships in SKOS's aim to represent KOS standards and practice. KOS are designed to be internally consistent but representing a particular point of view (and language). Mapping between thesauri (and  other schemes) therefore tends to be somewhat problematic regardless of who does it or by which method. 
 
For example, BSI Thesaurus Standard Part4 (draft) observes that mappings often work well in only one direction and this may lead to confusion if SKOS BT/NT employed. In examples of mappings between schemes, it is clear from the 'tags' that the mapping relationship is to another scheme (not internally). See extracts below. 
 
While it is very good we investigate assigning provenance or denoting approval of extensions by scheme 'owners' I think there will inevitably be a lot of practical difficulties in achieving this.

So if we muddy the distinction between the internal thesaurus relationships and mapping relationships I'm afraid it will lead to confusion in applications attempting to make use of the mapping relationships. One compromise might be to consider specialisation of the relationships, though am not sure this would be practical and the safest option in an RDF context may just be different sets of relationships.
 
Doug

from BSI Part4 (draft)
Commonly, the mappings work well in only one direction, and this effect is exacerbated when the vocabularies are of different types. A mapping from vocabulary A to vocabulary B cannot generally be used as a mapping from B to A. If this is required a separate mapping has to be created.
...
For mappings, the tag or field label should have two components: firstly the identifier for the target vocabulary and secondly a tag for relationship type. The identifiers of the source and target vocabularies should be chosen to avoid confusion with any of the standard tags. 

 

________________________________

From: public-esw-thes-request@w3.org on behalf of Antoine Isaac
Sent: Fri 22/02/2008 09:54
To: Alistair Miles
Cc: public-swd-wg@w3.org; public-esw-thes@w3.org
Subject: Re: [SKOS] on ISSUE-71 and ISSUE-74




Hi Alistair,

Thanks for this summary. I think it explains quite appropriately the
different positions. I will however try to defned myself, maybe
explaining my position in clearer way

To sum up, I think I started with the position Alasdair explained a
while ago [1]

> In the first case (intra-vocabulary relationships), all the concepts
> form part of a coherent whole and the relationships can be seen as a
> statement of fact. The relationships form part of the vocabulary,
> meaning that if you make use of the vocabulary then you accept all the
> intra-vocabulary relationships.
>
> In the second case (inter-vocabulary mappings), the mappings between
> the concepts are "fuzzier" and are more a statement of one person's,
> or group's, beliefs. The vocabularies can be used without accepting
> the statements made about the mappings.

But then I thought about KOS enrichment and KOS extension, which I
believe call respectively for intra-scheme mapping links and
inter-scheme "paradigmatic" ones, therefore blurring the lines
(but of course maybe we can find different solutions from the ones I've
put in the Primer [4])

So for me the difference between mapping and "paradigmatic" relations
would not be along the inter-scheme/intra-scheme dimensions but along:
- provenance & authority: "paradigmatic" links are endorsed by the
authority that created the scheme
- inherence of the relation: "paradigmatic" links are inherently part of
a concept's meaning, while mapping are mere accidents (different
applications can map a concept to different concepts, depending on
mapping technique and/or requirements)
Actually since the begining, I had understood "paradigmatic" as
"defining the meaning of concepts"...

Now I would make a single, very important comment on your mail, which
generally raise fair arguments except for the following one which is to
me way to optimistic

> As a general design principle, I say that no property should
> ever be expected to carry greater authority or trust than another
> property, because such an expectation cannot be supported in practice.
> Authority and trust can only be conveyed, via provenance, outside the
> graph.

Of course in theory they are good and bad ways to do model things. In an
ideal world, your point would surely work.
But honnestly I think the scenarios that need distinction between
mapping and "paradigmatic" links are too important to rely on the very
feable solutions we are currently proposing for provenance of
relationship statements [2,3]
The design of a pragmatic, application-guided model such as SKOS must
not be afraid to make "economies of representation" when a feature
becomes too important to be treated by too complex patterns.

Cheers,

Antoine

[1] http://lists.w3.org/Archives/Public/public-esw-thes/2007Dec/0063.html
[2] http://www.w3.org/2006/07/SWD/track/issues/36
[3] http://www.w3.org/2006/07/SWD/track/issues/47
[4] http://www.w3.org/TR/skos-primer/#secextension ,
http://www.w3.org/TR/skos-primer/#secmapping
>
> Dear all,
>
> I've been trying to collect my thoughts on issues 71 and 74. Here's
> where I've got to so far.
>
> === Background ===
>
> Antoine's email of the 17 Feb [1] discusses both issue 71 and issue
> 74, and proposes resolutions to both. This email contains an argument
> for a fundamental distinction between "paradigmatic" versus "mapping"
> relations based on notions of authority and semantic commitment, and
> hence for parallel vocabularies.
>
> Antoine's first email of 19 Feb [2] makes a new proposal for
> resolution of issue 71, based on the argument of 17 Feb.
>
> Antoine's second email of 19 Feb][3] makes a new proposal for
> resolution of issue 74, again based on the argument of 17 Feb.
>
> [1] http://lists.w3.org/Archives/Public/public-swd-wg/2008Feb/0062.html
> [2] http://lists.w3.org/Archives/Public/public-swd-wg/2008Feb/0076.html
> [3] http://lists.w3.org/Archives/Public/public-swd-wg/2008Feb/0077.html
>
> === Preamble ===
>
> First, a point of pedantry. "Paradigmatic" is used in BS 8723-2 to
> denote links that are inherent in the meaning of the linked concepts.
>
> The idea in SKOS was always that broader, narrower and related,
> whether used within a concept scheme or between concept schemes,
> denote links between concepts which are inherent in the meaning of the
> linked concepts. Therefore, broader, narrower and related mapping
> links are just as "paradigmatic" as broader, narrower or related links
> within a concept scheme.
>
> Below, I use "intra-scheme links" to mean broader, narrower or related
> links between concepts in the same scheme, and I use "inter-scheme
> links" to mean broader, narrower or related links between concepts in
> different schemes.
>
> === Discussion ===
>
> If we are going to have separate, parallel vocabularies in SKOS for
> intra-scheme versus inter-scheme links, then I want to make sure we
> have clear, sound and valid reason(s) for doing so. Note especially
> that no analogous pattern is present in OWL, and therefore we need to
> justify our different approach.
>
> Let me start by trying to restate Antoine's position on intra-scheme
> links, as points A-E below:
>
> A. The activity of constructing a concept scheme is typically carried
> out by a single authority. This activity results in, among other
> things, a set of intra-scheme links between the concepts of the
> scheme. The properties skos:broader, skos:narrower and skos:related
> should be used by such an authority to represent these intra-scheme
> links.
>
> B. Because the properties skos:broader, skos:narrower and skos:related
> are used, for the most part, by an authority as described above, then
> they can in general be relied upon to carry a certain degree of
> authority, without needing to question the provenance of any graph in
> which they are used.
>
> C. The activity of constructing a concept scheme generally follows a
> well-defined methodology, and is carried out by a single authority in
> support of a known application. Therefore, the intra-scheme links
> between concepts can generally be relied upon to carry a certain
> degree of semantic soundness or intellectual consistency.
>
> D. Because the properties skos:broader, skos:narrower and skos:related
> are used, for the most part, to represent intra-scheme links that
> result from such an activity, then they can in general be relied upon
> to carry a certain degree of semantic soundness or intellectual
> consistency, without needing to question the provenance of any graph
> in which they are used.
>
> E. The properties skos:broader, skos:narrower and skos:related may be
> used in other ways, however because they are mostly used as described
> above, then they can be trusted to, in general, represent intra-scheme
> links with a relatively high degree of authority and intellectual
> soundness or consistency, without needing to question the provenance
> of any graph in which they are used.
>
> Let me now try to restate Antoine's position on inter-scheme links, as
> points F-H below:
>
> F. The activity of constructing a mapping between two concept schemes
> is typically carried out by a single authority, which differs from the
> authorities who were responsible for developing each individual
> scheme. Such an activity results in a set of inter-scheme links
> between the concepts of the two schemes. The properties
> skos:broadMatch, skos:narrowMatch, skos:relatedMatch and
> skos:exactMatch should be used to represent these inter-scheme links.
>
> G. Because the properties skos:broadMatch, skos:narrowMatch,
> skos:relatedMatch and skos:exactMatch are used, for the most part, as
> described above, they cannot in general be relied upon to carry the
> authority of either party responsible for the construction of the
> individual concept schemes.
>
> H. Although the activity of constructing a set of mapping links
> between schemes might follow a well-defined methodology, the process
> is fundamentally different from the process of constructing links
> between concepts within a scheme, because the mapping authority has no
> control over the scope or organisation of each of the mapped schemes,
> and therefore has to cope with a wide variety of content and
> structure. Therefore, links that result from such an activity are
> generally more variable, less intellectually consistent or sound, than
> are links which result from the construction of a concept scheme.
>
> I. Because the properties skos:broadMatch, skos:narrowMatch,
> skos:relatedMatch are used, for the most part, to represent
> inter-scheme links which result from such an activity, they generally
> carry a lower degree of semantic soundness or intellectual consistency
> than do skos:broader, skos:narrower and skos:related.
>
> J. The properties skos:broadMatch, skos:narrowMatch, skos:relatedMatch
> may be used in other ways, however because they are mostly used as
> described above, then they can be trusted to, in general, represent
> inter-scheme links with a relatively low degree of authority and
> intellectual soundness or consistency, without needing to question the
> provenance of any graph in which they are used.
>
> === My Position ===
>
> Let us consider the ways in which links between concepts might differ.
>
> There are links which are "authoritative", and there are links which
> are not. There are links which are well-engineered and intellectually
> sound, and there are links which are not. There are links which span
> concept schemes, and there are links which do not. These are three
> orthogonal dimensions. There is also, of course, a fourth dimension of
> basic paradigmatic meaning, i.e. whether the link is broader, narrower
> or related, which is again orthogonal to the first three.
>
> Antoine's position, as stated above, is that skos:broader and
> skos:broadMatch share the same paradigmatic meaning, however
> skos:broader is typically (but not always) intra-scheme, more
> authoritative and more intellectually consistent, whereas
> skos:broadMatch is typically (but not always) inter-scheme, less
> authoritative and less intellectually consistent.
>
> This is quite a load for each of these properties to carry. My concern
> is that, in practice, neither of these properties (skos:broader,
> skos:broadMatch) can be relied upon to carry anything other than their
> basic, paradigmatic meaning, and that therefore, in practice, they are
> at best redundant, and at worst misleading. To use an analogy, if SKOS
> were a security-critical technology, then any application which relied
> on a fundamental difference between skos:broader and skos:broadMatch
> would have a serious vulnerability.
>
> Authority depends on provenance, as does trust in intellectual
> soundness. As a general design principle, I say that no property
> should ever be expected to carry greater authority or trust than
> another property, because such an expectation cannot be supported in
> practice. Authority and trust can only be conveyed, via provenance,
> outside the graph.
>
> Kind regards,
>
> Alistair.
>