Re: POI based Open AR proposal

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:02:15 UTC