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

From: Morgaine <[email-masked]>
Date: Wed, 22 Sep 2010 07:38:05 +0100

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.

---

From: Morgaine <[email-masked]>
Date: Wed, 22 Sep 2010 15:01:26 +0100

After a good night's sleep, I see that my definition still works, a minor
miracle.  :P

As another indication of its robustness in the face of architectural
variation, I've just noticed that it applies even to virtual worlds
implemented as P2P.  This was more good fortune than planning, as I could
have accidentally mentioned servers yesterday, but didn't.  Focusing
entirely on the client application's role in presenting the perceptual
mashup has paid dividends.

We need that kind of flexibility because our server-side architecture is
going to be arbitrarily complex once it is decomposed into services, so
tying it down in any way would probably be a mistake.  In contrast, the
"client application" is a single unit from a user perspective, even if
implemented as an arbitrary number of concurrent units in programming
terms.  This probably captures most scenarios that we are likely to see.

Morgaine.

=================================

On Wed, Sep 22, 2010 at 7:38 AM, Morgaine <[email-masked]>wrote:

> 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.
>
> assembled client-side from suitable data, and in the case of "onlineworlds", from suitable data delivered over network protocols.
> *'
>
> 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
> 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.
>
> *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
>    - It is precise enough to allow us to talk about VWs unambiguously
>    while dealing only with concrete elements like servers and services at the
>    - 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.
>
>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 22 Sep 2010 07:18:46 -0700

is anyone on this list planning on developing P2P worlds? and if so,
what about this problem domain makes it impossible for you to simply
layer RESTful resource access over an overlay network?

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

On Wed, Sep 22, 2010 at 7:01 AM, Morgaine
<[email-masked]> wrote:
>> 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.
>>
>> tentative starting point:  'Virtual worlds are perceptual constructs
>> assembled client-side from suitable data, and in the case of "online
>> worlds", 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
>> 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
>> Defining "shared" worlds is easy --- a VW is "shared" when more than one
>> 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
>> 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
>> still permitting them to be visualized and to interoperate where desired.
>>
>> Yay! \o/
>>
>> It is precise enough to allow us to talk about VWs unambiguously while
>> 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
>> 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
>> 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
>> It recognizes that AI-based agents are entirely viable, because data
>> 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.
>>
> _______________________________________________
> vwrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap
>
>

---

From: Morgaine <[email-masked]>
Date: Wed, 22 Sep 2010 15:44:49 +0100

No, we're not involved in P2P worlds at this stage, as far as I know.

The idea is to have a definition of the term "Virtual World" that is
completely neutral on architectural details, and the reference to P2P merely
affirms that good independence.  The fact that the definition is so flexible
doesn't mean that we're going to be examining VW use cases that only make
sense in a P2P setting, that's not in our scope, currently at least.

Our scope is clearly that of virtual worlds of the type exemplified by SL
and OpenSimulator, although as we have said many times, we do not wish to
narrow the range of possible deployment patterns.

Morgaine.

===================================

On Wed, Sep 22, 2010 at 3:18 PM, Meadhbh Hamrick <[email-masked]>wrote:

> > On Wed, Sep 22, 2010 at 7:38 AM, Morgaine <
> [email-masked]>
> > wrote:
> >>

---

From: Mike Dickson <[email-masked]>
Date: Wed, 22 Sep 2010 13:21:13 -0400

On 09/22/2010 10:01 AM, Morgaine wrote:
> After a good night's sleep, I see that my definition still works, a 
> minor miracle.  :P
>
> implemented as P2P.  This was more good fortune than planning, as I 
> could have accidentally mentioned servers yesterday, but didn't.  
> Focusing entirely on the client application's role in presenting the 
> perceptual mashup has paid dividends.
>
> We need that kind of flexibility because our server-side architecture 
> is going to be arbitrarily complex once it is decomposed into 
> services, so tying it down in any way would probably be a mistake.  In 
> contrast, the "client application" is a single unit from a user 
> perspective, even if implemented as an arbitrary number of concurrent 
> units in programming terms.  This probably captures most scenarios 
> that we are likely to see.
>
Well, no, the client itself could be a provider of services in a more 
distributed case.  But thats not really relevant as you suggest.   I 
guess I'm objecting to the server-side architecture comment. how the 
services we defined are implemented into a virtual world should ideally 
as flexible as possible.  The important thing to me is the service 
definitions (what messages I can send/receive) and the payload 
definitions/protocol used with the services.

Mike

---

From: Morgaine <[email-masked]>
Date: Wed, 22 Sep 2010 20:20:01 +0100

Yes, I agree with that totally Mike.

I'm glad that you pointed out that the client can be a provider of services
as well (or alternatively, services can be client-side, even if not part of
the client application).  I expect this to be a rather common use case ---
I've heard a lot of people state their interest in hosting their own
inventory and even asset services locally.

This deployment pattern could be very popular.

Morgaine.

==============================

On Wed, Sep 22, 2010 at 6:21 PM, Mike Dickson <[email-masked]> wrote:

>> implemented as an arbitrary number of concurrent units in programming terms.
>>  This probably captures most scenarios that we are likely to see.
>>
> distributed case.  But thats not really relevant as you suggest.   I guess
> I'm objecting to the server-side architecture comment. how the services we
> defined are implemented into a virtual world should ideally as flexible as
> possible.  The important thing to me is the service definitions (what
> messages I can send/receive) and the payload definitions/protocol used with
> the services.
>
> Mike
>
>