- From: Erik Wilde <dret@berkeley.edu>
- Date: Wed, 16 Jan 2008 11:48:08 -0800
- To: Sandro Hawke <sandro@w3.org>, "uri@w3.org" <uri@w3.org>
Sandro Hawke wrote: >> at least that is what i took away from the discussion of geolocation. in >> a http-centric world, a geolocation is a http resource which (a) is a >> regular web page (maybe displaying a map), and (b) to those who >> understand the magic prefix or the embedded profile, is not just a web >> page about the location, but the location itself. > It looks like you may have missed the key nuance of "303 See Other". > (This is not surprising. It took me a year or two to come up with it, > and the TAG took another year or two to endorse it. Of course, most of > that time was spent thinking "there must be something simpler!" before > deciding this was the best option.) thanks for the explanation! i am still voting for different uri schemes for different "kinds" of resources, but i do get your point. i think... ;-) for recognizing the non-http nature of u1, software has to dereference the uri, right? from the http spec, your usage of 303 seems to be much more nuanced and semantically loaded then what the spec suggests. so i assume to discover the non-http nature of the resource identified by u1, there must be some content within the returned resource that makes that statement. logically, i see three ways how the non-httpness of the identified resource could be established: 1. string matching with a magic prefix 2. the 303 returned when dereferencing the uri 3. embedded metadata in the returned resource what is the official vote on these? it seems that (2) is required, but it cannot be sufficient given the rather general definition of 303 in http. would (1) be ok? or is that discouraged? i am sure that (3) is the w3c's favorite given its inherent rdfness, but i am wondering whether in this whole approach there still is a chance for non-semantic web users to understand the non-httpness of the resource identified by u1. thanks and cheers, dret.
Received on Wednesday, 16 January 2008 19:49:13 UTC