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

Re: broader and broaderMatch

From: Dan Brickley <danbri@danbri.org>
Date: Thu, 12 Feb 2009 18:52:57 +0100
Message-ID: <499461F9.1000806@danbri.org>
To: Alistair Miles <alistair.miles@zoo.ox.ac.uk>
Cc: Antoine Isaac <aisaac@few.vu.nl>, Christophe Dupriez <christophe.dupriez@destin.be>, SWD Working Group <public-swd-wg@w3.org>, "public-esw-thes@w3.org" <public-esw-thes@w3.org>

On 12/2/09 18:45, Alistair Miles wrote:
> 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.

That makes plenty of sense to me...


Received on Thursday, 12 February 2009 17:53:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:31:55 UTC