Common Data Model is an abstract data model for scientific datasets that can be constrained by OCL. To hide complexity of OCL, CdmCL is proposed as a specific textual constraint language for CDM. CdmCL is based on the CDM structure and results in a set of constraint categories. CdmCL provides a user-friendly front end in order to define constraints which are subsequently translated to OCL. The conformity tool is based on an existing OCL checker integrated in EMF. CdmCL is experimented on the OceanSITES standard.
Unidata s Common Data Model (CDM) is an abstract data model for scientific
datasets. It is based on three layers, data access layer, coordinate system layer and
scientific feature type layer. Our work focuses on data access layer also called syntactic
layer that handles data modeling part. The complete data model and detailed
description is given in [
DataSet: a file, such as NetCDF file, characterized by a file name (location). Group: a container for dimensions, attributes, variables and nested subGroups. Dimension: the array shape of a Variable, characterized by a name and a length; Variable: a container for data, characterized by a name, a dataType, a set of dimensions that define its array shape, and optionally a set of attributes.
Attribute: a metadata to characterize a Variable or a Group, characterized by a name, a dataType and a value.
OceanSITES [
To check the data conformity to OceanSITES, a Java tool already exists [
OceanSITES Manual
CDM instance respecting OceanSITES
This work focuses on the automatic generation of OCL constraints from CdmCL. On the one hand, the CdmCL front end needs to be human readable and close to the classical standard. Therefore, Xtext has been used to define the textual grammar. On the other hand, each CdmCL concept has a semantic expressed using OCL.
In standards, most of the constraints are related to a specific instance of a named CDM concept (Variable, Dimension and Attribute): the attribute named data_type can hold either the value OceanSITES metadata, or OceanSITES profile data ; the dimension of the variable named TIME is the dimension TIME . Thus, CdmCL is structured by three abstract classes DimensionConstraint, VariableConstraint and AttributeConstraint (see figure 3). Then, to express a constraint related to a specific instance, CdmCL follows the three different scenarios, defining nine concrete concepts:
Constraint is applied to a specific CDM concept referenced by its name: aDimensionConstraint, aVariableConstraint or anAttributeConstraint.
Constraint is applied to items whose name matches a specific regular expression: TemplateDimensionRegex, TemplateVariableRegex, or TemplateAttributeRegex. Constraint is applied to a set of items, characterized by a set of names: TemplateDimensionList, TemplateVariableList or TemplateAttributeList.
The following section introduces the constraints that are common between DimensionConstraint, VariableConstraint and AttributeConstraint.
Mandatory: This constraint verifies that the name of the related concept exists. For the template list concept, an extra Boolean attribute or permits to indicate whether one of the items of the list is mandatory or all the items are mandatory. As an example, figure 4 presents the CdmCL expressions and the corresponding OCL statements for aDimension called DEPTH (a single dimension) and a TemplateDimensionList (coordinate dimension list holding LATITUDE and LONGITUDE).
The values between parentheses permit the definition of dimension length and are explained in the next section. Figure 5 presents a CDM instance to the left respecting the OceanSITES standard, thus the instance is valid, whereas the other instance is not valid because the mandatory dimension LONGITUDE and the mandatory variable TIME are missing, thus the OCL constraints checkMandatory_dimension_LONGITUDE and checkMandatory_variables_TIME are violated.
Repetition: This constraint checks that a name of a concept is never repeated.
Format: This constraint verifies that names of a set of concept have a specific format, either uppercase, lowercase or matches a specific regular expression.
User Defined Constraints: This concept increases the flexibility of the language, by allowing the user to enter manually an OCL statement. However, it is the user s responsibility to verify the correctness of the OCL statement regarding the CDM metamodel. These constraints are defined in the context of Group. In addition, other constraints are related to specific concepts.
· Dimensions length constraints: The length value for a dimension can be a limited or unlimited (any positive value). For the limited length, it can be a specific value, a value in a range, greater than or equal to a specific value, smaller than or equal. To achieve these constraint objectives, dimensionConstraint concept has two Integer attributes called minLength and maxLength and one Boolean attribute called IsUnlimited (see table 1). case 1 constraints are built all in the same way. The first part of the OCL constraint (exists, select) defines the context of the specific concept (here the TIME Dimension). Then, the second part expresses the constraint itself (forAll). · · · Variable shape constraint: A variable is characterized by a set of shapes i.e. a set of dimensions (see figure 1). A variable can have a shape of the same name as the variable s name. For example a variable named TIME is associated with a dimension named TIME. Moreover, a variable can be associated with a dimension or a set of dimensions. For example, a variable named TIME_QC is associated with dimension named TIME. To accomplish this type of verification, we have two concepts SimilarDimensionConstraint and/or a set of PredefinedShape concept for a VariableConstraint. On one hand SimilarDimensionConstraint concept allow the generation of an OCL invariant that verifies that a variable is associated with a dimension of same variable s name. On the other hand PredefinedShape concept permits to verify that a variable is associated with any preexisting dimensions. Figure 7 illustrates the previous discussion and presents the CdmCL representation along with the OCL to be generated.
verifies that the variables and the attributes can have any data type from a list of data types.
Attribute Value Constraint: A constraint on the value of an Attribute, the possible categories are given in table 2.
Based on CdmCL, we developed a conformity checker for netCDF1 files which conform to CDM metamodel. The tool architecture is shown in figure 8. It is developed in Java and based on the Eclipse Modeling Framework (EMF). First, the tool transforms the CdmCL model into OCL statements in a separated file. This part 1 NetCDF (Network Common Data Form ) is a CDM compliant file serialization format (CdmCL2OCL) uses Xtext API, and the library we developed for the transformation of CdmCL expressions to OCL constraints. Then, the tool transforms a NetCDF file into an instance of CDM model. This part (nc2CDM) is simply based on the Java NetCDF API and on the CDM Java API (provided by EMF). Finally, the tool checks the conformity of the CDM file to the CDM metamodel enriched with the generated OCL file, and indicates whether it is valid or not. This part is based on the integrated OCL checker of the EMF modeling tool. The tool has been tested on OceanSITES. Due to the lack of space we express only the OceanSITES global attributes standard given in figure 2 in CdmCL. The CdmCL shown in figure 9 indicates that a global attribute named data_type is mandatory, of type string and has any of the values presented by the list dataTypeGlobalList. This list hold the values OceanSITES metadata, OceanSITES profile data, OceanSITES time-series data or OceanSITES trajectory data. Furthermore, it indicates that a global attribute named format_version, of type string and should hold the value 1.1 . The CdmCL expressions and the generated OCL after using CdmCL2OCL tool are given in figure 9.
The generated OCL file is then used with the CDM model to check the conformity of an input netCDF file. If the input file does not respect the constraints, a message indicates that the input file does not conform to CDM model with the set of OCL violated constraints. Figure 10 presents an excerpt of CDM data converted from a netcdf file. These data are validated with this generated OCL. It is seen that the left instance is valid whereas the right instance is invalid because the global attribute format_version value constraint is violated.
Figure 10 illustrates that the right version is invalid because format_version constraints was violated, but in reality this global attribute can have the value of 1.2 and even 1.3 since OceanSITES standard has been evaluated to the new version 1.3 with backward compatibility. Therefore by just modifying the CdmCL format_version value to hold the values (1.1, 1.2 or 1.3), we can have the new standard OCL representation without any professional interference and the instance will be valid with respect to OceanSITES version 1.3.
Experimenting CdmCL on OceanSITES, it is observed that more than 90% percent of the constraints are achieved in the CdmCL except the constraints that are related to multiple CDM concepts at the same time. For example, a constraint verifies the existence of either a variable named TIME with attribute named QC_indicator or a variable named TIME_QC.
For CdmCL syntax readability, the two global attributes of OceanSITES given in figure 2 are represented by approximately eight lines in CdmCL expressions and generate around 30 lines of OCL statements. One page of textual constraints from the standard is expressed by around 25 lines in CdmCL and generates around 300 lines of OCL.
The language CdmCL was introduced to OceanSITES users (standard reader) and they confirm the expressiveness and the readability of CdmCL. 6
Several studies are proposed to support OCL integration on modeling processes.
The Dresden OCL Toolkit [
In the domain of OCL generation, [
In [
This paper proposes a domain specific constraint language for CDM. The language structure is based on CDM structure and results in a set of constraint categories. These categories permit to define constraints in a human readable language and serves in the automatic generation of OCL. The approach hides the complexity of writing OCL manually and increases the productivity by generating a large number of OCL statements for few lines written in CdmCL. Furthermore, any standard edition and conformity checking can be done easily without OCL and programming interference.
In perspective, we are working on developing domain specific operators to automate scientific data migration from a standard to another one. 8