- From: Eisele, Fred <fred.eisele@eds.com>
- Date: Fri, 9 Jul 1999 16:35:42 -0400
- To: www-math@w3.org
Caveat: I will use the term "I" to mean either myself or someone I have
worked with
(but all the errors are, of course, mine ;-)
Goal: I want a "good" way to associate dimension (length, time, stress,
orientation, interval)
and an appropriate unit (meter, second, psi, ?, pico-second) with a
quantitative measure.
Background: I develop computer aided engineering (CAE) systems in the
domains of
fluid dynamics, heat transfer, noise, vibration, fatigue. I have
developed many
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
some domain
specific document type definitions. It have become apparent to me
(and obvious
to you) that most of the elements that I have defined are modeled
using some
mathematical construct. Nonetheless, the elements are certainly
not
mathematical objects. So, while I see clear benefit in making use
of MathML;
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
existing MathML
domain (I presume you will have a namespace (MathML?)). I would
further propose
that this initial domain be Newtonian physics (most of what I am
working on
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
dimension:
- angle: radian, degree,
- 3d-orientation: ?
Argument[1]: It has been proposed in the past that a domain could be
comprehended
simply by including the units along with a quantity.
e.g. <cn> 5 * days </cn> or <cn unit="day"> 5 </cn>
Response[1]: 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
the
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
seems silly.
Argument[2]: I can represent most of these things as mathematical objects
especially
things like angle (which can be expressed as a complex number of
magnitude 1),
or orientation which doesn't even have a proper unit and is
typically indicated
by a direction cosine which is just a 3x3 matrix.
Response[2]: Just because something can be represented as a complex number
does not mean it is a complex number; granted an element named
"force" isn't
really a force either but ...
Argument[N]: ?
Note: In the following samples I will show the name spaces but they could be
omitted.
(Go ahead rip them apart.)
Sample[1]: length is a dimension & belongs to a new namespace but unit is
not.
<physic:length><mathML:ci> x
<mathML:unit>meter</mathML:unit></physic:length>
Sample[2]: position is a dimension and the unit attribute is part of an
archetype
<physic:position unit="meter"
type="mathML:vector"><ci>5</ci><ci>6.7</ci>-5.2</ci><physic:position>
This representation includes a type which indicates a MathML
element.
Sample[3]: From the namespace recommendation < http://www.w3.org/TR/
<http://www.w3.org/TR/> REC-xml-names>sec.4
<x xmlns:edi='http://ecommerce.org/schema'>
<!-- the 'price' element's namespace is http://ecommerce.org/schema
<http://ecommerce.org/schema> -->
<edi:price units='Euro'>32.18</edi:price>
</x>
Sample[4]: Basically, this one doesn't work but maybe the germ of an idea.
<apply>
<dimension type="physic:length" unit="foot">meter</dimension>
<ci> x </ci>
<cn> 5 </cn>
<vector><ci>5</ci><ci>6.7</ci>-5.2</ci></vector>
</apply>
Received on Friday, 9 July 1999 16:36:28 UTC