W3C home > Mailing lists > Public > public-esw-thes@w3.org > December 2007

RE: [SKOS] A new proposal for ISSUE-39 ConceptualMappingLinks

From: Stella Dextre Clarke <sdclarke@lukehouse.demon.co.uk>
Date: Mon, 10 Dec 2007 11:12:58 -0000
To: "'Antoine Isaac'" <aisaac@few.vu.nl>
Cc: "'Miles, AJ \(Alistair\)'" <A.J.Miles@rl.ac.uk>, <public-swd-wg@w3.org>, <public-esw-thes@w3.org>
Message-ID: <002001c83b1d$a1cee3c0$0300000a@DELL>

Thanks Antoine,
Brief replies on excerpts below:

> 
> >> First, I'd like to try to summarise the minimum consensus
> >> position. I.e. what's the least we can agree on? ...
> >>
> >> Minimum consensus: Using SKOS, it should be possible to state
> >> broader, narrower, related and exact (equivalent) semantic 
> >> links between concepts from different concept schemes. 
> >>     
> > Agreed. These relationships have stood the test of time in 
> the context 
> > of ISO 2788, BS 5723, ANSI/NISO Z39.19, going back to 1974, for use 
> > within a single concept scheme. They are widely used and 
> understood. 
> > They were always intended to be used for paradigmatic rather than 
> > syntagmatic relationships (in other words, they should apply in a 
> > broad range of contexts, not just on the basis of 
> co-occurrence in a 
> > particular document or set of documents) therefore they ought to be 
> > applicable for use across a range of applications, vocabularies and 
> > resource collections. There seems every reason to mirror them when 
> > designing mappings between vocabularies. (But using a syntax that 
> > makes it clear they are being applied across schemes, not within a 
> > scheme.)
> >   
> 
> I hope suffixing the relation names with "Match" fits such a concern
Yes indeed, adding "Match" conveys the situation rather well I think.

> 
> >> Moving beyond this, I think there a number of issues with our
> >> current proposals which need further discussion.
> >>
> >> I'd like to identify three sub-issues here, which could be
> >> discussed independently. I'll try to separate them out here, 
> >> then respond in more detail to each one in separate mails.
> >>
> >> (ISSUE-39A) Should "grouping" constructs for mapping be
> >> included, and if so, what are their semantics?
> >>     
> >
> > This topic seems to be about mapping from term A to a 
> combination of 
> > Term B and Term C, where the combination could be done with Boolean 
> > AND, OR, or NOT. Somebody asserted that BS 8723 allows use 
> of AND but 
> > deprecates OR. This is only partly true.  BS8723-2, which 
> applies only 
> > to relationships within a thesaurus, indeed recommends avoiding the 
> > use of "A USE B OR C", and explains how to do so. It 
> encourages use of 
> > "A USE B + C" where appropriate (but caution: in practice 
> there is not 
> > much commercially available  software that can handle this complex 
> > 3-way relationship) and it says nothing at all about NOT. 
> In fact, it 
> > steers clear of "AND" too, preferring the symbol "+", so as 
> not to get 
> > hung up on Boolean algebra. BS8723-4, the part of the standard that 
> > has just been published this December, deals with mappings between 
> > vocabularies and has a couple of pages of discussion on one-to-many 
> > and many-to-one mappings (which it does not simply equate to use of 
> > Boolean operators. Instead it recommends use of symbols + 
> and | ). One 
> > of the problems is that the way they work  for conversion of search 
> > statements is different from the way they work  for conversion of 
> > index terms. I think it was Margherita who made the point that 
> > many-to-one is hard to handle, and effectively means that complex 
> > mappings usually work well in one direction only (i.e. 
> one-to-many). 
> > The SKOS community might want to study some good use cases before 
> > reaching conclusions on this issue.
> >   
> 
> Indeed! If you have some links we would be very interested. 
AT the moment the only online examples I can think of are rather
limited; either they steer clear of setting up complex relationships
(understandably, in view of the problems!) or I'm not sure I can
recommend them. I'll try and let you know when I think of some.
 
> Notice that since we have to coin URIs for SKOS construct, I think we 
> will not be able to opt for something like "|" if we want to 
> represent 
> these things.
We pondered for ages before choosing "|", worried mostly about what
symbol would be most widely understood without ambiguity. We still have
to see cases where it is put effectively to use. I have by no means
thought through the issue of when and why you would need to use the
symbol in URIs. Scope for some discussion here, I suggest (if only we
all had time...)

Cheers
Stella

*****************************************************
Stella Dextre Clarke
Information Consultant
Luke House, West Hendred, Wantage, Oxon, OX12 8RR, UK
Tel: 01235-833-298
Fax: 01235-863-298
SDClarke@LukeHouse.demon.co.uk
*****************************************************
Received on Monday, 10 December 2007 11:13:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:38:58 GMT