Comments on http://www.w3.org/2001/tag/2008/02/RepresentationResources.html

Noah,

Looking at "Some thoughts on resources, information resources and  
representations".

Frankly, I find this note seems to be rather confused.  I will try to  
go through it and maybe at the face-face I can get to understand what  
the problem is you are trying to solve.

The document serves, it says to

"1. To identify a class of Web document resources that are immutable  
and do not engage in content negotiation.".

- This class is fairly well identified., I think. your are talking  
about thesame class as http://www.w3.org/2006/gen/ont #FixedResource .

2. To encourage resource providers to associate with each  
representation that they serve an IDR

   - Why?  For example, on the W3C web site, we could do that as the  
CVS system gives access to each snapshot of a page.  This information  
is not normally available to non-staff.    On most other sites, the  
pages are generated very sponteneously, with different ads and  
customization, and a IDR would be an unbearable burden to maintain.   
And what good would it do?

"Stated differently, we don't in general assign a URI to each  
representation, which is a fleeting thing on the wire; we assign a URI  
to a resource that would serve the same representation if asked.'

Who wants to assign a URI to a representation anyway?   Not I.  I  
don't know of any system which does.

3. "To create a new HTTP header, tentatively called: Representation- 
source. This header is very similar in use to Content-location, but  
with the crucial difference that, if used, Representation-source MUST  
identify an IDR (I.e. immutable resource) that serves the same  
representation content as was just retrieved. Stated differently, a  
GET response provides a URI that's associated with the content, I.e.  
the headers and entity body, of the provided representation."  -- why?

(And I assume you don't mean the date etc .. you only mean the entity  
headers?)

4. "# As a special case of the rule above, to specify that when  
responding to a GET an IDR SHOULD identify itself as its own  
Representation-source. So, you can tell you're speaking to an  
immutable IDR if the Representation-source comes back the same as the  
original Request-URI. In this case, you know there's no ambiguity as  
to what the URI represents, and you can make very rigorous semantic  
Web statements about it."

-- Well, this was the intent of the vary= syntax in HTTP, to give the  
dimensions along which this could vary
-- Do you have a compelling use-case for this?

5.  "# To back off from the advice to give 303's for non-IRs. You can  
give a 200 for (what we used to call) a resource that's not an  
Information Resource, but you SHOULD provide in the Representation- 
source header the URI of the IDR that is for the representation. The  
user agent can then distinguish semantic Web statements about the  
document retrieved (the IDR) from semantic Web statements about what  
may prove to be a "not an information resource"."

What are you bacing off from, here?  HTTP-Range-14 resolution.  That  
is  IMHO a majoe step backwards, as you  suddenly introduc

- Giving a 200 prevents the client distinguishing between a thing and  
a document about a thing
- Adding an IDR  doesn't help, without as an IDR does not identify the  
document nor allow one to conclude that document  one sees about the  
the thing, rather than being the thing denoted by the URI.

You say, "As a quick summary: the intuition is to acknowledge that due  
to conneg and just general lack of consensus in the community, the  
current deployed use of 200 isn't sufficiently consistent and reliable  
for rigorous reasoning in the semantic Web."    O  the contrary, we  
sem to have a widening base of understanding, and with the Linked  
open  Data movement, a bunch of interoperability.

"Why Information
Ummmm... later you say


"Information resources are those for which it's possible, at least in  
principle, to avoid the ambiguity discussed above, which is why the  
TAG's resolution of issue httpRange-14 suggests that HTTP status code  
200 is appropriate only for information resources. Ironically, having  
gone to all this trouble, we then allow for ambiguity anyway!."

Eh? You have just explained how the ambiguity is removed!  What  
ambiguity is allowed for?

Next you say "While the TAG carefully discourages use of HTTP 200 for  
non-Information Resources, 200 seems to be allowed for resources that  
engage in content negotiation, e.g. to select a language. If I request  
a press release http://example.org/pressRelease, the server may use  
various heuristics to decide to serve me a copy in French, in English  
or in Greek. Does a Web Statement "http://example.org/pressRelease is  
hard to understand" apply to the press release in the abstract, or to  
the French representation that was served to me?"

It is Generic.   Please see http://www.w3.org/DesignIssues/Generic for  
an old but still relevant treatment of Generic Resources.   Your  
statement applies to the press release in general.  There are  
typically more specific URIs for the French one so if you want to  
sepcifically talk aboiut that you can.    Specific resources of the  
same Generic resource vary by time, content-type as well as  
language.   A huge number of important  properties, such as   
authorshhip, intellectual property, trustworthiness, meaning in  
general,  generally apply generically.     If I say I wrote a paper, I  
don't want that to have to be said separately about the RDF an HTML  
versions.   I agree translation can be a counter example,and there are  
times when conneg should NOT be used for translations.  However, for  
things like weather and airline booking sites about flights, where  
the  same data can be labelled in 11 different languages it is really  
useful.

"From information resources to immutable documents" - as above, not  
practical except in certain cases.

"Not URIs for Representations, but URIs for the content of  
Representations"    -- As I said above, why ever give a URI to  a  
Representation?  It is like giving an email address to a SMTP  
connection.  The WWW works by giving documents URIs, and  
representtaions are part f the way the system of documents works.   If  
you go meta and want to name the representations, then you are  
designing a new more complicated system.  Again, what is the  
motivating case?

"A use case: Namespace documents"   You argue that you want separate  
URIs for the conceptual namespace and for the namespace document.  So  
far, a whole bunch of RDF ontologies have been built very practically  
where no one has needed a URI for the namespace.   Just as when we say  
"Resident according to the Act of 1976"  we don't make up separate  
names for the Act as a concept and as for the document which provides  
code information, but not all information, about it.    The namespace  
doesn't come into the architecture.  The software doesn't process it.

The great thing about the Web architecture is that it i in a sense  
complete loop.


Tim