One of the most important aspects of managing scientific data is the handling of units. Although there is a standardized system of units, the SI units (International System of Units), it is not absolutely said that researchers are using them. For example, in the combustion thermodynamics domain (the domain of this tool), though the trend is toward SI units, it is not said that the available data needed by the application is in SI units. In addition, even if SI units are used, there is still some conversion that is necessary. For example, depending on the range of values of the parameter, the simple unit could be used or if it has a larger range, with the prefix, for example, kilo-, or if with a smaller range, for example, milli-.
There are two philosophies of handling units in a database. The first is to convert them to a 'standard', relative to the database. Each parameter would have it's expected unit. With this philosophy, the units are implicit and do not need to be stored with the value. The disadvantage is that it is left to the user on input to convert the units. This can lead to errors and this 'hidden' step makes it more difficult to trace the value to and check the value with the original source value. The other philosophy, is to store not only the value, but the unit used for the value. In JThermodynamicsCloud the second philosophy is used for basically two reasons. The most important reason is that keeping the unit with the parameter means that the value stored can be exactly that of the original source. This promotes traceability and error-checking. In addition, during the thermodynamic calculation, the primary task of JThermodynamicsCloud, the user can choose the units for the final answer. With the first philosophy, the calculation units would be fixed and it would be up to the user to convert them if necessary.
To convert between different units requires a knowledge base of units. For a application within a small domain, this knowledge base could be 'hard-coded' into the application. However, a more general approach is provided by the QUDT ontology. In the QUDT ontology each 'kind' of unit is an instance of qudt:QuantityKind, for example qudt:MolarEnergy. In the annotations of the instance of qudt:QuantityKind, the available units of this kind are given by qudt:applicableUnit. For example, on applicable unit of qudt:MolarEnergy is qudt:CAL-PER-MOL, i.e. calories/mol of substance. In the applicable unit, the conversions to the SI units are given. To convert calories/mol to the SI unit joule, one multiplies the calories by 4.184.
The ontology definition for a parameter in JThermodynamicCloud stores both the value and the specification, meaning the units for the value. In addition, uncertainty values are taken into account. A parameter is represented by the dataset:ParameterValue class with three fields:
dataset: ValueAsString: This is a string representation of the value. If the value is numeric, there is no requirement for its representation, it would just be able to be converted by a string to numeric algorithm.
dataset:ValueUncertainty: This, if used, is the uncertainty of the value, of course in the same units as the value. If there is no uncertainty, then this value is zero.
dataset:ParameterSpecification: This is a record, meaning several components, giving the specification of the value..
The specification of the value is defined by dataset:ParameterSpecification. This specification is used not only within the parameter definition, but also to specify what type of data is expected in other data structures. The specification is made of the following:
dataset:ParameterLabel: This is a string keyword or label given to this parameter value. In a matrix, this would be the column name.
dataset:ParameterTypeSpecification: This is the qudt:QuantityKind, of the QUDT ontology, specifying the type of unit, for example, qudt:MolarEnergy in the above example.
dataset:ValueUnits: This is the QUDT label for the specific unir of the qudt:QuantityKind. For example, for qudt:MolarEnergy, a specific instance could be qudt:CAL-PER-MOL.
dataset:DataPointUncertainty: This is a classification parameter and specifies the type of uncertainty is given. The available uncertainties are subclasses of dataset:ChemConnectUncertaintyTypes, such as dataset:StandardDeviationAbsoluteUncertainty, dataset:EstimatedAbsoluteUncertainty, dataset:PercentageRelativeUncertainty and others.