Ingvar and Joe C., combined response here. (01)
About
>>> 1 N.m = 1 N.m : true or false? (02)
Ingvar writes:
> Can't you both cancel and preserve the difference? That is, can't you have
> both an over-arching concept 'nominal newton-meter' and a number of
> subsumed concepts such as 'energy newton-meter' and 'torque newton-meter';
> each of which brings in what VIM calls a kind-of-quantity? (03)
You could, although I would hope we would not call it "nominal newton-meter",
because the word "nominal" is used as a scale class "nominal - ordinal -
interval - ratio" and would be very confusing if also used as something
else in a field related to metrology. (04)
I describe how this could work below. (05)
Joe C. writes:
>> So, suppose I have two software applications that need to communicate and
>> I want to check if they would pass the same "type" of information to each
>> other.
>> I check on both sides and I find that they will exchange something of type
>> "R x N.m" (outer product of a Real and N.m). Is this sufficient to believe
>> that they will be exchanging like quantities?
>>
>> The answer is "Maybe". If you don't like multi-valued logic and prefer to
>> play it safe, then the answer is "No", particularly in this case because
>> torque and energy are sufficiently closely related that they may be easily
>> confused. (06)
Actually I believe the answer should be "don't count on it!" -- meaning,
you asked the wrong question. May be the best way to describe what I mean
is this. We have (essentially) in HL7 the following design: (07)
Quantity {
specificKindOfQuantity : KindOfQuantity;
value : NumberAndUnit;
} (08)
NumberAndUnit {
number : REAL;
unit : Unit;
canonicalForm : NumberAndUnit;
} (09)
Unit extends DimensionedQuantity {
/*and adds*/ symbol : String;
} (010)
DimensionedQuantity {
number : REAL;
dimension : VectorOfExponentsOverBaseUnits;
} (011)
As you can see in this, there is a difference between Quantity and
NumberAndUnit. NumberAndUnit does not preserve the specific kind of
quantity, only the dimension. But Quantity does preserve this. (012)
Now, you can do or not do things with Quantity that you can or
can not do with simple NumberAndUnit. (013)
For instance, for NumberAndUnit, 1 N.m = 1 N.m = 1 J always and without
any qualification. But if you have an ontology of mechanics, you can
tie that into the Quantity.specificKindOfQuantity, and it might
tell you that you can't compare a N.m of torque with a N.m of energy. (014)
On the opposite end, you may have an ontology of chemistry in there
which will tell you that you can equate 180 g/dL of Glucose mass
concentration with 1 mol/dL of Glucose substance concentration something
you would not have thought from just looking at the dimension. (015)
There is significant potential to create very powerful but also very
complex ontologies of kinds of quantity which would be used to
compute freely with Quantities. But this is not a matter of Units,
and the NumberAndUnit (or Quantity.value) computations and comparisons
would be much less powerful, just as DimensionedQuantities. (016)
Joe C continues:
>> The solution is then to use the additional mapping, "Kind", to distinguish
>> between torque and energy. (In my opinion, SI does NOT equate "N.m of
>> torque" with "N.m of energy", just N.m with N.m). In this case
>> Kind(torque)=torque and Kind(energy)=energy. (017)
Yes, but the mapping is not inherent in the concept of Unit. It is
in the Quantity. (018)
Ingvar's quote from the SI brochure is characteristic:
> Here comes the only passage where the SI brochure mentions 'torque' (pp.
> 119-20):
>
> "In practice, with certain quantities, preference is given to the use of
> certain special unit names, or combinations of unit names, to facilitate
> the distinction between different quantities having the same dimension.
> When using this freedom, one may recall the process by which the quantity
> is defined. For example, the quantity torque may be thought of as the
> cross product of force and distance, suggesting the unit newton metre, or
> it may be thought of as energy per angle, suggesting the unit joule per
> radian." (019)
it shows how little SI people think of formal computer processable
ontologies. It is always about what is "suggesting this" or "preference"
or "might be ambiguous" (when in fact it isn't.) It's all geared toward
humans writing things on paper for humans to read. That's why the field
where UCUM is in had been neglected by ISO and CEN and ANSI when they
allowed ISO 2955 to expire. (020)
But apart from this rant, SI people do not clearly impose on Units
the ability to preserve the kind of quantity. Not at all. They even
suggest here that 1 J can be used as the unit for torque (given that
in SI the angle is dimensionless and does not even have a symbol.) (021)
Joe C. continues
>> To support type-checking, my type needs to be
>> "R x Unit x Kind", where Kind represents the set of possible values that
>> that mapping can return. The types are the same if the Unit part AND the
>> Kind part are the same. (022)
yes, so you seem to agree with my design above. You write: (023)
Quantity {
specificKindOfQuantity : KindOfQuantity;
number: REAL;
unit : Unit;
} (024)
where I package NumberAndUnit for the Quantity.value: (025)
Quantity {
specificKindOfQuantity : KindOfQuantity;
value : NumberAndUnit;
} (026)
NumberAndUnit {
number : REAL;
unit : Unit;
} (027)
either way, you and I both seem to agree that specificKindOfQuantity is
not inherent in or preserved by the Unit. (028)
I am dropping the other examples from this thread. I mostly agree with
Joe and it would still be nice to collect a common list of these
examples on the Wiki so we can have a truly agreed scope. (029)
regards,
-Gunther (030)
PS: I removed the words "concept" from my text above so that I won't
give rise to anti-nominalists starting a battle against windmills :) (031)
--
Gunther Schadow, M.D., Ph.D. gschadow@xxxxxxxxxxxxxxx
Associate Professor Indiana University School of Informatics
Regenstrief Institute, Inc. Indiana University School of Medicine
tel:1(317)423-5521 http://aurora.regenstrief.org (032)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/uom-ontology-std/
Subscribe: mailto:uom-ontology-std-join@xxxxxxxxxxxxxxxx
Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/uom-ontology-std/
Shared Files: http://ontolog.cim3.net/file/work/UoM/
Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?UoM_Ontology_Standard (033)
|