Re: Re: MGET and machine processing

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

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

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]

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 Wednesday, 26 November 2003 05:54:30 UTC