[standards-jig] Geo positioning services -- advanced features
M.Dzbor at open.ac.uk
Tue May 6 10:35:51 UTC 2003
reading through JEP060 proposals, we think there is a lot of related work we have been doing here at KMi, esp. in the context of BuddySpace Jabber client development. Maybe the comments listed further down are directly relevant to this particular JEP, but IMHO they would be relevant to the topic of geo positioning and various issues connecting with this.
These "various issues" include a bit more advanced pub/sub model that might be used e.g. for:
1. geo positioning services and map-based (location-based) filtering;
2. publication of data on several different levels (of accuracy, frequency, "trust", etc.);
3. specifically "wrapping" the existing pub/sub model to define levels of trust (privileges) for various (groups of) users
A few ideas and comments to each of the categories mentioned above...
In respect to the geo location, we think that the actual locaiton is the crucial element; however, the MAP specification (or any other display on which the location should be shown) should also be part of the negotiation protocol for geo positioning. A map can be in general ANY (GRAPHICAL) DISPLAY of items (e.g. IM contacts). THese items may be taken from the user's roster or may be a result of search.... The purpose of geo positioning would then be to display this sub-set of contacts in some meaningful graphical way -- i.e. I might be interested in a particular view, context or resolution but the geo positions transmitted might be always the same. What is needed in addition to the lat/lon is some kind of description of the maps... esp. if maps are generated automatically (as in our case) to suit a particular sub-set or user's request.
Moreover, some maps might be hierarchical -- they may contain insets or smaller maps in them... This approach would combine several different views into a composite one... The inset maps may surely be scaled, panned, using different projection than the main map, etc. In other words, we think these additional attributes about scales, projections, etc. would be very handy for advanced features. For example, because we transmit the info about the "projection", we should be able to base the map on any attribute that can be translated into some kind of projection -- e.g. I can show project members in their particular work packages at a particular stage of their work (iff such info is available)......
Totally different point is about filtering the items shown in the map. Similarly to the groups in the roster, maps may contain individual "dots" or "clusters"... The user should be allowed to select a particular region on the map (say a circle of given radius), and do some action with all those "dots/clusters" that happen to fall inside the radius. THe action might be a simple "Send msg to all selected" but perhaps more interesting is something like "Give me more details on these people", "Apply this additional filter on the items in the selected region"......... [sky's the limit] ;-)
Geo data (but this applies to any other data) can be published on many different levels of precision - e.g. it makes a difference to use a lat/lon position or "within 1 mile radius"..... Both are "positions" in a way, and both may actually be measured very precisely by GPS or whatever. However, the user should be able to say how much information is provided (published) about them -- i.e. even if we know lat/lon, downgrade this precise location to something less scary ("1mile radius"). Moreover, this tweaking of the published service may include things like how often to update this information (automatically?), who can actually view it available (who's authorized)....
The point here is that the source of information (e.g. GSM operator), the service provider (translator from GSM to lat/lon), and the service "publisher" (the user) may be (and often will be) different! So, I as a user must be able to tell the provider how to provide the date about myself, with what accuracy, to whom, etc. Perhaps operations like "switch sending on/off", "set expiration time" (or "set automatic"), "set precision" (or different precisions based on zones of trust - see 3), etc.
DON'T KNOW if this point is relevant to the geo stuff - probably more to the pub/sub generally???
What we mean by "wrapping" and "zones of trust" is something along the following lines - still a very early idea though... ;-)
When publishin info, it may be useful to do it on several different levels - each with a different precision or privacy. The point is that we can't bother the subscribers to select a particular "level of (say) geo positioning"... THey may not even need to know that there are some levels... What is then needed is a kind of "wrapper" or "pub/sub firewall" (??) that would filter the incoming request from "joe at domain.org" for "GET location of jane at domain.org" based on what privileges Jane gave to Joe......
Assuming there is a rule like " * FROM GRP 'Family' SHOW SRV 'Location' LVL 'high-precision'" and Joe is part of the family, his original request should be translated by the wrapper into:
"GET location[high-precision] of jane at domain.org" [ignore the syntax of any query]
which may return lat/lon.... If the same request comes from (a former boyfriend) Jack, then the answer may be automatic rejection of any such information or providing only a very abstract positioning......
But the basic idea of this FW/Wrapper on pub/sub is that is an absolutely transparent interface for the communication with a particular service provider (in that example about, neither Joe, Jack, nor Jane have to ask for A SPECIFIC service; they all get what they are AUTHORIZED TO or what they deserve.....)
The management of this pub/sub FW/wrapper would be basically very similar to that of common alternatives on linux (other OS) --- say firewall package or squid or iproute.... Basically shileding the publisher from a very tedious confirmation of every single subscription request on an individual basis. Instead various filters based on (sub-)domain names, wildcards, groups of contacts, and/or time/date could be used to publish a robust service. Both positive and negative privileges might be useful.....
ANYWAY, enough of this lenghty email - congratulations, if you reached it this far..... ;-) ;-)
If you think some of the ideas mentioned would be relevant, please, respond and feel free to criticize or suggest improvements. We didn't want to do some official submissions before throwing the ideas against the wall and see how many of them (and which ones) remain stuck on the wall, and what's rubish.......
Thanks for your comments & looking forward to the response(s),
Martin Dzbor & Jiri Komzak
(http://buddyspace.sourceforge.net & http://kmi.open.ac.uk)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards