The meaning of "representation" (was: HTTP URIs and authority)

Now, we're seeing a spectrum of views on what a "representation" in HTTP
sense might be.

>From Xiaoshu's "I think there is no inherent 
relationship between a representation and resource, let along
isomorphic."

... to Pat's "But yes, I'm assuming that webarch:representation is 
something like taking an imprint from a platen. It has to in some 
sense be a 'faithful' representation of 'all' of the resource."

Both of the above cannot be true, and allowing both interpretation hurts
web architecture. The HTTP spec provides no real guidance.

I propose that the TAG provides the community with a single, consistent
view on this issue: "What is the relationship between a
http:representation and a webarch:resource"?

/Mikael

tor 2007-10-25 klockan 21:40 -0400 skrev Chimezie Ogbuji:
> Noah Writes:
> > Your view seems to be that the resource needs to, at least in some sense, be
> > isomorphic to the representation, so you infer that when the representation
> > changes the resource must have changed.  It seems to follow
> > that in the case of conneg, the resource must in some sense be (or be
> > isomorphic to) the union of all served representations.
> 
> This view is actually consistent with the normative behavior for GRDDL
> that we settled on with regards to content negotiation:
> 
> http://www.w3.org/TR/grddl-tests/#langconneg3
> 
> In the case of GRDDL, the 'maximal' GRDDL result (the RDF merge of the
> renditions of each of the representations) is an acceptable rendition
> of the original IR.
> 
> > My preferred view is that
> > there is allowance for changing policy as to how a particular resource is
> > represented, and that such changes to not necessarily imply that the resource itself has changed.
> 
> With such an allowance, a GRDDL-aware agent would not be able to
> assume much about the IR behind the RDF rendition.
> 
> -- Chimezie
> 
> 
-- 
<mikael@nilsson.name>

Plus ça change, plus c'est la même chose

Received on Friday, 26 October 2007 08:08:35 UTC