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

Dear Christophe,

First, let me say that I appreciate that this discussion takes place, even though I may sometimes take much time to answer...

About the need for SKOS to implement BT as defined in ISO standards. I understand your concern, and indeed we have designed skos:broader having ISO-BT in mind, and trying to "mirror" it (see the section on comparing ISO with SKOS in the Primer [1]). But I'd like to remark that it is nearly impossible to fit exactly what BT is.

First, ISO are term-based thesaurus standards: therefore, there will be discrepancies, if just because SKOS is concept-based. 

Second, ISO (especially 2788) was designed at a time thesauri were closed systems. On a the Semantic Web environment, we expect that this could change pretty easily, just as people now already re-use and extend each other's ontologies.
Note that this is not per se a requirement that we explicitly encountered in our Use Cases. Yet, it seemed to us harmful to close that option for a semantic web standard. Especially when it is very easy (e.g. using SPARQL queries) to distinguish between skos:broader statements that hold within a single concept scheme, and skos:broader statements that hold between concept schemes.

Now, maybe this difference should be emphasized in [1], e.g. by adding something like "Further, because of the highly networked aspect of the Semantic Web, we let open the possibility that (future) KOSs may be designed as networks, with concepts in one KOS being defined as extensions or refinements of other KOSs' concepts.", in the line of what is already discussed in the section on re-using/extending KOSs [2]. Your input on this would be warmly welcome.

Of course this should not prevent people to create their own extensions, if they feel that it is crucial to have a property which certainly holds within single schemes. But given what I've discussed here, we did not feel that need for the core vocabulary.

A final comment, about my dubious feather/bird example. I understand your objections, and your own examples. But ISO 2788 does introduce a "broader-partitive" relation, giving examples like "Arteries BT(P) Cardio-vascular systems" or "Blades BT(P) Compressors". It does not say it should be done like that. But still, some part-whole relations from some thesauri may be converted as skos:broader statements, which is acknowledged in the introduction of [3].

Cheers,

Antoine

[1] http://www.w3.org/2006/07/SWD/SKOS/primer/primer-20090113.html#seccorrespondencesISO
[2] http://www.w3.org/2006/07/SWD/SKOS/primer/primer-20090113.html#secextension
[3] http://www.w3.org/2006/07/SWD/SKOS/primer/primer-20090113.html#secrel

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

Received on Saturday, 7 February 2009 14:53:12 UTC