W3C home > Mailing lists > Public > public-poiwg@w3.org > September 2010

Re: POI based Open AR proposal

From: Hermodsson, Klas <Klas.Hermodsson@sonyericsson.com>
Date: Thu, 2 Sep 2010 09:20:11 +0200
To: Thomas Wrobel <darkflame@gmail.com>
CC: "roBman@mob-labs.com" <roBman@mob-labs.com>, "public-poiwg@w3.org" <public-poiwg@w3.org>
Message-ID: <F9DC823F-70FB-4ED6-A6DE-DE8E4563CD40@sonyericsson.com>
This may be a bit off topic but I think it is crucial that we lift our eyes a bit beyond the current AR browsers such as Layar, Wikitude etc. Channels (or opt-in streams that I like to call them) is the current style of many AR browsers. I have in my positional paper [1] for the W3C AR Barcelona workshop made the point that useful AR browsing requires relevance. This relevance requires "a lot of content" and to then apply filtering where a very important part of the filtering is to apply the user context. This "a lot of content" and filtering will require a different setup from the current request-response scheme of today's web. Similar to how google search engine ranks results off client infrastructure must most likely prepare this ranking. At the same time the aggregation and filtering should not be single server work or we will end up single point of failure and a structure which breaks the organic and independent distribution infrastructure that makes the current web so valuable.

So in summary, I wish we would stop talking about channels as the major AR browsing method for the AR. Of course we need to cover the current ways in order for the standard to be relevant but let's ensure the standard can grow and in a good direction.


[1] http://www.w3.org/2010/06/w3car/beyond_the_keyhole.pdf 

On Sep 1, 2010, at 18:48 , Thomas Wrobel wrote:

> So I don't really think the model of how Web2.0 application work is a
> very good fit for this system. Web 2.0 app's really have to do a fair
> bit of work (coding wise) in order to get functionality flowing
> between a server a client. This sets the bar rather high for those
> wanting to make simple collections of geolocated information. In this
> case we really want to move some of that into whats required from the
> client itself.
> Also, by keeping the client in charge of the pulling of data, it means
> one source of data can be more easily suitable for many devices. The
> client knows how often it can/should "refresh" and see if any of the
> conditions have been met. It can recheck based on movement or time,
> without sending that data to a server unnecessarily, or without the
> content creator to code request intervals themselves.
Received on Thursday, 2 September 2010 07:21:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:48:25 UTC