Hello,
Due to the continuing, external issues with Trac site (we can see it, but
not yet login), I am posting this ticket to the mailing list because I
would very much like to make it available before next week's meeting
<
https://www.ncas.ac.uk/en/conferencesandworkshops/2018cfworkshop>, where
it will be discussed.
When Trac is fully functional again (many thanks to Jeff and Brian for
working hard on this over the last week), I shall copy what follows into a
normal new ticket.
All the best,
David
New ticket (enhancement)
========================
Incorporating the CF data model into the conventions
----------------------------------------------------
In this ticket we propose that a CF data model for data and metadata
corresponding to the existing standard (version 1.7) is incorporated into
the CF conventions. As a netCDF convention, up to now the CF standard has
not included a data model. However, the design of CF implies a data model
to some extent and defining an explicit data model will contribute to the
CF goal to help in "building applications with powerful extraction,
regridding, and display capabilities".
A data model is an abstract interpretation of the data that identifies the
elements of the dataset and their scientific intent, and describes how they
are related to one another and to the real or model world from which the
data were derived. A data model is necessary because it imposes the rules,
constraints, and relationships connecting metadata to the data that are
needed to imagine how the quantities included in the dataset should be
combined and processed scientifically.
Following discussions at the 2017 netCDF-CF meeting, we propose that the CF
data model that was recently published in the Geoscientific Model
Development journal (GMD) (
https://www.geosci-model-dev.
net/10/4619/2017/gmd-10-4619-2017.pdf) be formally incorporated into the CF
conventions as an independent element of CF, separate from the CF standards
and conformance documents, to be updated for successive CF versions in line
with those documents.
The data model published in GMD was for CF-1.6, but it is consistent with
all of the changes to the conventions arising from the 28 tickets that
contributed to CF-1.7. Therefore we may consider this also to be the data
model for CF version 1.7.
We propose a new document for the CF data model and have produced a draft
of this (attached) that describes the data model, with associated UML
(Unified Modelling Language) diagrams to illustrate it. The description
follows closely from the text and diagrams of the GMD paper, which in turn
grew out of the discussions in tickets #68
<
https://cf-trac.llnl.gov/trac/ticket/68>, #88
<
https://cf-trac.llnl.gov/trac/ticket/88>, #95
<
https://cf-trac.llnl.gov/trac/ticket/95> and #107
<
https://cf-trac.llnl.gov/trac/ticket/107>. The new document also describes
how the data model is implemented in netCDF, but this is not part of the
data model itself, as the same data model could be implemented in other
non-netCDF-like file formats.
The CF data model overlaps with other work on data models, especially the
Unidata CDM. How the CF data model relates to other data models is not
required as part of the conventions, and so does not appear as part of this
proposal, but is discussed in the GMD paper.
Governance
----------
The CF data model will have to adapt to future enhancements to the
conventions, and therefore must be considered when changes to the
conventions are proposed. To ensure that this occurs, we suggest the
following guidelines to be added to the end of the existing "Rules for CF
Conventions Changes <
http://cfconventions.org/rules.html>" document:
* The CF data model will guide the development of CF by providing a
framework for ensuring that proposed changes fit into CF in a logical way,
rather than just a pragmatic one.
* All new proposals will be assessed to see if the new features defined in
the proposal map onto the CF data model.
* The assessment will be carried out by a member of the conventions
committee or another suitably qualified person. If no-one volunteers, the
chairman of the committee will ask someone to do it.
* If the proposal maps onto the existing CF data model then no further
action is required.
* Otherwise an attempt must be made to modify the proposal so that its new
features do map onto the CF data model, and in such a way that the
proposal's intent is not compromised.
* If the proposal cannot be acceptably modified to conform to the existing
data model, then the data model will need to be modified to accommodate the
new features. This modification will be either backwards compatible or
backwards incompatible. The former (preferable) case occurs if the data
model may be extended or generalised in some way that allows the new
features but does not affect its existing constructs and relationships.
* Any changes to the data model must be described verbatim as part of the
proposal discussion, including any modified or new data model diagrams.
David Hassell and Jonathan Gregory
--
David Hassell
National Centre for Atmospheric Science
Department of Meteorology, University of Reading,
Earley Gate, PO Box 243, Reading RG6 6BB
Tel: +44 118 3785183
http://www.met.reading.ac.uk/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20180615/e73ab306/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cfdm_for_cf.pdf
Type: application/pdf
Size: 554402 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20180615/e73ab306/attachment.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cfdm_for_cf.tex
Type: text/x-tex
Size: 29948 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20180615/e73ab306/attachment.bin>
Received on Fri Jun 15 2018 - 01:34:50 BST
