Re: Naming and identification in virtual worlds

Noah, thanks for posing these questions and thanks for your patience
waiting for this belated response.

Response summary: explanation of X3D multiple-value url semantics, and
identification of various shared virtual-world concerns. wrote:
> We have some time scheduled on our TAG telcon today to begin discussion 
> [1] of naming and identification of resources in 3D "Virtual Worlds".  The 
> purpose of this note is to suggest some issues the TAG might wish to 
> consider. 
> There is at least a significant chance that systems such as Second Life 
> [2] or Open Croquet [3] will continue to gain in popularity, and that 
> important information will be available within these systems.  Although I 
> do not claim deep expertise with any one of these systems, I have become 
> very interested in the question of how they might best integrate with the 
> World Wide Web.

First some background.

The Web3D Consortium mission is to "develop and advance an open standards,
royalty free 3D interchange format based on XML, along with tools to
represent and communicate 3D scenes and objects between diverse authoring
and presentation hardware and software on the web, distributed networks
and mobile devices."  Our slogan is Open Standards for Real-Time 3D
Communication.  Web3D is a liaison member in W3C.

Extensible 3D (X3D) graphics "is a royalty-free open standards file format
and run-time architecture to represent and communicate 3D scenes and objects
using XML. It is an ISO ratified standard that provides a system for the
storage, retrieval and playback of real time graphics content embedded
in applications, all within an open architecture to support a wide array
of domains and user scenarios."

X3D includes an abstract functional specification, multiple file-format
encodings (.x3d XML, .x3dv ClassicVRML, .x3db Compressed Binary), and
multiple programming-language script bindings (Ecmascript aka javascript,
Java and likely in 2008, C++).

Many of our participants are familiar with the technical capabilities of
Second Life and Croquet, but these groups are not currently participating
in Web3D activities.

> I suggest that some interesting issues to consider might include:
> * What sort of integration is desirable for the Web as we know it and 
> these new "virtual world" systems?  Of course, there are many such 
> systems, and the answers might differ, but I think the question applies 
> uniformly to all.  Stated differently:  what are the important use cases 
> that need to be considered? 

I agree that these are important questions.  There are a number of industry
efforts ongoing in the area of online virtual worlds.  To date, Web standards
have not been a prominent part of stated industry goals.

The technical infrastructure provided by X3D already provides many of the
necessary requirements for large-scale virtual environments.  A variety of
X3D-related working group efforts are ongoing.

> * Which resources in a virtual world should be identified with URIs? Using 
> Which URI schemes?  What metadata, if any, should be encoded in the URIs 
> (note that systems like SLURLs [4], which are used to provide URIs for 
> Second Life, encode coordinates in virtual 3 space)?  (To a significant 
> degree, this is issue URNsAndRegistries-50 [5], applied to the integration 
> of virtual worlds with the World Wide Web.)

The X3D specification uses the field name 'url' and the semantics are
similar to urls in other Web languages, with one important difference.
Descriptions follow, and am frontloading the relevant references here
since they might not be immediately familiar.


[7] X3D Specifications,

[8] X3D Architecture and base components Revision 1,
    9.2.1 URLs

[9] IETF RFC 1738, Uniform Resource Locators (URL)

[10] X3D Architecture and base components Revision 1,
    9.2.2 Relative URLs

[11] IETF RFC 1808, Relative Uniform Resource Locators

[12] IETF RFC 2141, URN Syntax

[13] IETF RFC 3541, A Uniform Resource Name (URN) Namespace for the
Web3D Consortium (Web3D)

[14] IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax

[15] 9.3.2 X3DUrlObject


The publicly available references [7] through [13] define our long-running
support for proper url use.  I'm happy to report that the latest draft
revision to the X3D Specification (currently only available for final
review by Web3D members and ISO reviewers) further specifies that X3D
url links will follow the URI specification [14].

The most-relevant reference topic here is [15], which is the abstract type
definition for X3D url semantics, excerpted as follows:

>> X3DUrlObject {
>>   MFString [in,out] url [] [URI]
>> }
>> This abstract interface is inherited by all nodes that contain data
>> located on the World Wide Web, such as AudioClip, ImageTexture and
>> Inline.
>> All url fields can hold multiple string values. The strings in these
>> fields indicate multiple locations to search for data in the order
>> listed. If the browser cannot locate or interpret the data specified
>> by the first location, it shall try the second and subsequent locations
>> in order until a location containing interpretable data is encountered.
>> X3D browsers only have to interpret a single string. If no interpretable
>> locations are found, the node type defines the resultant default behaviour.

The primary X3D url feature of interest has been that it is an array,
or more precisely, an ordered list.  A scene author can provide multiple
candidate url addresses, typed in as a string array, that are each queried
in order until a resource is successfully returned (or no resource if found). 

Typical use cases for such addresses are
- relative url local directory and filename, for most efficient
	localhost/localserver retrieval
