[mmox] Use cases

[Jon Watte <[e-mail]>]

Yesterday, I posted three possible use cases, but I haven't heard any 
responses. Perhaps it got lost on the way to the list (I don't generally 
get my own posts back, even though I've tried to configure that in Mailman).
Today, I added another two use cases, for a total of five persuasive use 
cases for virtual world interoperability. You can find them at 
http://www.interopworld.org/mmox-use-cases, or you can just read the 
following:

The use cases, in brief, are:
1. *Friend Invite* -- you invite me to come visit you in your virtual 
world, when I'm currently in another world.
2. *Collaborative Training* -- two organizations with different virtual 
world technologies can collaborate on a defined scenario.
3. *Scene Transfer* -- I can export content that I have rights to from 
one virtual world, and load as much as possible into another virtual world.
4. *Analysis* -- I can purchase or create a tool that does automatic 
analysis of events in a virtual world, and hook it up to any world/s I 
have permission to do it.
5. *Data Logger* -- I can record the events and interactions of a 
virtual world where I have permission to do it, and later provide that 
data as a playback (a la YouTube) for anyone to experience "read-only."

We are doing 2..5 in OLIVE already, but obviously only within the OLIVE 
technology domain. A large part of my interest in this field is to be 
able to do 1..5 across a wide variety of worlds.

*Use case "Friend Invite"*

   1. User A uses virtual world system A that complies with MMOX
      simulation interoperability.
   2. User B uses virtual world system B that complies with MMOX
      simulation interoperability.
   3. User A wants user B to visit him/her in system/world A, and gets a
      suitable URL from his/her system (A), and sends this to user B
      using any transport (mail, IM, integrated communication, carrier
      pigeon, ...)
   4. User B clicks/activates this link.
   5. After a brief "loading" screen, user B sees user A in user A's
      environment, including a representative form of any simulated
      object in that environment.
   6. User B can interact at some level with the objects from user A.
   7. Objects that user B take out of inventory show up in some
      representative form for both user A and user B.
   8. User A can interact at some level with any objects that user B
      bring out of inventory.

*Use case "Collaborative Training"*

   1. Company A operates a chemical plant in city B. Company A uses
      virtual world system A to do
      simulation/training/command-and-control of its plant.
   2. City B has an emergency response organization that uses virtual
      world system B for training and scenario planning.
   3. At a defined time, company A and city B agree to connect their
      worlds for a defined duration to conduct a training excercise
      related to a fire in the chemical plant.
   4. At the defined time, a representation of the detailed
      model/simulation of the chemical plant shows up at the right
      address in the virutal world for the city workers.
   5. At the defined time, city workers (ambulances, fire trucks, etc)
      become visible to the chemical plant workers.
   6. Interactions between users of the systems include conversations
      (voice, simulated radio, PSTN).
   7. Interactions between users of the systems include a display of the
      fire as it propagates based on company A simulation models.
   8. Interactions between users of the systems include the ability for
      firefighters to pour water (or other agents) onto the fire, and
      have the simulation respond.
   9. Interactions between users of the systems include the ability for
      city workers to load a chemical plant worker into a city ambulance.
  10. At the pre-determined time, the interoperability ends; the city
      disappears from the company plant, and the company plant
      disappears from the city model.
  11. Session record/review capability used by the city in virtual world
      B includes all communications and interactions made in the system
      including those internal to company/world A.

*Use case "Scene Transfer"*

   1. A user of virtual world A has prototyped an interesting environment.
   2. The user decides to donate that prototype to an organization that
      uses virtual world system B.
   3. The user "exports" his/her prototype to a series of common data
      containers (textures, meshes, scripts, etc) of some standard
      format (e g COLLADA, X, FLT).
   4. All content that the user has created and owns (no matter what the
      permission) that is part of the prototype is included in
      sufficient detail in the export.
   5. All content that has "free view/derive" permission that is part of
      the prototype is included in sufficient detail in the export.
   6. No content that is not created-and-owned by the user, and that
      does not have "free view/derive" permissions, is included in the
      export, although a reference saying "an object with
      characteristics C named N was here" may be.
   7. The exported data is attributed (in aggregate) to user A.
   8. Organization B can load the exported assets into their virtual world.
   9. Meshes and textures in a well-known standard format shows up in
      world B as expected, with attribution to user A, no matter what
      technology the respective virtual worlds use.
  10. Scripting and interactive behavior shows up only if the
      destination virtual world implements a scripting or behavior
      system compatible with the source world.

*Use case "Analysis"*

   1. ISV A creates a system for analyzing movement of avatars in a
      virtual world
   2. The product from ISV A can be connected to any virtual world or
      worlds implementing interoperability.
   3. When the tool is connected, certain patterns of movement are
      detected and flagged by the tool.
   4. The tool can report recognized actions through chat, or through
      introducing "flag" objects into the world.
   5. A virtual world user interacting with the "flag" objects can pull
      up a web page that gives information about the detected interaction

*Use case "Data Logger"*

   1. User of virtual world system A purchases a 'data logger' tool from
      company B.
   2. When attaching the data logger tool to the virtual world, the data
      logger receives information about all the objects, interactions
      and communication in the system.
   3. After the logger has been detached, the data logger tool can be
      seen as a separate "virtual world peer" and connected to by any
      virtual world using interoperability.
   4. The logger implements play and shuttle controls that allow the
      action from the original session to be re-played at a later time.
      Any attached virtual world peer will see the recorded actions.
   5. Enough data is available to the logger that search functions like
      "find the time when avatar X interacted with vehicle Y" can be
      implemented.
   6. Actions by avatars in the connected peers during playback do not
      affect the objects provided by the logger tool.


For purposes of these use cases, we can consider cases where "A" means 
"OpenSim" and "B" means "OLIVE," or use cases where "A" means Croquet 
and "B" means "Second Life," or "A" means Project Wonderland and "B" 
means "Multiverse.net" (although representatives from those two 
organizations are not yet on the list).