- 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