Hi You missed my point. I assume that the content model will differentiate between ucum code and some other code, so as to enable all the behaviour you describe. But you don't need to force the use of a different element in a different place of the model. Merely differentiating the terminology used will achieve that. A processor will know when it can use ucum based logic - not that I've ever seen that in the real world - and it will know when it can't
Eric's part of this thread notes the issues with doing with this implicitly, so I'm not advocating for that, which brings you back to the FHIR model: human units, and system + code for computable units. Grahame > On 18 May 2016, at 10:06 PM, Thomas Beale <[email protected]> wrote: > > > 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. > > there are only 9 primitive physical properties; > all other physical properties can be obtained by combining the 9 primitive > ones, e.g. pressure = mass/area; area = length^2; > various mathematical properties hold for true amounts (these can be described > formally) > 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 > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
