Re: URI policy for thesaurus concepts

On Sun, 2 May 2004, Thomas Bandholtz wrote:

>Thomas:
>> > The consequence is that a single URL is not enough.
>Dan:
>> That doesn't necessarily follow. HTTP supports content negotiation
>> (see http://www.w3.org/Protocols/ ftp://ftp.isi.edu/in-notes/rfc2616.txt)
>> which allows multiple representations of the same thing to be made
>> accessible via a common URI.
>
>I found http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html:
>"Server-driven negotiation has disadvantages:
>      1. It is impossible for the server to accurately determine what
>         might be "best" for any given user, since that would require
>         complete knowledge of both the capabilities of the user agent
>         and the intended use for the response (e.g., does the user want
>         to view it on screen or print it on paper?)."
>
>IMHO we only could think about server-driven negotiation here.
>This does not sound very encouraging ...
>Again, I would focus on a Web Service which at least has a WSDL, so the
>client can see what she will get back.

HTTP Content-negotiation isn't entirely server driven - it relies on teh
client specifying what they want. CC/PP  is even more  powerful in this sense
(and uses RDF :-)

WSDL actually ends up just being plain text, which is really not that handy
for users, difficult to search for if the service was created in french or
the searcher only reads vietnamese, chinese, and russian, and it is pretty
dreadful for trying to process automatically in general. (Hopefully that will
change of course...) But  Web service is a useful thing - although I don't se
it  as  being fundamentally different. If  we make a web service smart
enough to offer  more than one type of result, we need  to define how that
can be selected, and we are likely to come back to somethign as automatable
as HTTP content negotiation as a  well-understood system...

cheers

Chaals

Received on Monday, 3 May 2004 07:09:41 UTC