Talk:Physical measurement - Mesure physique

As promissed to Frederic, I will comment his "Physical measurement" proposal here, and present an alternative solution.

1) history:

  This entity was introduced shortly in 2022, but not part of the voted items of the KarstLink core.
  We elaborated together, then presented at the UIS congress (paper cosigned by Frederic Urien, Peter Matthews and myself, Eric Madelaine) a proposal for an extension dedicated to measurements by (mainly underground) sensors as time-series, that many cavers use for temperature, pressure, conductivity, gaz rates, etc.

Here monitoring can mean short term to very long series of measurements for a single campaign, typically weeks, or several months, as opposed to individual measures as one could take typically with a and-held thermometer.

  In April/May 2024, related to the planned implementation of a physical measurement database module in the Grottocenter plateform, Frederic introduced in the karstlink wiki his proposal for Physical Measurements, that covers in a single Entity the two kinds of measures.

2) Encoding of physical measurements versus time-series:

  In addition to the obvious differences in the devices and in the way the measures are taken, the structure of

the results of observations is quite different. This shows clearly in the item of proposal 1 about results, defined as "made up of one or more Time/Value pairs". My point is (please refer to the UIS congress communication for more details) that when you have to deal with a (time-series) containing typically a hundred thousand sets of quantities (e.g. temperature, pressure, conductivity) at each time when the sensor registered a measure, you definitely do not want to build this complex object as a huge data structure that you would store in your database. In practice, the device providers encode this data in compact formats (usually text formats), and what is important to store, in addition to this text file, is its structure (format of timestamps, and which quantity/unit is in each column)

3) I find Frederic proposal quite complicated because he wants to define a single ontology entity for both a single measurement and a time-series, that forces him to underspecify the relations within the entity. One typical case is with time stamps, where a single measurement would be _necessarily_ associated to a DateTimeStamp, and nothing else, while a time series would certainly be _necessarily_ associated to a start date and an end date, that would allow applications using such data to make requests based on these start/end dates, without having to scan the full list of time/value pairs...

4) My proposal (B) is then to separate these 2 kinds of physical measurements. Of course there is a subset that will be common to the two "ObservationTypes", but each of them will be simpler and more precise.

5) In addition, from my experience using such sensors, it should be very useful to add a notion of "quality" of the measures, that are usualy coming from the caracteristics of the sensors, but also from poor calibration procedures, for exemple. When people will extract sensor data from our database, say 20 years from now, to make analyses of the effect of climate changes, this will be an important information. I have no precise idea what this "quality" could be, if someone has references to existing ontologies, I will be interested.