- From: Erik Wilde <dret@berkeley.edu>
- Date: Tue, 11 Nov 2008 16:23:33 -0800
- To: Richard Barnes <rbarnes@bbn.com>
- CC: Doug Turner <doug.turner@gmail.com>, Andrei Popescu <andreip@google.com>, "Thomson, Martin" <Martin.Thomson@andrew.com>, Greg Bolsinga <bolsinga@apple.com>, public-geolocation <public-geolocation@w3.org>
hello everybody. > Do you really mean that every website that does geolocation will have to > provide geodetic location? As I've tried to point out, there are many > situations where it makes more sense to provide civic, *especially* in > contrast to just a lat/long pair. this discussion is now getting to the same point that we reached a while ago: i proposed to extend "geolocation" to something less constrained than lat/long, my use cases were civic addresses as well as social places (such as neighborhood names and maybe even more personal concepts), and i think if you look at how location is used on the web today, there are tons of applications that use location concepts that are non-lat/long. as i have pointed out earlier, i think this WG will set a pretty important precedent on how location concepts on the web will develop, and personally, i find it unfortunate to see something as limited as a lat/long model being developed under a much wider term of "geolocation". location is a concept that is so rich and diverse that anything as limited as just lat/long or just civic addresses will not be able to represent location concepts as they are and will be used by applications. personally, my wish would have been a more disciplined approach by first looking at "how do we want to represent location as a concept on the web", and then take this and start developing an API by saying "ok, and for the really important use case of lat/long locations, this API can be used". most people on this list are in favor of keeping the scope of the API limited. which i think would be fine as long as the API would just be clear about the fact that it is not about geolocation in general, but about acquiring lat/long information. if the API would be more clear about this, not only would this make it easier for people to understand the scope of this API, it also would give more generalized ideas about location concepts a better starting point later. i do see that there currently is mainly interest in getting web apps to talk to mobile clients and getting their lat/long info, and this of course is a very important functionality. my personal hope would just be to not claim that this is what "location on the web" is going to be. think about basic web principles such as REST and its implementation in HTTP. RESTful location management would allow negotiation of appropriate and useful location representations, and for many applications these will be lat/long, for many it will be civic addresses, and for many it will be social locations. this bigger question of how to manage location in a web-like way is still untackled, and it would be unfortunate if the narrow scope of a lat/long-API would shape the way in which people think location on the web in general will develop. i certainly hope that location on the web will become much richer and more web-like, and from what i see as the scope and goals of this API, it is just a fraction of how the web will evolve as a location-aware web. and finally the ad section: because i am mostly interested in these more long-term issues, we have organized workshops on "location and the web", one at this year's WWW conference in beijing, and the next is at CHI 2009. in these workshops, we try to look at the bigger picture, and i suspect that things like geocoding belong into the bigger picture, and not the lat/long-API. http://medien.informatik.uni-oldenburg.de/LocWeb2008/ http://ifgi.uni-muenster.de/locweb2009/ kind regards, dret.
Received on Wednesday, 12 November 2008 00:24:20 UTC