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

Re: broader and broaderMatch

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Thu, 12 Feb 2009 19:42:40 +0100
Message-ID: <49946DA0.7020907@few.vu.nl>
To: Dan Brickley <danbri@danbri.org>
CC: Alistair Miles <alistair.miles@zoo.ox.ac.uk>, 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...

OK, I think I can also buy that position, if I understood it correctly (something like "You can do whatever you want with your SKOS data, but we, as a standardization body, decide that it is fully legitimate for other SKOS applications to ignore or reject what you've been doing on certain points"?).
In fact it is already specified verbatim in the Reference. I think I just interpreted it differently when there was a discussion on the disjointness between skos:Concept and skos:ConceptScheme [1].

Thanks for the answers, the issue had got me pretty worried when I first spotted it :-)


[1] http://www.w3.org/2006/07/SWD/track/issues/129
Received on Thursday, 12 February 2009 18:43:42 UTC

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