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

It would be a great aid towards being able to understand what this discussion is about if the terms "resource", "fragment", "element" and "representation" were defined or at least elicidated somewhere. Apparently, for example, you find it hard to believe that an "element" can have a representation. Why is this considered puzzling or odd? What is it about "elements" which makes them unrepresentable (in your sense)?

Pat Hayes

On Oct 29, 2010, at 3:10 PM, Jonathan Rees wrote:

> 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?
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Saturday, 30 October 2010 14:26:48 UTC