3. Data Assimilation Into Models

Actor(s)

A scientist or other investigator who wants to assimilate relevant data into a model.

Background

The scientist, Ely, runs a model based on sea surface temperatures. He obtains a grid of these temperatures from a satellite, but he needs to validate these with in situ observations, and sometimes must use the in situ results as his only way to validate the model's daily run. The scientist knows about several data sets and has set up the model to use them. But he would like his model to make use of any additional data sources that may become available.

User Scenario

By instructing the model to regularly search for data sets that match the desired criteria, including a variable name that is 'same as', or equivlent to, the term needed for the model, the model can stay abreast of rapidly changing deployed assets, without having to be reprogrammed for each type of asset that is deployed. Note that if the scientist wants to take into account the difference between measurements of the skin of the sea surface, and the subsurface layer just slightly below, the scientist can use a controlled vocabulary like the CF Standard Names to specifically request a particular data type, or understand the provided data type. Even if the data provider uses a different name for their sea surface skin temperature, if a mapping exists between their name and the CF Standard Names, this will support automated discovery and use of the resource.

Solution Space

No existing ocean observing systems provide this capability, but it is incorporated in the design concepts for NSF's Ocean Observing Initiative. In the future, systems will have the ability to infer, by analysis of measurement technique as well as variable name, that a sea surface temperature is in fact the 'skin' measurement. This will require widespread standardization of a wide range of metadata, such as provide by the Sensor Web Enablement standards.