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

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
>>
>>     
>
>
>