uom-ontology-std
[Top] [All Lists]

Re: [uom-ontology-std] What is mass?

To: uom-ontology-std <uom-ontology-std@xxxxxxxxxxxxxxxx>
From: Gunther Schadow <gschadow@xxxxxxxxxxxxxxx>
Date: Fri, 02 Oct 2009 10:43:17 -0400
Message-id: <4AC61185.4020202@xxxxxxxxxxxxxxx>
Matthew West wrote:
> Dear Pat,
> 
>> On Sep 29, 2009, at 4:27 PM, Gunther Schadow wrote:
>>
>>> An object may have the property "maximum allowable temperature"
>>>
>>> That object would also have the property "actual temperature" at
>>> any point in time.
>>>
>>> The object might never have the property "actual temperature"
>> whose
>>> quantity value is equal to its property  "maximum allowable
>>> temperature".
>>>
>>> Either way, maximum allowable temperature and actual temperature
>>> are both special kinds of temperatures.
>> Exactly.
> 
> MW: Then I ask you how I know when I look at a temperature whether it is
> a maximum allowable one or not.    (01)

Mathew, you are catching up. Some discussion on this "direct" vs.
"indirect" property (names that I don't necessarily subscribe to)
has been had and maximum allowable operating temperature is of 
course different from actual temperature (I will repost my model
of this below.) But first ...    (02)

I find it curious how you, Matthew, can say "how [do] I know when 
I look at a temperature whether it is maximum allowable or not?"
-- well, my questions are:    (03)

 (a) how do you "look at a temperature"?
 (b) how do you "look at" just any property?
 (c) how do you assume that, even if you could "look at" some
     property in one way or the other, that you could see
     everything you might need to know to understand it?    (04)

I think that even if you could somehow perceive temperature by 
looking at it (tongue in cheek: I do not suppose you mean looking
at symbols that express a temperature, right?), then there is 
no guarantee that you would find all important context, just like
when you look at an apple you can't know whether it is poisonous,
and even if "looking" means "examining directly in any way", 
you could not know whether that apple came from a farm that 
employs indentured child labor.    (05)

All these discussions about "direct" and "indirect" properties 
and "real" and imaginative temperatures are terribly interesting,
but I think they should have little impact on the actual UoM
ontology. For in the end, UoM do not say what has been measured,
and how a temperature is real or imagined. For the purpose of 
UoM, both real or imagined, direct or indirect temperatures are
all temperatures, for how else could you compare a real temperature
to an imaginary one?    (06)

Thanks, and I am posting a revision of my HL7 conceptual models 
below that account for this "maximum operating temperature" issue.    (07)

regards,
-Gunther    (08)



= Real and Imagined Quantities: Maximum Allowable Temperature =    (09)

"Maximum allowable temperature" is the upper bound of the 
"operating temperature" interval, which in turn is a criterion over
the actual temperature property. The way we handle such things in 
HL7 is like this:    (010)

"Maximum temperature = 40 degree Celsius" is     (011)

Measurement (criterion)
  of quantity /core temperature/
  at time /any time/
  has value (*;40] /degree Celsius/    (012)

Notice that I have interpolated "core temperature" for just 
"temperature" because this distinction would be necessary
to know.    (013)

"Actual temperature 25 degree Celsius" is     (014)

Measurement (actual) 
  of quantity /core temperature/
  at time 2009-09-30T15:05
  has value [24.5;25.5] /degree Celsius/    (015)

"Actual temperature 43 degree Celsius" is     (016)

Measurement (actual)
  of quantity /core temperatue/ 
  at time 2009-09-30T15:15
  has value [42.5;43.5] /degree Celsius/    (017)

Comparison between a criterion and an actual quantity is done by
comparing whether the actual quantity is included in the criterion.
That way one can also define other criteria, such as     (018)

"Alarm temperature at > 35 degree Celsius"    (019)

Measurement (criterion)
  of quantity /core temperature/
  at time /any time/
  has value [35;*) /degree Celsius/    (020)

The difference between the 2 criteria is how they are related to
other information. For example, operating temperature would be 
related to the operation act that the machine performs whereas
alarm temperature would be related to the alarm action:    (021)

Act "to operate properly"
  isPerformedBy Machine X
  hasThroughCondition Measurement (criterion) for "operating temperature range"    (022)

Act "to raise alarm"
  isPerformedBy TemperatureMonitor 
  hasSubject Machine X
  hasTriggerCondition Measurement (criterion) for "alarm temperature"    (023)

so a lot of these notions of "indirect properties" is in my view
best modeled by additional structures. But nevertheless one can 
always define a property as a primitive to stand for such a complex
model. E.g.,    (024)

"Maximum operating temperature of Machine X" :=
  the high boundary of
    the range value of
      the Measurement (criterion)
        of quantity /core temperature/
        which is a throughCondition of
          the act of /operating properly/
            performed by 
              the Machine X.    (025)

If we avoid such "indirect properties" with such models, there are
then fewer true "direct properties" left, such as /core temperature/.
However, you still have multiple temperatures, such as     (026)

 - core temperature
 - surface temperature
   - measured by holding a thermometer close to the shell
   - measured by an attached thermometer (using heat transfer creme)    (027)

To push this a little further now, let's model "Maximum allowable
ambient temperature". The trick: the actual ambient temperature is 
never going to be a property *of* the machine, but of it's vicinity,
which is related to, but not part of the machine.     (028)

So, "Maximum allowable ambient temperature" is the upper bound of the 
"operating ambient temperature" interval, which in turn is a criterion 
over the actual ambient temperature of the machines environment for 
the machine to operate properly.     (029)

The model for "Maximum ambient temperature = 35 degree Celsius" hinges 
on the following criterion:    (030)

Measurement (criterion)
  of quantity /air temperature/
  at time /any time/
  has value (*;35] /degree Celsius/
  hasSubject Environment E
    contains Machine X    (031)

But that's not true: Machine X could be stored in different temperature
range, we're missing "operating properly":    (032)

Act A "to operate properly"
  isPerformedBy Machine X
  hasThroughCondition Measurement (criterion) for "operating temperature range"
  hasThroughCondition Measurement (criterion) for "ambient temperature range"
  hasLocation Environment E    (033)

So, putting this together:    (034)

"Maximum ambient temperature of Machine X" :=
  the high boundary of
    the range value of
      the Measurement (criterion)
        of quantity /air temperature/
        hasSubject Environment E
          which isLocationOf Act A /to operate properly/
            which isPerformedBy Machine X
        which is a throughCondition of said Act A    (035)

But in any case, ambient temperature, core temperature, surface
temperatures, maxiumum operating core temperature, minimum
operating ambient temperature, etc. etc. are all temperatures.
Their quantity value, which I consider a DimensionedQuantity 
are all comparable without limitations (the quantities are only
comparable under certain conditions, but their quantity values
are all comparable. The units are only a part of the 
quantity value notation, for a DimensionedQuantity. To recall:    (036)

Measurement {
  mood : Mood (i.e., actual vs. criterion)
  specificKindOfQuantity : KindOfQuantity;
  value : QuantityValue;
  subject : SubjectOfMeasurementWhichIsAPhysicalThingOrProcess
}    (037)

all the detail context is in Measurement, and most, if not all
constraints about comparability come from it. QuantitValue is 
much, much simpler:    (038)

QuantityValue is-a DimensionedQuantity {
  /*and adds*/ specificUnit : Unit;
}    (039)

DimensionedQuantity {
  number : REAL;
  dimension : VectorOfExponentsOverBaseUnits;
}    (040)

Unit extends DimensionedQuantity {
  /*and adds*/ symbol : String;
}    (041)

two QuantityValues are equal in the same way that two 
DimensionedQuantity instances are equal, i.e., if they have
the same number and dimension (regardless of specific 
unit, for 100 cm = 1 m.)    (042)

A Unit is merely a DimensionedQuantity that has been chosen
by convention and has been given a name.     (043)

-- 
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    (044)

_________________________________________________________________
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    (045)

<Prev in Thread] Current Thread [Next in Thread>