- From: <Patrick.Stickler@nokia.com>
- Date: Thu, 22 May 2003 09:48:51 +0300
- To: <zednenem@psualum.com>, <www-rdf-interest@w3.org>
- Cc: <www-talk@w3.org>, <uri@w3.org>
> -----Original Message----- > From: ext David Menendez [mailto:zednenem@psualum.com] > Sent: 22 May, 2003 07:35 > To: Stickler Patrick (NMP/Tampere); www-rdf-interest@w3.org > Cc: www-talk@w3.org; uri@w3.org > Subject: Re: URIQA! > > > There is definitely value in having a defined way (or perhaps > several) to get specific information about a URI. For example, an > agent reading my FOAF file might note that my homepage has the type > <http://www.eyrie.org/~zednenem/2002/web-threads/Weblog> and be able > to use a URI query agent to learn about its definition rather than > trying to download it. Exactly. > I'm less clear about the need for a new HTTP header. As I see it, (1) > the concise, bounded description of a URI reference is itself a > resource worthy of a URI I agree, and if you look at the URIQA demo, you'll see that each description is given its own distinct URI. The reason why it is imperative that one be able to get a description based only on the URI denoting the resource you wish described is that usually, that's all you have -- and while it would be possible to first do a HEAD request and hope to get a URI denoting a description, and then do a GET on the description URI, that is very inefficient and unneccesary, since one can simply specify in the first GET request that one would like a description of the resource rather than (some other form of) a representation. > and (2) all the HTTP headers in the world > won't help you get information about > <http://example.org/document#fragment> or <news:foo@bar>. That's why URIQA also supports direct querying of arbitrary URIs via its servlet interface. > I would > rather use <http://sw.org?uri=(encoded_stuff)> than a straight URI > with an extra header. Er. Perhaps you should read the information provided by http://sw.nokia.com/URIQA.html as that's precisely what it does. The reason why the header approach is needed is that one cannot know, given only a URI, what arbitrary web services might exist that can provide descriptions of the resource -- and what the URIQA model defines is a means by which a SW agent can obtain an authoritative description from the web authority (if any) component of the URI itself. I.e. the same web authority that provides representations can be queried for a concise bounded description. It may very well be that there are other servers which can provide third-party knowledge about a given resource, and URIQA provides for that at well, but the header is intended for interaction with the web authority of the URI itself. > (For a long term solution, what we would want is a way to describe a > classes of web services. The class would define functions like > concise_bounded_description(uri) and individual services would bind > that to a particular set of URIs.) I consider URIQA to provide the basis for such web services and to define the nature of the function you suggest. Cheers, Patrick
Received on Thursday, 22 May 2003 02:48:59 UTC