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

Re: [uom-ontology-std] retitled: magnitude of a quantity

To: uom-ontology-std <uom-ontology-std@xxxxxxxxxxxxxxxx>, "Patrick Cassidy" <pat@xxxxxxxxx>
From: Pat Hayes <phayes@xxxxxxx>
Date: Wed, 15 Jul 2009 09:10:36 -0500
Message-id: <B7E89A2A-EDDF-4319-9306-DCE5C5216B55@xxxxxxx>

On Jul 15, 2009, at 12:44 AM, Patrick Cassidy wrote:    (01)

> Just a comment on one point:
>
>>>
>>> I notice that Pat Hayes uses 'dimension' for 'kind of quantity'.
>>
> [Pat Hayes] > I did, but I think 'kind of quantity' is better. So I  
> will use
> that
>> from now on. So, to check my understanding, the following are kinds  
>> of
>> quantity: lengths, masses, weights, tensile strengths, time
>> durations, .... The KOQ Length is a class (or class-like thing, ie
>> something with members or instances) whose instances are particular
>> lengths, such as the distance from the earth to the moon, the width  
>> of
>> my left third finger, a light year, etc., all thought of in a pre-
>> measure-unit way. In general, all the elements of a given KOQ are
>> numerically comparable, so that for any two of them A, B, there is
>> some number N such that A is N*B. (Or maybe we need to generalize
>> number here to some ordering scale, I'm not sure about that.)
>>
>
> The OUM ontology that was mentioned by Geoff Williams uses the term
> 'Dimension' to refer to the class of measures that have the same  
> units.  In
> an ontology I prefer to reserve that terms for the more general  
> sense of
> 'dimension' in which case the 'dimension' of units of measure might be
> labeled as 'MeasurementDimension'.  I have preferences, by am readily
> agreeable to adopting any terminology agreed to by whatever  
> community is
> using the terms.  I merely state my preference here.
>
> The more substantive issue is whether we want to have a class  
> representing
> the specific instances of quantitative properties (length of a  
> particular
> stick, temperature of a particular room at some particular time,  
> etc.),
> inasmuch as (even though they are logically distinguishable entities -
> called 'tropes' in some treatments), I have never been able to find  
> a way to
> use them to good effect.  When I want to assert that a stick has some
> particular length, I assert, e.g. (in SUMO SKIF notation) (hasLength  
> Rod23
> (meters 1.3)) where 'meters' is used as a function.    (02)

Then you have just answered your own question:-). If this is a  
function, it must have a range which is the class of its possible  
values. Those are the particular lengths.    (03)

>  The notation is
> unimportant; the point is that what is asserted is the generic  
> numerical
> length value, which is the same instance of length value as any  
> other object
> may have, e.g. (hasWidth FatMan35 (meters 1.3)).  What is used is the
> generic value of some measurable quantity, and the fact that a  
> particular
> object has that measure is the subject of an assertion, not an  
> instance of a
> class.    (04)

The fact is an assertion, but the length itself is a member of a  
class. It is in fact the class
{x : (exists ((n Number))(= x (meters n))) }    (05)

Pat H    (06)

