RE: [SKOS] RE : Skos mapping issues

Just a brief note to agree with Libo and with Doug and Ceri that it is
vital (for human users as well as for automated applications) to be able
to distinguish easily between an inter-vocabulary mapping and an
intra-vocabulary relationship. The forthcoming BS8723-4 has some
recommendations for the style of tags which should be used to display
the mappings and the relationships to users.
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
*****************************************************



> -----Original Message-----
> From: public-esw-thes-request@w3.org 
> [mailto:public-esw-thes-request@w3.org] On Behalf Of L.Si@lboro.ac.uk
> Sent: 02 August 2007 16:41
> To: Tudhope D S (AT); Antoine Isaac
> Cc: public-esw-thes@w3.org; public-swd-wg@w3.org
> Subject: Re: [SKOS] RE : Skos mapping issues
> 
> 
> 
> Dear All,
> 
> i just want to say. ...In some situations, end-users may 
> prefer to have a direct look at the mapping and mapping 
> relationship between two concepts from different KOS. If 
> we use the skos:broader to represent the inter-mapping 
> relationship, the end users may be confused with the 
> sources of KOSs.
> 
> In many cases, it is very easy for users to misunderstand 
> the inter-mappings established as intra-mappings. Thus, I 
> strongly suggest the mapping should be particularly 
> presented to the end-users with some clear inter-mapping 
> relationships, (e.g. map:broader, map:majorMatch, etc.). I 
> cannot see any benefit from using skos:broader and 
> skos:narrower to represent them from end-users' points of 
> view.
> 
> There are a lot of project developed based on mapping work 
> to improve the interoperability between KOS, such as, 
> Renardus, HILT, MACS, etc. However, it is difficult to 
> find some excellent services. I just want to ask how the 
> end-users can benefit from the mapping? Will the mapping 
> effort be replaced by merging to a metathesaurus, or 
> mapping to a single ontologies?
> 
> Kind regards
> 
> Libo
> 
> Loughborough University
>   
> 
> 
> On Thu, 2 Aug 2007 12:34:28 +0100
>   "Tudhope D S (AT)" <dstudhope@glam.ac.uk> wrote:
> > Hi Antoine
> > re your points on skos:broader, in_scheme, mapping and
> >KOS extensions:
> > 
> > We agree it is important to know that a concept, or KOS
> >fragment, belongs to a particular scheme. Skos:inscheme 
> >appears a reasonable way of achieving this, within the 
> >constraints of a binary relational modelling framework 
> >like RDF. 
> > 
> > This is a separate issue from applicability of BT across
> >schemes. We do see a difference in the semantics of an 
> >inter-vocab relationship from an intra BT within a vocab. 
> > 
> > In our view, there are 2 quite different kinds of
> >relationship being discussed - local vocabulary 
> >extensions and inter thesaurus mappings between separate 
> >concept schemes (KOS).
> > 
> > To establish a BT relationship the child concept must
> >fall entirely within the scope and context of the parent 
> >concept. When creating local vocabulary extensions, the 
> >new local concept scheme should fully align with the 
> >scope and context of the vocabulary being extended - as 
> >it is the intention to supplement the original with finer 
> >detail. In this case you might reasonably employ 
> >skos:broader in our view. The provenance (eg in-scheme) 
> >is still important - any local extension may be 
> >muddled/controversial etc and an application may decide 
> >not to make use of it.
> > 
> > This is not the same as inter thesaurus mapping though.
> >There is likely to be an inherent mismatch in context and 
> >scope between 2 entirely separate KOS created for 
> >different purposes. A thesaurus (or related KOS) 
> >represents a particular perspective, considered useful 
> >for the various information retrieval purposes on a 
> >domain at a particular point in time. The concepts, the 
> >relationships between them and the language used to 
> >describe them are all contextually relative to the 
> >environment in which they are established. In this 
> >situation, we would argue that skos:broader should not be 
> >used as a mapping relationship between schemes and a 
> >different relationship should be used. There could for 
> >example be a set of skos mapping relationships, including 
> >say broader_mapping. We don't see that this creating any 
> >effective obstacle to semantic web applications but 
> >rather assisting with the semantics.
> > 
> > Returning to local vocabulary extensions, a fine point
> >is that in_scheme identifies the origin of each concept - 
> >but does not identify the origin of each relationship. Is 
> >there any easy way for a local vocabulary to indicate 
> >that it is an extension of an earlier (larger) 
> >vocabulary? It will tend to be the case in Digital 
> >Library type applications that extensions are defined for 
> >some of the major de facto standard vocabularies.
> > 
> > Doug Tudhope & Ceri Binding
> > Hypermedia Research Unit
> > University of Glamorgan
> > 
> > 
> > 
> > ________________________________
> > 
> >From: Antoine Isaac [mailto:aisaac@few.vu.nl]
> > Sent: Sun 29/07/2007 21:43
> > To: Tudhope D S (AT)
> > Cc: public-esw-thes@w3.org; public-swd-wg@w3.org
> > Subject: Re: [SKOS] RE : Skos mapping issues
> > 
> > 
> > 
> > Hi Doug,
> > 
> >> I tend to agree with Javier that it is important to be
> >>able to
> >> distinguish inter-thesaurus mappings from the standard 
> >>intra thesaurus
> >> relationships. It's not clear to me that even the 
> >>'broader/narrower
> >> mappings' necessarily carry the same semantics, although 
> >>there are
> >> some similarities.
> >> - As I see it, mappings usually carry a higher degree of 
> >>uncertainty
> >> (and a lower confidence in any query expansion 
> >>operations).
> > 
> > You might be right, even though in some cases, for query
> >expansion, I
> > would rely more on a mapping (especially for 
> >equivalence) between
> > concepts from different thesauri than on an 
> >inter-thesaurus BT...
> > 
> >> - Another point is that dissolving boundaries between
> >>specific
> >> thesauri (and similar concept schemes) would be counter 
> >>productive.
> >> They are created as a discrete entities, intended to be 
> >>internally
> >> consistent for information retrieval purposes in a 
> >>domain, although
> >> perhaps taking a particular view. So, while you may make 
> >>additional
> >> mappings of different kinds between thesauri, its 
> >>important to retain
> >> the integrity of concepts/relations belonging to the 
> >>same scheme.
> > 
> > I understand your point, but I really don't like this.
> >To having
> > skos:broader allowed between different concept schemes 
> >is an easy way to
> > create local vocabulary extensions, which will improve 
> >vocabulary
> > re-use, and hence bring more added value to the existing 
> >ones.
> > If we are to provide a format to port controlled 
> >vocabularies on the
> > semantic web then I would like not to prevent people in 
> >the future to
> > use these vocabularies in a semantic-web way!
> > 
> > Of course you could argue that this kind of link could
> >be represented by
> > a property different from skos:broader. Do you think 
> >that the *semantic*
> > value (so, apart from e.g. consideration on editorial 
> >control) of a BT
> > 'extension' link would be really different from a BT 
> >inside a vocabulary?
> > 
> > Antoine
> > 
> > PS: allowing for skos:broader between different concept
> >schemes and
> > disconnecting the problem of the 'semantic value' of 
> >skos broader from
> > the one of concept scheme containement [1] are actually 
> >the reasons why
> > in other discussions I defend skos:inScheme. This 
> >property seems to me a
> > less constraining (and more explicit) option for 
> >representing provenance
> > and providing for some editorial control, even if it is 
> >not perfect...
> > 
> > [1] http://www.w3.org/2006/07/SWD/track/issues/36
> > 
> >> 
> >> Doug
> >>
> >> 
> >>------------------------------------------------------------
> ------------
> >> *From:* public-esw-thes-request@w3.org on behalf of 
> >>Antoine Isaac
> >> *Sent:* Mon 23/07/2007 08:10
> >> *To:* jlacasta@unizar.es; public-esw-thes@w3.org
> >> *Cc:* public-swd-wg@w3.org
> >> *Subject:* [SKOS] RE : Skos mapping issues
> >>
> >> [Sorry I skept the subject in previous posting]
> >>
> >> Hi Javier,
> >> >
> >> >
> >> >
> >> > Hi All,
> >> >
> >> > I am interested in the mapping of thesauri, so I have
> >>been reviewing the
> >> > documentation available in the SKOS-Project. It seems
> >>that there is
> >> three main
> >> > documents related with SKOS mapping in SKOS project
> >>[1,2,3].
> >>
> >> Oops now I've realized that it was not so smart of me to
> >>release 3,
> >> because I have missed 2. And there are indeed some 
> >>similarities
> >> between the two, which is normal since I intended to 
> >>make an account
> >> of a SWD discussion in which Alistair played an 
> >>important role. Some
> >> synchronization should be done, so your discussion is 
> >>useful (and my
> >> main intent behind [3] was also to revive this 
> >>discussion :-)
> >>
> >> >
> >> > Each one present a quite different approach to mapping
> >> representation. The last
> >> > two documents it seems that try to simplify the skos
> >>mapping vocabulary.
> >> >
> >> > They map the partial and inexact equivalence
> >>relationships to other
> >> existent
> >> > relations in SKOS core. The partial relationship is
> >>mapped to
> >> skos:broader and
> >> > skos:narrower and the inexact is mapped or to
> >>skos:related or to a new
> >> > skos:overlappingConcept.
> >> >
> >> > I agree that the semantic of the partial equivalence
> >>relationship is
> >> equivalent
> >> > to the broader and narrower relationship. However, I
> >>think that the
> >> use of the
> >> > same property would difficult the identification of
> >>the mappings
> >> respect to the
> >> > basic ones.
> >>
> >> This is the crucial problem. The semantics are the same,
> >>so we should
> >> make them a same property.
> >> Ideally the identification problem is distinct (in our 
> >>working group
> >> we recorded it as [5]), so it should not intefere.
> >> But of course in practice [5] is very difficult to solve 
> >>in RDF, so in
> >> the end we might have to consider more than the 
> >>semantics to define a
> >> property.
> >>
> >> > I think that at least the namespaces should be changed
> >>(e.g:
> >> > skosm.broader). This properties can be an
> >>specialization
> >> > of the basic ones. This would facilitate the
> >>separation of the
> >> mappings to the
> >> > core structure of each thesauri.
> >>
> >> Problem is that specializing skos:broader might collide
> >>with the need
> >> to identify a skos:broader statement in a scheme in a 
> >>way similar to
> >> the one you want to identify a mapping. Some people (cf 
> >>[6]) would
> >> like skos:broader statements to hold only between 
> >>concepts from one
> >> scheme.
> >> I'm not a strong believer of this, but I certainly think 
> >>that if we
> >> want to record mapping identification by creating a 
> >>special property
> >> we should not make identification of intra-thesaurus 
> >>links even more
> >> difficult than what it is now.
> >>
> >> >
> >> > I do not agree with the use of skos:related as inexact
> >>equivalence
> >> exposed in
> >> > [2]. I think they are different. An inexact
> >>equivalence indicates
> >> > that two concepts share some meaning and that not
> >>always happen with
> >> the more
> >> > general skos:related relationship.
> >> > A inexact equivalence relationship can be seen as an
> >>specialization of
> >> > skos:related given that indicate a relationship
> >> > between the concepts but not in the other way.
> >>
> >> +1
> >>
> >> >
> >> > Respect to the compositions of mappings through "and",
> >>"or" and "not"
> >> > relationships I think that to be able to create
> >>complex compositions as
> >> > (A and B and (C or (D and E))), it would be needed a
> >>specialization
> >> of skos
> >> > concept (called for example conceptCollection) to
> >>group all the composed
> >> > concepts and the type of composition.
> >> >
> >> > I see that there are some similarities in the "and"
> >>relationship
> >> respect to the
> >> > pre-coordination of labels in a thesaurus, and also 
> respect to the 
> >> > composition in USE relationship to
> >>refer from a
> >> complex label to
> >> > two simpler ones. However, I think they are
> >> > some semantic differences between the "and" and the
> >>coordination
> >> making them not
> >> > completely interchangeable.
> >>
> >>
> >> This was the point in [3] to treat this "and" problem in
> >>the context
> >> of a different coordination problem which is on the SWD 
> >>agenda [4]
> >> Your point about "and" and pre-coordination is valid. 
> >>There are case
> >> of complex mappings with conjunctions that could well 
> >>correspond to
> >> post-coordination cases, and [4] is too narrow for this.
> >> So we should re-introduce post-coordination in the loop 
> >>by means of
> >> some specific "and". Something which semantics should be 
> >>roughly
> >> if x match (y andpostcoord z) then (if doc skos:subject 
> >>x then doc
> >> skos:subject y and doc skos:subject z )
> >>
> >> I think it is still a good idea to separate it from
> >>pre-coordination:
> >> in my current view (and I learned a lot reading the wise 
> >>posts of this
> >> list, and could continue learning)
> >> A mapping to a pre-coordination is a mapping to a 
> >>single, even if
> >> complex, subject: the semantics would not imply infering 
> >>new
> >> skos:subject triples. In this case the problem is 
> >>delegated to [4]
> >> A mapping to post-coordination would involve several 
> >>subjects, as
> >> mentioned in the previous rule
> >> Would such an approach alleviate your concerns?
> >>
> >> Best,
> >>
> >> Antoine
> >>
> >> >
> >> > [1] http://www.w3.org/2004/02/skos/mapping/spec/
> >> > [2]
> >>http://isegserv.itd.rl.ac.uk/public/skos/press/dc2006/mapping.html
> >> > [3]
> >> 
> http://www.w3.org/2006/07/SWD/wiki/SkosDesign/>
ConceptualMapping/Propo
> >> salOne
> >> [4] http://www.w3.org/2006/07/SWD/track/issues/40
> >> [5] http://www.w3.org/2006/07/SWD/track/issues/47
> >> [6] http://www.w3.org/2006/07/SWD/track/issues/36
> >>
> > 
> > 
> > 
> 
>   
> 
> 
>

Received on Friday, 3 August 2007 09:31:54 UTC