[vwrap] Definition of "Virtual World", in a protocols context

[Morgaine <[e-mail]>]

It has been one of the most puzzling aspects of MMOX/OGPX/VWRAP
deliberations that a mistaken idea has been asserted, and is continually
being reasserted despite ample evidence that it is false.  That idea is that
the term "Virtual World" is too complex or too varied to define, even within
the narrow confines of protocol definitions.  The aforementioned ample
evidence stems from every one of us recognizing a virtual world when we see
one.  Clearly there is a disconnect.

I want to address that idea and offer us a way to eliminate it, because,
frankly, it is making this professional group look silly and our documents
unhelpful.

If we're defining a protocol for interoperating virtual worlds, we need to
know what we mean by that term, otherwise we can't possibly know whether the
appropriate entities are being interoperated.  Instead of seeking that
understanding through analysis, the term has been labelled "undefinable" and
rejected from our deliberations, yet retained in the title of our working
group as a testament to our confusion.  This is very bad, and it is the
source of many of the problems in our draft documents.

I propose that we leave behind our alleged inability to approach the
subject, and analyse the term until we know exactly to what it refers.
"Virtual World" is actually very easy to define with the high degree of
precision we need in a protocol specification, while leaving out everything
that is not appropriate for our work on protocols.

We have a very powerful weapon at our disposal, in computing circles
commonly referred to as "duck typing" -- "if it walks like a duck and quacks
like a duck, then it's a duck".  A protocol for virtual worlds doesn't need
to be concerned with elements that it doesn't handle, so a suitable
definition of the term can be nailed down very tightly FOR THE PURPOSES OF
OUR DOCUMENTS without needing to address any elements beyond our scope.  If
we wield this weapon, defining the term "Virtual World" becomes a pretty
easy job, so that's what I'm going to do here.

Please note that instead of just stating a definition, I first deal with its
various elements separately before combining them.  *If this seems a bit
long then please skip to the definition*, but the rationale is given here
for those who are interested or who don't understand the definition.

The most important point to grasp by far is that a virtual world is a
perceptual construct, created in our minds by combining a variety of media
elements.  It's certainly not a server nor a bunch of services --- those
merely deliver the data that allow virtual worlds to take shape in our
minds.  That's the key to understanding "virtual world" in a manner relevant
to protocols:  a virtual world forms in a user's mind when appropriate data
is delivered to her client application, and the result is observed.  This
puts a definition on the horizon, amenable to further dissection.  The
tentative starting point:  *'Virtual worlds are perceptual constructs
assembled client-side from suitable data, and in the case of
"onlineworlds", from suitable data delivered over network protocols.
*'

A definition is getting closer.  Please note the path that this analysis is
taking --- it has narrowed down where worlds exist and how they form, but it
still lacks the concepts of "shared" and of "interoperating" that are
central to our work.  (Very importantly, note that it's already converging
on the concrete elements that we will be using, namely client applications,
servers, services and data.)

Before we can proceed further though, we need to understand how the
perception of a virtual world is formed from the data arriving at a client
application.  Here I'm going to deploy a very powerful word from the current
vocabulary of multimedia:  "*mashup*".  The client application receives
media elements from both local and/or remote sources, and processes them
into a media collage or mashup, commonly an audio-visual one although this
can vary.  We don't need to say HOW this is done in a protocol definition,
it's enough to say that it is done and that the result can be perceived as a
world in the mind of a user.

Defining "*shared*" worlds is easy --- a VW is "shared" when more than one
client application is present and the separate mashups depict the same
"place" (see later).  Note that VWs do not have to be shared.  Indeed,
single-user worlds are extremely common, and they constitute a very
important use case as a subset of shared worlds.

The concept of "*interoperation*" is more complex, because it requires us to
understand the concept of "*place*" first so that we can distinguish one
place from another place.  Fortunately humans have no problem with the
concept of place because it exists in the physical world.  What's more, we
already use the term "world" almost interchangeably with "planet", and hence
the idea that worlds are separate is completely natural.  The key concept is
*perceptual isolation*:  if two worlds are considered to be isolated, then
they are considered to be separate worlds --- this is true even if you can
walk from one to the other, because the only important requirement is
perceived isolation.  This is a powerful approach, because it allows worlds
to have any granularity we may wish, and it does not require virtual worlds
to have any particular form of organization.

