W3C home > Mailing lists > Public > public-swd-wg@w3.org > February 2009

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

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Fri, 13 Feb 2009 10:03:21 +0100
Message-ID: <49953759.5090901@few.vu.nl>
To: Alistair Miles <alistair.miles@zoo.ox.ac.uk>
CC: Christophe Dupriez <christophe.dupriez@destin.be>, SWD Working Group <public-swd-wg@w3.org>, "public-esw-thes@w3.org" <public-esw-thes@w3.org>

Hi Alistair,

Christophe's approach to using broadMatch in his case is quite legitimate imho. 

SKOS is about representing hierarchies that are not as precise as OWL ones. As a matter of fact, we do not really make strict recommendations on what a "broader" and "related" is from an ontological perspective.
I find therefore very difficult to say that someone should create his/her own ontology instead of using our standard one, because it would not fit semantics that we do not explicitly mention anyway. This is especially true for mapping properties, for which we say that they can have an even more fuzzy or application-specific flavor, compared to the BT/RT flavor we mention as a reference for broader/related. 

Note that Christophe's scenario makes me think to some geographically-organized web directory. I think there is no counter-indication using SKOS for this.

Of course then we can argue agains the broadMatch/broader subproperty pattern that makes this vision especially difficult to explain (because, yes, it makes broader more different from BT than it would be if broadMatch was not specializing it) as Christophe noted in [1]. 

Cheers,

Antoine

[1] http://lists.w3.org/Archives/Public/public-esw-thes/2009Feb/0028.html


> Hi Christophe,
> 
> On Mon, Feb 02, 2009 at 11:25:11AM +0100, Christophe Dupriez wrote:
>> 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.
> 
> I may not be understanding you correctly, but I would use a different
> property to connect an author to her country of birth. I would then
> use an expansion rule to capture this specific behaviour in a
> retrieval system. There may not be a suitable property already defined
> in some ontology ... (/me looks at FOAF, finds nothing, maybe danbri
> knows of something?) ... in which case you'd have to define your own.
> 
> But let's say you defined ex:countryOfBirth as an RDF property.
> 
> The SPARQL construction...
> 
> CONSTRUCT
> {
>   ?x dcterms:subject ?country .
> }
> WHERE
> {
>   ?x dcterms:subject ?person .
>   ?person ex:countryOfBirth ?x .
> }
> 
> ... would be one way to precompute this expansion. Alternatively you
> could expand retrieval queries on the fly, e.g.
> 
> SELECT ?x
> WHERE
> {
>   {
>     ?x dcterms:subject ex:UnitedKingdom .
>   }
>   UNION
>   {
>     ?person ex:countryOfBirth ex:UnitedKingdom .
>     ?x dcterms:subject ?person .
>   }
> }
> 
> (assuming for this query that the default graph is the merge of both
> the retrieval metadata and the concept scheme, otherwise you could use
> named graphs if you wanted to keep them separate).
> 
> Hth,
> 
> Alistair
> 
>> 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
>>>>
>>>>     
>>>
>>>   
> 
>> 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 Friday, 13 February 2009 09:04:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 13 February 2009 09:04:06 GMT