I knew someone would say that;-) But it's not for some principle of
ontological purity. It's for the most basic practical reasons. Consider
a quantity / units library designed based on a rigorous model of units,
like UCUM (which is a very good and rigorous piece of work), and also
other basic principles in science e.g.
1. there are only 9 primitive physical properties;
2. all other physical properties can be obtained by combining the 9
primitive ones, e.g. pressure = mass/area; area = length^2;
3. various mathematical properties hold for true amounts (these can be
described formally)
4. etc
These things don't hold for 'dose units', because they are not the same
kind of thing. They can't be modelled or computed in the same way.
So there are two choices:
* hack a clean model / library of scientific units to force it to deal
with non-units; these creates dirty code and bugs, and lots of
if/then exception conditions
* write a new clean model of the new kind of units, and integrate it
with the basic scientific units model.
I am only interested in one thing here: clarity for coders and data,
which translates to error-reduction, better quality data and more
maintainable code in the long run.
The final result may not be particularly differentiated on the screen,
or even consciously understood by end users, but they are miles away
from the models and code inside the systems we build.
- thomas
On 18/05/2016 12:54, Grahame Grieve wrote:
The arbitrary units are something different, but why does that matter
at the data type level? If you understand the unit, you can work with
it, if you don't you can't. Separating them because of ... Ontological
... Purity: just creates make -work for all the users who otherwise
don't differentiate them
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
