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

On Fri, Feb 13, 2009 at 10:03:21AM +0100, Antoine Isaac wrote:
>
> Hi Alistair,
>
> Christophe's approach to using broadMatch in his case is quite legitimate 
> imho. 

Yes, quite legitimate. I was just making a suggestion.

Alistair.


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

-- 
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 Friday, 13 February 2009 17:51:04 UTC