Action:
I'm in Virtual World L, and want to talk to Totally VIrtual.  Through some mutual agreement about displaying presence (such as a Friend List), I can see that Totally Virtual is available.

Discussion:
Virtual Worlds are a communication medium. The key element is presence - knowing that people on my contact (Friends) list are available and I can contact them by text or voice. This would enable presence to be visible in both directions - seeing on my cell phone who has their phone on or is available in a virtual world, or from the virtual world, which Friends are available via text or voice channels. As with other services, this requires a way to find the Friend and for the Friend to agree to have presence visible to me.

Standards: presence

Discussion:
This lets the company manage my account status through its existing employee management tools - when I leave the company my name won't appear on the OpenID server and any accounts established with that identity will no longer be available.  Rather than a company having to manage employee lists in multiple virtual worlds, this lets them manage their existing employee accounts and simply makes those securely and privately available to virtual worlds to verify identity when creating accounts.  (Note: the virtual world would be unable to directly obtain any information from that server other than verifying the person did exist and was on the server's list.)

Standards: data exchange that verifies server and passes data about accounts

The link may have a 2D web representation and/or a VW representation. The user is taken to that site from his client and the page/location represented. In the case where there is a 2D and VW representation, the user is either prompted and asked where he would like to go, or based on his client preference settings is taken to the version of the site indicated by this preference.

If you want explicitly to consider moving an avatar between systems, then even there there are sevaral different levels of interoperability. The simplest case might look like this:

1. I have an avatar in System A (say, an OLIVE based corporate virtual world).
2. I want to use that avatar for a social gathering in System B (say, the Pimp My Ride virtual world by MTV).
3. I register at the PMR site. When time comes to specify my avatar and user name, I instead tell the system to "go get my identity from over there," pointing it at my OLIVE based virtual world.
4. The PMR system will fetch avatar data such as clothing, name and appearance from that other system, using an open protocol that's yet to be determined.
5. When I log in to PMR, I get my regular avatar, and others see him as well.

Note: I'm not announcing any particular support for this; I just used two random virutal world names to come up with an example to illustrate how it could work in an early step.

Just to get that example to work, we need at least:

• A way to perform requests of "copying" avatar information around, with some way of handling authentication. This is a Web 2.0 style problem, and solutions might be emerging but there's no "winning" standard yet. Another way to think about it is to use an existing low-level standard (like XMLRPC or SOAP) but define a new schema on top of that.
• A way to transfer geometry and textures in a format that makes sense to the destination system. Example standards might include the COLLADA file format.
• A way to represent "remote identity" in the destination world — someone using that world should see me as "Jon Watte @ OLIVE Corporate World" because that's my "identity" in this case. An existing standard is OpenID; I'm not sure how much modification it would need to fit.
• An approach for how (and whether) to allow write-backs to the identity in the original world, if I change something of the avatar in the destination world. Again, this is a Web 2.0 style problem, and solutions emerging in that space might be re-used.

For that to happen, though, there needs to be economic incentive. People would have to want to pay for that capability, else virtual world providers won't spend time and money implementing something like that. It would be interesting to see the results of a survey trying to figure out whether, and how much, people would be interested in paying for avatar mobility.

Once this level of interoperability exists, future improvements may include:

