RE: Realtime use-case's

Yes.

We (NAVTEQ) went down the road of differentiating static from dynamic content. It was a slippery slope that did not yield great value in understanding the real problem space. Also separation of basic content from rich content has aspects of the same definition problem. It tends to be contextual.

I assume we will broach this topic tomorrow.

_______________________________
Karl Seiler
Director Location Technology & Services
NAVTEQ - Chicago
(T)  +312-894-7231
(M) +312-375-5932
www.navteq.com<http://www.navteq.com/>

From: Christine Perey [mailto:cperey@perey.com]
Sent: Monday, December 13, 2010 1:14 PM
To: Seiler, Karl
Cc: Thomas Wrobel; public-poiwg@w3.org
Subject: Re: Realtime use-case's

Hi Karl,

I think your statements are basically in support of not making a distinction at least at the data format/definitions level between real time and non-real time use cases.

Did I understand correctly?


Christine



Spime Wrangler



cperey@perey.com<mailto:cperey@perey.com>

mobile +41 79 436 6869

VoIP +1 (617) 848-8159

Skype Christine_Perey

On 12/13/10 7:30 PM, Seiler, Karl wrote:

Historical experience (no pun intended) has shown that any attempts to separate real-time from non-real-time definitions suffer from the attrition of the world speeding-up-all-things.



What was considered static is now updated more frequently.

Change happens when it happens and not on fixed cycles.

Everything is real-time just some more so than others.



_______________________________

Karl Seiler

Director Location Technology & Services

NAVTEQ - Chicago

(T)  +312-894-7231

(M) +312-375-5932

www.navteq.com<http://www.navteq.com>



-----Original Message-----

From: public-poiwg-request@w3.org<mailto:public-poiwg-request@w3.org> [mailto:public-poiwg-request@w3.org] On Behalf Of Thomas Wrobel

Sent: Saturday, December 11, 2010 1:23 PM

To: cperey@perey.com<mailto:cperey@perey.com>

Cc: public-poiwg@w3.org<mailto:public-poiwg@w3.org>

Subject: Re: Realtime use-case's



Those all seem reasonable statements to me.

I can't see of any flaws and it seems to cover the more specific examples.



I think the key is, as much as possible, for the data being submitted

(in both the play and create) examples to be the same sort of data

being read in the guide example. So the data creation, data update,

and data viewing can all be done with the minimum of transformations

or conversions by both clients and servers.



As far as the data itself goes, yes, I really don't see any special

requirements realtime introduces to the formatting. Although a few

minor things would be beneficial - for example, timestamps of the last

