W3C home > Mailing lists > Public > public-geolocation@w3.org > June 2008

Re: skeleton Geolocation API

From: Erik Wilde <dret@berkeley.edu>
Date: Fri, 27 Jun 2008 18:24:33 -0700
Message-ID: <486592D1.2000501@berkeley.edu>
To: public-geolocation@w3c.org
CC: Aaron Boodman <aa@google.com>

hello aaron.

Aaron Boodman wrote:
> I am most interested in providing a way for web applications to get
> the current location of the user. I get the impression that this is
> what the other UA vendors here are interested in as well, but they
> should chime in one way or the other.

yes, it would be great to better understand what people really want to 
do. for example, i am very interested in mixing social applications and 
location-aware applications, and because of this, places (i.e., place 
names that make sense to people, maybe even only a small set of people 
sharing their location info through a social app) are something that i 
think is central to location information.

the funny thing about spaces (spatial information about location) and 
places (named locations that make sense to groups of people) is that 
there can be interesting combinations: you can have spaces that map to 
no places, or places that map to no space. the latter concept, for 
example, is great wrt privacy, because it allows meaningful location to 
be shared without disclosing spatial information.

because this is what i am interested in, i think it is not a good idea 
to have a location API that only focuses on spatial data. if the UA 
makes a "location fix", the user should have the option to say "at 
home", and there is not spatial information for that. i believe that the 
future of the mobile web will depend of this kind of more human-centered 
application design.

on the other hand, i am sure that are many web app developers who simply 
want to get their hands on that nice GPS data and that's all they want 
from an API. which is why i think it's important to have use cases and 
requirements, and to use this as a starting point to develop a location 
concept.

> Having a URI scheme for location is an interesting concept, but it
> does not seem like the simplest way to expose this information.  I
> also see no privacy benefit to exposing information this way.

personally, i'd love to see the coordinates disappear and also become 
part of the URI, so that a location would always be just a URI. but i am 
pretty sure this is not going to happen... it would not be much more 
complicated than having individual values, though, something along these 
lines:

loc:27.988056,86.925278

wrt privacy: the benefit would be that you could also decide to provide 
your information as a place name, which would only makes sense within a 
certain context, and maybe even then only socially and not spatially, if 
you never told anybody where you are living:

loc://aaron.boodman/homesweethome

or even more explicit just signaling that you are not at work or at 
home, just someplace else:

loc://aaron.boodman/noneofyourbusiness

(again, all examples are hypothetical)

> Therefore, I suggest pursuing the idea separately. If successful,
> there is no reason the two ideas could not be integrated in some
> future version of this spec.

in theory, you're right. in practice, i think the privacy and user 
interface design implications are pretty substantial, so there really is 
a difference in how well locations can be handled on the mobile web, 
depending on whether you have a location concept that is spatial only, 
or one that supports "location resources" (URIs) as well.

cheers,

dret.
Received on Saturday, 28 June 2008 01:25:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 March 2012 18:13:39 GMT