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 _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
