A#B where A redirects to C#D ('tertiary resources')

The TAG discussed a thorny question at last week's F2F.

The HTTP working group has proposed to relax the syntax of the
Location: header to permit fragment ids.  That is:

  GET A
  302 Location: C#D

If you're a web browser, this seems pretty straightforward: you browse
to URI A, the redirect is discovered, a document C 'representation' is
fetched, and you're positioned at fragment D within it (if it exists).

If you're interested in the properties or "identity" of resource A,
this reduces to our previously unsolved problem of redirect semantics.

For the scenario

  GET A
  302 Location: C

we've discussed three theories:

1. 'A' is a name for a resource that is also named 'C'.  This is what
RFC 2616 suggests ("the requested resource resides temporarily under a
different URI" - note, only a single resource is mentioned).

2. The resource named 'A' currently shares representations with the
resource named 'C'.  This would happen if they're the same resource,
but if they were different the two resources might differ in other
ways.  This is the theory I put forth a while back.

3. The resource named 'A' is related to the resource named 'C#D' only
in that if you browse to it, you'll browse to 'C' (and the address bar
will show 'C', not 'A').  This seems closer to a theory Noah put
forth, and to what browsers actually do.

There is a practice in linked data/semweb of using 301/302/307
redirects, but I don't think this is much affected by the choice as
what usually happens is you end at RDF that uses
the original URI ('A').  In this case the nature of the resource 'C'
is never in question.

The theories get a bit messed up if you allow Location: C#D.

1. If C#D names an element, then A is a name for that element.  If A
has representations (e.g. due to conneg?), then the element does too -
but how can an element have a representation?

2. Even worse - if C#D is an element, it would be very odd to speak of
its representations.

3. Probably OK.

Now what happens if the original URI of interest was A#B?  Consider
first if the redirect of A is to C:

1. A and C are the same resource, so A#B is C#B (right?), so anything we learn
about C#B is also true of A#B.

2. Fragid semantics are determined by the available representations,
so again, if A and C share representations, they will share all fragid
definitions.  A#B is therefore equal to C#B.  (Hmm, maybe some
subtleties around base URIs.)

3. A theory that discourages us from thinking of A and C as being
closely related cannot justify displaying C#B when A#B is requested.
But that is exactly what browsers do...

Now what if we're looking for A#B, and A redirects to C#D?

The HTTP WG wants to say, I think, that the #B is dropped, and this is
the same as the previous case.  I can't figure out how one would
explain this.

I can explain the #B being dropped in the case that C#D is an element -
the normal situation.  You just say that a representation of an
element is simply any representation of the document that contains the
element.

But if C#D is something else, like an 'information resource', it might
have its own representations, and a sufficiently savvy browser might
show the B fragment of that information resource.  We wouldn't want a
rule such as 'you must drop the #B' preventing this, would we?

Or do browsing and nose-following follow completely separate rules?

Received on Friday, 29 October 2010 20:10:59 UTC