- From: Rob Manson <roBman@mob-labs.com>
- Date: Sun, 24 Apr 2011 16:44:51 +1000
- To: "discussion@arstandards.org" <discussion@arstandards.org>, "public-poiwg@w3.org" <public-poiwg@w3.org>
Hi all,
after quite a bit of absorbing and re-thinking of my initial
rant...here's a few distinctions that I'd like to raise that relate
directly to location based Augmented Reality.
1. Locations
2. Queries
3. Representations
Locations
It seems like RFC5870[1] geo: URIs are a good solution for
embedding locations, in the same way that mailto:, tel: and sms:
URI schemes provide a good way for embedding email addresses,
phone numbers and SMS capable mobile phone numbers into content.
But I think there is a slightly confusing element within the RFC
that I'll describe below after the other 2 points.
Queries
Requests that are sent to a specific server or local application
in order to extract a list of Points of Interest relative to a
specific Location seems to be the natural interaction that
drives location based Augmented Reality.
Layar use a getPOI request. Junaio use a pois/search? request.
Wikitude uses a similar but unnamed request. The list goes on.
Representations
The responses to Queries about specific Location return POIs
that are Representations of interesting "things" that have or
had a relative Location at some point in time.
So, what I had attempted to map out in my earlier email was using the
geo: URIs as the basis for a query where the geo: part was the Location
content and the #fragment constrained the scope. But upon reflection I
don't think this does make sense. I think what confused me initially
was the uncertainty parameter[2]. In some ways this is very similar to
the radius/perimeter parameters used by Layar and Junaio, etc. as the
uncertainty parameter defines an area within which the location may be.
But it is really quite the opposite. This uncertainty area is defined
by how precise (or imprecise) the source of the lat/lon/alt coordinates
really is (e.g. the GPS). By contrast the radius/perimeter in a getPOI
or search/pois Query defines the area within which you want to search.
I know this may be quite obvious...but I think it's worth discussing
because the example in section 7.4[3] of RFC5870 starts to blur this
line even further. Here the uncertainty parameter is used to define the
radius of a GML sphere...and this to me seems like it's diluting the
meaning of this parameter. What do you think?
I also think these 3 distinctions of Location, Query and Representation
relate really well to the "Categorization + Whether a POI must have
location" thread[4]. I think a POI representation by definition as a
Point "requires" a Location. Vinod, in your recent question about the
advertisements...
"If we say that POIs always need to have location, *many of the
suggestions, advertisements (which don't represent a single
geo-tagged item but a list of geo-tagged items) can never be
POIs*. So, do we think and agree that such 'virtual entities'
representing groups of POIs are not POIs?"
...I think these are just Queries that return Representations that are
related to Locations (e.g. POIs). But the Queries are NOT the
POIs...just like the Map is NOT the Territory. It can be confusing
because the Location is embedded in both the Query and the
Representations...but in these 2 different contexts the Locations have
quite different meanings.
Are there any other related distinctions here we should be calling out?
NOTE: Thomas, I know the Query doesn't directly map to the sort of
syndicated POI distribution you've discussed using xmpp, rss, etc...but
I really just see that as a caching/distribution layer and the final
Representations are still displayed based on a real Query using the
users Location at a point in time.
roBman
[1] http://tools.ietf.org/html/rfc5870
[2] http://tools.ietf.org/html/rfc5870#section-3.4.3
[3] http://tools.ietf.org/html/rfc5870#section-7.4
[4] http://lists.w3.org/Archives/Public/public-poiwg/2011Apr/0016.html
On Fri, 2011-03-18 at 01:10 +1100, Rob Manson wrote:
> Hi Karl,
>
> yeah it's probably worth explicitly separating out the different
> points...I kinda jumped into the deep end there 8)
>
> First, I thought I'd just raise the geo:URI rfc as I thought it was
> relevant...at least for discussion.
>
> Second, I thought that was useful for having a URI standard that we
> could use for the ID primitive.
>
> Third, I thought there was some ambiguity as the browser is open to
> interpret the geo:URI any way it wants...and that we would need all
> those other details you listed...or at least a way to scope the
> reference down to a specific object/item that then has those other
> details attached to it. So I was speculating that we could use the
> fragment as a way to handle that.
>
> Essentially there would be two elements in the full URI - the left side
> of the # and the right side.
>
> geo:...left side...#...right side...
>
> So the left side would be used as a way to specify the location.
> The right side would be the permalink for the POI itself
> e.g. the actual id.
>
> But after thinking about it further maybe I'm blurring a few layers
> together and need to be more explicit about the use case. Let me write
> up some other notes and post them later.
>
>
> roBman
>
> On Thu, 2011-03-17 at 08:22 -0500, Seiler, Karl wrote:
> > If I am interpreting this right, we are discussing using a geo URI as the unique and persistent ID of the Place's location primitive. But we still need the other resolved attribution in the location primitive such as civil address, associations to other spatial constructs such as this is inside the building, etc.
> >
> > Also if (when) the business at a Place moves that Places gets a new geo URI, buts it's Place ID does not change.
> >
> > Right?
> >
> > Sent from my iPad
> >
> > Karl Seiler
> > Director, Location Technology and Services
> > Navteq
> > O: 312-894-7231
> > C: 312-375-5932
> >
> > On Mar 17, 2011, at 2:58 AM, "Christine Perey" <cperey@perey.com> wrote:
> >
> > > Hello,
> > >
> > > By way of this message I am bringing the public-poiwg mailing list
> > > (which Rob originally copied--brilliant move IMHO--but which was
> > > "truncated" after one or two messages) back into the thread.
> > >
> > > For those on the public POI WG mailing list who are interested, you have
> > > missed a few posts. Some of the posts are preserved in this message.
> > >
> > > The entire thread which was on the AR discussion mailing list is
> > > archived [1]
> > >
> > > If those on public POI WG mailing list wish to post/contribute to the AR
> > > discussion mailing list (this or any other thread) or just to lurk on
> > > this list, please subscribe yourself [2]
> > >
> > > Regards,
> > >
> > > Christine
> > >
> > > Spime Wrangler
> > >
> > > cperey@perey.com
> > > mobile +41 79 436 6869
> > > VoIP +1 (617) 848-8159
> > > Skype Christine_Perey
> > >
> > > [1] http://arstandards.org/pipermail/discussion/
> > > [2] http://arstandards.org/mailman/listinfo/discussion
> > >
> > > On 3/17/11 4:33 AM, Rob Manson wrote:
> > >> Hey Carl,
> > >>
> > >> absolutely will engage directly with the authors.
> > >>
> > >> Probably worth having a good AR specific discussion first to see if we
> > >> can provide some consolidated feedback though 8)
> > >>
> > >>
> > >> roBman
> > >>
> > >>
> > >> On Wed, 2011-03-16 at 20:14 -0400, creed@opengeospatial.org wrote:
> > >>> If there are questions regarding the internet RFC for the geo uri, I would
> > >>> suggest contacting the authors directly. Their emails are in the document.
> > >>>
> > >>> Regards
> > >>>
> > >>> Carl
> > >>>
> > >>>> That's kinda the whole issue I see with geo:URIs.
> > >>>>
> > >>>> My second point was that the fragment could be the thing that binds it to
> > >>>> a server/request if it were a standard URI.
> > >>>>
> > >>>> G'night Thomas 8)
> > >>>>
> > >>>>
> > >>>> roBman
> > >>>>
> > >>>>
> > >>>> On 17/03/2011, at 10:28 AM, Thomas Wrobel<darkflame@gmail.com> wrote:
> > >>>>
> > >>>>> This is of the top of my head, as its getting a bit late here and I'm
> > >>>>> doing far too many things at once...
> > >>>>>
> > >>>>> But what would the fragment actually mean for the client?
> > >>>>>
> > >>>>> " geo:-33.874813;151.21840#robman"
> > >>>>>
> > >>>>> Unlike a url which points to a server which points to a page where the
> > >>>>> fragment refers to a specific state (or location) within the page -
> > >>>>> the geo location points to a point on the earth. There is no
> > >>>>> datasource to look for that string within. How does the string
> > >>>>> fragment then narrow down that specification of location? What does
> > >>>>> the client do when it gets the string "robman"?
> > >>>>>
> > >>>>> Theres probably something I'm missing here. I can certainly see a use
> > >>>>> for narrowing down the location - but I think it would need to specify
> > >>>>> an image or some other physically identifying property the ar client
> > >>>>> could then use to pinpoint what rather then a simple string.
> > >>>>>
> > >>>>> I'll re-read this all again tomorrow and probably have more/different
> > >>>>> comments ;)
> > >>>>>
> > >>>>> -Thomas
> > >>>>>
> > >>>>>
> > >>>>> ~~~~~~
> > >>>>> Reviews of anything, by anyone;
> > >>>>> www.rateoholic.co.uk
> > >>>>> Please try out my new site and give feedback :)
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On 16 March 2011 23:49, Rob Manson<roBman@mob-labs.com> wrote:
> > >>>>>> Hey Thomas,
> > >>>>>>
> > >>>>>> yeah those are good points.
> > >>>>>>
> > >>>>>> After absorbing it for a little while I think orientation could be
> > >>>>>> externalised/abstracted (see my thoughts below) so the core geo:URI
> > >>>>>> just
> > >>>>>> becomes the reference point of origin.
> > >>>>>>
> > >>>>>> As for the uncertainty...I agree and I don't think that's the only
> > >>>>>> ambiguity about it that would be good to resolve.
> > >>>>>>
> > >>>>>> Perhaps I'm missing the point...so I'd love to hear other people's
> > >>>>>> constructive criticism of how I think we could extend it 8)
> > >>>>>>
> > >>>>>> So, from my reading it seems that this is really dependent upon the
> > >>>>>> browser/client having a pre-defined model for handling the local
> > >>>>>> presentation of geo:URIs. This is very ambiguous. I can see why this
> > >>>>>> may be the case...but I wonder if there was any thought or discussion
> > >>>>>> during draft the rfc around an optional broader handling as traditional
> > >>>>>> urls do - e.g. including an optional hostname or even url
> > >>>>>>
> > >>>>>> Also, adding/using fragments identifiers[1] like traditional
> > >>>>>> urls do to refer to specific objects or parts within that geo:URI could
> > >>>>>> really extend this in useful ways and maps to the existing HTTP model.
> > >>>>>>
> > >>>>>> e.g.
> > >>>>>>
> > >>>>>> geo:-33.874813;151.21840#robman
> > >>>>>> or
> > >>>>>> geo:-33.874813;151.21840#$unique_local_id
> > >>>>>>
> > >>>>>> I can see how this would be very useful and relevant to the POI-WG and
> > >>>>>> AR in general. In fact if the fragment identifier were able to include
> > >>>>>> a url (possibly an evil tunnelling extension 8)) then this could kill
> > >>>>>> both the points I've raised with one stone.
> > >>>>>>
> > >>>>>> e.g.
> > >>>>>>
> > >>>>>> geo:-33.874813;151.21840#http://$host/$path<- possibly evil 8)
> > >>>>>>
> > >>>>>>
> > >>>>>> This would allow multiple objects/things to share the same location
> > >>>>>> point of origin...and then also to support structured queries and
> > >>>>>> filters etc. I'm really just thinking of this in terms of the ID
> > >>>>>> primitive [2] and this would work well in existing format like KML etc.
> > >>>>>> too.
> > >>>>>>
> > >>>>>>
> > >>>>>> roBman
> > >>>>>>
> > >>>>>> [1] http://en.wikipedia.org/wiki/Fragment_identifier
> > >>>>>> [2] http://lists.w3.org/Archives/Public/public-poiwg/2011Feb/0037.html
> > >>>>>>
> > >>>>>> On Wed, 2011-03-16 at 21:40 +0100, Thomas Wrobel wrote:
> > >>>>>>> I gave it a very quick read over and it does indeed have much of
> > >>>>>>> that's needed (including a default co-ordinate system while being able
> > >>>>>>> to specify others, as well as a accuracy spec).
> > >>>>>>>
> > >>>>>>> However, I think it lacks any orientation specification which we would
> > >>>>>>> need. So we could adopt the key/value pairs used here, but would need
> > >>>>>>> to add additional ones as well. We could of course use the standard as
> > >>>>>>> is, but include the additional data as separate fields - but that
> > >>>>>>> would lead to more complex parsing.
> > >>>>>>>
> > >>>>>>> I'm also not completely sure I like how circle and sphere regions seem
> > >>>>>>> to be defined just by a "uncertain point"...seems like data stored in
> > >>>>>>> that way could be ambiguously and vulnerable to be interpreted in
> > >>>>>>> different ways.
> > >>>>>>> [/my 0.0143918euros]
> > >>>>>>>
> > >>>>>>> I agree however, this should certainly be discussed and added to the
> > >>>>>>> existing standards list.
> > >>>>>>>
> > >>>>>>> -Thomas
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> ~~~~~~
> > >>>>>>> Reviews of anything, by anyone;
> > >>>>>>> www.rateoholic.co.uk
> > >>>>>>> Please try out my new site and give feedback :)
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On 16 March 2011 01:40, Rob Manson<roBman@mob-labs.com> wrote:
> > >>>>>>>> Hi,
> > >>>>>>>>
> > >>>>>>>> I know there has been a lot of mention of WGS-84[1] in the
> > >>>>>>>> public-poiwg
> > >>>>>>>> discussions but I couldn't seem to find[2][3] any mention of or
> > >>>>>>>> reference to rfc5870 - A Uniform Resource Identifier for Geographic
> > >>>>>>>> Locations ('geo' URI)[4].
> > >>>>>>>>
> > >>>>>>>> This seems like a significant thing to be overlooked and something it
> > >>>>>>>> seems like we should be utilising and benefiting from...if indeed it
> > >>>>>>>> does look like becoming a usable standard (obviously only a
> > >>>>>>>> draft/proposed standard at the moment).
> > >>>>>>>>
> > >>>>>>>> So...what do people think of rfc5870?
> > >>>>>>>>
> > >>>>>>>> Christine, this is definitely something we should add to the
> > >>>>>>>> ARStandards.org "existing standards" page under the "Location
> > >>>>>>>> Standards"
> > >>>>>>>> section.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> roBman
> > >>>>>>>>
> > >>>>>>>> [1]
> > >>>>>>>> http://www.w3.org/Search/Mail/Public/search?type-index=public-poiwg&index-type=t&keywords=WGS-84&search=Search
> > >>>>>>>> [2]
> > >>>>>>>> http://www.w3.org/Search/Mail/Public/search?type-index=public-poiwg&index-type=t&keywords=5870&search=Search
> > >>>>>>>> [3]
> > >>>>>>>> http://www.w3.org/2010/POI/wiki/index.php?title=Special%3ASearch&search=5870&go=Go
> > >>>>>>>> [4] http://tools.ietf.org/html/rfc5870
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> _______________________________________________
> > >>>>>>>> Discussion mailing list
> > >>>>>>>> Discussion@arstandards.org
> > >>>>>>>> http://arstandards.org/mailman/listinfo/discussion
> > >>>>>>>>
> > >>>>>>>
> > >>>>>> _______________________________________________
> > >>>>>> Discussion mailing list
> > >>>>>> Discussion@arstandards.org
> > >>>>>> http://arstandards.org/mailman/listinfo/discussion
> > >>>>>>
> > >>>> _______________________________________________
> > >>>> Discussion mailing list
> > >>>> Discussion@arstandards.org
> > >>>> http://arstandards.org/mailman/listinfo/discussion
> > >>>>
> > >>>
> > >>>
> > >> _______________________________________________
> > >> Discussion mailing list
> > >> Discussion@arstandards.org
> > >> http://arstandards.org/mailman/listinfo/discussion
> > >>
> > >
> >
> >
> > The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.
> >
> >
Received on Sunday, 24 April 2011 06:45:31 UTC