- online url, typically http/https, for Web-connected clients
- Unified Resource Naming (URN) addresses, similarly motivated to allow
	functionally equivalent access to local or remote resources

Single-value url addresses have no fallback mechanism for link failure.

The X3D approach has proven essential for providing resource links that are
both reliable and portable (e.g. working across a range of X3D destinations
including local installation, server, email account, etc.) so that all
linked geometry/image/video/audio/anchor scene assets are loadable at
run time.

Of note is that the author usage of URNs has not been anywhere near as
widespread as first expected.  It is not a common practice, but it is
specified and has seen some use.

Occasionally, online http links are preferred to local links.  For example,
online weather imagery might be requested first, falling back to locally
installed default imagery if up-to-date resources can't be retrieved.

I think that since X3D has adopted URI, and since the added semantics
of the ordered list are such that it provides no more than one working
address at a time, this construct is effectively consistent with other
single-url definitions in other XML languages.  For X3D at least, it is
certainly more reliable than a singleton address and has greatly improved
the reliability of integrating multiple multimedia resources in X3D scenes.

We have 10+ years experience with this ordered-list string-array construct
for url addressing and have no reported issues with it.

> * Is there value in having the same resource (I.e. identified by the same 
> URI) offer differing representations in the 3D and 2D worlds, much as we 
> suggest that the same resource might offer different representations for 
> small mobile devices vs. for more full-featured user agents?  Example:  if 
> appliance company "" has washing machines for sale, should 
> their billboard read:
>           "For good deals on washing machines,
>           see
>           (Second Life users, go to
> ,200,300)",
> -or- (my preference)
>         "For good deals on washing machines,
>           see
>           (works in Second Life too!)"
> If the latter form is to be encouraged, what sorts of content negotiation, 
> redidrections, etc. do we suggest be used so that the appropriate 
> representation of the washing machine sale will be provided on everything 
> from mobile phones to 3D clients?  (This is more or less issue 
> genericResources-53 [6] applied to virtual worlds.)

We have not needed to overload either url or scene-output semantics
within X3D scenes to be dependent on device.

The X3D scene graph includes the LOD (level of detail) and GeoLOD nodes.
Child content is only loaded preferentially depending on factors such as
viewer proximity, display frame rate, etc.  Other similar mechanisms
are possible using ProximitySensor, Script, etc.  Thus careful authoring
is able to create scenes that work flexibly on a variety of devices
without requiring content negotiation.

Web3D participants are definitely interested in virtual world naming.
There are a wide variety of practice being used.  Of note is that they
includes multiple distinct kinds of assets:  scenes, audio, video,
texture imagery, avatars, body parts, nicknames, network streaming
channels, etc.
> I think it's useful, when considering the above questions, to remind 
> ourselves that the Web already coexists with at least one 3-dimensional 
> world (or 4-dimensional if you prefer the Einsteinian formulation).  I 
> think we can draw useful lessons from that experience.   For example, we 
> could have adopted a convention that everything with a physical presence 
> in our real world, an appliance store for example, would be named by a URI 
> along the lines of 
><latitude>/<longitude>/<altitude>.  Indeed, we see 
> some URIs very much in that spirit used in to good advantage by MapQuest, 
> Google Maps, and the like.  Usually, though, we find value in leveraging 
> the DNS system to provide a much richer framework for naming http-scheme 
> resources, for controlling who has authority over parts of the namespace, 
> and for allowing the same resource to be at different physical locations 
> at different times (if indeed it has a physical location at all).  So, 
> while there is probably a good role for URIs that are assigned according 
> to positions in virtual 3-space, my intuition is that these will only 
> sometimes be the right answer.

Yes there are a lot of issues to think about and implement/explore.

FWIW we just completed a very successful X3D Earth working group meeting
last week in Boston that demonstrated multiple geospatially referenced
X3D globe implementations.  We are further collaborating with the Open
Geospatial Consortium (OGC) to ensure that our standards are complementary
and mutually supportive. [16] [17]

The recently announced reports of the W3C Geospatial Incubator Group [18]
are also being reviewed with interest.




> I'm sure this isn't an entirely balanced or completely well researched 
> overview, but I hope it's good enough to spark useful discussion of what's 
> needed, and what if any the TAG's role should be.  My apologies if my lack 
> of detailed knowledge of common practice in some of these systems shows 
> through in the above summary, but I'm sure others on this list will help 
> with corrections.  Thank you.
> Noah

Again thanks for raising these issues.  Further dialog and collaboration is
always welcome.

> [1]
> [2]
> [3]
> [4]
> [5]
> [6]
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------

all the best, Don
Don Brutzman  Naval Postgraduate School, Code USW/Br       work +1.831.656.2149
              MOVES Institute, Monterey CA 93943-5000 USA  fax  +1.831.656.7599
Virtual worlds/underwater robots/X3D/XMSF

Received on Wednesday, 7 November 2007 21:28:15 UTC