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
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
>
> -----Original Message-----
> From: 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
> Cc: 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>  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
>> 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
>> 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.