Please allow me to make a comment on dimensions and measures in OUM (from the
forthcoming concept paper): (01)
Units of measure and quantities have a dimension. Dimensions are abstract
properties of units and quantities neglecting their vectorial or tensorial
character and all numerical factors including their sign. Dimensions can be
expressed as the products of powers of base quantities of a system of units. (02)
The above is mainly based on Cohen, E.R. and Giacomo, P. (1987): Symbols,
units, nomenclature and fundamental constants in physics. 1987 revision.
Document I.U.P.A.P.-25 (SUNAMCO 87-1). International Union of Pure and Applied
Physics, SUNAMCO Commission. (03)
Hope this helps. (04)
Regards, Hajo (05)
________________________________ (06)
Van: uom-ontology-std-bounces@xxxxxxxxxxxxxxxx namens Patrick Cassidy
Verzonden: wo 15-7-2009 7:44
Aan: 'uom-ontology-std'
Onderwerp: Re: [uom-ontology-std] retitled: magnitude of a quantity (07)
Just a comment on one point: (08)
> >
> > 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.)
> (09)
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. (010)
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. 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. 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). (011)
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). (012)
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). (013)
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. (014)
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. (015)
Pat (016)
Patrick Cassidy
MICRA, Inc.
908-561-3416
cell: 908-565-4053
cassidy@xxxxxxxxx (017)
> -----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
> (018)
_________________________________________________________________
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 (019)
<<winmail.dat>>
_________________________________________________________________
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 (01)
|