Re: broader and broaderMatch

Hi Antoine,

On Mon, Feb 02, 2009 at 11:51:22AM +0100, Antoine Isaac wrote:
> Hi Alistair,
>
> By the way I've got doubts with wrt. to these contraints we put on mapping properties via the axioms you cite:
>
> Consider two concepts schemes, one with ex1:birds and the other with ex2:feathers.
>
> I can imagine that, from the perspective of someone who is keen on using the ISO 2788 "broader-term-partitive" modelling approach, it makes sense to assert:
> ex2:feathers skos:broadMatch ex1:birds
>
> Now, for someone else with a stricter approach to hierarchy definition (inspired by subClass links in RDFS/OWL, in which the only specializations of birds can be specific kind of birds, e.g. eagles), it would make sense for her to assert rather:
> ex2:feathers skos:relatedMatch ex1:birds
>
> Our axioms imply that *the two RDF datasets cannot be used at the same time without raising formal inconsistency*. Is that really what we want?
> I agree that someone would not want to use both at the same time wihout dealing with provenance mechanisms (like SPARQL named graphs) to sort them out. But even then it would not be possible to deploy that on a unified dataset. While it could make sense to have datasets (as Jon's metadata registry) which are devoted to store all mappings available for a given concept scheme.

Yes, I can see that under some circumstances, partitive relationships
might be modeled as either broader or related mappings, and that this
could give rise to inconsistencies where data from two independently
created mappings are merged.

But I don't think I would want to change the spec. I think it is fine
for the merge of two such mappings to be inconsistent wrt the SKOS
data model. In such a case, the inconsistency highlights the fact that
strange application behaviour might result from using both mappings
combined. But how a tool or person should respond to such an
inconsistency is not defined by the SKOS reference, so an application
is not required to reject such data.

Cheers,

Alistair


>
> Cheers,
>
> Antoine
>
>
>> 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
>>>
>>
>>
>

-- 
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 17:46:38 UTC