Re: fragment identifiers

On Tuesday, July 30, 2002, at 10:57  AM, Mark Baker wrote:
> On Thu, Jul 25, 2002 at 01:57:38PM -0700, Roy T. Fielding wrote:
>> That problem is simple to fix.  It is natural to want to make statements
>> about resources and about representations of resources.  It is necessary
>> to distinguish between the two when targeting an assertion, since most
>> assertions about resources are going to be statements about the range
>> of representations over time.  In other words, the reason that REST
>> distinguishes the two is precisely because we wanted to solve that 
>> problem
>> back in 1995.  It is solved for HTTP/1.1.  Now we just need to find the
>> corresponding syntax for it in RDF.
>
> Roy, would you mind explaining exactly how HTTP/1.1 solved this problem?
> I think that would help.

It solved the problem by distinguishing between resources, messages,
and the results of method invocations.  The spec doesn't say
"representations" because the editors couldn't agree on whether
to call them representations or instances.  Dan did a great job of
explaining the distinctions in header field definitions within

   http://lists.w3.org/Archives/Public/www-tag/2002Jul/0351.html

> I suspect it has something to do with the Content-Location header, which
> I've been using to solve this problem in my work.  But not knowing the
> history, or being involved in this space back then, I can't say
> authoritatively.

Only vaguely.  Content-Location (named as such due to a dependency
on MIME, which requires the Content- prefix, not because it gives
the location of the content) is only used when the provider wishes
to let the client know about the less-indirect URI of the result
of a GET on a content negotiated URI.  Since the provider rarely
wishes to do that, it is not a solution to the problem.  The
solution is to not assume that a URI's referenced identity
and the result of GET on the URI are the same thing.

....Roy

Received on Thursday, 1 August 2002 17:12:00 UTC