Changes between Version 1 and Version 2 of DataModelmarkhscratch


Ignore:
Timestamp:
03/04/13 03:35:09 (6 years ago)
Author:
markh
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DataModelmarkhscratch

    v1 v2  
    11= Markh Scratch of the CF Data Model 1.5 =
    22
    3 This page is the scratch draft of the CF data model for CF 1.5,
     3This page is a scratch pad draft of the CF data model for CF 1.5
    44
    55== UML Sketch ==
     
    1010
    1111
     12= Constructs, Types =
     13
     14==== Notes ====
     15
     16Wherever it is used for a Type, 'attributes' is a collection of key:value pairs.
     17
     18Particular keys are banned from use for each type, as a particular implementation (NetCDF) has used them for referencing between variables.  Such specified attribute keys may not be used to provide semantic meaning to a Type. 
    1219
    1320== Controlled Vocabularies ==
     
    1825
    1926
    20 = Constructs, Types =
     27== Field Construct ==
    2128
     29The central concept of the data model is a Field construct.  A Field represents a single phenomenon with metadata to define that phenomenon and to define the domain which the phenomenon is sampled from.
    2230
    23 With this in mind, I propose a data model text, as follows:
     31The domain of the Field defines the Field's location in time, space and all other degrees of freedom it may have; it also may provide further contextual metadata. A field construct may be regarded as a domain definition with data in that domain.
    2432
    25     == Field Construct ==
     33The Field contains one multi-dimensional array of data values, which may include missing data.  Elements of the data array must all be of the same data type.
    2634
    27     The central concept of the data model is a Field construct.  A Field represents a single phenomenon with metadata to define that phenomenon and to define the domain which the phenomenon is sampled from.
     35The data array has shape, an ordered set of dimensions with extents defined by the Field's explicit domain_axes. 
    2836
    29     The domain of the Field defines the Field's location in time, space and all other degrees of freedom it may have; it also may provide further contextual metadata. A field construct may be regarded as a domain definition with data in that domain.
     37The data model makes a central assumption that each Field construct is independent.
    3038
    31     The Field contains one multi-dimensional array of data values, which may include missing data.  Elements of the data array must all be of the same data type.
     39The Field defines it's domain using the attributes: '''domain_axes''', '''dim_coordinates''', '''aux_coordinates''', '''transforms''' and '''cell_measures''' and the constructs these attributes reference:
    3240
    33     The data array has shape, an ordered set of dimensions with extents defined by the Field's explicit domain_axes. 
     41 * '''dim_coordinates''':
     42  * a set of containment associations,
     43  * referencing !OrderedCoord instances,
     44  * each mediated by one and only one explicit domain axis;
     45 * '''aux_coordinates''':
     46  * a set of containment associations,
     47  * referencing !OrderedCoord or !UnorderedCoord instances,
     48  * each mediated by a collection of domain axes (recognising the constraints on shape matching).
    3449
    35     The data model makes a central assumption that each Field construct is independent.
     50The Field defines its phenomenon with the attributes: '''standard_name''', '''units''', '''long_name''', all of which take strings and '''cell_methods''' which qualify the phenomenon referencing a !CellMethod collection.
    3651
    37     The Field defines it's domain using the attributes: '''domain_axes''', '''dim_coordinates''', '''aux_coordinates''', '''transforms''' and '''cell_measures''' and the constructs these attributes reference:
     52Other attributes are interpreted consistently with Appendix A. Attributes of the CF Conventions for NetCDF files (1.5), apart from '''coordinates''' and '''grid_mapping''' which are not to be used within the scope of the data model. 
    3853
    39     * '''dim_coordinates''':
    40       * a set of containment associations,
    41       * referencing !OrderedCoord instances,
    42       * each mediated by one and only one explicit domain axis;
    43     * '''aux_coordinates''':
    44       * a set of containment associations,
    45       * referencing !OrderedCoord or !UnorderedCoord instances,
    46       * each mediated by a collection of domain axes (recognising the constraints on shape matching).
     54All the Fields attributes are optional except for data.
    4755
    48     The Field defines its phenomenon with the attributes: '''standard_name''', '''units''', '''long_name''', all of which take strings and '''cell_methods''' which qualify the phenomenon referencing a !CellMethod collection.
     56=== The Field Construct in a NetCDF File ===
    4957
    50     Other attributes are interpreted consistently with Appendix A. Attributes of the CF Conventions for NetCDF files (1.5), apart from '''coordinates''' and '''grid_mapping''' which are not to be used within the scope of the data model. 
     58In a dataset contained in a single CF netCDF file, each data variable usually corresponds to a field construct, but a field construct might be a combination of several data variables, as long as they represent the same phenomenon, over comparable but not overlapping domains. In a dataset comprising several netCDF files, a field construct may span data variables in more than one file, for instance from different ranges of a time coordinate (to be introduced by Gridspec in CF version 1.7). Rules for aggregating data variables from one or several files into a single field construct are needed but are not defined by CF version 1.5; such rules are regarded as the concern of data processing software.   
    5159
    52     All the Fields attributes are optional except for data.
    53 
    54     === The Field Construct in a NetCDF File ===
    55 
    56     In a dataset contained in a single CF netCDF file, each data variable usually corresponds to a field construct, but a field construct might be a combination of several data variables, as long as they represent the same phenomenon, over comparable but not overlapping domains. In a dataset comprising several netCDF files, a field construct may span data variables in more than one file, for instance from different ranges of a time coordinate (to be introduced by Gridspec in CF version 1.7). Rules for aggregating data variables from one or several files into a single field construct are needed but are not defined by CF version 1.5; such rules are regarded as the concern of data processing software.   
    57 
    58     Data variables stored in CF-netCDF files are often not independent, because they share coordinate variables. However, this is viewed solely as a means of saving disk space, and it is assumed that implementations will be able to alter any field construct without affecting other field constructs. For instance, if the coordinates of one field construct are modified, it will not affect any other field construct. Explicit tests of equality will be required to establish whether two data variables have the same coordinates. Such tests are necessary in general if CF is applied to a dataset comprising more than one file, because different variables may then reside in different files, with their own coordinate variables. In a netCDF file, tests for the equality of coordinates between different data variables may be simplified if the data variables refer to the same coordinate variable.
     60Data variables stored in CF-netCDF files are often not independent, because they share coordinate variables. However, this is viewed solely as a means of saving disk space, and it is assumed that implementations will be able to alter any field construct without affecting other field constructs. For instance, if the coordinates of one field construct are modified, it will not affect any other field construct. Explicit tests of equality will be required to establish whether two data variables have the same coordinates. Such tests are necessary in general if CF is applied to a dataset comprising more than one file, because different variables may then reside in different files, with their own coordinate variables. In a netCDF file, tests for the equality of coordinates between different data variables may be simplified if the data variables refer to the same coordinate variable.
    5961
    6062
    6163
    6264
    63     == !DomainAxis Construct ==
     65== !DomainAxis Construct ==
    6466
    65     A !DomainAxis defines a degree of freedom for a Field.
     67A !DomainAxis defines a degree of freedom for a Field.
    6668
    67     Explicit !DomainAxis instances are bound to a Fields data array, such that the ordered collection of the Field's !DomainAxis instances define the shape of the Field's data array.
     69Explicit !DomainAxis instances are bound to a Fields data array, such that the ordered collection of the Field's !DomainAxis instances define the shape of the Field's data array.
    6870
    69     A Field also defines one Potential !DomainAxis, with an explicit length of one.
     71A Field also defines one Potential !DomainAxis, with an explicit length of one.
    7072
    71     The one potential !DomainAxis and the collection of explicit !DomainAxes together provide the degrees of freedom for the Field in its current state and provide the facility to expand the degrees of freedom by altering the Field.  The potential !DomainAxis provides an flexible pool of Explicit !DomainAxes of size 1, which may be created or removed without changing the data and metadata values of the Field.
     73The one potential !DomainAxis and the collection of explicit !DomainAxes together provide the degrees of freedom for the Field in its current state and provide the facility to expand the degrees of freedom by altering the Field.  The potential !DomainAxis provides an flexible pool of Explicit !DomainAxes of size 1, which may be created or removed without changing the data and metadata values of the Field.
    7274
    73     This enables a Field's dimensionality to be changed, e.g. by collapsing an explicit !DomainAxis or by stacking potential !DomainAxes into a new explicit!DomainAxis.   
     75This enables a Field's dimensionality to be changed, e.g. by collapsing an explicit !DomainAxis or by stacking using the potential !DomainAxis to create a new explicit!DomainAxis.   
    7476
    7577
    76     === The !DomainAxis Construct in a NetCDF File ===
     78=== The !DomainAxis Construct in a NetCDF File ===
    7779
    78     In a CF NetCDF file an explicit !DomainAxis is a NetCDF dimension.  The potential !DomainAxis is implicit in the CF NetCDF file.
     80In a CF NetCDF file an explicit !DomainAxis is a NetCDF dimension.  The potential !DomainAxis is implicit in the CF NetCDF file.
    7981
    80     == !OrderedCoord ==
     82== !OrderedCoord ==
    8183
    82     A !OrderedCoord represents a single, defined phenomenon used to define an individual !DomainAxis instance of the Field's domain or describe some of the Field's domain.
     84A !OrderedCoord represents a single, defined phenomenon used to define an individual !DomainAxis instance of the Field's domain or describe some of the Field's domain.
    8385
    84     A !OrderedCoord must have an array of points which is constrained to be one-dimensional unambiguously sortable and strictly monotonic.
     86A !OrderedCoord must have an array of points which is constrained to be one-dimensional unambiguously sortable and strictly monotonic.
    8587
    86     It may have an array of bounds, with two dimensions, one of size two, and the other matching the size the points array.
     88It may have an array of bounds, with two dimensions, one of size two, and the other matching the size the points array.
    8789
    88     The points and bounds arrays must be of the same data type.
     90The points and bounds arrays must be of the same data type.
    8991
    90     The sizes of the points array and optional bounds array are defined by the referencing !DomainAxis.
     92The sizes of the points array and optional bounds array are defined by the referencing !DomainAxis.
    9193
    92     The attributes of an !OrderedCoord are interpreted consistently with Appendix A. Attributes of the CF Conventions for NetCDF files (1.5) apart from '''bounds''' which is only to be used for referencing of a seperate bounds array, as implemented in NetCDF.
     94The attributes of an !OrderedCoord are interpreted consistently with Appendix A. Attributes of the CF Conventions for NetCDF files (1.5) apart from '''bounds''' which is only to be used for referencing of a seperate bounds array, as implemented in NetCDF.
    9395
    94     === The !OrderedCoord Construct in a NetCDF File ===
     96=== The !OrderedCoord Construct in a NetCDF File ===
    9597
    96     In a CF NetCDF file the !OrderedConstruct is implemented as a NetCDF Coordiante Variable, in accordance with the NUG.
     98In a CF NetCDF file the !OrderedConstruct is implemented as a NetCDF Coordiante Variable, in accordance with the NUG.
    9799
    98     == !UnorderedCoord ==
     100== !UnorderedCoord ==
    99101
    100     An !UnorderedCoord represents a single, defined phenomenon, used for interpreting some of the !DomainAxes of the Field.
     102An !UnorderedCoord represents a single, defined phenomenon, used for interpreting some of the !DomainAxes of the Field.
    101103
    102     An !UnorderedCoord must have an array of points.
     104An !UnorderedCoord must have an array of points.
    103105
    104     It may have an array of bounds, with one extra dimension compared to the points array, of size two, and matching the shape of the points array in all other respects.
     106It may have an array of bounds, with one extra dimension compared to the points array, of size two, and matching the shape of the points array in all other respects.
    105107
    106     The points and bounds arrays must be of the same data type.
     108The points and bounds arrays must be of the same data type.
    107109
    108     The sizes of the points array and optional bounds array are defined by the referencing !DomainAxes.
     110The sizes of the points array and optional bounds array are defined by the referencing !DomainAxes.
    109111
    110     The attributes of an !UnorderedCoord are interpreted consistently with Appendix A. Attributes of the CF Conventions for NetCDF files (1.5) apart from '''bounds''' which is only to be used for referencing of a seperate bounds array, as implemented in NetCDF.
     112The attributes of an !UnorderedCoord are interpreted consistently with Appendix A. Attributes of the CF Conventions for NetCDF files (1.5) apart from '''bounds''' which is only to be used for referencing of a seperate bounds array, as implemented in NetCDF.
    111113
    112114
    113     === The !UnorderedCoord Construct in a NetCDF File ===
     115=== The !UnorderedCoord Construct in a NetCDF File ===
    114116
    115     In a CF NetCDF file the !UnorderedConstruct is implemented as a variable which is referenced by a data variable using the CF attribute coordinates.     
     117In a CF NetCDF file the !UnorderedConstruct is implemented as a variable which is referenced by a data variable using the CF attribute coordinates.     
    116118
     119{{{
     120#!html
     121<!--
    117122
    118123=== !CellMeasure ===
     
    137142
    138143e.g. A pair of !AuxiliaryCoordinates: latitude and longitude, from a projected spatial coordinate pair.
     144-->
     145}}}
     146 
    139147
    140  
    141 ==== Notes ====
    142148
    143 Wherever it is used for a Type, 'attributes' is a collection of key:value pairs.
    144 
    145 Particular keys are banned from use for each type, as a particular implementation (NetCDF) has used them for referencing between variables.  As such the specified attribute keys may not be used to provide semantic meaning to a Type. 
    146 
    147 == Notes ==
     149== UML Notes ==
    148150
    149151=== Qualified Associations ===