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

Doug quotes a draft of BS8723-4. In the final version, published last
November, the wording has changed very slightly. I've inserted the
published wording in his message below. I don't think the change of
wording diminishes Doug's argument.
 
Quite apart from the words of the standard, I would personally agree it
is a good idea to clarify whether a BT/NT relationship connects concepts
within one vocabulary or drawn from different vocabularies, even though
the semantic intention in both cases is the same. I agree with
Alistair's assertion, "There are links which are well-engineered and
intellectually  sound, and there are links which are not. "
I'm not so sure about his follow-on, "in practice, neither of these
properties (skos:broader, skos:broadMatch) can be relied upon to carry
anything other than their  basic, paradigmatic meaning," 
In my experience, they cannot necessarily be relied upon even for that,
because of the bad engineering that sometimes occurs, and also the
change of perspective when you move from one vocabulary/context to
another. In general the proportion of badly assigned mappings across
vocabularies tends to be higher than that of badly assigned
relationships within any one vocabulary. (That said, I do not very often
encounter broader/narrower mappings across vocabs; I'm basing that
remark mostly on my observations of equivalence mappings, which are much
more common.) The recommendation of BS8723-4 is to mark the identities
of source and target vocabularies for all mappings, to assist with
interpretation of results at the time when the mappings are applied.
 
 
If you want a copy of BS 8723-4, by the way, it can be obtained from BSI
for 71 pounds (members) or 142 pounds (non-members). The number and
title are:
" BS 8723-4:2007 	Structured vocabularies for information
retrieval. Guide. Interoperability between vocabularies"
" BS 8723-3:2007 	Structured vocabularies for information
retrieval. Guide. Vocabularies other than thesauri"

is available too. Same price.
 
Cheers
Stella
*****************************************************
Stella Dextre Clarke
Information Consultant
Luke House, West Hendred, Wantage, Oxon, OX12 8RR, UK
Tel: 01235-833-298
Fax: 01235-863-298
stella@lukehouse.org
*****************************************************



-----Original Message-----
From: public-esw-thes-request@w3.org
[mailto:public-esw-thes-request@w3.org] On Behalf Of Tudhope D S (AT)
Sent: 28 February 2008 16:10
To: public-esw-thes@w3.org
Cc: public-swd-wg@w3.org
Subject: 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. 
 
published version of BS 8723-4 reads: " 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 should not be used as a mapping from B to A, without
checking its validity in the latter direction. " 

 
...
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.  
published version is unchanged. 

 

  _____  

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.
>