W3C home > Mailing lists > Public > public-swbp-wg@w3.org > November 2004

Re: [PORT] Concept identification and reference

From: Charles McCathieNevile <charles@w3.org>
Date: Tue, 9 Nov 2004 17:13:19 -0500 (EST)
To: Carl Mattocks <carlmattocks@checkmi.com>
Cc: "Miles, AJ (Alistair)" <A.J.Miles@rl.ac.uk>, "'public-esw-thes@w3.org'" <public-esw-thes@w3.org>, "'public-swbp-wg@w3.org'" <public-swbp-wg@w3.org>
Message-ID: <Pine.LNX.4.55.0411091703250.9544@homer.w3.org>

On Thu, 4 Nov 2004, Carl Mattocks wrote:

>at Al :
>Given this group is the source of best practice for using 'RDF
>descriptions of existing thesauri ' I do not think you can be neutral.

Well, we can say "we don't know".

>Pragmatically, until all controlled vocabulary authors employ a common
>central / federated / peer to peer facility that helps them understand
>when a concept has a URI , SKOS guidelines will have to explain ;
>(1) the value of the 'owl:sameAs machinery' which enables multiple
>published URIs to exist for the same concept
>(2) how reference by description may be used to refer to such concepts
>from other (RDF) descriptions.

I think it is worth saying how you implement this stuff. OWL's same as,
equivalentThingies, etc. Using a SPARQL query you can describe the things
you're looking for, too.

>> So the choice I see boils down to:
>> When describing best practise for creating RDF descriptions of thesauri
>> without official URIs, do we ...
>>  (a) attempt to remain neutral about whether people make up unofficial
>> URIs,
>> and rely on the owl:sameAs machinery to cope with multiple published URIs
>> for the same concept, or ...
>>  (b) actively encourage the publication of these thesauri with concept
>> nodes
>> as blank nodes, and additionally publish guidelines on how reference by
>> description may be used to refer to such concepts from other RDF
>> descriptions (which may depend on rules technology without any current
>> standard implementations).
>> What do you think ???

Personally I think it is worth saying "these are the options, these are the
solutions to the prolems they raise (which are...), take your pick". For
simple use cases I prefer the first approach, if there are indeed simple
common tools for resolving the information afterwards, because it is simple.

For doing stuff that involves deep thinking I prefer the latter, because it
allows us to reflect what happens in the real world (which is that there
isn't so much interoperaility as we want, because we don't think on the same
lines). But I think it is easier to explain, and explain its value, to people
who have run into the problems of identity that you only get to if you have a
complex use case (or series that build up to one).

just my 2 cents.


Received on Tuesday, 9 November 2004 22:13:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:09:40 UTC