Re: skeleton Geolocation API

Hellos,

Having just finished making the argument against including any kind of 
reverse geocoding in the API I will dodge to the left long enough to 
suggest adding something like "context" and "context identifier" 
attributes to the Position object.

For the sake of argument, the default context could be assumed to be a 
WSG84 URI and sorting out what anything else actually *means* is left to 
individual developers. (Maybe of handful of known-knowns to deal with 
situations where WSG84 is known-known to cause problems, too...)

At a minimum, that would allow people to identify what system is being 
used for Plain Old Points (tm) and in the hand-waving future leave some 
wiggle room for the kinds of things that Erik mentions and stuff no one 
has imagined yet.

For example :

'context' : 'x-urn:wsg84:pos:', 
 

'id' : '41.370594,2.149999', 
 

'latitude' : 41.370594, 
 

'longitude' : 2.149999, 
 

 
 

-- 
 

 
 

'context' : 'http://ws.geonames.org/rdf?geonameId=', 
 

'id' : 6544104,  # Barcelona 
 

'latitude' : 41.370594, 
 

'longitude' : 2.149999, 
 

 
 

--

'context' : 'http://ws.geonames.org/rdf?geonameId=', 
 

'id' : 3116282, # Montjuic
'latitude' : 41.370594, 
 

'longitude' : 2.149999,

-- 
 

 
 

'context' : 'http://where.yahooapis.com/v1/place/', 
 

'id' : 753692, 
 

'latitude' : 41.370594, 
 

'longitude' : 2.149999, 
 

 
 

-- 
 

 
 

'context' : 'http://www.flickr.com/places/', 
 

'id' : 'Spain/Catalonia/Barcelona', 
 

'latitude' : 41.370594, 
 

'longitude' : 2.149999, 
 

 
 

-- 
 

 
 

'context' : 'x-urn:flickr:photos:', 
 

'id' : 2561027599, 
 

'latitude' : 41.370594, 
 

'longitude' : 2.149999,

--

'context' : 'http://www.dopplr.com/place/',
'id' : 'es/barcelona',
'latitude' : 41.370594, 
 

'longitude' : 2.149999,

-- 

# I don't actually think this is what Mikel
# had in mind but you get the idea...
# http://www.slideshare.net/mikel_maron/its-about-time-for-time/

'context' : 'x-urn:geotime:',
'id' : '41.370594,2.149999 14:23:44 GMT', 
 

'latitude' : 41.370594, 
 

'longitude' : 2.149999,

--

Granted, these examples could all play reverse geocoding on TV but 
that's just my bias these days.

The point is to have some sort of extra hook to pivot off of because, as 
Erik points out, people's concept of "place" is a whole lot mushier than 
a simple coordinate.

Cheers,

Erik Wilde wrote:
> 
> 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 Sunday, 29 June 2008 05:28:06 UTC