Pat, (01)
> 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. (02)
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? (03)
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. (04)
> 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. (05)
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. (06)
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. (07)
Regards,
Chris Partridge
Chief Ontologist (08)
BORO Centre Limited
Website: www.BOROCentre.com
Registered in England No: 04418581
Registered Office: 25 Hart Street, Henley on Thames,
Oxfordshire RG9 2AR (09)
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. (010)
> -----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
> (011)
_________________________________________________________________
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 (012)
|