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/ProposalOne
>> [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 Thursday, 2 August 2007 23:29:04 UTC