scalar measurement datum - to rename?

[zhengj2007]

From mcour...@gmail.com on March 22, 2010 20:27:23

measurement of handedness has no unit (e.g. -100 to +100 ), but is a scalar measurement datum (cf discussion at OBI workshop) which per current definition should have value and unit parts

Original issue: http://code.google.com/p/information-artifact-ontology/issues/detail?id=79

[zhengj2007]

From mcour...@gmail.com on March 23, 2010 09:44:27

should have 2 children: one with units, and one for scores (OBI WS March 23rd 2010)

[zhengj2007]

From michel.dumontier on March 30, 2010 09:28:44

what is required is a dimensionless quantity.

[Public-Health-Bioinformatics]

It would be great if the coverage of the "has measurement value" data property could be resolved. One move would be to rename it more accurately as "has scalar measurement float value", and then add the more general data property "has measurement value" that has no domain restriction, and whose value can be any kind of OWL/XML data type. We would not force the top-level measurement datum to have a "has measurement unit label" relation per. above discussion.

But then I see the object property tree:

has part
    has measurement datum
    has measurement unit label
    ...

Why don't we have more generic "has datum" and "has unit label" relations that apply to both measurements and settings etc. Measurement datum and setting datum capture which i/o end of an instrument or process a datum was observed at, (e.g. temperature reading at thermometer or as thermostat input) but this i/o distinction could be marked as a property (or via multihoming) just like the other details of a datum like its value, units, precision etc. So I'm thinking of something like these hierarchies:

Object Properties:

    has part
        has datum
        has unit (label)
        has preferred unit      // I'd like to sneak this one in
        has numeric precision
        has SI dimension      //range: International system of units (SI)

and possibly relations so we can say:

  "air temperature datum" is_datum_output_of some "thermometer" 
  "air temperature datum" is_datum_input_of some "thermostat"

Which gets at the way we use intentionality with a basic datum concept.

Classes:

data item
    data item by type
        numeric datum
            scalar datum
               ... types of numeric datum
            ordinal datum 
            interval datum 
            ratio datum
        categorical datum (nominal)
    data item by process context (i/o)
        measurement datum
           ...
        setting datum
           ...

I suggest datum be redefined as a numeric (e.g. 99.5) or categorical (e.g. feverish) value that can be accompanied by an SI fundamental dimension if not a more particular unit, and possibly numeric precision and scale information. I'll do a draft of this if I get encouraging feedback!

I've seen that the OWL spec won't work with some types of numeric values so until that technical limitation is fixed some projects might need to avoid reference to certain numeric types.

STATO and some unit ontologies have covered a bit of this territory. I feel a better organization of these relations and data types is pretty important directly within OBO for enabling more accurate description of 3rd party datasets so we can develop ontology-driven data exchange between systems, and to reduce training/exploration time for up and coming OBO ontologists.

Feedback really appreciated...