RE: URI policy for thesaurus concepts

> Personally I like this approach. The recent TAG document 
> endorses a REST
> view; so basically you're saying that
> 
> 	http://www.eionet.eu.int/GEMET/[version]
> 
> "names" the thesaurus, and
> 
> 	http://www.eionet.eu.int/GEMET/[version]/[conceptID]
> 
> "names" the particular concept. That's fine - I ought to be 
> able to ask
> (via content negotiation) for a representation of a concept (or a
> thesaurus) by an HTTP request for each of those URIs. What advice are
> you offering on the stuff that's found at the end of those URIs?

That's a whole other ball game.  As I understand it, the choice is between
the HTTP GET request for the concept URI returning either a machine readable
or a human readable description of that concept.  I may have boiled that
down too much - have I missed anything?      

> 
> It'd be reasonable to generate (for instance) RDF describing an
> individual concept (that perhaps links it to related 
> concepts) but it's
> not immediately clear to me what content might live at the "whole
> thesaurus" URI. Perhaps the whole thesaurus? Or a document with RDDL
> content that points to related web services, etc..?
> 

One thing a GET request for the thesaurus URI should definitely return is a
description of that thesaurus (i.e. name, version, creators, description of
scope and content etc.) although again whether that should be machine or
human readable is open.  

The other question is, should the request for the thesaurus URI also return
the entire content of the thesaurus?  Personally I think no, but again I'm
not sure about that.

Al.

Received on Friday, 30 April 2004 11:38:18 UTC