Once we have an implementation of data models flexible enough to define the kinds of data we produce and manage, then it becomes possible to write more generic software and simpler processing modules.
We can write programs which generate source bindings for languages besides C++, such as Python. For that matter, we can write a program to generate IDL, from which several different language bindings can be generated which all support distributed method calls.
The data model can generate XML DTDs or schema for an application's configuration files, likewise the same datamodel can generate the source code for reading the configuration into a data object.
Centralizing the dataspace behind a CORBA interface or web application, so the dataspace can be browsed and edited by anyone. Make it as easy as possible for anyone to define new data models and enter them into the global record.
As the data model represents an architecture- and implementation-independent interface, we can write a CORBA layer for it which allows generic processing modules to be plugged together. In the aRTs sound framework, clients use a remote interface to plug modules together on the server, so the client has complete control over the processing, but no data need to be shifted back and forth from the client.
Since ultimately a data model is just an interface, the implementation behind a data model instance does not need to be arrays of data values. Instead it could be a dynamic data source like process status.
The dataspace is just a namespace and intended to be distributable. Different departments can manage their own dataspace which have virtual mount points in the global dataspace. The dataspace can divide the global namespace into management units while ensuring unique names among all the units. So RAF can manage their own dataspaces, say /raf or /aircraft.
If the data model is general enough to describe an instrument's data stream, then an instrument can use the model to identify itself and its data stream dynamically. In other words, plug it in and clients which want to handle those data, such as an archiver, should be able to decipher the data stream enough to store it. If the central data server were a database, it would be easy to dynamically create a database table for the instrument and insert its data into the table as its received. Chris Webster and I were talking about this option recently as a possibility for the plane, where most of the data are time series and fit well with a relation database model.
Dimensions can be extended beyond being just a 'physical dimension' into a full-fledged relation, as in RDBMS. For example, profilers have a set of beam configurations which describe the radar signal and antenna parameters. These do not need to be replicated in time as is done now. Instead, define a beam configuration dimension which is the set of beam configuration IDs. Then a single time-mapped field which maps into that beamconfig dimension can be used as a relation between beam data at a certain time and the beam config for that time. This is exactly a join on an index column in RDBMS terms, but casted in a way more familiar to the data domain in which we work, and it can be mapped into either a RDBMS table or netcdf files.