RE: SKOS ISSUE-39: clarification?

For the lists...

> Dear Antoine,
>
> Yes... sorry i get now to the email were you were sending 
> conclusions... Anyway here my comments for you. Just to double 
> check...
>
> 1) 39-C Concerning: inexactMatch, overlappingMatch, relatedMatch 
> Summarizing this is the situation:
> 	inexactMatch is deprecated
> 	overlappingMatch is dropped
> 	relatedMatch is maintained
>
> I agree with Leonard: relatedMatch is different from overlappingMatch.
> I would say that all "overlappingMatch" may be considered "relatedMatch",
but
> it is not true the opposite... Anyway is the distinction useful for SKOS
> thinking what the uses can do of  (or how they can use) the mapping file in
> searches?
>
> My idea is that depends on what level of precision we would like the 
> user are able to express. Keeping in mind we are just at the beginning 
> and maybe all this skos mappings is not soo much used, ok for me to 
> have less precision and basically maintain the generic relatedMatch. 
> (although i would have vote for a different solution).
>
> By the way: this doc 
> http://www.w3.org/2004/02/skos/mapping/spec/2004-11-11.html will need 
> to be updated with the conclusions, right?
>
> 2) 39-A: "grouping" constructs
>
> I think that "grouping" constructs such as "AND", "OR", "NOT" 
> (whatever symbol we use to represent them) may not be so difficult to 
> understand, and they may be useful to make a better mapping, more 
> precise... But as i was mentioning the mapping that uses those will be 
> only monodirectional, which is not very good. Performing a less 
> precise but a bidirectional mapping may have more uses...
>
> However just to let you know, over a mapping project that mapped 64635 
> terms from one thesaurus to a 38000 terms thesaurus (counting only 1 
> language), there were 1747 relations using AND, OR, NOT and "No 
> Mapping". The other relations were: 13105 ExactMatch relation, 11408 
> BroadMatch relation, and 173 NarrowMatch relation. So... basically 
> more "grouping" than narrowMatches....
>
> Again, it depends on the precision we want the user be able to express 
> and what we want they can do with the mapping file....
>
> 3) 39-B: parallel vocabulary for mapping
>
> Yes, I like that: i like the idea to keep distinct the mapping 
> vocabulary from the intra-thesaurus relationships. A parallel, as 
> proposed, is welcome.
>
> Sorry i was late... but now i understood better that i have to follow 
> up more frequently... Margherita
>
> -----Original Message-----
> From: Antoine Isaac [mailto:aisaac@few.vu.nl]
> Sent: 11 December 2007 15:14
> To: Sini, Margherita (KCEW)
> Subject: Re: SKOS ISSUE-39: clarification?
>
>
> Hi Margherita,
>
> This would be very welcome! but timing is tight on this issue ;-)
>
> Antoine
>
>   
>> ok I will read the other emails about issue 39 and then come back 
>> with
>> a global answer....
>>
>> wait for my feedback.... :)
>>
>> -----Original Message-----
>> From: Antoine Isaac [mailto:aisaac@few.vu.nl]
>> Sent: 04 December 2007 20:21
>> To: Sini, Margherita (KCEW)
>> Cc: SKOS; SWD WG
>> Subject: Re: SKOS ISSUE-39: clarification?
>>
>>
>> Hi Margherita,
>>
>> Thanks for the comments on minor/majorMatch!
>>
>>   
>>     
>>> (example: c_34708_ÆÀÊö_Review  InexactMatch
>>> c_2736_Evaluation_ÆÀ¹À )
>>> But if I well remember the InexactMatch was deprecated, right?
>>>   
>>>     
>>>       
>> I guess so. But of course there is nothing preventing you to create
>> your own mapping property until some workgroup finds something fitting 
>> the situation
>> ;-)
>>   
>>     
>>> 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.
>>>   
>>>     
>>>       
>> :-( the discussion we had today in our teleconf just concluded in the
>> opposite direction: we would drop overlappingMatch, and keep 
>> relatedMatch. The motivation for it was that overlapping was a bit too 
>> specific (Alistair came with examples about overlapping time periods) 
>> Also, while the distinction between related and overlapping is not 
>> 100% clear, keeping relatedMatch/broadMatch/narrowMatch makes a more 
>> coherent counterpart to the standard broader/narrower/related semantic 
>> relations of SKOS.
>>
>> In the end, the more I think about it, the more I'm convinced that
>> people have so different situations in mind for these two variants of 
>> "inexact" match could fit. You say that "inexact" means "having 
>> something in common", and your example about Review and Evaluation 
>> could well be a "related" link if the two concepts were in a same 
>> concept scheme...
>>
>> But of course I might be wrong. Your feedback (as well as Emma's and
>> other's) would be very interesting here.
>>
>> Cheers,
>>
>> Antoine
>>
>>   
>>     
>>> -----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/Prop

>>>> os
>>>> alTwo
>>>> [2] http://www.w3.org/2006/07/SWD/track/issues/40

>>>>
>>>>
>>>>
>>>>
>>>>   
>>>>     
>>>>       
>>>>         
>>>   
>>>     
>>>       
>>
>>   
>>     
>
>   

Received on Tuesday, 11 December 2007 15:52:53 UTC