Jeni,
First, thanks for confirming - many responses in line from here:
Jeni Tennison wrote:
> The server *can* return the same content from the /uri URI and from
> the /uri-documentation URI, but it does not have to, and it wouldn't
> be sensible to do so for an image. Your first question asked if the
> server could return the same content, your second asked if it must.
Apologies for any confusion from my wording, however I did mean "can"
rather than "must".
In a nutshell then, this proposal says that you can return a 200 OK for
a GET request on any URI, but if you return "a representation of a
description of the thing referred to by <uri>" rather than "a
representation of the thing referred to by <uri>" then you should say it
is so by including the special "<uri> :describedby <uri-documentation>"
triple.
Additionally, rather than special casing this so that this rule let's a
publisher override the default 200 OK return a representation of a
resource, the proposal also aims to change web arch and the HTTP
specification such that a 200 OK in response to a GET no longer returns
a representation of the requested URI, rather it just returns a
representation which you must consult to find out what it is.
That's quite a large change to the web / web arch / http.
On 28 Mar 2012, at 16:07, Nathan wrote:
Jeni Tennison wrote:
Yes, that's correct. With no constraining Accept headers, it could alternatively return HTML
with embedded RDFa with a <link rel="describedby"> element, for example.
Is that universally true?
Suppose /uri identified a PDF formatted ebook, or a digital image of a monkey
in JPEG format, or even an RDF document.
Then it would return those things. I think that you may have leapt to the
conclusion that /uri *always* returns the same as /uri-documentation. There's
nothing to my knowledge that says that, indeed given that you can have several
:describedby links it would be impossible.
Sorry no, not *always* just *always could* or *always can*. As in, it
would be universally true that for any successful GET request you would
receive a representation, and that representation may be a
representation of the <target-uri>, or it may be a representation of
<some-other-uri> which describes the target-uri.
Question A:
Currently we have:
<http://example.org/uri>; - a JPEG image of a monkey.
When you issue a GET on that URI the server currently responds
200 OK
Content-Type: image/jpeg
Link: <http://example.org/uri-documentation>;; rel="describedby"
So under this new proposal, the server can return the contents of
/uri-documentation with a status of 200 OK for a GET on /uri?
Under the proposal, the server would return the JPEG with a 200 OK for a GET on /uri. http://example.org/uri-documentation would return a description of the JPEG in some machine-readable format.
Or more accurately, the server MAY return the JPEG with a 200 OK for a
GET on /uri, or it may return the same result as a successful GET on
/uri-documentation (a description of the /uri in some machine readable
format).
Is this limited to machine readable format, why not human readable too?
It appears that if one can return text/turtle for a GET request on
</foo>, where { </foo> a :Horse } then one should also be able to return
an image/jpeg which visually describes the horse.
If yes, this seems like massively unexpected functionality, like a proposal to treat
"Accept: some/meta-data" like a DESCRIBE verb, and seems to exaggerate the URI
substitution problem (as in /uri would be taking as naming the representation of
/uri-documentation).
If no, where's the language which precludes this? (and how would that language
go, given that it's exactly the same protocol flow and nothing has changed -
other than the reader presuming that /uri now identifies something that does
have a representation that can be transferred over HTTP vs identifying
something that doesn't have a representation that can be transferred over HTTP).
I don't really understand what you think it needs to say I'm afraid.
Question B:
How would conneg work, and what would the presence of a Content-Location
response header mean? Would HTTPBis need to be updated?
I can't see any way in which any of that would work differently from currently.
Okay, given the use-case of a GET on </uri> returning 200 OK, and the
response containing a representation of </uri-documentation> in text/turtle:
What would the value of the Content-Location header be? /uri-documentation?
short version: this proposal would mean many sections of httpbis would
need to be reworded and changed, as it conflicts to the point of saying
the opposite.
Question C:
Currently 303 "indicates that the requested resource does not have a representation of its own
that can be transferred by the server over HTTP", and the Link header makes it clear that you
are dealing with two different things (/uri and /uri-documentation), but where does this proposal
make it clear at transfer protocol level that the representation included in the http response is a
representation of another resource which describes the requested resource (rather than it being as
the spec defines "a representation of the target resource")?
The proposal says that applications can draw no conclusions from information at
the transfer protocol level about /uri. In particular, it can't tell whether
the representation that is returned with /uri is *the content* of /uri or *the
description* of /uri. Further information about /uri (eg that it is a
foaf:Person) may help the application work out that the representation was *a
description*.
Wow, so every URI no longer refers to anything unless it's explicitly
stated in some RDF somewhere, and if one looks up <b> in a browser and
sees a picture of a monkey, they are incorrect for saying it refers to a
picture of a monkey if some RDF document somewhere describes <b> as a
:SpaceShuttle.
Can the TAG really just say "okay, all http:// URIs no longer refer to
anything"?
However, an application can draw conclusions about /uri-documentation, assuming
it gives a 2XX response, because it has been retrieved as the result of
following a :describedby link (or if it were the target of a 303 redirection).
The application can tell that the representation from /uri-documentation is
*the content* of /uri-documentation and *the description* of /uri.
I can't see how it could tell that "the representation from
/uri-documentation is *the content* of /uri-documentation and *the
description* of /uri". Perhaps that it's *a* description of /uri, but
certainly not that it's "the content of /uri-documentation", the
proposal itself removes all notion of a representation being a
representation of the current state of the requested uri.
if <a> is described by <b>, and <b> is described by <c>, then a GET on
<a> can now return <b>, whilst a get on <b> can return <c>, and so
forth, and if that :describedby triple is missing, or you don't get back
RDF in some form, then you don't know what you retrieved or if the
requested uri refers to it at all.
Either way, there is no implication that what you've got from
http://example.org/uri is the content of http://example.org/uri (or that
http://example.org/uri identifies an information resource), but there is an
implication that what you get from http://example.org/uri-documentation is the
content of http://example.org/uri-documentation (and that
http://example.org/uri-documentation is an information resource).
Sorry I don't follow, how is there an implication from a 200 OK for <uri-a> that it's
not an IR and for <uri-b> that it is an IR?
Because /uri-documentation was reached through a :describedby link. This extra
information allows the application to draw the conclusion that the
representation from /uri-documentation is *the content* of /uri-documentation.
and when you don't reach it via a ":describedby" link (as in 99.99% of
cases on the web)? also see above, same points.
If there was a Set of all Things (Set-A), then that set would have two sets, "the
set of all things which can be transferred via a transfer protocol like HTTP"
(Set-B), and then everything else (Set-C) which comprises Set-A minus Set-B. As far as I
can tell, the one thing that determines whether something is a member of the Set-B or
Set-C, for HTTP, is that 200 OK in response to a GET, hence why we need the 303.
This proposal appears to try and override that "rule" (fact) by saying let the
content of a representation define what is a member of Set-B or Set-C, however the act of
dereferencing itself is what determines whether an identified thing is a member of Set-B,
as Set-B is the set of all things that can be dereferenced. Hence my confusion at this
proposal.
The "fact" that a 200 OK determines whether something is a member of Set-A or
Set-B is a design choice made by httpRange-14, not a fundamental truth of the universe.
The proposal makes a different design choice, in saying that you need more than just a
200 OK response to say, beyond all doubt, that a URI refers to something that is member
of Set-B.
Apologies but I have to disagree completely here, I can say I'm a
goldfish but I have the properties of a human and belong in the Set of
Humans, no matter how much I say, I'm never going to be a goldfish -
there's no design choice there, similarly if something a representation
of something was retrieved via HTTP, then it belongs to the set of
things which can have their representations retrieved via HTTP, that
just is a fact, not a design decision.
Sorry this appears so negative, but... well the above hopefully
explains, personally I see it as ripping the foundational constraints of
the web/uris/http away to try and save an extra GET request in a few cases.
Nathan
