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