Re: URI policy for thesaurus concepts

Dan Brickley wrote:

>* Bernard Vatant <bernard.vatant@mondeca.com> [2004-04-30 17:36+0200]
>  
>
>>To go along with Dan ...
>>
>>I also prefer the / approach in principle because it defines more neatly the "subject
>>indicator", but consider that e.g. OWL uses fragment identifiers to define classes and
>>properties ...
>>
>>Will not people be confused with OWL elements defined by
>>http://example.org/myontology#class001
>>and SKOS concepts defined by http://example.org/myskos/concept001
>>    
>>
>
>Some RDF/RDFS/OWL vocabs end in a / and others end in a # and others do
>other things. This is the current state of affairs. The confusion is
>only a problem because these different approaches have different
>technical and standards characteristics (and those aren't well
>explained, currently).
>  
>
This calls for engineering guidelines, which probably means the issue 
should be shunted onto the SWBPD WG.

>>And having, e.g. for GEMET, over 8000 different resources/concepts, if you just want to
>>download the whole stuff, hmm...
>>Is not it more simple to have a / namespace for a whole SKOS scheme, and # for each
>>concept in it?
>>
>>We've been through this in Published Subjects TC, without clear conclusion ...
>>    
>>
>
>I've a few years experience using the http://xmlns.com/wordnet/1.6/Cat
>etc approach, and have to say it is useful. The ability to return a
>useful chunk of information from a larger dataset is something I am
>reluctant to give up. Surely in the future we'll have richer (SKOS API,
>RDF DAWG etc) interfaces to these datasets, but the current approach can
>be implemented with a simple filetree or CGI script, and has proved
>reasonably popular.
>  
>
Yes, this approach is immediately useful. I suspect it would be sensible 
for any future interfaces to retain the http://xmlns.com/wordnet/1.6/Cat 
kind of behaviour. This is akin to getting the concise bounded 
description of the resource, which as an RDF representation over http in 
RDF/XML seems to make a lot of sense. Similarly, for the root "service" 
URI it would probably be consistent, and make pragmatic sense for the 
default RDF representation returned to be a concise description of the 
service rather than the whole caboodle. Having a recommended means of 
retrieving the whole dataset may well be useful, but I'm not sure how 
this could be done without conflicting with general architectural 
requirements. All that comes to mind is use of the same URI but content 
negotiation for an "application/rdf+kitchensink" mime type.

Cheers,
Danny.

-- 
----
Raw
http://dannyayers.com

Received on Thursday, 6 May 2004 04:43:03 UTC