Uncertainty

[taxles]

New issue to progress the topic of 'Uncertainty' raised at Complex units (#51).

[taxles]

Thanks Hajo,

to kick things off:

1. Foundation References for Measurement Uncertainty I've found:

1. Joint Committee for Guides in Metrology (JCGM) (formed by seven International Organisations):
   • Guide to the Expression of Uncertainty in Measurement (GUM) (online) JCGM 100:2008(E)
   • International Vocabulary of Metrology (VIM) (online) JCGM 200:2008(E)
2. National Institute of Standards and Technology (NIST) (US Gov)
   • Guidelines for Evaluating and Expressing the Uncertainty of NIST Measurement Results (online) Technical Note 1297

2. Tolerance A helpful presentation that defines 'Tolerance' is "Extending conformance measures to more than one measurand – Conformity assessment of multicomponent materials or objects" by Francesca Pennecchi (Istituto Nazionale di Ricerca Metrologica, Torino, Italy), EMPIR 17NRM05 EMUE Workshop, LNE, Paris 21Jan20 (Francesca's presentation is Workshop_EMUE_PENNECCHI.pdf from the .zip under the Workshop presentations heading).

3. My Goal I'm hoping for defined data structures (probably tuples) that include the uncertainty of a measure to support:

• the Law of Propagation of Uncertainty, and
• conformity assessment (See ISO/IEC 17000:2020 "Conformity assessment — Vocabulary and general principles")

4. My Current Position My roots are in mechanical engineering, not software engineering, and just because a measure can be stored in a machine with incredible precision (see IEEE's SWEBOK Numerical Precision, Accuracy, and Errors) it doesn't mean the (source) measure gains that precision. One means to represent the uncertainty of a measure would be to record the number of significant digits associated with the (source) measure.

5. Example See (your) OM RecordTable Ontology Table 1. and Figure 3. Table 1 presents Measures of Life Expectancy (years) to 3x significant digits. However, Figure 3 shows the Measures being stored as a double (which provide 17 digits of precision (64-bit), or 31 significant digits if using a 128-bit long double floating-point data type). Whilst this may seem to be a good thing for some people, it erodes my ability to achieve the above 2x goals.

6. Next Steps There are multiple ways to define measurement uncertainty, such as significant digits, min-mean-max, etc. already defined (such as the above foundation references). In my next posts I'll:

• attempt to summarise these multiple ways to represent uncertainty, and
• point to any implementations that I've found to date.

I also hope to discuss representing the (initial) purpose of the measure (but that may be best done in a separate thread).

Regards, AL.

[HajoRijgersberg]

Hi Al,

Thanks for this overview! I think the sources you've mentioned are very suitable to base our design on. I've looked at GUM and VIM before, but it's been a very long time, and now that I'm looking at it again, I realize it will be quite a study. If you could summarize the different ways to represent uncertainty, and find implementations, that would really be great! Discussing the (purpose of the) measure would also be interesting (indeed for a separate thread). I'm curious if min-mean-max occurs in GUM. If we define uncertainty in measures, propagation of uncertainty will indeed be supported.

In the meantime, I've been thinking. We now have the measure in OM (om:Measure). It has a numerical value (om:hasNumericalValue) and a unit (om:hasUnit). This is actually the simplest measure one can think of. So, in the future we would like to define more complex types. We will therefore have to reserve the term om:Measure as an umbrella term for all the different types of measures that will be introduced. We should perhaps call the mentioned simple measure: om:SimpleMeasure. There will for example also be an om:CompoundMeasure. It would consist of several other measures, usually simple measures such as in the case of 5 foot 10 (inch). om:CompoundMeasure should then, I think, only have one property, with a cardinality > 1: om:hasMeasure. For example, the compound measure 5 foot 10 could then be defined as follows:

:_5Foot10 a om:CompoundMeasure ; om:hasMeasure :_5Foot ; om:hasMeasure :_10Inch .

The min-mean-max measure may need to have the following properties:

• om:hasMinimumNumericalValue
• om:hasMeanNumericalValue
• om:hasMaximumNumericalValue
• om:hasUnit

Or, if we would like to permit min, mean, and max to each have its own unit:

• om:hasMinimumMeasure om:Measure
• om:hasMeanMeasure om:Measure
• om:hasMaximumMeasure om:Measure

Another point: om:hasNumericalValue is currently of datatype string, so anyone is free to specify a number, range, list of numbers, or whatever. In the future I think we should use xsd number datatypes. Then we may get different kinds of measures, like in the case of the om:SimpleMeasure:

• SimpleIntegerMeasure,
• SimpleDoubleMeasure,
• etc.

I'm not sure, but it's one of my thoughts. This will perhaps be the case with other kinds of measures too, such as min-mean-max (IntegerMinMeanMaxMeasure, DoubleMinMeanMaxMeasure, etc.)

Hopefully the above will help us in our thoughts and design processes. Looking forward to your feedback/response!

Best, Hajo

[HajoRijgersberg]

P.S.: Proposal (from my side) for a measure representing a mean and a standard deviation:

om:MeanStandardDeviationMeasure, with properties:

• om:hasMeanNumericalValue
• om:hasStandardDeviationNumericalValue
• om:hasUnit