> Ingvar and Joe C., combined response here.
>
> About
>>>> 1 N.m = 1 N.m : true or false?
>
> 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?
>
> 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. (01)
In natural languages such creations are not confusing. Even though the
same word 'fast' is used both in talk of 'fast cars' and 'fast airplanes',
no one thinks that such cars and airplanes can move equally fast.
Similarly, no one ought to confuse 'nominal newton-meter' (a newton-meter
in name only) with a 'nominal scale' (a scale that uses names only). (02)
Ingvar (03)
>
> I describe how this could work below.
>
> 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.
>
> 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:
>
> Quantity {
> specificKindOfQuantity : KindOfQuantity;
> value : NumberAndUnit;
> }
>
> NumberAndUnit {
> number : REAL;
> unit : Unit;
> canonicalForm : NumberAndUnit;
> }
>
> Unit extends DimensionedQuantity {
> /*and adds*/ symbol : String;
> }
>
> DimensionedQuantity {
> number : REAL;
> dimension : VectorOfExponentsOverBaseUnits;
> }
>
> 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.
>
> Now, you can do or not do things with Quantity that you can or
> can not do with simple NumberAndUnit.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Yes, but the mapping is not inherent in the concept of Unit. It is
> in the Quantity.
>
> 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."
>
> 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.
>
> 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.)
>
> 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.
>
> yes, so you seem to agree with my design above. You write:
>
> Quantity {
> specificKindOfQuantity : KindOfQuantity;
> number: REAL;
> unit : Unit;
> }
>
> where I package NumberAndUnit for the Quantity.value:
>
> Quantity {
> specificKindOfQuantity : KindOfQuantity;
> value : NumberAndUnit;
> }
>
> NumberAndUnit {
> number : REAL;
> unit : Unit;
> }
>
> either way, you and I both seem to agree that specificKindOfQuantity is
> not inherent in or preserved by the Unit.
>
> 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.
>
> regards,
> -Gunther
>
>
>
> 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 :)
>
> --
> 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
>
> _________________________________________________________________
> 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
>
> (04)
_________________________________________________________________
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 (05)
|