Re: broader and broaderMatch

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.

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

Received on Monday, 2 February 2009 10:51:58 UTC