Re: POI based Open AR proposal

I think that we may be going down into the details a bit too far 
however, this is a fascinating dialog

[ BIG Applause [clap] [clap] [clap] ]

I share Thomas' concern that "intelligence" totally on the server would 
be far too heavy. Perhaps that's not Klas' intention (would seem odd 
coming from a device maker!!)

Client designers should be able to build based on what is best for the 
user experience.

Hope that others will express their opinions.

Christine

On 9/3/2010 2:01 PM, Thomas Wrobel wrote:
> On 2 September 2010 09:20, Hermodsson, Klas
> <Klas.Hermodsson@sonyericsson.com>  wrote:
>> 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.
>
>
>
> Maybe I'm misunderstanding you, but surely totally server-side
> filtering/sorting of data (like google) would become very heavy as
> users increase? Also, in order for the server to know whats relevant
> to *you* it will need to know a lot about you, which would cause a lot
> of privacy concerns.
> It seems to me it makes more sense for servers to only do either
> specific query's or "broad sweep" filtering, and let the clients
> choose the precise data out of that.
>
> I think the "intelligence" for both scalability and privacy would be
> better left mostly to the client designers. The standard would allow
> people to subscribe to multiple streams of information, and the client
> picks what out of those feeds is relevant to display at any one time.
> (I picture many,many feeds at once typically here)
> However, clients might also get good at suggesting streams or
> auto-sub-subscribing to things relevant. (and heres where search
> engine like enitys come into play). But by overall keeping the "most
> precise" level of filtering down to the device, it means the server
> never needs to know precisely where you are, or precisely what you are
> wishing to display.
>
> Remember also, the client (potentially) will by far and away know the
> most about the user and what the user needs to see. So I dont think
> the potential for constant relevant information is reduced. (for
> example, a client might know when your in your kitchen, would you
> really want to be sending a search engine information on that level of
> fidelity constantly? Even ignoring privacy, that will quickly become a
> lot of data. If, on the other hand, theres a stream for "Recipes" and
> "Food information" your client could choose to display that
> information only when your in the kitchen)
>
> Finally, I'd just like to say I'd too like to go a bit from the
> "request-response" system, which is why I'm quite passionate that
> whatever standard that is come up with can work quite happily over
> XMPP or WFP. Realtime data pushed from the server, and the user being
> able to easily contribute data back into a stream I see as infinitely
> useful in an AR context.
>
>
>

Received on Friday, 3 September 2010 12:35:53 UTC