Unable to express an unit of measurements in UCUM syntax

[Grahame Grieve]

> I don't think that your proposed solution is valid. It meets the
> syntactical requirements while making a mess of any semantic
> meaning.
>
>
> well... ok, but {} in UCUM is for things whose syntax doesn't make proper
> sense

>From UCUM:
"Annotations do not contribute to the semantics of the unit but are
meaningless by definition. Therefore, any fully conformant parser
must discard all annotations. Parsers of limited conformace should
not value annotations in comparison of unit"

so If I say that the unit really is g/m^2.7, but because of
UCUM limitations I say the unit is g/m{^2.7}, I'm actually
now making a false claim. (And only secret knowledge, along
with a non-conformant parser, will allow it to be made right
again).

As I said, the proper way to do this is to open a ticket.
There's a related one:

http://www.unitsofmeasure.org/ticket/51

But i don't think that this is expressed the way we would
want to express this one, which would be somewhere
along the lines of

* ucum is normatively used by HL7 v3 and others
  for representing units
* a community are using the unit x (can't recall the original)
* in the health record, we need to record these units
* so how are we supposed to do this?
* UCUMs scope is "intended to include all units of measures
  being contemporarily used in international science, engineering,
  and business", and these units clearly comply with this scope
* a harmless way to extend the syntax to support this notion
  would be to use "," a la european usage

Grahame

Unable to express an unit of measurements in UCUM syntax

[Thomas Beale]

On 29/05/2011 22:50, Grahame Grieve wrote:
> it'd be either Orders and Observations or Modeling and Methodology.
>
> I don't think that your proposed solution is valid. It meets the
> syntactical requirements while making a mess of any semantic
> meaning.
>

well... ok, but {} in UCUM is for things whose syntax doesn't make 
proper sense... if we can make sense of it in the non-{} part of UCUM, 
how do is it done? Everything unit has to either fit into the regular 
part of UCUM or else the {} 'escape hatch' doesn't it?

- thomas*
*
-- next part --
An HTML attachment was scrubbed...
URL: 

Unable to express an unit of measurements in UCUM syntax

[Grahame Grieve]

it'd be either Orders and Observations or Modeling and Methodology.

I don't think that your proposed solution is valid. It meets the
syntactical requirements while making a mess of any semantic
meaning.

Grahame


On Fri, May 27, 2011 at 10:26 PM, Leonardo Moretti
 wrote:
>
> In UCUM, the period '.' is only used as a multiplication operator, thus ?2.7?
> means always 2 ? 7 and is not equal to 27/10.
> The use of curly brace is already part of UCUM systax, so it would be
> already compliant with it.
>
> I haven't yet found any mailing list in HL7 which deals with this aspect..
>
> Regards,
> leonardo
>
>
> Thomas Beale-3 wrote:
>>
>> On 26/05/2011 16:48, Leonardo Moretti wrote:
>>> 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.
>>
>> I am surprised that precedence does not force the reading of the full
>> number following a '^', or a unit like 'm' when the '^' is inferred. I
>> will have to look at my own UCUM parser to see what it does!
>>
>>> 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.
>>
>> I actually think that is a good idea. Have you looked for a mailing list
>> or place in HL7 where you can make that proposal?
>>
>> - thomas beale
>>
>> ___
>> 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-tp31494533p31715342.html
> Sent from the openehr-technical mailing list archive at Nabble.com.
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>



-- 
-
http://www.healthintersections.com.au /
grahame at healthintersections.com.au / +61 411 867 065

Unable to express an unit of measurements in UCUM syntax

[Leonardo Moretti]

In UCUM, the period '.' is only used as a multiplication operator, thus ?2.7?
means always 2 ? 7 and is not equal to 27/10.
The use of curly brace is already part of UCUM systax, so it would be
already compliant with it.

I haven't yet found any mailing list in HL7 which deals with this aspect..

Regards, 
leonardo


Thomas Beale-3 wrote:
> 
> On 26/05/2011 16:48, Leonardo Moretti wrote:
>> 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.
> 
> I am surprised that precedence does not force the reading of the full 
> number following a '^', or a unit like 'm' when the '^' is inferred. I 
> will have to look at my own UCUM parser to see what it does!
> 
>> 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.
> 
> I actually think that is a good idea. Have you looked for a mailing list 
> or place in HL7 where you can make that proposal?
> 
> - thomas beale
> 
> ___
> 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-tp31494533p31715342.html
Sent from the openehr-technical mailing list archive at Nabble.com.

Unable to express an unit of measurements in UCUM syntax

[Koray Atalag]

Hmm, haven't had a chance to read the full thread but does this mean I can also 
represent Gauge as a Quantity unit (which is not part of openEHR terminology) 
similarly? 

Cheers,

-koray


-Original Message-
From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Thomas Beale
Sent: Friday, 27 May 2011 4:24 a.m.
To: openehr-technical at openehr.org
Subject: Re: Unable to express an unit of measurements in UCUM syntax

On 26/05/2011 16:48, Leonardo Moretti wrote:
> 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.

I am surprised that precedence does not force the reading of the full 
number following a '^', or a unit like 'm' when the '^' is inferred. I 
will have to look at my own UCUM parser to see what it does!

> 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.

I actually think that is a good idea. Have you looked for a mailing list 
or place in HL7 where you can make that proposal?

- thomas beale

___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Unable to express an unit of measurements in UCUM syntax

[Thomas Beale]

On 26/05/2011 16:48, Leonardo Moretti wrote:
> 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.

I am surprised that precedence does not force the reading of the full 
number following a '^', or a unit like 'm' when the '^' is inferred. I 
will have to look at my own UCUM parser to see what it does!

> 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.

I actually think that is a good idea. Have you looked for a mailing list 
or place in HL7 where you can make that proposal?

- thomas beale

Unable to express an unit of measurements in UCUM syntax

[Leonardo Moretti]

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
> 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.

Unable to express an unit of measurements in UCUM syntax

[Colin Sutton]

'...twopointseven', or ask the cardiologists to give the unit a name. "heartz"?

Regards,
Colin

On 29/04/2011, at 9:44 PM, "Ian McNicoll"  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?
> 
[...]
#
This e-mail message has been scanned for Viruses and Content and cleared 
by MailMarshal
#



IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be 
read or used by the named addressee. 
It is confidential and may contain legally privileged information. No 
confidentiality or privilege is waived or lost 
by any mistaken transmission to you. The CTC is not responsible for any 
unauthorised alterations to this e-mail or 
attachment to it. Views expressed in this message are those of the individual 
sender, and are not necessarily the 
views of the CTC. If you receive this e-mail in error, please immediately 
delete it and notify the sender. You must 
not disclose, copy or use any part of this e-mail if you are not the intended 
recipient.

#

Unable to express an unit of measurements in UCUM syntax

[Grahame Grieve]

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.

Grahame


On Fri, Apr 29, 2011 at 7:14 PM, Thomas Beale
 wrote:
>
> it is a pretty weird unit, since it is partway between 2-d and 3-d space,
> and therefore partway between the concept of 'area' and that of 'volume'. So
> whether it is acceptable depends on whether we think that such concepts are
> meaningful in the activity we call 'measurement' in the physical world.
> Probably there are weird units like this in quantum mechanics, or other
> esoteric mathematical spaces, so then it comes down to scope of UCUM -
> presumably not all of science, just physical measurement?
>
> Changing openEHR or HL7 to handle it probably would not be hard, but it
> might open up a can of worms, and also just plain annoyances, by allowing
> fractional dimensions (i.e. as soon as you start using floating point
> numbers for values that are almost always integers, computers struggle to
> get it right...).
>
> - thomas
>
> On 29/04/2011 01:48, Grahame Grieve wrote:
>
> Hi Leo
>
> Gunther says that these units are not proper units.
>
> http://www.xkaw.com/Education_Reference/Science_Mathematics.asp?id=2276318
>
> There's a possible question of scope alignment here. It's kind of tantamount
> to
> saying that a measure like that is not a proper measurement. I don't think
> I agree with that.
>
> To pursue the UCUM issue, you need to make at ticket at
> http://www.unitsofmeasure.org/
>
> I think that there's a tension here between the notion of purity from UCUMs
> point of view, and the use of UCUM in the measurement data types (PQ in
> HL7 v3 and DV_QUANTITY in openEHR - both have the same scope and the
> same usage of UCUM)
>
> Also see http://www.unitsofmeasure.org/wiki/ProcedureDefinedUnits
>
> Grahame
>
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>



-- 
-
http://www.healthintersections.com.au /
grahame at healthintersections.com.au / +61 411 867 065

Unable to express an unit of measurements in UCUM syntax

[Ian McNicoll]

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 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
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 

Unable to express an unit of measurements in UCUM syntax

[Thomas Beale]

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.
>
*
*
-- next part --
An HTML attachment was scrubbed...
URL: 

Unable to express an unit of measurements in UCUM syntax

[Grahame Grieve]

Hi Leo

Gunther says that these units are not proper units.

http://www.xkaw.com/Education_Reference/Science_Mathematics.asp?id=2276318

There's a possible question of scope alignment here. It's kind of tantamount to
saying that a measure like that is not a proper measurement. I don't think
I agree with that.

To pursue the UCUM issue, you need to make at ticket at
http://www.unitsofmeasure.org/

I think that there's a tension here between the notion of purity from UCUMs
point of view, and the use of UCUM in the measurement data types (PQ in
HL7 v3 and DV_QUANTITY in openEHR - both have the same scope and the
same usage of UCUM)

Also see http://www.unitsofmeasure.org/wiki/ProcedureDefinedUnits

Grahame



On Fri, Apr 29, 2011 at 9:20 AM, Grahame Grieve
 wrote:
> There's some question about whether such a funky unit is
> a proper unit. It does look rather like a statistical imagination
> to me, rather than an actual unit.
>
> I'm not sure where the right place to discuss this is. I'll let
> you know when I find out.
>
> Grahame
>
>
> On Fri, Apr 29, 2011 at 12:50 AM, Leonardo Moretti
>  wrote:
>>
>> Hi
>> there are a lots of scientific publications treating the indexations of left
>> ventricular mass (LVM).
>> I can link some abstracts, but the whole PDF documents are not public:
>> - http://www.nature.com/jhh/journal/v23/n11/full/jhh200916a.html
>> - http://www.ncbi.nlm.nih.gov/pubmed/11729247
>> or here
>> https://www.stanford.edu/group/ccm_echocardio/cgi-bin/mediawiki/index.php/Left_ventricle_wall_thickness
>>
>> It can be used to detect left ventricular hypertrophy.
>> You can google "mass/height^2.7" to find more references.
>>
>> Thanks for your help.
>> leo
>>
>>
>> Grahame Grieve-3 wrote:
>>>
>>> Hi Leo
>>>
>>> Can you please provide some references to show the use of height^2.7?
>>>
>>> Grahame
>>>
>>>
>>> On Thu, Apr 28, 2011 at 6:47 PM, Moretti Leonardo
>>>  wrote:
>>>> In cardiology, left ventricular mass (LVM) is often indexed to better
>>>> identify left ventricular hypertrophy.
>>>> Possible indexations are:
>>>> - LVM/BSA (body surface area)
>>>> - LVM/height
>>>> - LVM/height^2.7
>>>> The first and the latter are often used.
>>>> The units of measurement of the latter is usually g/m2.7
>>>> [gram/(meter^2.7)].
>>>>
>>>> In DV_QUANTITY, "units" attribute should be expressed in UCUM unit
>>>> syntax.
>>>> UCUM doesn't allow not integer exponent (see
>>>> http://aurora.regenstrief.org/~ucum/ucum.html#section-Syntax-Rules), so I
>>>> have the problem that I cannot express the units as g/m2.7.
>>>>
>>>> Any suggestion to solve this problem!?
>>>> Best regards
>>>> leo
>>>> ___
>>>> openEHR-technical mailing list
>>>> openEHR-technical at openehr.org
>>>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> -
>>> http://www.healthintersections.com.au /
>>> grahame at healthintersections.com.au / +61 411 867 065
>>> ___
>>> 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-tp31494533p31497302.html
>> Sent from the openehr-technical mailing list archive at Nabble.com.
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>
>
>
>
> --
> -
> http://www.healthintersections.com.au /
> grahame at healthintersections.com.au / +61 411 867 065
>



-- 
-
http://www.healthintersections.com.au /
grahame at healthintersections.com.au / +61 411 867 065

Unable to express an unit of measurements in UCUM syntax

[Thomas Beale]

it is a pretty weird unit, since it is partway between 2-d and 3-d 
space, and therefore partway between the concept of 'area' and that of 
'volume'. So whether it is acceptable depends on whether we think that 
such concepts are meaningful in the activity we call 'measurement' in 
the physical world. Probably there are weird units like this in quantum 
mechanics, or other esoteric mathematical spaces, so then it comes down 
to scope of UCUM - presumably not all of science, just physical measurement?

Changing openEHR or HL7 to handle it probably would not be hard, but it 
might open up a can of worms, and also just plain annoyances, by 
allowing fractional dimensions (i.e. as soon as you start using floating 
point numbers for values that are almost always integers, computers 
struggle to get it right...).

- thomas

On 29/04/2011 01:48, Grahame Grieve wrote:
> Hi Leo
>
> Gunther says that these units are not proper units.
>
> http://www.xkaw.com/Education_Reference/Science_Mathematics.asp?id=2276318
>
> There's a possible question of scope alignment here. It's kind of tantamount 
> to
> saying that a measure like that is not a proper measurement. I don't think
> I agree with that.
>
> To pursue the UCUM issue, you need to make at ticket at
> http://www.unitsofmeasure.org/
>
> I think that there's a tension here between the notion of purity from UCUMs
> point of view, and the use of UCUM in the measurement data types (PQ in
> HL7 v3 and DV_QUANTITY in openEHR - both have the same scope and the
> same usage of UCUM)
>
> Also see http://www.unitsofmeasure.org/wiki/ProcedureDefinedUnits
>
> Grahame
>
>
*
*
-- next part --
An HTML attachment was scrubbed...
URL: 

Unable to express an unit of measurements in UCUM syntax

[Grahame Grieve]

There's some question about whether such a funky unit is
a proper unit. It does look rather like a statistical imagination
to me, rather than an actual unit.

I'm not sure where the right place to discuss this is. I'll let
you know when I find out.

Grahame


On Fri, Apr 29, 2011 at 12:50 AM, Leonardo Moretti
 wrote:
>
> Hi
> there are a lots of scientific publications treating the indexations of left
> ventricular mass (LVM).
> I can link some abstracts, but the whole PDF documents are not public:
> - http://www.nature.com/jhh/journal/v23/n11/full/jhh200916a.html
> - http://www.ncbi.nlm.nih.gov/pubmed/11729247
> or here
> https://www.stanford.edu/group/ccm_echocardio/cgi-bin/mediawiki/index.php/Left_ventricle_wall_thickness
>
> It can be used to detect left ventricular hypertrophy.
> You can google "mass/height^2.7" to find more references.
>
> Thanks for your help.
> leo
>
>
> Grahame Grieve-3 wrote:
>>
>> Hi Leo
>>
>> Can you please provide some references to show the use of height^2.7?
>>
>> Grahame
>>
>>
>> On Thu, Apr 28, 2011 at 6:47 PM, Moretti Leonardo
>>  wrote:
>>> In cardiology, left ventricular mass (LVM) is often indexed to better
>>> identify left ventricular hypertrophy.
>>> Possible indexations are:
>>> - LVM/BSA (body surface area)
>>> - LVM/height
>>> - LVM/height^2.7
>>> The first and the latter are often used.
>>> The units of measurement of the latter is usually g/m2.7
>>> [gram/(meter^2.7)].
>>>
>>> In DV_QUANTITY, "units" attribute should be expressed in UCUM unit
>>> syntax.
>>> UCUM doesn't allow not integer exponent (see
>>> http://aurora.regenstrief.org/~ucum/ucum.html#section-Syntax-Rules), so I
>>> have the problem that I cannot express the units as g/m2.7.
>>>
>>> Any suggestion to solve this problem!?
>>> Best regards
>>> leo
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical at openehr.org
>>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>>
>>>
>>
>>
>>
>> --
>> -----
>> http://www.healthintersections.com.au /
>> grahame at healthintersections.com.au / +61 411 867 065
>> ___
>> 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-tp31494533p31497302.html
> Sent from the openehr-technical mailing list archive at Nabble.com.
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>



-- 
-
http://www.healthintersections.com.au /
grahame at healthintersections.com.au / +61 411 867 065

Unable to express an unit of measurements in UCUM syntax

[Grahame Grieve]

Hi Leo

Can you please provide some references to show the use of height^2.7?

Grahame


On Thu, Apr 28, 2011 at 6:47 PM, Moretti Leonardo
 wrote:
> In cardiology, left ventricular mass (LVM) is often indexed to better
> identify left ventricular hypertrophy.
> Possible indexations are:
> - LVM/BSA (body surface area)
> - LVM/height
> - LVM/height^2.7
> The first and the latter are often used.
> The units of measurement of the latter is usually g/m2.7
> [gram/(meter^2.7)].
>
> In DV_QUANTITY, "units" attribute should be expressed in UCUM unit syntax.
> UCUM doesn't allow not integer exponent (see
> http://aurora.regenstrief.org/~ucum/ucum.html#section-Syntax-Rules), so I
> have the problem that I cannot express the units as g/m2.7.
>
> Any suggestion to solve this problem!?
> Best regards
> leo
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>



-- 
-
http://www.healthintersections.com.au /
grahame at healthintersections.com.au / +61 411 867 065

Unable to express an unit of measurements in UCUM syntax

[Grahame Grieve]

hi Leo

I have forwarded this question onto the UCUM wizard (Gunther Schadow).
It's a pretty good question. Simply allowing the decimal would make the
syntax ambiguous, but there's no easy way to do it any other way.

Grahame


On Thu, Apr 28, 2011 at 6:47 PM, Moretti Leonardo
 wrote:
> In cardiology, left ventricular mass (LVM) is often indexed to better
> identify left ventricular hypertrophy.
> Possible indexations are:
> - LVM/BSA (body surface area)
> - LVM/height
> - LVM/height^2.7
> The first and the latter are often used.
> The units of measurement of the latter is usually g/m2.7
> [gram/(meter^2.7)].
>
> In DV_QUANTITY, "units" attribute should be expressed in UCUM unit syntax.
> UCUM doesn't allow not integer exponent (see
> http://aurora.regenstrief.org/~ucum/ucum.html#section-Syntax-Rules), so I
> have the problem that I cannot express the units as g/m2.7.
>
> Any suggestion to solve this problem!?
> Best regards
> leo
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>



-- 
-
http://www.healthintersections.com.au /
grahame at healthintersections.com.au / +61 411 867 065

Unable to express an unit of measurements in UCUM syntax

[Moretti Leonardo]

In cardiology, left ventricular mass (LVM) is often indexed to better identify 
left ventricular 
hypertrophy.
Possible indexations are:
- LVM/BSA (body surface area)
- LVM/height
- LVM/height^2.7
The first and the latter are often used.
The units of measurement of the latter is usually g/m2.7 [gram/(meter^2.7)].

In DV_QUANTITY, "units" attribute should be expressed in UCUM unit syntax. UCUM 
doesn't allow not 
integer exponent (see 
http://aurora.regenstrief.org/~ucum/ucum.html#section-Syntax-Rules 
), so I 
have the problem that 
I cannot express the units as g/m2.7.

Any suggestion to solve this problem!?
Best regards
leo
-- next part --
An HTML attachment was scrubbed...
URL: 

Unable to express an unit of measurements in UCUM syntax

[Leonardo Moretti]

Hi 
there are a lots of scientific publications treating the indexations of left
ventricular mass (LVM).
I can link some abstracts, but the whole PDF documents are not public:
- http://www.nature.com/jhh/journal/v23/n11/full/jhh200916a.html
- http://www.ncbi.nlm.nih.gov/pubmed/11729247
or here
https://www.stanford.edu/group/ccm_echocardio/cgi-bin/mediawiki/index.php/Left_ventricle_wall_thickness

It can be used to detect left ventricular hypertrophy.
You can google "mass/height^2.7" to find more references.

Thanks for your help.
leo


Grahame Grieve-3 wrote:
> 
> Hi Leo
> 
> Can you please provide some references to show the use of height^2.7?
> 
> Grahame
> 
> 
> On Thu, Apr 28, 2011 at 6:47 PM, Moretti Leonardo
>  wrote:
>> In cardiology, left ventricular mass (LVM) is often indexed to better
>> identify left ventricular hypertrophy.
>> Possible indexations are:
>> - LVM/BSA (body surface area)
>> - LVM/height
>> - LVM/height^2.7
>> The first and the latter are often used.
>> The units of measurement of the latter is usually g/m2.7
>> [gram/(meter^2.7)].
>>
>> In DV_QUANTITY, "units" attribute should be expressed in UCUM unit
>> syntax.
>> UCUM doesn't allow not integer exponent (see
>> http://aurora.regenstrief.org/~ucum/ucum.html#section-Syntax-Rules), so I
>> have the problem that I cannot express the units as g/m2.7.
>>
>> Any suggestion to solve this problem!?
>> Best regards
>> leo
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>
>>
> 
> 
> 
> -- 
> -
> http://www.healthintersections.com.au /
> grahame at healthintersections.com.au / +61 411 867 065
> ___________________
> 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-tp31494533p31497302.html
Sent from the openehr-technical mailing list archive at Nabble.com.