RE: HTTP Methods, Service Description URI, and OPTIONS with CONNE G.

-----Original Message-----
From:	www-tag-request@w3.org on behalf of ext Thompson, Bryan B.
Sent:	Thu 2004-02-26 13:10
To:	Stickler Patrick (Nokia-TP-MSW/Tampere); 'www-tag-request@w3.org '; 'jon@hackcraft.net '
Cc:	'danny666@virgilio.it '; 'joe@bitworking.org '; 'www-tag@w3.org '
Subject:	RE: HTTP Methods, Service Description URI, and OPTIONS with CONNE 	G.



Patrick,

I understand why conneg and mime types are not appropriate here.
That is why I was recommending a Service-Description-Uri header
which could be discovered through HEAD, GET, etc., and which
provided the URI of a distinct resource that was the description
of the service being provided.  I see this as a very simple mechanism
that could be "standardized" through a simple agreement about service
description discovery for HTTP.

However, I believe that you alluded to a problem with this approach
as well and I was wondering if you could clarify that.

           I see two key problems with a header based approach (1) causing
           confusion by overloading the semantics of the existing methods,
           and (2) the inefficiency of multiple server requests.

           The semantics of HEAD, GET, PUT, etc. have to do with
            representations, and it doesn't seem like very good
            engineering to trap requests having to do with representations
            and coerce them, based on headers, to work for descriptions.

            There is also the problem of efficiency. IMO, any solution that
            requires multiple requests to accomplish the simple operation
            of obtaining a resource description via a URI is less acceptable
            then introducing dedicated, efficient methods.

Also, another path is the OPTIONS request, which can respond to CONNEG
and which can accept a request entity that describes a query in some
depth concerning the service functionality (e.g., a service description),
and which can provide a response entity that describes the service.

From the HTTP/1.1 RFC:

<pre>

If the OPTIONS request includes an entity-body (as indicated by the
presence of Content-Length or Transfer-Encoding), then the media type
MUST be indicated by a Content-Type field. Although this specification
does not define any use for such a body, future extensions to HTTP
might use the OPTIONS body to make more detailed queries on the
server. A server that does not support such an extension MAY discard
the request body.

A 200 response SHOULD include any header fields that indicate optional
features implemented by the server and applicable to that resource
(e.g., Allow), possibly including extensions not defined by this
specification. The response body, if any, SHOULD also include
information about the communication options. The format for such a
body is not defined by this specification, but might be defined by
future extensions to HTTP. Content negotiation MAY be used to select
the appropriate response format. If no response body is included, the
response MUST include a Content-Length field with a field-value of
0.

</pre>


Has anyone worked through this (OPTIONS + CONNEG) approach in depth 
so that they could offer some feedback.

              I myself have not seriously investigated the use of OPTIONS
              because of the inevitable requirement of multiple system requests
              it would entail.

              I'm taking a rather long-term view with URIQA. It's possible to hack together
              all kinds of solutions which work using the existing machinery. But do we
              want the semantic web to be built upon hacks and tricks, rather than a clear
              and well defined architecture? I feel that the clear semantics and well defined
              behavior offered by the new methods introduced by URIQA will serve the SW
              community far better over the long term than tricks with headers. 

              Regards,

              Patrick


Thanks,

-bryan

-----Original Message-----
From: www-tag-request@w3.org
To: jon@hackcraft.net
Cc: danny666@virgilio.it; joe@bitworking.org; www-tag@w3.org
Sent: 2/25/2004 10:25 PM
Subject: RE: HTTP Methods



It seems that you're missing the key point of why MIME types
and conneg do not work in this case.

You can have a resource which has, as its primary representation,
an RDF/XML instance, yet that RDF/XML instance is not, nor does
it, or should/can it contain a description of the resource itself.

How do you request a description about an RDF/XML instance
if you cannot make clear to the server that you are asking for a
description, and not simply an RDF/XML encoded representation?

You can't.

The RDF/XML representation of an RDF schema or OWL ontology
is not the same thing as a description of that RDF schema or OWL
ontology, even if the description can be considered a kind of
representation.

Conneg is great. And there is alot of functionality that can be 
triggered by MIME types. But the distinction between a description
and some other kind of representation is not a matter of encoding.
It is a fundamental semantic distinction -- and one, by the way, that
is reflected in the architecture of most content management solutions.

Cheers,

Patrick


-----Original Message-----
From:	www-tag-request@w3.org on behalf of ext Jon Hanna
Sent:	Wed 2004-02-25 17:21
To:	Stickler Patrick (Nokia-TP-MSW/Tampere)
Cc:	Danny Ayers; Joe Gregorio; www-tag@w3.org
Subject:	Re: HTTP Methods



Quoting Patrick Stickler <patrick.stickler@nokia.com>:

> 
> 
> On Feb 25, 2004, at 16:48, ext Jon Hanna wrote:
> 
> >
> > Quoting Patrick Stickler <patrick.stickler@nokia.com>:
> >
> >> What if the resource denoted by the URI has an RDF/XML
representation
> >> yet you don't want the representation of the resource, you want its
> >> description.
> >
> > Could you elaborate on the difference between "description" and
> > "representation"?
> >
> 
> C.f. http://sw.nokia.com/uriqa/URIQA.html

D'oh. I had that page open in another window at the time and everything.

"Concise bounded descriptions of resources can be considered to be a
form of
representation"
And I consider them as such.

"however they are a highly specialized form"
'Specialised' is relative.

"and not the most usual or obvious form in a web primarily intended for
human
consumption"
Human consumption is a factor of rendering, not of data (reading raw
HTML sucks
too).

Well, at least I remember why I wasn't convinced by MGET when it was
first
mentioned on rdf-ig; I'm not convinced of descriptions as fundamentally
different to representations. I also think that "concise bounded
resource
descriptions" are the minimum of any generally useful RDF
representation, and
as such a GET for application/rdf+xml (or any RDF serialisation) should
return
such a description (or as much of one as there is available information
to
return), optionally with additional data (which granted could make for
an
efficiency issue, indeed a heavy efficiency issue, since there would be
unused
triples transmitted).

A triple that would belong in a "concise bounded resource description"
that
wouldn't belong in a general application/rdf+xml representation would be
a good
counter-argument ("good" in that it would make me personally more
convinced),
otherwise it is relatively easy to produce the former from the latter (a
lot of
unneeded triples, maybe the lot, could be discarded by a stream-based
reader
quite efficiently).

I think I'm happier to discard triples than to use a new method.

-- 
Jon Hanna
<http://www.hackcraft.net/>
"…it has been truly said that hackers have even more words for
equipment failures than Yiddish has for obnoxious people." - jargon.txt

Received on Thursday, 26 February 2004 07:55:50 UTC