Re: URIs for Concepts: Best Practices

cc- public-esw (this is relevant now to the thesaurus, and is relevant to the
best practices working group)

On Tue, 20 Apr 2004, Kal Ahmed wrote:

>
>On Mon, 2004-04-19 at 22:22, David Menendez wrote:
>> Miles, AJ (Alistair)  writes:
>>
>> > I wanted to consult you all on this matter.  I have agreement from
>> > the EEA to publish the GEMET environmental thesaurus in the SKOS/RDF
>> > format.  The next step is to work out with them the URIs they wish to
>> > assign to their thesaurus and concepts.  I'm not sure what to
>> > recommend to them on this matter.
>>
>> Dan Brickley's Wordnet vocabulary service[1] at xmlns.com seems like a
>> useful model. Essentially, each concept is given a (non-fragmentary) URI
>> which, if dereferenced, returns a description of the concept. Mr
>> Brickley's system only returns RDF/XML presently, but there's no reason
>> it couldn't also return HTML or something else via content negotiation.
>>
>> [1] http://xmlns.com/2001/08/wordnet/
>>
>> > I thought to use an http:// based URI base (e.g.
>> > http://www.eionet.eu.int/GEMET) and then add the id number of each
>> > concept (e.g. http://www.eionet.eu.int/GEMET#204).
>>
>> That works, but my preference would be for something like
>> <http://eionet.eu.int/GEMET/204>. In practice, using a fragment ID means
>> that an HTTP request to a term's URI will return nothing or else a
>> description of the entire vocabulary, which I'm guessing is pretty
>> large.
>>
>I think that this practice would certainly work much better with
>PSI/PSID constructs than the fragmentary approach - one resource per
>concept is probably a best practice that the Published Subjects TC
>should recommend.

Something I have done is use http://example.org/terms? as a namespace, so the
URI resolves to a query (which says to cache it by good practice, since it
doesn't change anything to run the query) and since that means you can do
something different for the "bare URI". Of course there is no reason not to
configure foo#bar to return just the relevant RDF if that's the content-type
requested, but people don't.

another option is to have a URI per term, and to add #term (or something
similar) in each case.

>> > A first question is, is it OK to use http: URIs for concepts?

Yes, it seems like a good idea. The RDF specs even define that a URI with a
fragment identifier in it refers to the RDF version in case of a
content-negotiated resource, so presumably they expect that practice.

>> It would be confusing for a URI to identify a thesaurus concept and an
>> RDF file. The key, as I see it, is the idea that the response to an HTTP
>> Get is a representation of the resource, not the resource itself. The
>> fact that <http://xmlns.com/wordnet/1.6/Dog> returns an RDF/XML
>> document, doesn't mean that it identifies that particular document. If,
>> for some reason, you wanted to talk about that RDF/XML document instead
>> of the word "Dog", you would need to use a blank node or a different
>> URI.

that's why I like using .../Dog#term

>It is certainly true that content negotiation gives you the problem of
>talking about the descriptive resource as opposed to the described
>thing. That is a strong argument against content negotiation for RDF /
>XTM resources. However, there are still two other options:

The solution to this problem is defined in the RDF specs, no? If you use
Dog#term then you are constrained to interpret it as whatever the RDF version
of the resource tells you.

>> > What do you think of info: based URIs for concepts?
>>
>> >From an RDF perspective, it's just as good. From a web perspective, it's
>> less useful because it can't be dereferenced.
>
>I tend to agree.

me too!

(I love ending emails like that :-)

cheers

Chaals

Received on Thursday, 22 April 2004 11:33:11 UTC