- From: Thomas Wrobel <darkflame@gmail.com>
- Date: Sun, 24 Apr 2011 12:49:52 +0200
- To: roBman@mob-labs.com
- Cc: "discussion@arstandards.org" <discussion@arstandards.org>, "public-poiwg@w3.org" <public-poiwg@w3.org>
>"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."
No, I'd have to disagree with that; queries are fundamentally pull,
xmpp (and others) can be push based.
eg. A new POI could appear in the users field of view instantly, if
they are subscribed to that source and its just been created.
No query was sent from the device to get it - the server sent a update
saying it was there to anybody relevant.
Now I get that you could say the server mearly says a new POI is at a
location, and the device internally has to ""query"" itself to see if
its in the field of view. But that's implementation stuff that should
be left upto the client makers. (ie , they might want to give personal
filtering options, highlighting of some content etc). Internally a app
might use sone sort of DB and query, but that internal stufff doesn't
have any reliance on a standard.
(be it a POI standard, or a POI query standard - which are two separate things)
I don't have any objections to a query standard, mind you. Merely that
POIs will be used in many cases without any query's.
imho, POIs should be defined first anyway, else you wont know
potential query parameters.
>"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?"
Uncertainly should not be used to define an area!
I'm very concerned about double meanings like this, we need to be as
specific as possible.
Remember, you could also have something that is a known area but an
imprecise centerpoint. So uncertainly and radius are very clearly
separate things to.
I see some usefulness for a client to know the rough size of a POI,
incidentally; it would help it work out if its visible from a specific
distance or not. (ie, don't load a coffee shops sign when your 20
miles away, but that skyscrappers label or 3d augmentations should be
loaded). This doesn't have to be worked out now or anything, and I am
coming from an engine-design perspective here.
-Thomas
On 24 April 2011 08:44, Rob Manson <roBman@mob-labs.com> wrote:
> 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.
>> >
>> >
>
> _______________________________________________
> Discussion mailing list
> Discussion@arstandards.org
> http://arstandards.org/mailman/listinfo/discussion
>
Received on Sunday, 24 April 2011 10:50:21 UTC