W3C home > Mailing lists > Public > www-talk@w3.org > May to June 2003

RE: URIQA!

From: <Patrick.Stickler@nokia.com>
Date: Thu, 22 May 2003 09:48:51 +0300
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B01B90E1E@trebe006.europe.nokia.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:27 GMT