[x3d-public] X3D design issue: metadata collection(s) as root nodes

[Don Brutzman]

The X3D working group is taking a close look at what nodes are allowed to be root nodes in a scene graph.

This makes it useful to look at whether diverse metadata ought to be allowed at the root of an X3D scene. - more than just WorldInfo.

Wondering if this might e an X3D architecture design issue that has further use cases, such as
- Re-usable metadata libraries for CAD, humans, medical, 3D printing, etc.
- Modeling and simulation
- HTML microformats/metadata, perhaps
- Database and Semantic Web queries
- Other potential application areas.

Please advise if you know of any uses of metadata for entire or multiple scenes, that will help.

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

Preliminary technical analysis follows.  All comments and reactions welcome.

Typically, a WorldInfo node is used to provide information about a scene.

GeoMetaData can also be used to provide metadata information about other geospatial nodes in a scene.

GeoOrigin has some similarities since it is not rendered but is typically shared among multiple geospatial nodes in a scene - and so consistency is particularly important in this case.  Because GeoOrigin cannot be placed at the root of a scene, it is difficult to share among multiple scenes, which is commonly needed when building a large terrain set.

The various typed Metadata* nodes in the Core component are typically used to annotate another node in the 'metadata' field.  MetadataSet collections can collect large amounts of metadata in one place.

Conceivably authors may want to have scenes that contain complex metadata structures, or even metadata libraries, that can be easily re-used by other scenes via Inline/IMPORT/EXPORT.

Currently only WorldInfo and GeoMetadata would appear to be legal root nodes, because each implements the X3DInfoNode interface which in turn implements X3DChildNode, which in turn is an allowed root node.

Related point.  As a holdover from the original VRML97 design, the root of a scene itself is defined a bit inconsistently expressed in the various encodings.
- implicit, not referencable in VRML97 or ClassicVRML encoding
- explicit, referencable as Scene element in .x3d XML encoding, compressed binary encoding, draft JSON encoding and when contained within HTML document

The recent work on the JSON encoding mapped the VRML/X3D document model to a strict object model, the JavaScript _Object_ notation.  Close scrutiny showed that the root (as embodied by Scene) is directly similar to a Grouping node with children.  This is identical to the case when an Inline brings another scene graph into a parent scene - it acts as a type of remotely-loaded Grouping node.

NPS has some good experience with metadata collections via the SAVAGE Modeling and Analysis Language (SMAL), in which we collect many kinds of metadata in a metadata template that allows a simulation tool to load an X3D model and utilize modifiable metadata regarding the scene's utilization in a larger model.

In order to pass validation, the SMAL design pattern for containing metadata in a scene is

	X3D/Scene/WorldInfo/MetadataSet/[lots of structured metadata]

Not so bad, but multiple WorldInfo peers might be present.  That means the root of the scene (e.g. Scene element) does not have a single 'metadata' field, thus making it different that other grouping nodes.

Pretty involved! The X3D Working Group will continue to consider potential specification improvements on this issue, all feedback remains welcome.

References:

4.3.2 Root nodes
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#Rootnodes

X3D Core Component (WorldInfo, Metadata* nodes)
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html

X3D Geospatial Component (GeoMetadataSet, GeoOrigin)
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geodata.html

X3D for Web Authors: online chapter 14, Metadata Information
http://x3dgraphics.com/chapters/Chapter15-MetadataInformation.html
	
SAVAGE Modeling and Analysis Language (SMAL)
https://savage.nps.edu/Savage/Tools/SMAL/SMAL.html

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman