Create design pattern for environmental data and variables

[pbuttigieg]

@cmungall - as you've probably noticed, there is a mass of issues requesting environmental variables. I'm about to get stuck in, but I think a design pattern and some finalisation on the semantics is needed.
We seem to have two major cases:

Data vs 'variables'

Data items & data sets

Similar to what @celineaubert has been suggesting (e.g. #432), this keeps focus on individual 'variable' values by creating an environmentally themed class beneath a PATO quality (

PATO:temperature <--is-- ENVO:'air temperature' --inheres_in--> ENVO:air

and then linking a corresponding IAO:measurement datum (--about--> ENVO:'air temperature').

This is partially covered in the entity_attribute DP. See ENVO:temperature of air.

All that's left is to extend this as entity_attribute_dataItem or entity_attribute_dataset so we have, e.g., "datum about the temperature of air" (syn "air temperature datum") or "data set about the temperature of air". Perhaps we should create both these classes (data item + data set) simultaneously using the same DP script as if one exists the other is must or is very likely to exist too.

We should perhaps auto-tag all these classes with an 'in_subset' envoData or similar.

I'm a little confused regarding the difference between data item and measurement datum. The latter is more clear for the requests we have, but their defs look pretty similar.

Variables

Before any data is even generated, I would say that a 'variable' is the conceptualisation/operationalisation of one or more attributes (qualities) of an entity (see, e.g. this very general Wikipedia page). I think this holds for other kinds of variables in mathematics and statistics.

The ingredients for this DP would be the quality or qualities of interest and the method (OBI:protocol or similar plan) used to operationalise them.

@marieALaporte @celineaubert
This is somewhat more similar to the CO treatment of variables (data + method + quality)

STATO has a variable class which has a somewhat strange def and is a subclass of IAO's data item, which really doesn't ring true. It seems STATO means "variable value" (which is pretty much a measurement data item) rather than the variable itself (this sounds like indicator vs indicator value from SDGIO).

PS: There is a variant quality which could be in the mix, but I think that may be complicating things.

Need more thinking on this.

[marieALaporte]

After discussing with @cmungall, we decided that we won't create the variable/datum hierarchy in AgrO.
The variables will be post composed from the list of qualities, methods and units, when the data are created. The methods and the units will be directly linked to the qualities for that purpose. See AgriculturalSemantics/agro#14 and AgriculturalSemantics/agro#15

[pbuttigieg]

This makes sense.
@celineaubert Do the all requests to ENVO still stand then? Please close the ones you don't need. I think we will pre-compose some of the common variables/measurments.

[celineaubert]

@pbuttigieg I will delete the measurement datum requests. However, the other requests still stand.

[pbuttigieg]

great, thanks! If the request is very general and useful to many domains (e.g. soil temperature), please leave it. I'll create a light-weight class (without the method part) for ease of use.

[pbuttigieg]

@pbuttigieg I will delete the measurement datum requests. However, the other requests still stand.

@celineaubert Please link back to this issue (#435) when you close those issues so we know why. Thanks!

[celineaubert]

@pbuttigieg I won't close the issues since the ''measurement datum'' are in the same issue than the class their refer to. I was thinking on updating the issues by removing the measurement datum part.