Hi all, I thought a lot on your proposal. If we want to use pseudo-units (non-UCUM terms), then we have to be able to distinguish when a term is in UCUM syntax. For example g/m2.7 is a valid UCUM string, but it is interpreted as (g/m^2) * 7 and not as g/(m^2.7), because in UCUM ?.? is the symbol for multiplication operator. So ?units? attribute should become a sort of code phrase, with the information on adopted syntax. Otherwise we can have an ambiguous syntax.
As alternative, if we want to go on using only UCUM syntax, we could express this pseudo-unit (and not standard units) with the so-called annotation, wrapped in curly braces (see http://aurora.regenstrief.org/~ucum/ucum.html#section-Character-Set-and-Lexical-Rules, section 6). In this case, we can adopt {g/m2.7} safely, remaining compliant with the UCUM syntax. What do you think!? Regards, Leonardo Ian McNicoll-3 wrote: > > This kind of scenario is very common and we need to establish some > guidelines and governance about how to handle these sort of > 'pseudo-units', > so that vendors can get on with some kind of implementation while these > sort > of difficult and obscure issues are discussed. > > Am I correct in thinking that since 'units' is a string, there is no > particular barrier to the use of a non-UCUM term? > > We obviously want to enforce UCUM use where-ever possible but this will > not > always be sensible or possible and we need to give developers alternatives > (perhaps temporary) and a clear change request mechanism. > > e.g. As alternatives > > 1. Use the pseudo-unit in the unit attribute, as a qualified real > 2. Use a qualified real and keep the name of the unit in the element name > 'LV function factor (m2/kg3/m)' or whatever. > > > Ian > > Dr Ian McNicoll > office +44 (0)1536 414 994 > +44 (0)2032 392 970 > fax +44 (0)1536 516317 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > ian.mcnicoll at oceaninformatics.com > > Clinical Modelling Consultant, Ocean Informatics, UK > openEHR Clinical Knowledge Editor www.openehr.org/knowledge > Honorary Senior Research Associate, CHIME, UCL > BCS Primary Health Care www.phcsg.org > > > > On 29 April 2011 12:27, Thomas Beale > <thomas.beale at oceaninformatics.com>wrote: > >> >> I think that we at least need to find out what the physical basis of this >> unit is. I could not find any definitive reference online, only papers >> reporting its use. Any cardiologists here? >> >> - thomas >> >> >> On 29/04/2011 10:25, Grahame Grieve wrote: >> >> Hi Tom >> >> It's a strange concept for sure. The real question here is whether >> UCUM and PQ/DV_QUANTITY are for real measurements, or >> whether they for quantitative notions. >> >> There's general agreement that things like "tablet" etc are not >> UCUM units - because they're not quantitative. Now we have a different >> issue - these are quantitative, but not real. >> >> I can see the grounds for keeping them out of UCUM. In >> addition, I'd have to recode my ucum library for this, and >> it's an odd challenge for such a strange notion. >> >> On the other hand, why not let scientists how measure things >> measure them how they want, as long as the units are meaningful >> - to them. >> >> >> * >> * >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -- View this message in context: http://old.nabble.com/Unable-to-express-an-unit-of-measurements-in-UCUM-syntax-tp31494533p31709299.html Sent from the openehr-technical mailing list archive at Nabble.com.
