>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
