- From: Sini, Margherita (KCEW) <Margherita.Sini@fao.org>
- Date: Tue, 11 Dec 2007 16:52:30 +0100
- To: public-swd-wg@w3.org, public-esw-thes@w3.org
- Cc: Antoine Isaac <aisaac@few.vu.nl>
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