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

Re: SKOS ISSUE-39: clarification?

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Tue, 04 Dec 2007 18:02:46 +0100
Message-ID: <47558836.80109@few.vu.nl>
To: "Sini, Margherita (KCEW)" <Margherita.Sini@fao.org>, SWD WG <public-swd-wg@w3.org>, SKOS <public-esw-thes@w3.org>

Hi Margherita,

AND, OR and NOT would be technically deprecated, but I hope that they
will appear in some form in SKOS, as a solution to ISSUE-40, which my
mapping proposal strongly points to.
Actually, coordination of concept is an important problem for me also!
(everything that you say is right, and I do have FAO as a reference use
case for this issue, contrary to what is in the use case document ;-)
But I think it is not specific to the mapping situation. Therefore, I
would like to have it explored at a general level (not doing something
for mapping and then realize that the chosen solution is not ok for
other types of coordination). If that general approach fails, well, then
we could consider the problem from the strict point of view of mapping
again...

Cheers, (and yes, it is a helpful comment to get, again ;-)

Antoine

[1] http://www.w3.org/2006/07/SWD/track/issues/40

> Hi Antoine,
>
> I saw the link:
> http://www.w3.org/2006/07/SWD/wiki/SkosDesign/ConceptualMapping/ProposalTwo
>
> Note that it is proposed to deprecate AND OR and NOT.
>
> Actually, in the mapping we have used in FAO, these are really used a lot.
> BUT, I know that this use, makes the mapping more precise but not
> bi-directional, but only mono-directional....
>
> So we lose precision but we gain in possibility of exploiting the mapping :-)
>
> Hope this helps
> Margherita
>
> -----Original Message-----
> From: public-swd-wg-request@w3.org [mailto:public-swd-wg-request@w3.org] On
> Behalf Of Sini, Margherita (KCEW)
> Sent: 04 December 2007 17:42
> To: Antoine Isaac; Emma McCulloch
> Cc: SKOS; SWD WG
> Subject: RE: SKOS ISSUE-39: clarification?
>
>
> Hi all,
>
> FAO has also worked in a project of mapping the AGROVOC thesaurus to the
> Chinese Agricultural Thesaurus, using the SKOS mapping relations.
>
> I confirm what also Emma pointed out: major and minorMatch were very
> difficult to use and therefore has not been used.
>
> skos:relatedMatch and overlappingMatch were not mentioned when we started the
> project, and therefore the experts used a relationships called "InexactMatch"
> which was somehow mentioned...
> Example:
> 	InexactMatch was used (example: c_34708__Review  InexactMatch
> c_2736_Evaluation_ )
>
> But if I well remember the InexactMatch was deprecated, right?
>
> Personally I think that overlappingMatch is somehow similar to InexactMatch
> ... the idea is always to explain to people that 2 concepts may have
> something in common...
>
> relatedMatch I do not really like very much because seems to me more
> difficult to understand.
>
> Hope this helps
> Margherita
>
>
>
>
> -----Original Message-----
> From: public-swd-wg-request@w3.org [mailto:public-swd-wg-request@w3.org] On
> Behalf Of Antoine Isaac
> Sent: 04 December 2007 16:22
> To: Emma McCulloch
> Cc: SKOS; SWD WG
> Subject: Re: SKOS ISSUE-39: clarification?
>
>
>
> Hi Emma,
>
> Thanks for the quick feedback!
> Actually the fact that some application were rather looking at thesaurus 
> terms was also a reason for introducing skos:relatedMatch, because 
> overlappingMatch is very much resource-oriented (even though I do think 
> it is useful for many cases).
> If you find examples, these would be highly welcome. As already said, my 
> proposal is to be discussed. If the community thinks that one of 
> overlappingMatch or relatedMatch should be dropped, then let it be that 
> way...
>
> Cheers,
>
> Antoine
>
>   
>> Hi Antoine,
>>  
>> Many thanks for your reply; it has definitely cleared a few things up
>> for me.
>>  
>> I totally agree with the proposed deprecation of major and minorMatch.
>> We found it particulary difficult to come up with an example of what might
>>     
> constitute a minorMatch and the division at the 50% point was extremely
> difficult to gague, as you say. I also agree that overlappingMatch is a
> valuable mapping type and will be far more straightforward to apply. I think
> we're finding the application of the mapping vocab quite difficult in HILT
> generally, since SKOS is geared towards equivalence between indexed
> resources, whereas we are looking purely at thesaurus terms with no
> attachment to actual resources.
>   
>>  
>> The platypus/egg example has made things clearer (as has your
>> France/War example) but I believe there will be instances where the
>>     
> distinction between related and overlapping might be more blurred. I'm not
> absolutely convinced that they are sufficiently distinct if both are to be
> used in inter thesaurus mapping. I'll try to find some examples of this in
> our ongoing mapping work.
>   
>>  
>> Thanks again, your response is much appreciated,
>> Emma
>>
>> ________________________________
>>
>> From: public-esw-thes-request@w3.org on behalf of Antoine Isaac
>> Sent: Mon 03/12/2007 21:45
>> To: SKOS; Emma McCulloch
>> Cc: SWD WG
>> Subject: Re: SKOS ISSUE-39: clarification?
>>
>>
>>
>>
>> Dear Emma,
>>
>> I'm very glad to have some comments by someone from HILT! I will try
>> to answer your questions below:
>>   
>>     
>>> 1)       What is the status of this issue and proposal (ISSUE-39)?
>>>
>>>     
>>>       
>> The issue states that there is a requirement for SKOS (i.e. conceptual
>> mapping links) that is not dealt with in the current version of SKOS. 
>> And [1] is a proposal to tackle this issue, by having the SKOS 
>> namespace featuring some constructs devoted to mapping representation. 
>> Even if SKOS mapping (I'll keep the MVS you use for it) is around, it 
>> is not stable and has no official W3C status. Notice that for the 
>> moment [1] has no official status either, it's just a proposal to be 
>> discussed. Your comments/questions are therefore highly welcome.
>>
>>   
>>     
>>> 2)       ISSUE-39 states that Major/minorMatch are deprecated, along with
>>> classes AND, OR and NOT. It also 'transfers' skos:mappingRelation,
>>> skos:exactMatch; skos:broadMatch and skos:narrowMatch from the MVS 
>>> into the standard SKOS vocabulary. Does this mean that the MVS will 
>>> no longer be used
>>> if this proposal is accepted?
>>>
>>>     
>>>       
>> Yes, the current proposal states that MVS would not exist as such any
>> more. Some of its elements would be purely deprecated 
>> (major/minorMatch) while some other would be technically deprecated 
>> but in practice moved to the 'official' SKOS namespace. the latter 
>> case would be true for the mappingRelations, but also perhaps for 
>> AND/OR/NOT. The resolution for the last elements would wait till a 
>> resolution for another issue, ISSUE-40 [2] Notice again that this is a 
>> proposal, which can be adjusted. For example, even if people agree on 
>> removing major/minorMatch, there could be a consensus on keeping the 
>> official mapping vocabulary in the same separate namespace that is 
>> used now (http://www.w3.org/2004/02/skos/mapping)
>>
>>   
>>     
>>> 3)       skos:relatedMatch and skos:overlappingMatch are introduced: could
>>> you please provide a definition of relatedMatch (assuming this is for
>>> inter-thesaurus mapping) and perhaps an example? I'm not clear of the 
>>> distinction between this and overlappingMatch, at a practical level.
>>>
>>>     
>>>       
>> Before answering this question: is the platypus/egg example in [1] not
>> clear enough? If yes, please say so, and I'll try to find another 
>> one...
>>
>> That being said, the difference between relatedMatch and
>> overlappingMatch is not 100% obvious even to me. The main motivation 
>> is that the previous SKOS mapping specification was assuming a quite 
>> 'mechanical', extensional approach to partial mappings. 
>> minor/majorMatch were defined on the basis that resources were 
>> described by both mapped concepts. If I wanted to remove 
>> minor/majorMatch (because I find the 50% criterion too much 
>> arbitrary), I had to find something with the same kind of criterion to 
>> replace them (because I thought there was some point in representing 
>> this "overlapping extensions" situations). So overlappingMatch is 
>> defined as a relation that holds when there is a set of documents 
>> potentially described by the two concepts at the same time. The 
>> problem is that this does not render the associative "related" link 
>> between terms from a thesaurus. Imagine two concepts, "France" and 
>> "War", coming from two thesauri. In a library, there will be an 
>> overlap between the sets of books indexed by the two concepts. Yet, I 
>> dare not imagine that there would be a "related" link between the two 
>> concepts, if they stood withing one single thesaurus. If a searcher is 
>> interested in resources about "France", you will not generally try to 
>> point him to resources about War. In my opinion, this is a case where 
>> you would have an overlapingMatch but no relatedMatch. Does this make 
>> enough sense? (please do not hesitate to say if you are not fully 
>> convinced)
>>
>>   
>>     
>>> 4)       The first version of ISSUE-39 proposed to introduce
>>> skos:equivalentConcept as a replacement for skosm:exactMatch - has
>>> this idea now been dropped?
>>>
>>>     
>>>       
>> Yes. The first proposal tried to deprecate the current MVS as much as
>> possible, and to have it replaced it by the exsiting SKOS semantic 
>> relations (broader, related, narrower, but there is no equivalence 
>> link until now in this part of SKOS). Given that this proposal has not 
>> been very popular, I took the inverse stance, which is to keep mapping 
>> links distinct from semantic relations. I thought that in this case it 
>> would be better to stay as close as possible to the MVS elements.
>>
>> Best regards,
>>
>> Antoine
>>
>> [1]
>> http://www.w3.org/2006/07/SWD/wiki/SkosDesign/ConceptualMapping/Propos
>> alTwo
>> [2] http://www.w3.org/2006/07/SWD/track/issues/40
>>
>>
>>
>>
>>   
>>     
>
>
>   
Received on Tuesday, 4 December 2007 17:02:49 GMT

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