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

Dear Antoine,

Reading this (and seing my (reasonable) difficulties to apply SKOS to 
real life problems), I would like to insist that the frame defined by 
previous ISO standards for thesauri be kept and supplemented. This may 
seem bottom-up compared to the apparent top-down process to define SKOS: 
it is alway better when stalagmites join stalagtites !

For my own stuff, I will implement:

skos:semanticRelation
 |
 +- skos:related
 |   |
 |   +- ???:RT
 |   |  (disjoint from)
 |   +- skos:relatedMatch
 |
 +- skos:broaderTransitive (disjoint from related and narrowerTransitive)
 |   |
 |   +— skos:broader
 |       |
 |       +- ???:BT
 |       |  (disjoint from)
 |       +- skos:broadMatch
 |
 +— skos:narrowerTransitive (disjoint from related and broaderTransitive)
     |
     +- skos:narrower
         |
         +- ???:NT
         |  (disjoint from)
         +- skos:narrowMatch


Please note that "BT <union> broadMatch" does not cover "broader" 
because "broader" may cross scheme boundaries and "BT" cannot.
If you add the concept of "subScheme" (micro-thesaurus), "BT" should not 
cross micro-thesaurus borders.

With "RT", you can cross micro-thesaurus borders but not scheme boundaries.

But all this, you probably know better than me: I am computerizing those 
for decades, not USING them...

I sincerely hope that "???" above will be replaced by "skos" !!!

For the "feather" and the "bird", a "feather" cannot gives birth to a 
"bird" (it is not a "kind of" bird): it should not be an NT in a taxonomy.
It could be a "functional" narrower= narrowMatch (if you are interested 
in "bird", the application designers may judge you will be always 
interested by "feather") but it is rarely the case. It is certainly an 
RT (if you are interested by birds, you may be interested by feathers).

All this because "feather" is appearing somewhere else in another kind 
of classification:
- anatomical composition of living beings
- clothes industry
- ...

This means that "feather" will probably be in a different scheme than 
"bird" (controlled by different people): an relatedMatch or a even a 
narrowerMatch (if automatic query expansion is judged useful) will be 
just nice.

In Belgium Poison Centre, we continuously have this kind of problems 
because we use together biological or chemical taxonomies, 
classification by use, toxicological classifications, pharmaceutical 
effect classification, etc. The thesaural conceptual frame has been 
proven valid for decades. I would like it to migrate within SKOS (When 
we will "align" with the MeSH, SKOS mapping relations will be 
essential). I add my colleagues in copy.

Have a nice day!

Christophe

Antoine Isaac a écrit :
>
> 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
>>>>
>>>
>>>
>>
>
>
>
>