Once we understand "place", and that the perceptual isolation of places also
covers separation of virtual worlds, "interoperation" is just a small step
away.  If the perceptual mashup contains elements from more than one VW,
then the user is experiencing VW interop.  If the mashup contains elements
from only one world, then interop between VWs is either not occurring or is
not detectable.  As an example of interop, if some element E1 is present in
world W1 but does not exist in world W2, and then at some other time E1 is
present in W2, the mashup containing both E1 and elements from W2 is the
result of interop between worlds.  It does not matter at all what E1 happens
to be --- objects, agents, music, lines of text, or anything at all.  The
mashup concept is all-powerful.

At last we have the pieces in place to allow us to define the term "Virtual
World" very precisely in a manner suited to writing documents on VW interop
protocols, while ignoring all other aspects.  Here is my stab at it:

*DEFINITION of "Virtual World", in a protocols context:*

*For the narrow purpose of describing interoperability protocols for Virtual
Worlds, a Virtual World is defined as a perceptual mashup depicting media
elements located within a single virtual place based on data received by a
client application.  Interoperation of Virtual Worlds occurs when media
elements from more than one such Virtual World are present in a given
perceptual mashup.  This document describes protocols which permit media
elements and other data relating to one or more Virtual Worlds to be
received by client applications, and hence enable such Virtual Worlds to be
perceived.  This definition is intentionally agnostic to all other aspects
of Virtual Worlds in order to allow unbounded variation and evolution, while
still permitting them to be visualized and to interoperate where desired.*

Yay! \o/

Of course it's just a first stab, but the elements are there.

This definition permits us to ignore entirely those aspects of VW
implementation that do not concern protocols, such as how worlds are
implemented internally, how they are used socially, and how they differ in a
million ways that are of no consequence to us here.  Earlier attempts which
tried to define "Virtual World" based on in-world or implementation
properties were doomed to failure because of VW diversity, whereas the
mashup approach has no such problems.


Note the following properties of this definition:


   - It is precise enough to allow us to talk about VWs unambiguously while
   dealing only with concrete elements like servers and services at the
   technical level.  We need refer to VWs only when examining use cases,
   because that's the only place where VWs actually appear, on the user's
   output device.  Everything else is just computing. :-)


   - It makes it irrelevant to the definition how VWs are displayed, eg. in
   a dedicated client, in a Web browser, or purely as text or in Braille.


   - It makes it irrelevant which media elements are in the perceptual
   mashup --- a blind person can have access to the same world despite lacking
   the ability to perceive visual renderings normally.  Nor does it prescribe
   that any specific set of elements must exist in worlds, which would be
   futile.


   - It makes it irrelevant which kind of service deployments or data
   pathways are chosen, as long as appropriate data is reaching client
   applications.


   - It is highly robust in the face of architectural variation --- for
   example, whether VW systems are structured in the SL way or in the LESS way
   is immaterial to this definition of Virtual World, because the same data
   could (in principle) arrive at the client to allow the same virtual world to
   be manifest in both cases.


   - It recognizes the important concept of immersion, because it does not
   try to hide the fact that virtual worlds are manifest in our minds.


   - It makes it irrelevant how many dimensions are being simulated or
   presented:  3D and 2D graphic worlds are covered equally, as are worlds of
   higher dimensionality created by scientific visualization, and also
   partially non-spatial worlds arising from perception of textual data alone.
   (Indeed, some of the most compelling and immersive virtual worlds ever
   invented by Mankind arrived in our culture through text alone.)


   - It explains interop between VWs so very simply and unequivocally ---
   when the perceptual mashup contains elements from more than one VW, we have
   VW interop.


   - It is totally happy with sloppy statements like "The virtual world
   operated by XXX", because such common phrases simply mean "The virtual world
   perceived by a user when communicating with computer systems operated by
   XXX".  It's just shorthand.


   - It recognizes that AI-based agents are entirely viable, because data
   arriving at a client application can be processed by a machine just as well
   as by a human user, or even better.


   - It even covers server-side rendered worlds without batting an eyelid,
   as well as the MUD and Adventure worlds of yesteryear.



In summary, I think the above offers us a very clear basis for a definition
of the term "Virtual World" that is specific enough for our protocol needs,
yet still valid no matter how worlds evolve in the forseeable future.  And
very importantly, it allows us to deal exclusively with concrete elements
like servers, services and clients at the technical level, yet still able to
examine use cases in the only context in which they make sense, which is of
course that of Virtual Worlds.

Perhaps most important of all, it lets us dispose of the jaw-dropping idea
that our specifications are concerned with something that they can't define.


Morgaine.