Dear Chris, Pat and others, (01)
Alternative approaches
----------------------
I agree that the usefulness of reifing "particular quantities" is a
difficult issue. We could have the four objects: (02)
- physical object: Rod23
- particular quantity: length of Rod23
- magnitude of quantity: the length that is expressed as 1.3 metres
- quantity value: (1.3, metre) (03)
The object "magnitude of quantity" is not explicitly defined in the VIM, and
the implication is that when recording data according to the VIM only
"physical object", "particular quantity" and "quantity value" are required.
There is also Pat's view of the world in which there is a function hasLength
from the class of rods to the class of "length magnitude". (04)
I think that Chris's point about 3D/4D and change with time does not help us
make a choice. Introducing change with time, the four possible objects can
become five: (05)
- physical object: Rod23
- state of physical object: Rod23 at 2009-7-15T16:47
- particular quantity: length of Rod23 at 2009-7-15T16:47
- magnitude of quantity: the length that is expressed as 1.3 metres
- quantity value: (1.3, metre) (06)
We can still make use of Pat's hasLength function, provided that its domain
is now "state of rod". (07)
A different example
-------------------
My initial feeling was in line with Pat's - that there is little need for
reified instances of "particular quantity". Worrying about this, I
considered an example: (08)
Consider the supply of widgets. Widgets are supplied in identified batches
containing a finite number of identified widgets. If I have widget with
serial number X-1234, I can request an "observation" to determine its source
batch. I can define this observation as "determine the batch of widget
X-1234". When the observation has been carried out, the answer can be "the
batch of X-1234 is B-28". Naively we could say that we have the following
objects: (09)
- physical object: X-1234
- particular quantity: batch of X-1234
- magnitude of quantity: the batch that is identified as "B-28"
- quantity value: "B-28" (010)
The object "batch of X-1234" is a very useful one - it is specified as the
objective of an observation, and it can be reported that its value known or
unknown. However B-28 is a finite set and X-1234 is a member of it - this is
something very simple. (011)
There may be more to the object "batch of X-1234" than a reification of a
"type" statement. Perhaps it is more the reification of a query. (012)
How to go forward
-----------------
The initial statement of objects and relationships associated with
quantities and units has to include all the objects that people refer to -
especially where "people" is the BIPM. There is then a second phase of
producing useful ontologies for different purposes and with different
technical approaches. (013)
Best regards,
David (014)
At 08:53 15/07/2009 +0100, you wrote:
>Pat,
>
>> 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.
>
>It seems to me the substance of your argument is that it is not useful to
>re-ify these specific instances of quantitative properties, rather than you
>find it difficult to represent them. Is that right?
>
>My experience is different, in that I have found that systems often work
>more effectively if one does reify them. However, in a 4D ontology, this is
>just a matter of reifying the states that have the property (the specific
>property collapses into the state or that state being an instance of the
>general property). So, where an room undergoes a series of (step)
>temperature changes - it has a series of states that each are instances of
>their general temperature property.
>
>> 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 issue here is the old 3D/4D issue of change over time. If the stick /
>room undergoes changes over time then it does not have the length /
>temperature property simplicitur, it has it at a point or over a period of
>time. The representation example you give above does not cater for this.
>
>Representationally you can argue for an extra parameter in the
>representation or a reification of the states. When one starts builing
>systems that need to track changes over time, it is easier to take the
>reification option.
>
>Regards,
>Chris Partridge
>Chief Ontologist
>
>BORO Centre Limited
>Website: www.BOROCentre.com
>Registered in England No: 04418581
>Registered Office: 25 Hart Street, Henley on Thames,
>Oxfordshire RG9 2AR
>
>This email message is intended for the named recipient(s) only. It may be
>privileged and/or confidential. If you are not an intended named recipient
>of this email then you should not copy it or use it for any purpose, nor
>disclose its contents to any other person. You should contact BORO Centre
>Limited as shown above so that we can take appropriate action at no cost to
>yourself. All BORO Centre Limited outgoing E-mails are checked using Anti
>Virus software.
>
>> -----Original Message-----
>> From: uom-ontology-std-bounces@xxxxxxxxxxxxxxxx [mailto:uom-ontology-
>> std-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Patrick Cassidy
>> Sent: 15 July 2009 06:45
>> To: 'uom-ontology-std'
>> Subject: Re: [uom-ontology-std] retitled: magnitude of a quantity
>>
>> 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. 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).
>>
>> 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
>>
>
>
>_________________________________________________________________
>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
>
>
> (015)
============================================================
David Leal
CAESAR Systems Limited
registered office: 29 Somertrees Avenue, Lee, London SE12 0BS
registered in England no. 2422371
tel: +44 (0)20 8857 1095
mob: +44 (0)77 0702 6926
e-mail: david.leal@xxxxxxxxxxxxxxxxxxx
web site: http://www.caesarsystems.co.uk
============================================================ (016)
_________________________________________________________________
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 (017)
|