SECoP: sample environments

[g-guenther]

This PR solves issues #1315, #1329, #1342, #1365, #1571 and replaces PR #1330 and #1328. Moreover, #1326 and #1327, respectively, are redundant since SECoP agreed that having any number of NXenvironment groups in NXsample is sufficient. The reason for this PR is that jkotan, who creates most of the issues and PRs, is no longer so heavily involved in the SECoP project.

This PR implements SECoP changes that require to implement complex sample environment systems, a clear definition of the sample's state, and the sample environments defining the sample's state. Up to now this is only achieved for some sample conditions, e.g. the temperature by defining the field temperature and temperature_env in NXsample as well as the 'temperature' value in NXsensor/measurement. To achieve this on a wider level, three more optional values (humidity, viscosity, concentration) are added to NXsensor/measurement and missing CONDITION fields (including units type if required) and CONDITION_env are added to NXsample, namely:

• pH, pH_env, NX_MOLAR_DENSITY
• electric_field_env
• current, current_env
• conductivity, conductivity_env, NX_CONDUCTIVITY
• resistance, resistance_env, NX_RESISTANCE
• voltage, voltage_env
• pressure_env
• flow, flow_env, NX_FLOW
• stress_field_env
• strain_field, strain_field_env
• shear_field, shear_field_env
• surface_pressure, surface_pressure_env
• humidity, humidity_env
• viscosity, viscosity_env, NX_PRESSURE_TIME
• concentration_env

To my understanding, this PR is just a coherent implementation of the logic that is already inherent in NeXus.

[g-guenther]

Regarding the fruitful discussion in the meeting on the 16.07., it was suggested that additional options 'humidity', 'viscosity', and 'concentration' could be applied to the NXsensor/measurement field with the attribute 'custom=True' according to the current NXsensor definition (without explicitly defining them) and, additionally, could be defined by a reference to an external resource (e.g. a PURL of an ontology term), see #1569. Following this approach, I wonder if all requirements of SECoP in this issue could be solved this way, i.e. by referencing an external knowledge representation. For example, adding the custom field 'humidity' to NXsample with a reference to the QUDT ontology (https://qudt.org/vocab/quantitykind/RelativeHumidity).

For this reason, I would suggest to wait with this PR and see if #1569 can be solved.

[g-guenther]

To record other comments from the meeting on July 16:

• it should be noted in the NXsample/temperature field (and where appropriate) that it could contain an HDF5-internal softlink to a NXenvironment/NXsensor/value field (if available).
• the parameters in field defintions (e.g. n_pField) and at the beginning of the NXsample base class are rather useless since they are not used for validation
• rethink to define dimensions of fields since they could vary; it is already implemented that every data field can be replaced by NXlog; in general, the dimension of a data field can depend on the setup. measurement technique, or the arrangement of data in the file

[g-guenther]

As a note: The NXsensor/meaning field of NeXus is represented in SECoP by the 'function' (https://sampleenvironment.github.io/secop-site/specification/descriptive.html#optional-module-properties).