Re: [SKOS] RE : Skos mapping issues

Hi all

Just to say +1 with Stella, Doug and Ceri on this.
I've already defended this view previously, so won't  repeat the 
arguments. See below posts

http://lists.w3.org/Archives/Public/public-esw-thes/2007Jun/0034.html
http://lists.w3.org/Archives/Public/public-esw-thes/2007Jul/0015.html

Bernard

Stella Dextre Clarke a écrit :
> 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
>>>>
>>>>         
>>>
>>>       
>>   
>>
>>
>>
>>     
>
>
>
>
>   

-- 

*Bernard Vatant
*Knowledge Engineering
----------------------------------------------------
*Mondeca**
*3, cité Nollez 75018 Paris France
Web:    www.mondeca.com <http://www.mondeca.com>
----------------------------------------------------
Tel:       +33 (0) 871 488 459
Mail:     bernard.vatant@mondeca.com <mailto:bernard.vatant@mondeca.com>
Blog:    Leçons de Choses <http://mondeca.wordpress.com/>

Received on Friday, 3 August 2007 10:17:16 UTC