Re: resource and representation

> I buy your definition but have one question. Do fragment identifiers
> identify into the representation or the resource? If a fragment
> identifier is representation-specific (which it seems they typically
> are) then shouldn't URI References say what representation they are
> trying to address into?

They are client-side indirect references, just like server-driven
negotiation in HTTP allows a server-side indirect reference.  The
fragment identifier will (if the resource provider has done it right)
identify the same thing across multiple representations.  Even a
static content resource has multiple representations over time --
they are all byte-equivalent, but not age-equivalent.

The aspect of fragments that is media-type-specific is the mechanism
of the indirect reference when it is dereferenced.  The mechanism is
not known (and cannot be known) until after a GET action is performed
on the URI, unless it is a same-document reference.  In other words,
the representation, once in hand, determines what needs to be done to
complete the retrieval action.  Retrieval and name-equivalence are
the only two "actions" allowed on a fragment because the interface
does not allow a fragment identifier to traverse the architectural
boundary between client and server.  Fragments are not first-class
resources; not even when they consistently identify semantics across
multiple representations.

BTW, for others sake, let me again emphasize that this is not
specific to HTTP.  HTTP was designed to be specific to the Web,
not the other way around.  HTTP was effectively rewritten three
times over the course of the last decade to better meet the
evolving needs of the Web.  The concepts of identification and
access to resources haven't changed significantly since 1993.
HTTP was also designed to support the goals of the Semantic Web, as
opposed to just the web of static documents, because that was the
essence of TimBL's talk at the First WWW conference.  It works.

When I visited with TimBL recently, he said [and I hope I remember
this correctly] that the reason my definition "doesn't work for RDF"
is because resources are documents and therefore, when you retrieve
a resource that is RDF, you don't know whether the identifier
referred to the RDF document or something described by the RDF.

What does that mean, exactly?  It means that RDF is supposedly able
to make assertions relative to the retrieval context, rather than
tied to a specific URI (or set of URI).  Sorry, that simply cannot
work in practice.  First of all, people don't want assertions about
what they have already received; they want assertions about what
can be assumed for future access to that resource (or some other
identified resource).  Thus, any context-dependent assertions in
RDF would have to be about the resource accessed (something that is
capable of varying over time).  But the Web architecture doesn't
allow the content generator/author to know which URI was actually
used by the user agent to retrieve that representation. It could
be anything: a URN (via proxy), an http URL, an HTTP gateway to
some other site, a local file URL, or even some proprietary scheme
for accessing historical content.  To which URI, and thus which
resource, do the context-dependent RDF assertions apply?

I fixed that philosophical conundrum ages ago!  Resources are not
documents. We don't allow any resource to be retrieved -- only
instantaneous representations of that resource.

Documents are representations.  The semantics of a resource, and
hence the reason a person is choosing to use a given identifier
as a reference, are defined not by the contents of any one
representation, but rather by the set of common characteristics
of all representations, across all time, that are provided or
consumed by that resource.  RDF can make additional assertions
about a resource, creating additional shared semantics, but those
assertions must be made on specific URI -- they cannot be
interpreted to apply to any URI used in the retrieval action,
since neither the generating server nor the RDF content author
can possibly know what URI was used by the user agent to make
the original request, and thus cannot know for sure which resource
was accessed in order to obtain the representation in RDF, and
thus cannot make assertions about future accesses of that URI.

In other words, the argument that there is ambiguity between
the two is based entirely upon the notion that RDF itself should
be ambiguous.  The way to solve it is to not allow context-dependent
assertions to be made by RDF.  The assertions must be explicitly
linked to the resources about which the assertions are being made,
either by external metadata links from that resource to a separate
RDF resource, or by explicit reference to the target resource URI
within the RDF.  Any other encounter with an RDF document doesn't
imply that the assertions within it apply to the URI accessed --
it merely implies that the resource is currently represented by
that RDF document.

same-document-references != same-resource-references, in both
theory and practice, regardless of the media type.

Sorry for the long response to a short question.


Cheers,

Roy T. Fielding, Chief Scientist, Day Software
                  (roy.fielding@day.com) <http://www.day.com/>

                  Chairman, The Apache Software Foundation
                  (fielding@apache.org)  <http://www.apache.org/>

Received on Friday, 12 July 2002 21:02:48 UTC