Ron, Brian, Gerhard et al,
Gerhard- I read the papers. Wow :^) I'm impressed with the clarity &
detail.
Both of the discussions about my post (orientation & apples vs. oranges) are
valid, but perhaps out of scope. There are indeed variety of ways to
specify orientations & the closely related 'point transformations' of a
rigid body. My personal favorite is to use the 'bivector' notation used in
'Clifford algebras'. This elegant formalism has been applied in a variety
of fields from optics to quantum mechanics to orbital calculations. As you
may guess from the name 'bivector', this description of orientation does
work by specifying two points. However, I would be careful about
'inflicting' my somewhat eccentric tastes on others in the form of a
universal DTD :-) The point about the apples != oranges is also well taken,
the context is critical in determining if an operations if valid. (This is
why I chose apples and oranges, since the phrase 'you can't add apples to
oranges' comes to mind, at least for US readers.)
Dimensional analysis is a general technique that can be applied to any 'real
world' relation. Adding square feet to gallons is NEVER correct, you need
at least one conversion factor (as in the problem: I have an inch of water
in my basement. If my basement has 804 sq. ft., how many gallons of water
to I need to pump out? :-( ). But adding cubic feet to inch-acres is a
dimensionally valid operation. (As in: As I pumped out the basement, how
well did I irrigate my neighbor's garden - irrigation is often measured in
inch-acres of water.) The use of dimensional analysis has been invaluable
tool for a variety of scientific & engineering disciplines. I feel that it
should be considered in any universal scheme to describe units of measure.
A critical feature of any unit is to know what its 'dimensionality' is.
Garhard Freriks has written two well researched papers that carefully
discuss many issues that will be involved in determining an XML
microstandard to describe measurements and the units of measure. After
reading this paper, I highly recommend it to anyone else that is interested
in working on such a microstandard. My major suggestion would be to make
the 'dimensionality' a stronger feature in any system of units. In XML,
there should be an effort to determine a set of something like 'dimensional
groups' that have a set of 'basis vectors' like mass, length, time, charge.
Nearly all units encountered in science, engineering and commerce have a
dimensionality of the form mass^A1 *length^A2 *time^A3 *charge^A4. Thus, the
dimensionality units are located in an N-dimensional space. In any given
unit, most of the exponents are likely to be zero. Most commonly, the
exponents are integers in the range -4 < Ai < 4. There are examples of
units with non-integral exponents (square roots and the like) and number
outside of this range, but they are not as common. This 'dimensional
analysis' is discussed in Freriks' paper, but I would like to make this the
core of the standard, since it is truly universal and can be expressed in a
way that computers can readily utilize.
In summary, get the dimensionality correct is a necessary but certainly not
sufficient check of a measurement or a relationship between measurements.
Adding apples to oranges is dimensionally correct, but it may violate other
business rules. This sort of rule is dependent on the context, and is not
universal. Garhard Freriks has presented two papers that lay a foundation
to develop a robust XML microstandard for units of measure. This should be
of interest to this group, I would be happy to work with anyone on such a
standard. The standard should also involve representatives from groups like
NIST & ISO, since they are the 'keepers' of such standards.
Bob Folkerts
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 05, 2000 8:09 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: "Tower of Babel" or Bizcodes, UDEF (standard tag IDs)
Brian,
I believe you can also get orientation either from "angle" or by specifying
two "coordinates" in space.
Ron Schuldt
> ----------
> From: Brian Densmore[SMTP:[EMAIL PROTECTED]]
> Reply To: Brian Densmore
> Sent: Thursday, May 04, 2000 10:27 AM
> To: 'Ian Galbraith'; 'Folkerts, Robert';
> '[EMAIL PROTECTED]'
> Subject: RE: "Tower of Babel" or Bizcodes, UDEF (standard tag IDs)
>
> I would tend to agree.
> 5 Apples + 5 Oranges = 10 fruit. Is a high intelligence conclusion, very
> few
> digital computers would make that connection. I also agree that the 17
> property words are not mutually exclusive.
> Volume is just 3 dimension values. In fact 3 dimension values are
> preferable, after all if you want a container for your soda would you want
> to put it in a 16 oz. saucer or a 16 oz glass? There is one other word
> missing from the list:
>
> Orientation - a unit vector measurement from the center of the base in the
> direction of the top of the object.
>
> A very useful property if you want to pour soda into a glass, or put up
> architecture.
>
> Brian Densmore
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Ian Galbraith
> Sent: Thursday, May 04, 2000 3:42 AM
> To: Folkerts, Robert; [EMAIL PROTECTED]
> Subject: Re: "Tower of Babel" or Bizcodes, UDEF (standard tag IDs)
>
>
> >5 apples + 5 oranges would be ok since both are 'counts'
>
> Really? I would disagree with that fundamentally. 5 fruit items + 5
> fruit
> items = 10 fruit items; OK. But I cannot imagine that any
> supplier/purchaser of fruit would be too happy to receive apples instead
> of
> oranges.
>
> Not a trivial point, I suggest.
>
>
> Ian Galbraith
>
> -----Original Message-----
> From: Folkerts, Robert <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Date: 04 May 2000 04:11
> Subject: RE: "Tower of Babel" or Bizcodes, UDEF (standard tag IDs)
>
>
> >Oh well, here I go again...
> >
> >I disagree that this list is complete or mutually exclusive. There are
> only
> >a few basic physical quantities that can be tracked. they are:
> > mass,
> > length,
> > time,
> > electrical charge,
> > temperature.
> >Charge doesn't appear on your list. A rigorous physicist may even argue
> >that time and length are redundant ( 1 nanosec = 30 cm, more or less) and
> >that temperature is just an energy per particle, angles are just numbers
> >(measured in radians, of course). This would drop us down to mass,
> length
> >and charge. The physicist would then add 'exotic' measures like charm
> and
> >strangeness for completeness.
> >
> >The quantities listed (above)will provide us with the building blocks to
> >specify the dimension of any physical quantity.
> > area = length^2 ( hence the list is not mutually exclusive)
> > volume = length^3
> > energy = mass *length^2/(time^2)
> > electrical potential = energy / charge
> > specific heat capacity = energy/(mass * temperature)
> > speed = length/time
> > weight = force = mass * length / time^2
> > pressure = force / area = mass / (length^2 * time^2)
> > etc ...
> >Any commonly encountered physical quantity can be reduced to the list of
> >five basic quantities in the first list. I would agree that adding
> angle,
> >amount (capital), and quantity (count) are also useful as we move beyond
> >the physicist's set of units. I will accept the 'text', 'identifier' and
> >'code' types as they have been proven useful.
> >
> >I would like to generalized the unit type 'rate' has been replaced by the
> >exponents to which the 'fundamental' units have been raised.
> >
> >I find the coordinate type problematic. This is a rather different
> concept
> >(component of vector vs. scalar) than dimensional analysis. It is
> clearly
> >important to take this into account at a low level, but the choice of
> >coordinate values depends upon coordinate system. This is more like a
> >'collection' than a dimensional type.
> >
> >We must also specify a measure and a unit for any physical quantity. This
> >idea is tied to the difference between 'time' and 'date'. Both are
> measures
> >of time, but they use different units. By sticking with 'time' fewer
> types
> >are needed. We do need to be able to convert between various 'units'
> >(seconds, hours, days) of the same 'quantity' (time).
> >
> >In short, I feel that XML should be used to specify measured quantities
> in
> >terms of a number and a unit. The 'unit' should be tied to a underlying
> >'dimensional group'. Measurements with the same 'dimensional group' may
> be
> >added ( 10 seconds + 100 days is ok since both are time, 5 USD + 10 FF is
> ok
> >since both are money, 10 pounds + 10 Kg is wrong since force is not mass,
> 5
> >apples + 5 oranges would be ok since both are 'counts'). Computers can
> be
> >programmed to multiply units & manage dictionaries of standard units ( so
> >that you see force in 'Newtons' rather than Kg m /s^2.) Based on locale
> and
> >other aspects of the context, you could even change the display of a
> >quantity to suit the user.
> >
> >This is indeed a great place for an XML 'microstandard'.
> >
> >Bob Folkerts
> >
> >-----Original Message-----
> >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> >Sent: Monday, May 01, 2000 11:58 AM
> >To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> >Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> >[EMAIL PROTECTED]
> >Subject: RE: "Tower of Babel" or Bizcodes, UDEF (standard tag IDs)
> >
> >
> >David, XML/EDI list,
> >
> >The 17 property words of DoD 8320.1-M-1 were carefully selected over the
> >course of many years within DoD's data administration function. This list
> of
> >17 words appears to enable semantics conflict resolution in the simplest
> >manner. By forcing any data element concept (see ISO/IEC 11179 Part 1 for
> a
> >definition) to a common starting point (one of 17 properties) it appears
> to
> >be a viable way of aligning data element concepts that are semantically
> >equal but have been assigned different names.
> >
> >It has been my experience within industry and shared by those within the
> DoD
> >data administration function that the 17 property words are intuitive,
> >mutually exclusive, and seemingly exhaustive. The committee I chaired
> within
> >the CALS Industry Steering Group was tasked with defining a means for
> >integrating the data within the enterprise. The UDEF was the result.
> >
> >The 17 UDEF property words (class words within DoD 8320.1-M-1) are as
> >follows:
> >
> >* Amount - A monetary value.
> >* Angle - The rotational measurement between two lines and/or planes
> >diverging from a common point and/or line.
> >* Area - The two dimensional measurement of a surface expressed in
> >unit squares.
> >* Code - A combination of one or more numbers, letters, or special
> >characters substituted for a specific meaning.
> >* Coordinate - One of a set of values which identifies the location of
> >a point.
> >* Date - The notation of a specific period of time.
> >* Dimension - A one dimensional measured linear distance.
> >* Identifier - A combination of one or more numbers, letters, or
> >special characters which designates a specific object and/or entity, but
> has
> >no readily definable meaning.
> >* Mass - The measure of inertia of a body.
> >* Name - A designation of an object and/or entity expressed in a word
> >or phrase.
> >* Quantity - A nonmonetary numeric value.
> >* Rate - A quantitative expression that represents the numeric
> >relationship between two measurable units.
> >* Temperature - The measure of heat in an object.
> >* Text - An unformatted character string generally in the form of
> >words.
> >* Time - A notation of a specified chronological point within a
> >period.
> >* Volume - A measurement of space occupied by a three dimensional
> >figure.
> >* Weight - The force with which an object is attracted toward the
> >earth and/or other celestial body by gravitation.
> >
> >Based on experience, it appears that any data element concept property
> can
> >be mapped into one of these 17 property words. For example, velocity is a
> >type of "rate" and part number is a type of "identifier"
> >
> >Ron Schuldt
> >
> >
> >
> >
> >
> >> ----------
> >> From: David RR Webber[SMTP:[EMAIL PROTECTED]]
> >> Sent: Monday, May 01, 2000 9:53 AM
> >> To: INTERNET:[EMAIL PROTECTED]
> >> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> >> [EMAIL PROTECTED]
> >> Subject: RE: "Tower of Babel" or Bizcodes, UDEF (standard tag IDs)
> >>
> >> Message text written by INTERNET:[EMAIL PROTECTED]
> >> >
> >> The UDEF naming convention conforms to the requirements of ISO/IEC
> 11179
> >> and
> >> uses the same 17 property words (class words) as those specified by DoD
> >> 8320.1-M-1. Each data element within DoD's data dictionary (based on
> DoD's
> >> Enterprise-wide Data Model) uses one of the 17 property words. Each
> data
> >> element within MIL-STD-2549, Configuration Management Data Interface
> was
> >> named based on the UDEF naming convention. See Appendix C to
> MIL-STD-2549
> >> at
> >> http://www.acq.osd.mil/io/se/cm&dm/cm&dm_pubs.htm
> >> <<<<<<<<<<<<<
> >>
> >> Ron,
> >>
> >> Perhaps it would clarify if you could pen some lines on the purpose
> behind
> >> the
> >> idea of having 17 property words - and how this is applicable more
> >> generally?
> >>
> >> Obviously in a global context you can translate the 17 words into local
> >> usage.
> >>
> >> As we wrestle with the issues of BPR and Core Components within ebXML,
> >> I'm seeing the top down can often get very confusing for the lay person
> -
> >> or
> >> someone who just understands the business domain - but not the
> >> technobabble!
> >>
> >> I'm always trying to distill out what will work at the bottom up - so
> that
> >> the two
> >> world can co-exist without tripping each other up. The Army seems to
> >> avoid
> >> words at all cost afterall - its that A317-B12 you are needing, etc!
> >>
> >> At the end of the day some Army Quartermaster has to understand how his
> >> warehouse is organized, and where that actual physical part really is!
> >>
> >> DW.
> >>
> >>
> >
> >==========================================
> >XML/EDI Group members-only discussion list
> >Homepage = http://www.xmledi.org
> >
> >Brought to you by: Online Technologies Corporation
> > Home of BizServe - www.bizserve.com
> >
> >TO UNSUBSCRIBE: Send email to <[EMAIL PROTECTED]>
> > Leave the subject blank, and
> > In the body of the message, enter ONLY: unsubscribe
> >
> >Questions/requests should be sent to: [EMAIL PROTECTED]
> >To join the XML/EDI Group complete the form located at:
> >http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
> >
> >
> >
> >==========================================
> >XML/EDI Group members-only discussion list
> >Homepage = http://www.xmledi.org
> >
> >Brought to you by: Online Technologies Corporation
> > Home of BizServe - www.bizserve.com
> >
> >TO UNSUBSCRIBE: Send email to <[EMAIL PROTECTED]>
> > Leave the subject blank, and
> > In the body of the message, enter ONLY: unsubscribe
> >
> >Questions/requests should be sent to: [EMAIL PROTECTED]
> >To join the XML/EDI Group complete the form located at:
> >http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
> >
> >
>
>
> ==========================================
> XML/EDI Group members-only discussion list
> Homepage = http://www.xmledi.org
>
> Brought to you by: Online Technologies Corporation
> Home of BizServe - www.bizserve.com
>
> TO UNSUBSCRIBE: Send email to <[EMAIL PROTECTED]>
> Leave the subject blank, and
> In the body of the message, enter ONLY: unsubscribe
>
> Questions/requests should be sent to: [EMAIL PROTECTED]
> To join the XML/EDI Group complete the form located at:
> http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
>
>
> ==========================================
> XML/EDI Group members-only discussion list
> Homepage = http://www.xmledi.org
>
> Brought to you by: Online Technologies Corporation
> Home of BizServe - www.bizserve.com
>
> TO UNSUBSCRIBE: Send email to <[EMAIL PROTECTED]>
> Leave the subject blank, and
> In the body of the message, enter ONLY: unsubscribe
>
> Questions/requests should be sent to: [EMAIL PROTECTED]
> To join the XML/EDI Group complete the form located at:
> http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
>
>
==========================================
XML/EDI Group members-only discussion list
Homepage = http://www.xmledi.org
Brought to you by: Online Technologies Corporation
Home of BizServe - www.bizserve.com
TO UNSUBSCRIBE: Send email to <[EMAIL PROTECTED]>
Leave the subject blank, and
In the body of the message, enter ONLY: unsubscribe
Questions/requests should be sent to: [EMAIL PROTECTED]
To join the XML/EDI Group complete the form located at:
http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
==========================================
XML/EDI Group members-only discussion list
Homepage = http://www.xmledi.org
Brought to you by: Online Technologies Corporation
Home of BizServe - www.bizserve.com
TO UNSUBSCRIBE: Send email to <[EMAIL PROTECTED]>
Leave the subject blank, and
In the body of the message, enter ONLY: unsubscribe
Questions/requests should be sent to: [EMAIL PROTECTED]
To join the XML/EDI Group complete the form located at:
http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
