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