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

[Meadhbh Hamrick <[e-mail]>]

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/ * [e-mail]



On Wed, Sep 22, 2010 at 7:01 AM, Morgaine
<[e-mail]> wrote:
> 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 <[e-mail]>
> wrote:
>>
>> 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 "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
>> 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.
>>
>
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>
>