Hi Jonathan,
> Although CF is primarily a file format convention, we often have in mind a
> logical data model for CF data while we are discussing modifications and
> extensions to CF. In principle the data model can be separated from the
> mechanics, restrictions and requirements of netCDF itself, and could apply to
> other file formats. In http://www.met.rdg.ac.uk/~jonathan/CF_metadata/cfdm.ht
> ml
> I have outlined my perception of the CF data model. I know this is not the
> only such description. For example, libcf implicitly has a CF data model, but
> it is generally more low-level, it seems to me. I may well be completely
> unaware of other relevant documents, and I'd be grateful to hear of them, and
> in any case for comments on my version of the data model. Would it be useful
> to write down a data model as part of the CF standard document, I wonder?
Thanks, I also appreciate your description of the CF Data Model.
Since you've asked for other relevant documents, I wrote the CF Metadata
Conventions submission
http://www.esdswg.org/spg/rfc/esds-rfc-021/ESDS-RFC-021-v0.01.pdf/view
to the NASA Earth Science Data Systems (ESDS) Standards Process Group,
which was recommended last October for endorsement as a NASA Recommended
Standard. It contains a brief section "6.4 Format Independence of CF"
on data models and how CF can apply to other formats. The last five
paragraphs are short enough that I'll just quote them here, using the
notation *...* for phrases in italics:
... the CF Conventions are currently written as a way to encode
metadata in netCDF classic format files, represented using the netCDF
classic data model [I7]. Furthermore, netCDF and CF are sometimes used
in combination to specify a single standard for binary encoding, for
example the netCDF-CF extension proposed for the OGC Web Coverage
Service [I10]. It is also useful to consider whether CF is applicable
to metadata representations for other data models and formats. In the
following discussion, the netCDF classic data model on which the CF
conventions are based will be referred to as the *CF data model* to
emphasize its format independence.
Because of its simplicity and generality, other file formats can be
modeled using the CF data model. Thus the concepts and relationships
specified in CF may be applied to other formats by mapping the
*variable*, *dimension*, and *attribute* abstractions in the CF data
model to analogous concepts in the other formats, in a way that
preserves the essential characteristics of the data model needed by
the CF conventions.
For example, with suitable mappings, HDF5 [N6] is capable of
representing metadata conforming to the CF Conventions in this more
general sense, as demonstrated by the implementation of the netCDF-3
API on top of the HDF5 library. Where the CF Conventions documents
refer to a *variable*, substitute the corresponding HDF5 concept of a
*dataset*, and similarly for CF *attributes* and HDF5
*attributes*. The CF abstraction of a named dimension shared by
multiple variables has no exact analogue in HDF5, but can be modeled
by HDF5 *dimension scales* [I11], as used in the netCDF-4 software
package to represent shared dimensions in HDF5. The fact that HDF5
dimension scales are more complex than CF dimensions is not relevant
for the purpose of encoding CF metadata in the HDF5 format, because
the extra complexity is not used.
Mapping the CF data model concepts into NcML [I12], netCDF-4 [I13],
OPeNDAP [N5], or the Unidata Common Data Model [I2] is even more
straightforward than for HDF5, because in each case the simpler CF
data model is already embedded in the extended data model that
includes it.
Employing such mappings of CF concepts into other data models and
associated formats makes the CF standard more generally
useful. Encoding CF metadata into other formats would be facilitated
by agreement on standard mappings between the netCDF data model and
the data models associated with the other formats. Taking this
perspective is important for the evolution of CF, to ensure that
extensions to the current CF data model can be faithfully mapped to
other data models associated with formats in use for CF-compliant
data, where here a more general sense of format-independent compliance
is intended than in the previous section, where a specific binary
encoding is required by concrete software applications.
--Russ
Received on Tue Jan 11 2011 - 12:29:20 GMT