• A way of transferring avatar behavior (procedural animation like breathing, eye contact, etc)
• A way of transferring emotes/animations.
• A way of transferring inventory; first as "dead items" that just serves as decoration; later as actual objects with physical simulation behavior (that's a very tough nut to crack).

Until that point, you would still be using client program A to access world A, and client program B to access world B. The problem being solved in this use case is basically a content translation and authentication/ownership problem.

As an alternative, I propose starting the virtual world interoperability train by connecting existing services at the back end. This suggestion is based on having solved that kind of interoperability for a number of different customers already, and seeing a clear desire to achieve more integration among enterprise customers, who actually want to pay for the feature. Standards with customers tend to be more effective, and easier to implement, to greater success.

As a use case, to work through some of the areas needing attention, I use the following scenario, which is not far from what we're doing today, although without the benefit of interoperability standards:

• Company A operates chemical plants. They also use virtual world platform Q for training and simulation.
• City B uses virtual world platform S for city planning and emergency management. One of the plants of Company A is located in City B.
• City B wants to run an emergency preparedness scenario involving a large fire at the chemical plant.
• Company A has a nice, detailed simulation/model of the chemical plant in their virtual world.
• City B has a virtual view of the city in their virtual world, but no specifics regarding the chemical plant.
• Employees of Company A log into platform S to participate in the scenario, as usual (no big IT deployment needed).
• Employees of City B log into platform Q to participate in the scenario, as usual (no big IT deployment needed).
• Company A employees see city firetrucks pull up to the plant on the streets outside, and enter the plant.
• City B employees (including emergency responders) can enter the chemical plant, and see the results of the high resolution simulation (which may simulate things like chemical fires and plume dispersal).

To achieve this scenario, a system that interconnects the two back-ends of Company A and City B would have to deal with agreeing on the duration and "virtual area" of the exercise, agree on the content (terrain) used within the area, and agree on what entities take part of the simulation and how they interact. That's still a big mouthful, but it's something that has been done successfully in the military space for 20 years using the DIS protocol (*1).

While DIS has served the military well, it is not quite suitable for an enterprise or consumer class virtual world interoperability protocol for two reasons. First, it hard-codes a lot of military knowledge into the protocol, while leaving a lot of things interesting to civilians out of the equation. Second, it is based on a peer-to-peer, trusted-network model with sizeable PDUs being broadcast between participating peers. However, taking the benefits of DIS, such as a well-defined wire protocol, a reasonable terrain/entity/interaction division, and the good results being had with an "entity telemetry" approach, should be seriously considered when defining a new protocol for virtual world interoperability.

With that in mind, the areas that may need to be addressed by a back-end system integration include:

1. Physical connectivity between the instances of platform S and platform Q. May be as simple as a TCP tunnel using a firewall hole, or as complex as a PKI VPN or SSL solution.
2. Agreement on playbox (area of simulation) and duration of the scenario, to avoid a connection to linger longer than necessary, and to avoid problems like City B employees teleporting to other chemical plant areas in different cities of the virtual world of Company A.
3. Agreement on the terrain (ground and buildings) of the scenario, so everyone sees the same thing, and nobody "runs through a wall."
4. Agreement on high-level information about entities in the simulation ("people" vs "vehicles" vs "trees").
5. Agreement on voice and text communications between the simulations.
6. Agreement on finer detail information about entities — what do they look like; how do they animate.
7. Agreement on user interface for cross-simulation entities; for example how to present a simulated 2D plant status panel to a city worker.
8. Agreement on interaction between entities, for example:
   1. what happens when a firetruck collides with a Company employee.
   2. what happens when water is poured on a chemical fire.
   3. what happens when a City employee pushes the "intercom" button at the gate of the plant.
9. Agreement on the exchange of instrumented data from the simulation, to help in run-time management and post-scenario analysis and review.

This is certainly a large nut to crack, and probably can't (or at least shouldn't) be done in a single big effort. However, I believe there are pieces from this list that can be knocked down relatively easily, and provide good value to existing customers — which means that implementation doesn't need to be on speculation, but can be driven by real needs, and real money, which is always a benefit when making sure that standards serve the needs of stakeholders, rather than the needs of creative engineers and academics with big dreams but little guidance from market demand(*2).

Footnotes:

(*1) Other approaches, such as HLA or TENA, have not received enough adoption to be widely accepted as successful. HLA has problems with cross-vendor interoperability, because it doesn't specify a wire protocol; moving a simulation from one RTI vendor to another requires significant engineering effort. We have also found that, in practice, HLA is also not suitable for an open-ended, general-purpose system with round-the-clock operation. As support for this view, note that large interoperability exercises, both demonstrations and for effect, are still largely based on DIS, unless significant engineering is put into the exercise pre-event.

(*2) An anti-example of a useful standard would be X3D, which simultaneously specifies too much detail, such as an Open Inventor style scene graph, and javascript bindings to the world, and too little, such as what a client/server model would look like, or how to migrate objects between hosts. As support for this view, VRML/X3D has been around for 15 years, with very little industry adoption, whereas a format like COLLADA is only 2 years old and already outstrips X3D content in amount and quality.