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

[Morgaine <[e-mail]>]

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 <[e-mail]>wrote;wrote:

> 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
> >
> >
>