Datatypes R2 Issue 14
Data Types Issue 14: Relax Unit Constraint on PQ
Change PQ.unit so that it does not have to a valid UCUM code.
Currently PQ.unit must be a valid UCUM code. There is a few things that you want to do with a PQ where the units you have to express are not UCUM units. Example: 3 tablets
? backward compatible: This element will be semantically backward compatible but will introduce new possible values for the PQ.unit field
The unit of measure specified in the Unified Code for Units of Measure (UCUM) or any other unit of measure
This is a very, very bad idea. Didn't we want to be interoperable? --Gschadow 01:22, 25 Jun 2006 (CDT)
Grahame Grieve: This proposal is introduced as there was no other proposal made regarding PQ, and this was informally proposed before the call for R2 proposals was released.
I personally do not support this proposal (see below), but we need to discuss this
Grahame: It's clear that a physical quantity is a tri-value:
* the number * the units * the thing being measured
In a PQ, we have only modelled the first 2 parts, on the basis that the third comes from the context. There is a few cases where the third element, what is being measured, doesn't come from the context. In this case, people want to call it the unit, but this is wrong. Generally the unit is unity - *but not always*.
I think that we need to resolve whether
* the context should provide the third piece of information and needs to be fixed if it doesn't
* we need to extend PQ to handle the third part.
Gunther: It is extremely important that it be clear that Observation.code (or Observation.definition) set the context for any PQ in an Observation.value and that whatever attribute is of type PQ define the measurement concept specifically.
The context (such as the definition of the attribute) in which the PQ is used must define what thing that the PQ is a quantity of. + Add examples + add warnings against being an idiot.
(much other correspondence not reproduced here)
Back to Data Types R2 issues