[vos-d] VOS requirements

[Karsten Otto]

Am 26.01.2007 um 01:39 schrieb Braden McDaniel:

> [...]
> Why isn't this a job for a metadata spec? It seems to me that this  
> kind
> of semantic information is too application-specific to encode in the
> structure of the file format itself.
>
I could say as well, 3D appearance information is too application  
specific to encode in the structure of the file format itself. See  
also my previous post, its basically a matter of preferrence for  
outward or inner beauty :-)

Also, physics information already *IS* application specific semantic  
information... why not go all the way?

> Note that you can attach metadata to any node in X3D. I don't know  
> what
> the case is with COLLADA; however, you could also transmit such  
> metadata
> out-of-band.
>
If there is a way to refer to the scene elements from outside, yes,  
certainly you can. You know VRML, the only way to do this is  
referring to DEF names, but DEF names are not required by the  
specification. Especially exported/generated VRML usually omits them,  
so the nodes remain anonymous, and you cannot refer to them from  
outside. VOS fortunately has vobject URIs for this purpose, phew! So  
an external semantic description may be the way to go if we really  
want to keep them separate.

However, VOS is not a syntactic file format, but an object system.  
The object code already represents a form of semantics! Also, there  
is some overlap in semantic and geometric information, particularly  
object positions and bounds. So why keep them separate?

> The out-of-band solution has a couple of interesting qualities:
>       * It readily supports a notion of allowing the same scene to  
> mean
>         different things to different clients.
>       * You could potentially define mappings from the semantic  
> metadata
>         file format to multiple different geometry file formats. So  
> the
>         same semantic data could be meaningful regardless of  
> whether the
>         geometry was expressed in X3D, COLLADA, or whatever.
>
> Anyone who's ever used HTML and CSS should be seeing an analogy here.
>
Precisely. That is one of my reasons for wanting the emphasis on the  
semantic part, not on any particular 3D file format. The semantic  
part is usually less bulky than geometry (no textures!), and by its  
very nature provides an excellent  base for deciding which geometry  
parts to load. Leave geometry loading to file format plug-ins...

> Whether the semantic metadata lives out-of-band or in the scene,
> coupling the nature of its specification to that of the geometry seems
> like the Wrong Way.
>
I am not quite sure wheter I agree or disagree, or even understand  
the sentence at all.. could you elaborate?

Regards,
Karsten Otto (kao)