>  When we want to refer to the length of a particular object as a
> term in some other assertion (e.g. a comparison of lengths), we can  
> define
> or generate a function related to the assertion that returns a value  
> of
> length, such as 'TheLengthOf' and in the above case (TheLengthOf  
> Rod23) =
> (TheWidthOf FatMan35) = (meters 1.3).
>
> In COSMO I use three distinguishable basic types related to  
> Attributes:
>  (1) type 'AttributeType' (similar to 'Dimension' but including  
> qualitative
> (e.g. Color) as well as quantitative attribute types);
>  (2) type 'AttributeValue', including subtype  
> 'QuantitativeAttributeValue'
> instances of which are measures such as 'N1.3_Meters' (in SUMO  
> (meters 1.3))
> or  'N37_DegreesC' (in SUMO (DegreesC 37)), but also including  
> qualitative
> attribute values (such as RedColor); and
>  (3) type 'Attribute', each instance of which is a structure that  
> specifies
> both the AttributeType and the AttributeValue (such as  
> Length_1.3Meters or
> Color_RedColor).
>
> The UnitsOfMeasure are actually included as subtypes of
> QuantitativeAttributeValue, using the SUMO convention that each
> UnitOfMeasure is actually just a Measure with an implied numerical  
> value of
> 1.  The last type 'Attribute' is not essential, being constructed  
> from other
> types, but in an OWL environment without higher-arity relations, can  
> be a
> convenient alternative to defining multiple relations, one for each
> Dimension (or AttributeType).  In this usage, the numerical portion  
> of each
> quantitative attribute value is just a real number which is one of the
> elements of the attribute value, together with the UnitOfMeasure.  So,
> rather than the four measure-related classes that Pat Hayes  
> suggests, it
> seems adequate to make do with two (Real numbers being defined  
> elsewhere,
> and tropes ignored), or three (if one wants a class like the COSMO
> 'Attribute' including both the AttributeType (Dimension) and actual
> measurement).
>
> Beyond the choice of what basic classes (types) we would like to  
> represent
> measures, there is the issue of how to handle the inevitable  
> inaccuracy of
> measurement.  This is important for very basic issues such as  
> whether we
> want to say that Mr X is as tall as Mr. Y.  If X is 1.3 meters tall  
> and Y is
> measured at 1.31 meters, we need to know the error range, and the
> probability of difference used as the criterion for measures being  
> actually
> different.  One possible convention is that used in sciences, where,  
> if no
> explicit error range is mentioned, it is assumed that the standard  
> deviation
> is about one unit in the last reported decimal place.  (This  
> convention is
> not always followed, and ridiculous apparent accuracies may be  
> reported).
> But that can be left until after the more fundamental issues of how to
> represent UOMs and measures is resolved, since the error range can  
> probably
> be appended to the basic structure.
>
> The OUM ontology (download link at:
> http://www.atoapps.nl/foodinformatics/index.asp) has more detail  
> than the
> NASA SWEET sciUnits ontology, and may be a good base from which to add
> whatever is needed to include all other units or units-related  
> things that
> others want.
>
> Pat
>
>
> Patrick Cassidy
> MICRA, Inc.
> 908-561-3416
> cell: 908-565-4053
> cassidy@xxxxxxxxx
>
>
>> -----Original Message-----
>> From: uom-ontology-std-bounces@xxxxxxxxxxxxxxxx [mailto:uom-ontology-
>> std-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Pat Hayes
>> Sent: Tuesday, July 14, 2009 10:29 PM
>> To: edbark@xxxxxxxx; uom-ontology-std
>> Subject: Re: [uom-ontology-std] retitled: magnitude of a quantity
>>
>>
>> On Jul 14, 2009, at 5:52 PM, Ed Barkmeyer wrote:
>>
>>> David Leal wrote:
>>>
>>>> This is good progress.
>>>
>>> Thanks, but real progress would be if we had captured chapter and
>>> verse
>>> from various reference documents and put this someplace.
>>>
>>>> You say:
>>>>> But what is important is that there are 4 distinct concepts:
>>>>> - particular quantity = a physical instance to be quantified
>>>>> - kind of quantity = a category of comparable particular  
>>>>> quantities
>>>>> - magnitude of quantity = an abstract quantification of particular
>>>>> quantities
>>>>> - quantity value = the expression of a magnitude as a number and a
>>>> measurement unit (where the number is the ratio of the magnitude to
>>>> the unit)
>>>>
>>>> Probably we need to look at two "kinds of quantity":
>>>> - categories such as that which includes Ed Barkmeyer's height,
>>>> width of the
>>>> Thames at London Bridge, the diameter of the earth's orbit;
>>>> - categories such as that which includes ultimate tensile strength,
>>>> yield
>>>> strength in tension, yield strength in compression (all are
>>>> stresses).
>>>
>>> If I understand you right, yes.
>>
>> Can anyone elaborate on the distinction here? I don't follow it.
>>
>>> There is a set of categories that are
>>> 'kinds of quantity', such that all instances of any 'kind of
>> quantity'
>>> category are comparable and no pair of instances from two different
>>> kinds of quantity are comparable.
>>
>> Why the second requirement? If length and width are different
>> quantities (why not?) they are nevertheless comparable.
>>
>>> There are other categories that must
>>> be subclasses of the 'kinds of quantity' (each of which is a
>>> subclass of
>>> the general category 'quantity'), which is your second bullet.   
>>> (As I
>>> mentioned in the email to Martin, these might be "roles" instead of
>>> subclasses.  I don't know.
>>
>> I think subclass vs. role vs. property is a function of the  
>> underlying
>> formalism we decide to use. I can transcribe everything into CLIF or
>> IKL in any case, whatever we decide.
>>
>>> )
>>>
>>> I notice that Pat Hayes uses 'dimension' for 'kind of quantity'.
>>
>> I did, but I think 'kind of quantity' is better. So I will use that
>> from now on. So, to check my understanding, the following are kinds  
>> of
>> quantity: lengths, masses, weights, tensile strengths, time
>> durations, .... The KOQ Length is a class (or class-like thing, ie
>> something with members or instances) whose instances are particular
>> lengths, such as the distance from the earth to the moon, the width  
>> of
>> my left third finger, a light year, etc., all thought of in a pre-
>> measure-unit way. In general, all the elements of a given KOQ are
>> numerically comparable, so that for any two of them A, B, there is
>> some number N such that A is N*B. (Or maybe we need to generalize
>> number here to some ordering scale, I'm not sure about that.)
>>
>>> I
>>> think the VIM also uses the term 'dimension', but I can't recall  
>>> what
>>> meaning VIM assigns to it.
>>
>> It would make sense to allow each KOQ to have an associated  
>> dimension,
>> but the association be many-one, so that length, width, distance,  
>> etc.
>> all are different KOQs but all associated with the one physical
>> dimension, which is spatial distance. But that requires relaxing the
>> 'incomparable with other kinds' restriction you mention above. NOt
>> sure about this.
>>
>> Pat
>>
>>
>>>
>>> -Ed
>>>
>>> --
>>> Edward J. Barkmeyer                        Email: edbark@xxxxxxxx
>>> National Institute of Standards & Technology
>>> Manufacturing Systems Integration Division
>>> 100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
>>> Gaithersburg, MD 20899-8263                FAX: +1 301-975-4694
>>>
>>> "The opinions expressed above do not reflect consensus of NIST,
>>> and have not been reviewed by any Government authority."
>>>
>>> _________________________________________________________________
>>> 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
>>>
>>>
>>>
>>
>> ------------------------------------------------------------
>> IHMC                                     (850)434 8903 or (650)494  
>> 3973
>> 40 South Alcaniz St.           (850)202 4416   office
>> Pensacola                            (850)202 4440   fax
>> FL 32502                              (850)291 0667   mobile
>> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>>
>>
>>
>>
>>
>>
>> _________________________________________________________________
>> 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
>>
>
>
> _________________________________________________________________
> 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
>
>
>    (07)

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes    (08)






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

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