W3C home > Mailing lists > Public > www-rdf-interest@w3.org > November 2003

Re: MGET and machine processing

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Thu, 27 Nov 2003 11:39:06 +0200
Cc: ext Mark Baker <distobj@acm.org>, <www-rdf-interest@w3.org>
To: "ext " <jalgermissen@topicmapping.com>
Message-Id: <8B89C088-20BD-11D8-9830-000A95EAFCEA@nokia.com>

On Wednesday, Nov 26, 2003, at 12:52 Europe/Helsinki, ext wrote:

> Patrick Stickler <patrick.stickler@nokia.com> schrieb am 26.11.2003,
> 10:31:28:
>> My #1 requirement is that, for any arbitrary URI which is meaningful
>> to the HTTP protocol, and contains a web authority component, a SW 
>> agent
>> should be able to send a request to that web authority to obtain a
>> concise bounded description of the resource denoted by that URI,
> Patrick--
> can you explain why this is your #1 requirement? Why do you favor
> exactly this approach?
> There is a 'convention' on the Web that if you send a GET request
> to a server without a path portion (http://www.example.org) the
> server will redirect you to a meaningful entry point to the site
> (e.g. index.html). What if this convention was extended to have
> the server return some sort of RDF entry point if the client
> indicates it accepts only rdf+xml?
> GET http://www.example.org HTTP/1.1
> Host: www.example.org
> Accept: application/rdf+xml

Please read the whole of this discussion over the past week or so.
This is addressed at length and in several postings.

In short, it's about (a) maintaining clear semantics and (b) knowing
for certain the server understood those semantics and (c) doing so
in an efficient manner.

> To me, it makes much more sense to provide a single entry point to
> all the descriptions of resources of a site, than to have to poke
> to every URI with a separate request to obtain it's description
> (or to find that none exists!).

Er. How would you feel if for *every* GET, for every server, you
first had to query the "root" URI to find out the portal via which
you could interact with the server for "longer" URIs?

Not very efficient.

> The single entry point could also provide information where to look
> up descriptions for resources. Using RDF Forms[1] the 'RDF-entry-page'
> could look like this:
> <rf:Indexable xmlns:rf="http://www.markbaker.ca/2003/rdfforms/"
>               xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>               rdf:about="http://www.example.org/description-index">
>   <rf:indexedBy>
>     <rf:IndexParam rf:shortName="uri">
>       <rdf:predicate rdf:resource="no-exactly-sure-what-to-put-here"/>
>     </rf:IndexParam>
>   </rf:indexedBy>
> </rf:Indexable>
> The RDF above communicates (to an RDF Forms aware client) that
> http://www.example.org/description-index can be used to look up
> descriptions of resources. [2]

I'm all for RDF descriptions of web services, which are discoverable
via the "root" URI of a given web server (that portion of the URI
consisting only of the web authority component) -- and then being
able to discover the protocols and parameters of each service, etc.

And I expect to see that happen.

But that is a different form of interaction than the more atomic
protocols being addressed by this discussion. Web services would
not work without the fundamental behavior provided by GET, PUT, etc.

Likewise, MGET, MPUT, etc. provide a fundamental, atomic way to
obtain the descriptions of servers, services, portals, parameters,
etc. so that other things can happen.

In your example above, it would be far, far more scalable, flexible,
and generic to have the "root" URI denote the web server, from which
one is able to MGET a formal description of that server, including
the services it offers, and then MGET a description of each service,
based on their URIs, etc.

E.g., http://sw.nokia.com/uriqa?uri=http://sw.nokia.com&format=text/html



> Thoughts?
> Jan
> [1] http://www.markbaker.ca/2003/05/RDF-Forms/
> [2] Mark, shouldn't the RDF Form also communicate that the
> indexable is of some type (e.g. Resource Description Index)?
>> with
>> a single request, and without any further information than the URI
>> itself
>> (and the generic protocol by which the request is made) and recieve in
>> response either a description, or an error indication of some fashion.
>> While there are other requirements that I consider also to be 
>> essential,
>> the above is, for me, the very heart and core of how (atomic level
>> of) the SW should work, regardless of all other more capable
>> protocols, apis, services, etc.
>>>> No. Content negotiation does *not* do the job. And we will want
>>>> to use content negotation *as* content negotiation, for requesting
>>>> different possible encodings of descriptions.
>>>> I've pointed this out before.
>>>> In short, content negoation does not work, nor should it be 
>>>> overloaded
>>>> in this fashion, as the semantic distinction between description and
>>>> (other form of) representation has nothing whatsoever to do with
>>>> encoding (even if RDF/XML is a default encoding for descriptions).
>>> What you've pointed out before - and presumably what you're referring
>>> to
>>> there - was that it is incorrect to use content negotiation to
>>> negotiate
>>> for descriptions from the URI which is being described, and I agree
>>> completely.  But I can safely negotiate for RDF/XML *representations*
>>> using the URI.
>> Absolutely. And if you have a URI denoting a concise bounded 
>> description
>> of some other resource, you could use content negotiation to request
>> any number of supported encodings/serializations of that description.
>> Content negotiation and the distinction between description and
>> representation
>> are orthogonal, and should remain so.
>> It appears that we agree on that point. Yes?
>> Cheers,
>> Patrick
>>> Mark.
>>> -- 
>>> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> -- 
> Jan Algermissen                <algermissen@acm.org>
> Consultant & Programmer
> http://www.topicmapping.com
> http://www.gooseworks.org
Received on Thursday, 27 November 2003 04:42:58 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:48 UTC