[uf-new] Measurement brainstorming

LucaP lucapost at gmail.com
Thu Oct 18 11:01:13 PDT 2007


Hi all, I have been redirected in here after posting my personal
measurement-brainstorming on the 'discuss' list:

http://www.mail-archive.com/microformats-discuss@microformats.org/msg08902.html

Despite being totally unaware of this thread, my reasoning seems to
fit for the most part in the ongoing discussion, I believe there is
one big issue that has been totally forgotten thought:

in many contexts (scientific/technical) a measurement has no meaning
without a corresponding error/confidence!

thus, something like <span class="data-error">0.1</span> should find
its place inside hmeasure ( hWhateverWillBe), actually this can be
simplified by exploiting the '&plusmn;' html-entity to signal the
beginning of the error-value part, in place of the extra <span
class="data-error>

The correct measurement notation on paper is normally (absolute_error):

( 5.8 +/- 0.4 ) km.

i.e. the 2 values must be expressed in the same unit and with the same
precision (number of digits).
This is far more important than requiring that the string used for the
unit-measure conforms with SI standard.
As long as the 2 values are consistent (as defined above), they
represent a valid data-entry in some unit, and the parser's should
just 'export' (*).

another notation is (relative_error):

5.8 Km. +/- 7%

error propagation on derived quantities is computed by algebraic rules
on relative_errors, than converted back to the absolute_error
notation.

Sorry for the cheap 101-lesson in Experimental Science & Statistics!


(*)
Verifying strict SI-conformance is not that important for the entry in
itself, it does get crucial when comparing and combining entries, but
I believe this is a separate computing layer and the initial hmeasure
specs can go soft about it.
For example let's imagine a 'universal unit-conversion Firefox
extension', it would definetly exploit the hmeasure parser, but would
have to take care of unit-validations on its own, once it gets the
data entries from the parser.


More information about the microformats-new mailing list