[vos-d] semantics

[Peter Amstutz]

I've been following the thread on semantics with great interest, but 
it's gone long enough and in enough different directions I'm going to 
start a new thread for my thoughts.

It's important to note that my background is in agent-based simulation 
(and, to a lesser extent, search engines), so incorporating semantics 
into the structure of a scene has always been an explicit goal for VOS.

I think the kernel of Kao's argument is that if you have a choice of 
different dimensions to organize your data, whether based on semantics, 
rendering efficiency, download time or whatever, that you should choose 
a semantic layout.  Having thought about this a bit, this makes a lot of 
sense: optimal organization for rendering or downloading can be 
determined mechanically by software, whereas the semantic information by 
definition requires intellegence to organize.

My experience has been that piling metadata on top of a non-semantic 
structure tends to lead to a compromise design.  Certain parts of the 
graph need to be flattened and other parts stretched out to fit the 
semantic structure, leading to a layout that is neither optimal for 
rendering nor ideal in expressing semantics.

Braden's idea of a "CSS for 3D" is an interesting one, however I'm not 
sure how well the analogy really works.  In particular, CSS is supposed 
to separate content from layout, since most semantic interpretations of 
the text don't care about where exactly on the page or screen the text 
appears.  Conversely, the 3D environment is explicitly spatial, and 
semantic information more often than not includes information like paths 
through the environment, waypoints, sensitive zones, that the object at 
position X,Y,Z is a tree, etc all of which are based explicitly on a 
some level of geometric interpretation of the space.

To address Kao's question: VOS fits in here at a couple of levels.  The 
first is the basic services it provides.  VOS as a distributed 
programming system tries to split the difference between declarative and 
imparative programming, by providing a data model in conjunction with a 
message passing model.  The message passing model defines how the object 
behaves.  The data model allows attaching arbitrary objects to other 
objects, so you can inject metadata at any point in the graph.  The data 
type model also allows for interface aggregation (effectively multiple 
inheritance) so objects can have a number of different aspects which can 
be added on to at runtime.  Because no distinction is made between 
metadata and "real" data, the synchronization protocols are the same.

The higher level is the structure of the actual 3D scene.  This uses the 
facilities provided by VOS, but as I discussed above, different uses of 
the scene suggest different layouts.  Since the Abstract 3D Layer (A3DL) 
is the model for 3D data in VOS, we want to ensure that it supports a 
design that is friendly towards semantic structures.  In that vein I'm 
not sure what the "right" structures are, and is probably somewhat 
application-specific anyway (although I hope that over time people can 
get together and agree upon standard datatypes for, say, path networks).  
The advantage to VOS is that it supports that flexibility, so people can 
try stuff out without having to turn everything else upside down in the 
process.

One last thing: it just occurred to me is that most other developers of 
3D VR applications end up writing their own renderer on top of OpenGL, 
so there is a natural bias towards designing their data structures to 
fit their particular rendering loop.  VOS from the beginning was 
intended to be implemented using an existing 3D engine, so we don't care 
so much about rendering specifics because someone else has already done 
the work of taking a scene and optimizing it on the fly...

-- 
[   Peter Amstutz  ][ tetron at interreality.org ][ peter.amstutz at gdit.com ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.interreality.org/pipermail/vos-d/attachments/20070130/ce747d3b/attachment.pgp