OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

unitsml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: FW: UnitsML query


UnitsML TC,
More info on the topic.    -Bob

-----Original Message-----
From: Robert Muetzelfeldt [mailto:r.muetzelfeldt@ed.ac.uk] 
Sent: Wednesday, June 09, 2010 5:48 AM
To: Dragoset, Robert A.
Subject: Re: UnitsML query

Dear Bob,

Given the imminence of the TC meeting, I have looked a bit more into 
UnitsML. I now see (e.g. from slide 15 of 
http://unitsml.nist.gov/Presentations/UnitsML_for_TC.pdf, 2006), that a 
<physQuant> element has an @units, which is therefore (being an XML 
attribute) always an atomic term. Using the UnitsML "meta" approach, 
this is then defined in a compound way using a UnitsML <Unit> element 
with (in the example case) two <UnitRepresentation> child elements. As I 
understand it, the definition of the atomic @units can either be local 
or in the UnitsML database.

Slide 10 of 
http://unitsml.nist.gov/Presentations/UnitsML-Santa-Fe-2003.ppt gives a 
similar example, but this time uses a <units> child element for 
<physicalQuantuty>, rather than an @units attribute, and asks the 
question: "Why not use MathML to mark up these?". I am wondering what 
the answer to that question is within the UnitsML TC?

To be honest, it is the ability of MathML-for-Units to express units 
directly as a compound term (rather than as an atomic term which needs 
to be defined elsewhere) that I find very attractive, with the added 
bonus that MathML allows any term in the MathML expression to be 
supplemented with a <semantics> element, which seems to provide 
everything needed for 'semantic units' out of the box. The big downside 
of MathML-for-Units (as far as I am concerned) is that it seems to be 
moribund, whereas UnitsML is very much alive, but I have to balance that 
against the fact that (as I understand it) UnitsML seems to be based on 
the definition of potentially a very large number (through combinatorial 
explosion) of atomic units definitions, something which would simply not 
occur using MathML-for-Units.

Perhaps a possible solution is to have <units> as a child element of 
<physQuant>/<physicalQuantity> (rather than an attribute), and to allow 
its content to be (as one option) a MathML-for-Units expression?

It's no doubt clear that I have no technical expertise in this area, but 
I am an interested potential user and promoter of UnitsML (we are 
currently developing a web-based portal for crop models, and the 
question of how to represent units is central to this). I'd be happy to 
comment on any proposals from the TC if that would be helpful.

Best wishes,
Robert


Dragoset, Robert A. wrote:
> Dear Robert,
>
> We're having a UnitsML TC meeting tomorrow and I was planning on bringing up the issue that you address below to discuss with the TC members. I'll send additional comments to you after that meeting.
>
> We're somewhat "between a rock and a hard place" regarding the SI. Whereas NIST strongly supports the adoption of the SI, it is obvious that the U.S. uses units not recommended for use within the SI. UnitsML is designed to be a usable schema that is not restricted by the SI. For this reason we've adopted "counted items" being represented as "units". I'll probably relax the wording in the Guidelines regarding use of units not specifically allowed within the SI. Being in the U.S., I'm not always aware to what extent other countries have adopted the SI. It's interesting to me that in practice your community uses a representation that I suspect would not be strictly allowed for use within the SI.
>
> The Guidelines is very much a draft document. One of the items we'll be discussing in the meeting tomorrow is the location of various pieces of schema documentation: in the Guidelines vs. in the schema. 
>
> Sincerely,
> Bob Dragoset
>
>
> Robert A. Dragoset, physicist
> Physics Laboratory
> National Institute of Standards and Technology
>
> NIST
> 100 Bureau Drive, Stop 8400
> Gaithersburg, MD 20899
> Phone: 301-975-3718
> Email: dragoset@nist.gov
> Website: http://physics.nist.gov
>
>
> -----Original Message-----
> From: Robert Muetzelfeldt [mailto:r.muetzelfeldt@ed.ac.uk] 
> Sent: Friday, June 04, 2010 3:39 PM
> To: Dragoset, Robert A.
> Subject: UnitsML query
>
> Dear Robert,
>
> I'm involved in a project which aims to build a web-based repository of 
> ecological and environment models, all marked up using an XML-based 
> language. We use MathML for the equations, and are now turning our 
> attention to the representation of the units for the model variables.
>
> Within our community, there are a number of attempts to develop standard 
> ontologies for the units of data and/or model variables, but almost all 
> of these use long atomic names for units (e.g. 'metres_per_second') for 
> units. This is of course a dead end.
>
> I am aware of units handling in Systems Biology modelling (e.g. CellML, 
> SBML). These groups have come up with their own bespoke representations 
> for units. I understand that this is precisely the type of situation 
> which has motivated the formation of the UnitsML group.
>
> I have looked at MathML for Units. While I am naturally drawn to this, 
> because of my experience of working with MathML and because of what sem 
> to be nice features (such as the use of semantics and annotation-xml 
> elements, the initiative seems to be moribund, with no sourev of basic 
> unit definitions etc.
>
> I am pleased to see that the UnitsML group seems to be still active, 
> although some of the material (e.g. the - undated - "Guidelines for the 
> Use of Units Markup Language, Draft Version 0.4.2") seems very 
> incomplete, with various emailed comments included in the text.
>
> I am, however, concerned with a paragraph in the Guidelines which 
> address an issue of considerable importance to my community. You state 
> (page 5):
> "/For example, the expression emission rate = 1.36 e/s, where 'e' 
> represents electron, treats 'electron' as a unit. The correct expression 
> should be electron emission rate = 1.36 s-1, or electron emission rate = 
> 1.36 /s. Even though the UnitsML schema allows for the inclusion of 
> unique items as units, this practice is strongly discouraged and is not 
> acceptable usage in the SI/."
> It is very common in our community to qualifier terms within a units 
> expression in some way, e.g. 'plant_weight = 5.2 kg(carbon) m-2'. Maybe 
> the correct approach is to re-express this as 'plant_weight_as_carbon = 
> 5.2 kg m-2'. But then we have variables in our models which involve all 
> sorts of ratios, e.g. kg(carbon)/kg(nitrogen), and it would be both 
> difficult, if not impossible, to capture all such cases unambiguously in 
> the variable name.
>
> I would like some guidance on this issue, which promoses to be of 
> considerable importance across the whole field of biological, ecological 
> and environmental research, but I'm not sure how whom to turn to or in 
> what forum to discuss this. Can you give me some advice on how to proceed?
>
> Many thanks,
> Robert Muetzelfeldt
>
> Honorary Fellow,
> School of Informatics,
> University of Edinburgh
> and
> Research Director,
> Simulistics Ltd
> htttp://www.simulistics.com
>
>
>
>
>
>
>
>   


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]