Re: skeleton Geolocation API

hello.

Aaron Boodman wrote:
> On Thu, Jun 26, 2008 at 4:35 PM, Erik Wilde <dret@berkeley.edu> wrote:
>> i still think that http://dev.w3.org/geo/api/spec-source.html#position is
>> just too limited in its model of location. a location can be a lat/long pair
>> of coordinates, but it also can be something else, like the identification
>> of a city or a state or some other place-oriented location concept.
> We are trying to implement a way for web applications to get the
> current position of the user. Having the user actually specify this
> seems useful to some subset of users, but having it be automatic seems
> better for most users.

i think this is a good example where a more developed set of 
requirements would help a lot. the current proposal is very much focused 
on the "mobile device with GPS and scripting code needs access to the 
location fix" scenario, which of course is a very important use case. 
but as i said, privacy issues are very crucial in this area (just wait 
until you have any europeans looking at the spec, they usually have a 
much stronger view of privacy). i am trying to look at scenarios that 
(a) go beyond the GPS-to-javascript scenario, and (b) could help to 
address privacy issues.

location is a highly contextual concept. i can say "i am at home" which 
makes no sense for most people, but makes perfect sense for people who 
know where i live. this is a place-oriented model of location. looking 
at coordinates is a space-oriented model of location. i think both 
models have very important use cases. just look at all the social media 
and social networking supporting location concepts such as jaiku. they 
flourish because people say where they are in place-oriented ways, not 
necessarily by publishing their coordinates.

i am thinking that location-oriented services on the web will not be 
restricted to pure matching of coordinates. locations may refer to 
places which can be understood in some contexts and are not understood 
in others.

> Automatically generating a URI like this seems like it would be a lot
> of work, and greatly increase the specification size. And it probably
> requires reverse geocoding. And I don't see that it buys any
> additional privacy over just chopping digits off the coordinates.

i am not proposing to include the specification of a location URI scheme 
in the spec. what i am proposing is that the spec should not limit 
itself to a spatial concept of location, it should be open to talk about 
locations as resources. whether the code getting such a location URI can 
understand it as it is (loc://usgs.gov/CA/Berkeley), has to reverse 
geocode it (loc:south%20hall%20berkeley), or only knows it in some 
context because there is no spatial definition available anywhere 
(loc://dret.net/home) is a different issue. all of these URIs do 
identify locations and can be used in location-oriented services (all 
the URIs are fictional examples from a non-existing loc: URI scheme).

cheers,

dret.

Received on Friday, 27 June 2008 00:41:05 UTC