RE: URIQA!

>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.

If I'm trying to find out about <http://example.com/document>, 
wouldn't it make sense to try something like:

   GET http://example.com/document HTTP/1.1
   Accept: application/xml+rdf

You should either get back a representation of the resource in RDF 
(which one would expect to describe it) or an error if no description 
exists.

>  > 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.

Yes, I didn't appreciate that you were defining a web service *and* 
proposing an HTTP header.

>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.

The Accept header has the same effect in terms of getting information 
from the same authority. It doesn't guarantee that you'll get a 
concise, bounded description, but I'm not convinced that such a 
requirement is necessary.

>  > (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.

It does, but I was talking about a way to describe such classes in a 
machine-readable way, like WSDL or WRDL but with another layer of 
abstraction.

You would have a signature, which defines the input and output of the 
function (eg. concise_bounded_description :: uri -> rdf), and one or 
more implementations (eg. service 1 uses URIs of the form 
"http://sw.org/{uri}", service 2 uses URIs of the form 
"http://example.net/sw?uri={encoded(uri)}", etc.).

This would allow a programming environment to represent these 
services as objects belonging to the same class.

-- 
Dave Menendez - zednenem@psualum.com - http://www.eyrie.org/~zednenem/

Received on Friday, 23 May 2003 02:02:13 UTC