RE: URIQA!

> -----Original Message-----
> From: ext David Menendez [mailto:zednenem@psualum.com]
> Sent: 23 May, 2003 09:03
> To: Stickler Patrick (NMP/Tampere); www-rdf-interest@w3.org
> Cc: www-talk@w3.org; uri@w3.org
> Subject: 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

No. Because that doesn't work for RDF/XML documents. What if the
above resource has several representations (XML, HTML, RDF, XTM)
and you want to get a description about <http://example.com/document.rdf>?

If you say

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

How does the server know if the Accept: header means to return
a description or is simply redundant for the representation?

I experimented defining a MIME type for a concise bounded description
(application/uriqa+xml+rdf) and earlier versions of the URIQA servlet
actually used content negotation to request such representations.

This works OK for GET, but breaks down for PUT and DELETE as it is
quite acceptable for one to store a complete CBD instance as a resource
on its own right, so again, you loose the distinction between the
Web and SW behavior.

I.e. given

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

does the server put the input as a representation of document.rdf or
add the input to the body of knowledge describing document.rdf?

You can't tell.

It also precludes asking for descriptions in other formats unless
you enumerated a parallel set of MIME types for each format, which
feels a bit too much like a hack to me.

Rather, it is necessary to differentiate between the different
modes of resolution in a manner that is complementary to the
existing machinery, including content negotiation.

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

This should be the case regardless of the solution, and is
the case for the demo URIQA servlet.

> >  > 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 heart of the URIQA model is the ability to GET/PUT/DELETE
knowledge expressed in concise bounded descriptions based solely
on the URI denoting the resource in question.

There are two ways to interact with a URIQA enabled server, 
via the Servlet interface (for any arbitrary URI) and using
the URI-Resolution-Mode header (for URIs where the web authority
is the same as the server).

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

No, see above.

> It doesn't guarantee that you'll get a 
> concise, bounded description, but I'm not convinced that such a 
> requirement is necessary.

Getting a CBD is IMO imperative to scalability and efficiency.

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

Right.

Patrick


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

Received on Friday, 23 May 2003 02:53:26 UTC