I need to write netcdf input and output modules for RAP's NIMA software, which computes moments and winds from profiler spectra. Rather than write any more netcdf API code, I'll define a model for the input and output data and generate a higher-level API from that. As changes need to be made to the data model, the API can be regenerated. If (when) anyone needs to know what kind of data file they need to produce for input to NIMA, they can refer to the model and even generate their own software API.
MAPR already contains lots of boilerplate netcdf code which could be replaced by an automatically generated interface. Eventually we need to plug MAPR output into to NIMA to implement a DBS profiler: a data model can define and partially implement that interface.
For the ELDORA and R-DOW data handling and archiving, named datamodels can identify defined data streams. A producer specifies the kind of data it produces by naming a dataspace path to a dataset and the segmenting info, eg, "/radar/eldora/aft/raw". Clients use that path to subscribe to the datastream, and the data model software layer can marshall the data across the network because it can deduce the on-the-wire layout of the data from the data model.