Re: broader and broaderMatch... and BT???

Hi Christophe,

Your need to "distinguish between internal thesaural relations (controled as being partitive / is-a / ... ) and mappings to other concepts (another scheme) made for "practical" reasons."
lies actually at the root of another discussion we had on the SWD list [1]
At the time it was argued by some (Alistair and Dan) that there was no real motivation to represent this distinction. Thanks for bringing a case that examplifies that requirement...

Note that for some reason the main problem of passing the message seems to be to put a convincing one-word label to the "internal/thesaural/controlled "broaders"" on which you are also stumbling upon ;-)
(see our many attempts there of turning to notions such as "authority", "inherence", "application-dependance", "qualified asserter"...)

Cheers,

Antoine

[1] http://lists.w3.org/Archives/Public/public-swd-wg/2009Jan/0048.html


> Alistair, thank you very much for answering thoroughly!
> 
> My need is to distinguish between internal thesaural relations 
> (controled as being partitive / is-a / ... ) and mappings to other 
> concepts (another scheme) made for "practical" reasons.
> 
> As I explained before, my need is to be able to retrieve documents by 
> authors birth country (soon to be installed at 
> http://www.windmusic.org/dspace/records-search currently in 
> development). "Country of birth" is certainly not a "broader" for an 
> author in a thesaural (or authority list) approach but it may be mapped 
> as "broader" for some pragmatic goal (here: being able to retrieve 
> documents by authors place of birth). This is the meaning I gave to 
> "broadMatch": I understand I am wrong.
> 
> If I understand your explanation:
> "broader" can be used to link to any useful "broader" (for any use)
> and "broadMatch" is to signal those which are mappings amongst them (in 
> that case, "broadMatch" implies "broader" and not the contrary).
> Do I understand your answer below correctly?
> 
> I do not feel fully comfortable with this. I would like to label more 
> strict internal/thesaural/controlled "broaders"  (a new BT relation !?).
> I would then suggest to add the classical semantical thesaural relations 
> in SKOS to be able to express the desired internal control over them 
> (for instance no hierarchichal links crossing (micro-)thesaurus 
> boundaries).
> 
>  From my point of view, it is not because SKOS brings RDFS/OWL 
> expressiveness and precision that decades of ISO thesauri investments 
> should be forgotten: I would really appreciate to find straightforward 
> SKOS equivalences to BT/NT/RT/USE/UF
> 
> A problem with any hierarchy of relations specialisation is that if 
> relation XX specializes relation X, you may often need to label also the 
> relation "X but not XX".
> 
> Still all my thanks for your patient explanations!
> 
> Christophe
> 
> P.S. At http://www.windmusic.org/dspace, SKOS based concept 
> management/retrieval is integrated for every control-list. Still in 
> development.
> 
> Alistair Miles a écrit :
>> Hi Christophe,
>>
>> Section 10.6.1 of the SKOS Reference current editors' draft [1]
>> states:
>>
>> "By convention, the SKOS mapping properties are only used to link
>> concepts in different concept schemes. [...] The mapping properties
>> skos:broadMatch, skos:narrowMatch and skos:relatedMatch are provided
>> as a convenience, for situations where the provenance of data is
>> known, and it is useful to be able to tell "at a glance" the
>> difference between internal links within a concept scheme and mapping
>> links between concept schemes."
>>
>> So skos:broadMatch is intended for the special case where concepts
>> from different schemes are being mapped. I expect that tools for
>> translating information retrieval queries using one KOS into queries
>> using another, or for translating metadata statements from one KOS to
>> another, will make use of these special mapping properties to drive
>> these transformations.
>>
>> The properties skos:broader, skos:narrower and skos:related establish
>> the basic expectations for broader/narrower (hierarchical) and related
>> (associative) links. For example, [S27] establishes that
>> broader/narrower links are disjoint with associative (related) links.
>>
>> The mapping properties skos:broadMatch, skos:narrowMatch and
>> skos:relatedMatch extend (refine) the properties skos:broader,
>> skos:narrower and skos:related [S41]. That means they also effectively
>> "inherit" these basic expectations. I.e. by virtue of [S27] and [S41],
>> broader/narrower mapping links are disjoint with associative mapping
>> links.
>>
>> Can you describe your practical development issues in more detail?
>>
>> Many thanks,
>>
>> Alistair
>>
>> [1] http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/#mapping
>> [S27] http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/#S27
>> [S41] http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/#S41
>>
>>  
>>> For me:
>>> <A> broader <B> implies <A> broadMatch <B>
>>> but not <A> broadMatch <B> implies <A> broader <B>
>>>
>>> You can branch me to some document or tutorial (supplement to specs  
>>> chapter 10.6) as this is a rather basic question!!!
>>> This question is not "academic" as it is related with practical  
>>> development issues.
>>>
>>> Thanks!
>>>
>>> Christophe
>>>     
>>
>>  
>>> begin:vcard
>>> fn:Christophe Dupriez
>>> n:Dupriez;Christophe
>>> org:DESTIN inc. SSEB
>>> adr;quoted-printable:;;rue des Palais 44, bo=C3=AEte 
>>> 1;Bruxelles;;B-1030;Belgique
>>> email;internet:Christophe.Dupriez@Destin.be
>>> title:Informaticien
>>> tel;work:+32/2/216.66.15
>>> tel;fax:+32/2/242.97.25
>>> tel;cell:+32/475.77.62.11
>>> note;quoted-printable:D=C3=A9veloppement de Syst=C3=A8mes de 
>>> Traitement de l'Information
>>> x-mozilla-html:TRUE
>>> url:http://www.destin.be
>>> version:2.1
>>> end:vcard
>>>
>>>     
>>
>>
>>   
>

Received on Monday, 2 February 2009 11:02:02 UTC