Robert,
You have raised some good questions and concerns. I'll attempt to address
each as follows:
> 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.
>
As I previously stated, the list of 17 properties appeared to be exhaustive.
I was allowing for the possibility that it was not complete. Fortunately,
you identified electrical charge (Coulomb) and the document from Gerard also
identified luminous intensity (candela) as base units that need to be added
to the list of 17 properties which I would suggest should now be 19. As an
item of note, the document from Gerard lists "plane angle" as a base unit in
addition to those you identified plus luminous intensity.
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.
>
Since length ("dimension" in the UDEF list) is a base unit it cannot be
simply raised to a power to obtain the desired result. For example, you do
not obtain the desired result for "area" by simply squaring one of the two
lengths of a non-square rectangle.
> I would like to generalized the unit type 'rate' has been replaced by the
> exponents to which the 'fundamental' units have been raised.
>
With regard to your "pressure" example, it can be determined by at least two
different ratios (rates within the UDEF). Which of the two is the correct or
standard one? I would suggest that they are both equally correct. The DoD
approach in 8320.1-M-1 was to use the property "rate" to address any
quantity that included any type of ration (numerator and denominator). The
way that "rate" is further qualified is to use "pressure" or "velocity" or
"acceleration" as types of rate (i.e., velocity rate, acceleration rate,
pressure rate, percentage rate, etc.).
> 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.
>
I agree with everything you stated and most importantly that coordinate has
no meaning unless the coordinate system is explicitly defined (e.g.,
latitude, longitude, etc.).
> 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).
>
I realize that DoD' 8320.1-M-1's definition of "date" is somewhat
misleading. An example instance of date is July 4, 1776. An example instance
of time is 12:31 PM. As stated in an earlier message and which requires
further clarification, a period of time is a "quantity" which is further
qualified by the word time. Therefore, a period of time is a "time quantity"
which can be measured in any of the units desired - years, months, days,
hours, etc.
> 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.
>
>
I am in the process of updating the UDEF to accommodate units of measure as
they apply to dimensional groups. The intent is to allow for an optional
units of measure extension to the UDEF that would be intelligent and only
list those units of measure applicable to the property string selected. For
example, the UDEF property string "velocity rate" - would list both English
and Metric options such as miles/hour, feet/second, kilometers/hour,
meters/second, etc.).
Ron Schuldt
> ----------
> From: Folkerts, Robert[SMTP:[EMAIL PROTECTED]]
> Reply To: Folkerts, Robert
> Sent: Wednesday, May 03, 2000 8:57 PM
> To: [EMAIL PROTECTED]
> 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
>
>
==========================================
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
