Re: [ISSUE 57] Representation-source: a possible new approach to the HTTP Redirection Issue

Noah,

Looking at "Some thoughts on resources, information resources and  
representations".
Working through the document on the place to the face-face, so unable  
to follow links from it.

Frankly, I find this note seems to be rather confus{ing,ed}.  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 the same 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?


> "What's this business about status code 200 for "Resources that  
> aren't Information Resources?"
>
> The reason for limiting code 200 to information resources was to  
> avoid ambiguity. For the reasons explained above, I don't think  
> common practice avoids the ambiguity very well anyway. First of all,  
> both conneg and mutable resources are allowed. Secondly, even if  
> that weren't a problem, it's not at all clear that the architecture  
> is being followed sufficiently carefully today that we can count on  
> much from just a 200 in any case, regardless of what the TAG may  
> have hoped. "

We clearly live in different worlds.  Can you give examples?  The  
semantic web community seems to have settled down to mind billion of  
URIs which work right, for all kinds of things.

In the table,  you have a different memory of the intent of "Resource- 
Description" header.  I thought it would be useful for saying  "This  
NOT a representation of R, this is another document R2 which is  
*about* R".  Like  "303 to RR2, and this is what you would get from  
R2".   Your table in the 3rd non-header row says  ".... The provided  
representation carries the full state of the resource, and is the same  
as what will be returned for subsequent references. D is the URI for a  
resource that provides metadata about or descriptions of R."   Instead  
it would provide, I thought, the full state of D.

> "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.


Maybe we can discuss this at the face-face.   I may have been  
confused.  We have flaps down .. gtg

Tim



On 2008-02 -23, at 15:39, noah_mendelsohn@us.ibm.com wrote:

> As I've mentioned privately to a few TAG members the past few weeks,  
> I've
> been spending some time trying to think through the HTTP Redirections
> issue.  I've never been quite comfortable either with our use of
> Information Resources or our suggestion to rely on 303 status codes.
> Anyway, I've been working through that time to pull together some  
> thoughts
> on what might be new approaches, and I've come up with some ideas.   
> I'm
> not ready to promote these as "the right answers", but even finding  
> out
> why they're not quite right may teach us something about what the  
> problems
> are.  A writeup is linked at [1] and is also attached to this email  
> (same
> content).
>
> I had hoped to come up with something a bit more polished in time to  
> be on
> the official F2F reading list, but I got delayed working on the
> self-describing Web draft.  Stuart:  I do hope that there might be  
> some
> time to sketch these ideas on the whiteboard during our discussion  
> of HTTP
> Redirections, and if anyone has time to give these notes a look before
> than I'd be very grateful for comments.  Again, I don't consider  
> either
> the writeup itself or the ideas to be polished, but I hope that  
> getting
> this out for discussion in rough form now is better than waiting.    
> For
> the record, this is not a formal W3C Note, a draft of a TAG finding or
> anything like that.  It's just my own musings on this issue.    I hope
> this is of at least some value in moving the discussion along.
>
> Noah
>
> [1] http://www.w3.org/2001/tag/2008/02/RepresentationResources.html
>
>
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
> <RepresentationResources.html>

Received on Tuesday, 26 February 2008 02:16:48 UTC