Units, Dimension, Domain & playing nice with MathML (fwd)
strotman at nu.cs.fsu.edu
Wed Jul 14 20:41:09 CEST 1999
This thread appeared in the www-math mailing list the other day. Since
this is about extending MathML, and OpenMath is a/the designated extension
mechanism for MathML, but also because this particular topic did come up
in some discussions during the Eindhoven workshop, I'm taking the liberty
of forwarding the message to om at openmath.org.
PS: my apologies to those of us who are on both mailing lists.
---------- Forwarded message ----------
Date: Fri, 9 Jul 1999 16:35:42 -0400
From: "Eisele, Fred" <fred.eisele at eds.com>
To: www-math at w3.org
Subject: Units, Dimension, Domain & playing nice with MathML
Resent-Date: Fri, 9 Jul 1999 16:36:33 -0400 (EDT)
Resent-From: www-math at w3.org
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>
More information about the Om