Units, Dimension, Domain & playing nice with MathML
Subject: Units, Dimension, Domain & playing nice with MathML
From: "Eisele, Fred" <email@example.com>
Date: Fri, 9 Jul 1999 16:35:42 -0400
From firstname.lastname@example.org Fri Jul 9 16: 36:28 1999
Caveat: I will use the term "I" to mean either myself or someone I have
(but all the errors are, of course, mine ;-)
Goal: I want a "good" way to associate dimension (length, time, stress,
and an appropriate unit (meter, second, psi, ?, pico-second) with a
Background: I develop computer aided engineering (CAE) systems in the
fluid dynamics, heat transfer, noise, vibration, fatigue. I have
proprietary (and brittle) document types over the years. I wish to
do away with
as much of this as possible. To this end I have been working on
specific document type definitions. It have become apparent to me
to you) that most of the elements that I have defined are modeled
mathematical construct. Nonetheless, the elements are certainly
mathematical objects. So, while I see clear benefit in making use
it is also clear that domain specific elements are required.
Proposal: I propose hat we start a thread to discuss the nature of the
interaction between a
new domain (tentatively represented by a namespace) and the
domain (I presume you will have a namespace (MathML?)). I would
that this initial domain be Newtonian physics (most of what I am
is based on this domain). I couldn't find a physicsML.
The principle dimensions could therefore be:
- mass: kg, slug, lb., carat, ...
- distance: meter, foot, parsec, angstrom
- time: second, millennium, day
- force: Newton, lbf
- energy: erg, watt
- temperature: Kelvin, degree Fahrenheit
It may also be necessary to treat geometry first, in particular the
- angle: radian, degree,
- 3d-orientation: ?
Argument: It has been proposed in the past that a domain could be
simply by including the units along with a quantity.
e.g. <cn> 5 * days </cn> or <cn unit="day"> 5 </cn>
Response: There is no association with a domain.
There is no indication of the dimension. It may be argued that
the dimension is
inferred by the unit but this is not so. e.g. Kelvin may be
either an absolute
temperature or a temperature range. It may be tempting to include
dimension as well as the unit.
e.g. <cn> 5 * pico-second(distance)</cn>
But, creating such a (hard to parse) beast when all the XML tools
are at hand
Argument: I can represent most of these things as mathematical objects
things like angle (which can be expressed as a complex number of
or orientation which doesn't even have a proper unit and is
by a direction cosine which is just a 3x3 matrix.
Response: Just because something can be represented as a complex number
does not mean it is a complex number; granted an element named
really a force either but ...
Note: In the following samples I will show the name spaces but they could be
(Go ahead rip them apart.)
Sample: length is a dimension & belongs to a new namespace but unit is
Sample: position is a dimension and the unit attribute is part of an
This representation includes a type which indicates a MathML
Sample: From the namespace recommendation < http://www.w3.org/TR/
<!-- the 'price' element's namespace is http://ecommerce.org/schema
Sample: Basically, this one doesn't work but maybe the germ of an idea.
<dimension type="physic:length" unit="foot">meter</dimension>
<ci> x </ci>
<cn> 5 </cn>