time the data was updated. (if its a remotely linked mesh, the client

shouldn't have to re-download unless its strictly needed). So maybe in

a few case's realtime would add some weight to the need for specific

fields in the POI.



I can also see realtime later  influencing some of the design of the

spec though by way of protocol.

I think it was mentioned earlier, for example, that if the data is to

be transmitted in a non-html format, you cant relay on a xml style

hierarchy being present. This could influence how you would position

one (virtual) object with respect to another. In xml it might make

sense to have one as a child of the other, and hence when one moves,

the client knows to move the children.

However, this becomes impossible if the two bits of data are from

different sources not within the same file or stream. So in that case,

an ID system of some sort would have to be used. (So maybe one POI

could be positioned relative to a URI of another??)



This example, of course, moves beyond merely defining a single POI

structure and more into the realms of using many different POI to

create a composite scene of independent elements relating to

each-other - which might be outside the scope for now.



So while there is no distinction between a real time use case and a

non-real time in terms of the description of the data itself, when it

comes to relating data together we might run into more issues.



-Thomas







On 11 December 2010 09:29, Christine Perey <cperey@perey.com><mailto:cperey@perey.com> wrote:

Hi Thomas,



I share your general position (stated in the last paragraph of your message

below).



I believe it can be paraphrased as follows: there is (in principle) be no

distinction in the data format used in a "real time" use case and one which

is not real time.



In fact, real time and non real time can (should) use precisely the same

data format and should (must) be totally independent of the architecture of

the application (e.g., data format identical when data is all local, partly

local data, all remote).



This means the same experience for the user if the bandwidth is unlimited

and the protocol is lightweight as the user experience if the data is all

local.



Does anyone believe this is a false assumption to make? What issues does it

raise?



If the above is generally considered a "fair assumption", the logical

extension of this is that there is no need to distinguish between a real

time use case and a non-real time use case.



Further on the topic of use cases.



I am unclear if the use cases need to be as specific as you describe or if

they can be more general.



In Seoul the participants of the International AR Standards meeting

described three AR use case (they are actually categories of use cases).



They have been described several times in conf calls, are depicted visually

in an output of the International AR Standards meeting and can be summarized

for completeness and quick reference as follows:



A. Guide: a system which leads the user through a process involving the real

world



B. Create: a system with which the user attaches/contributes a digital

"object" to or in the real world



C. Play: a system which supports bi-directional interaction between two or

more users in and with the real world



I will now connect the dots (as I see them) between the above use cases and

those you suggest below.



1. tracking of friends or exploration (tourism applications)



for me, these are all specific conditions of the Guide use case.



2. using AR to obtain information about a moving object which the user can

then use to make a decision



for me this is also a Guide use case which includes all the "what's around

me?" use cases



3. tracking celestial bodies



another example of "what's around me?"



4. game in/with the real world



possibly a subcase of Play use case



I think in order to move discussion forward on the topic of use cases, we

must understand what (precisely) needs to be "known" or included about the

complete use case to inform the definition of a suitably flexible and broad

data format.



Christine



Spime Wrangler



cperey@perey.com<mailto:cperey@perey.com>

mobile +41 79 436 6869

VoIP +1 (617) 848-8159

Skype Christine_Perey



On 12/10/10 2:57 AM, Thomas Wrobel wrote:



Seeing as the topic of real-time use case's came up recently, I

thought Id suggest a few rough ones for discussion or refinement;



1. Tracking your friends locations when going to an outdoor event, or

exploring a city while on Holiday. I picture a simple "arrows from the

sky" depiction in the view, with each arrow being updated

independently above your friends every few seconds. The arrows should

only be visible to the friends/family members that have permission to

see the stream.

Additionally, fully public, possibly not-realtime elements should be

scene at the same time, such as a city map overlaid in the sky.



2. Public transport tracking system. Holding your viewing client to

bus/train stops gives you eta's of things arriving and notices of

delays etc. Updated as new information comes in.



3. Astronomy overlay, which shows the paths and position of heavenly

bodies as they pass though the sky. This angular position of these

objects in the sky would naturally have to change based on the time of

day. Nasa or Esa might also supply a update stream of their satellite

positions or other less predictable craft.



4. A Pokemon-esq game played in a local park. Players see their

creatures battling around them, the creatures responding to commands

given.

 While the game rules are dealt with by a dedicated server, the data

is published out in a standard format, so bystanders can watch easily

with generic AR browser software.





My own view;



I personally feel the realtime, as well as social, is a massive area

for AR and should be carefully considered to ensure as flexible

a system as possible. However, I think for most circumstances,

realtime use affects more the protocol of data transmission then the

content itself. That is, the same format of key/value pairs

positioning stuff statically on a http based webserver, could also be

used to reposition stuff dynamically every few seconds over, say, a

xmpp based stream.(which also allows for  selective viewing, such as

in usecase1 above)



As long as the format stays neutral to the transmission method (ie,

not one strictly relaying on a webpage structure), and the required

POI format is lightweight enough, I -think- realtime use should be a

"free" possibility without extra effort.



-Thomas wrobel



~~~~~~

Reviews of anything, by anyone;

www.rateoholic.co.uk<http://www.rateoholic.co.uk>

Please try out my new site and give feedback :)















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.


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.