Term request: 'air temperature measurement datum', 'rate of hydrological precipitation', 'atmospheric water vapor measurement datum', 'mean rate of hydrological precipitation', 'mean air temperature', and 'mean atmospheric water vapor'

[dillerm]

Recently, we began using some of your classes in Apollo-SV, which focuses on epidemic modeling and computational epidemiology, because some modelers incorporate climate data into their models. As such, we are also in need of the aforementioned classes, but figured that they may be more appropriate for ENVO.

Below are definition proposals for each:

air temperature measurement datum = A scalar measurement datum that is the result of measuring the air temperature in some geographical region.

rate of hydrological precipitation = A rate measurement datum that is the result of the measurement of the volume of water produced by some hydrological precipitation process at a particular geographical region divided by the number of temporal intervals of equal duration over which the precipitation occurred.

atmospheric water vapor measurement datum = A rate measurement datum that is the result of the measurement of the atmospheric water vapor at a particular geographical region.

mean rate of hydrological precipitation = An average value that takes, as input, some set of hydrological precipitation rate data that were recorded over a particular duration of time.

mean air temperature = An average value that takes, as input, some set of air temperature measurement data that were recorded over a particular duration of time.

mean atmospheric water vapor = An average value that takes, as input, some set of atmospheric water vapor measurement data that were recorded over a particular duration of time.

[pbuttigieg]

Thank you for your feedback! I'll push these forward.

On 28 Sep 2016 18:07, "Matthew Diller" notifications@github.com wrote:

Recently, we began using some of your classes in Apollo-SV, which focuses on epidemic modeling and computational epidemiology, because some modelers incorporate climate data into their models. As such, we are also in need of the aforementioned classes, but figured that they may be more appropriate for ENVO.

Below are definition proposals for each:

air temperature measurement datum = A scalar measurement datum that is the result of measuring the air temperature in some geographical region.

rate of hydrological precipitation = A rate measurement datum that is the result of the measurement of the volume of water produced by some hydrological precipitation process at a particular geographical region divided by the number of temporal intervals of equal duration over which the precipitation occurred.

atmospheric water vapor measurement datum = A rate measurement datum that is the result of the measurement of the atmospheric water vapor at a particular geographical region.

mean rate of hydrological precipitation = An average value that takes, as input, some set of hydrological precipitation rate data that were recorded over a particular duration of time.

mean air temperature = An average value that takes, as input, some set of air temperature measurement data that were recorded over a particular duration of time.

mean atmospheric water vapor = An average value that takes, as input, some set of atmospheric water vapor measurement data that were recorded over a particular duration of time.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/EnvironmentOntology/envo/issues/387, or mute the thread https://github.com/notifications/unsubscribe-auth/ACK7Mvld5paMhNilpZ5ud48fhu4JBjLPks5qupDOgaJpZM4KJAup .

[dillerm]

Hi, @pbuttigieg, just wanted to check in to see how things are going and if there's anything that you folks could use some extra input on.

[ddooley]

I could use "air temperature measurement datum" as a teaching example to say it is a measure of 'temperature of air'.

[cmungall]

Just following up on this. @ddooley I am not sure I follow but is what you are saying consistent with what I say here: https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1539 (namely that ENVO should provide a class "temperature of air", there is no need to precoordinate shadow datum concepts?

however I think the core concepts requested here make sense and we should add to ENVO

[ddooley]

Definitely an ubiquitous "temperature of air" precomposed term is a needed building block - that can become a global standard nanopublication type entity. This is still very general - it could be the temperature of air in a freezer, where geography is not important, or on top of mount Kilimanjaro, or at 30,000 ft.

@cmungall I'll dive into your 1539 issue, but IF ENVO does accept datums, note that "measurement datum" has semantic siblings - predicted data item, setting datum, even simulation datum - which are actually about the role a given datum is playing with regard to a measurement process or a protocol / setting on a device (upstream/downstream creation/use). Ideally models infer infer the role a datum is playing by where it came from or where it is used, e.g. based on whether upstream processes are operating on real or simulated data. This avoids further fractioning of the datum hierarchy based on measurement/simulation etc. So have a general "air temperature datum" be a parent class of "air temperature measurement datum", or chop "measurement" out of the label if the role the datum is play is flexible and can be inferred elsewhere.

[kaiiam]

I had a longer reply to this topic https://github.com/matentzn/trait-phenotype-ontology-patterns/issues/1 trying to spur similar discussion. The summary of what I suggest is: I think some ontologies like ENVO, TO etc (or a future OBO parameters and qualities ontology) should having basic quality building blocks temperature of air blood glucose concentration etc. These building block terms (following DOSDPs) could then used as @ddooley suggests to infer a datum role in models which use that. Additionally I would see these building blocks being used as the new UCUM style annotations, e.g., mg{blood glucose concentration}/mL in UCUM-based unit system several of us are working on https://github.com/kaiiam/UO_revamp.

[smrgeoinfo]

I think the direction @kaiiam is suggesting is useful. The high-level ontologies (e.g. ENVO) can define kinds of qualities (e.g. Air Temperature, Water Temperature, Concentration of constituent, volume, density). The things called '...datum' here can be considered observation result types (using SSN/SOSA thinking) , which would translate to things like schema.org variableMeasured or InstanceVariables in the DDI variable cascade. These are based on a phenomenon (the quality kind), how it was measured, the featureOfInterest (context, why it was measured), and how it is represented (unit of measure, dataType). These more granular data types should be defined in domain/application specific ontologies to avoid the explosion of 'properties' that they would produce in high level ontologies like ENVO.