- From: Gannon Dick <gannon_dick@yahoo.com>
- Date: Thu, 7 Jan 2010 21:13:38 -0800 (PST)
- To: Erik Wilde <dret@berkeley.edu>, noah_mendelsohn@us.ibm.com
- Cc: "uri@w3.org" <uri@w3.org>
Noah: I'm not convinced that a physical point on the earth "has a representation" in the HTTP/AWWSW sense. See permathread on httpRange-14, etc.
Erik: maybe the semweb world view is different, but that is something i want to stay away from, because it treats HTTP as axiomatic,
FWIW: I'd rather not speak for the semweb world view, and vice-versa but I think this is a (hypertext) meta data transport problem. Geo Coordinates are always a Dublin Core Box (a region) because of the finite accuracy. There is such a thing as a Dublin Core Point, but it only can apply to entities such as ISO 3166 Country Codes. These are irregular "regions" with GUID's Base 26. This[1] may help to explain, from the content, rather than transport protocol perspective. A cheesey, but practical workaround would be to define html@xml:lang as [HTTP Return Code(200) | HTTP Return Code(!200)] = ["en"|"dxx"[2]]. I think that will satisfy both ways of thinking.
--Gannon
[1] http://www.rustprivacy.org/meta/roundtripping.pdf
"Meta Data Round-Tripping & Privacy"
[2] there is an ISO Code for "No Linguistic Content". I think it's "dxx". I'll look it up if it's important.
> Response Code 200
> According to the HTTP specification, when a code of 200 is
> received in
> response to an HTTP GET request, it indicates that "an
> entity
> corresponding to the requested resource" has been returned
> in the
> response. The contents of this entity is what we understand
> as a
> representation of the resource. This correspondence between
> a resource and
> a representation is defined in [AWWW] as characterising an
> information
> resource. Consequently, we can assume that if we receive
> this particular
> response code in response to an HTTP GET request, we have
> also received a
> representation and that the URI references an information
> resource.
> ----
>
> So, to the extent you take [2] as representative of the
> TAG's position on
> httpRange-14, it is grounded in the definition of HTTP
> status code 200,
> the semantics of which are independent of URI scheme.
> If you're returning
> a 200, you're saying that the "entity corresponds to the
> resource", and I
> think it's fair to say that's what the TAG says can't be
> the cases for
> resources that aren't information resources.
>
> Noah
>
>
> [1] http://www.w3.org/2001/tag/issues.html#httpRange-14
> [2]
> http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14#sec-http-rep-assoc
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
>
>
>
> Erik Wilde <dret@berkeley.edu>
> 01/07/2010 04:57 PM
>
> To: noah_mendelsohn@us.ibm.com
> cc:
> Mark Baker <distobj@acm.org>,
> Jan Algermissen
> <algermissen1971@mac.com>,
> mark@coactus.com,
> "uri@w3.org" <uri@w3.org>
> Subject:
> Re: non-HTTP URIs in HTTP requests
>
>
> hello.
>
> noah_mendelsohn@us.ibm.com
> wrote:
> > I still think it's
> > unlikely that, per httpRange-14 resolution, 200
> responses will be
> > appropriate for geo-scheme URIs.
>
> so you're interpretation of
> http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14
> is
> that it applies to any URI? the title "Dereferencing HTTP
> URIs" to me
> suggests it doesn't, and it's mostly a document for the
> semweb world
> where people wanted to have a well-defined way of how to
> use HTTP URIs
> for ease of implementation, without sacrificing the
> guarantee that
> everything can be accessed via HTTP. my view of that
> document is that it
> only applies to HTTP URIs, but i don't think it clearly
> says what it is
> about.
>
> cheers,
>
> dret.
>
>
>
>
Received on Friday, 8 January 2010 05:20:51 UTC