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

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
> 


-- 
Alistair Miles
Senior Computing Officer
Image Bioinformatics Research Group
Department of Zoology
The Tinbergen Building
University of Oxford
South Parks Road
Oxford
OX1 3PS
United Kingdom
Web: http://purl.org/net/aliman
Email: alistair.miles@zoo.ox.ac.uk
Tel: +44 (0)1865 281993

Received on Thursday, 12 February 2009 18:14:54 UTC