On Fri, 2007-01-26 at 11:51 +0100, Karsten Otto wrote: > 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.
You could say that; however, we have enough interoperable 3D formats and too many similarities between different extant formats for this claim to be taken seriously. > See > also my previous post, its basically a matter of preferrence for > outward or inner beauty :-) Maybe. But the fact is that if you want a 3D scene, you need data a renderer understands. Emerging applications that use semantic data need to play in that world. > Also, physics information already *IS* application specific semantic > information... why not go all the way? The simple (and flippant) and answer to that is: You can't outrun entropy. More seriously, while I'll grant that sharing physics data interoperably is not nearly so well explored as doing the same with geometry data, it does represent quantitative data for which there should be a clear interpretation. The important thing here is that applications have identified data that they want to interpret in the same way (or sufficiently similar ways). *Any* data--visual, physical, whatever--require that some semantics be applied in order for them to be interpreted usefully. The fact that we have interchangeable file formats for things like rendering data and--to an emerging extent--physical data simply reflects the fact that there are certain semantics upon which consensus has been reached. So, if you want your semantics in an interoperable file format, fight the fight. Come up with a scheme and build consensus (and implementations). On the other hand, if you want the freedom to play in your own sandbox while leveraging existing model data, work out-of-band. > > 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. VRML is a hierarchical format with, for most purposes, a constrained node set. That means it's straightforward to devise a syntax to select nodes in an arbitrary hierarchy. XML file formats already have such a syntax standardized: XPath. > 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? Are you asking about VOS' architecture or a file format? Applications can integrate data however makes the most sense for them. And if having its own model file format makes sense for VOS, that's fine. But, relative to other 3D file formats, a VOS-specific format would most likely be a backwater; it should be there for it's utility to VOS developers--not for users. So the more VOS can leverage other file formats and allow VOS users to leverage other file formats, the better. > > 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... Given the application-specific nature of semantic metadata, there's certainly an argument to be made for pluggable semantic heuristic suites as well. > > 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? The requirements of renderers is a relatively well-traveled, well-understood space. Even if you wanted for some reason to go off and define your own file format for geometry, establishing the kind of data it has to include is pretty straightforward. Applying semantic data to 3D scenes to get some useful result is not nearly so well explored. It is likely that inevitable (and desirable) experimentation in this realm would lead to greater volatility. The less this volatility can spill out into other parts of the application, the easier things are for everybody. And then there is the issue of domain expertise. The 3D graphics people who design model file formats are not typically experts in the particular semantics you're interested in. There's a good chance they don't even care that much. That means that getting your semantics into one of these more-or-less-standard file formats is going to be an uphill battle--to put it mildly. So, you're better off going and doing your own thing if you possibly can. But if you want to avoid becoming just another ghetto, you'll leverage model data in the formats in which users are already storing it. -- Braden McDaniel e-mail: <[EMAIL PROTECTED]> <http://endoframe.com> Jabber: <[EMAIL PROTECTED]> _______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
