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

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

To: edbark@xxxxxxxx, uom-ontology-std <uom-ontology-std@xxxxxxxxxxxxxxxx>
From: Pat Hayes <phayes@xxxxxxx>
Date: Thu, 16 Jul 2009 05:03:39 -0500
Message-id: <EE89E240-3F23-4368-BABE-2BC30D56E66C@xxxxxxx>

On Jul 15, 2009, at 5:17 PM, Ed Barkmeyer wrote:    (01)

> David Leal wrote:
>
>> Alternative approaches
>> ----------------------
>> I agree that the usefulness of reifing "particular quantities" is a
>> difficult issue.
>
> The issue is whether the generic concept 'particular quantity' should
> appear in the ontology.  My position, which matches David's  
> conclusion,
> is that we should keep the generic concept, in order to distinguish it
> from others, at least until we know that we don't have a use for it.
>
>> We could have the four objects:
>>
>> - 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)
>
> And we have the object "length", which is a 'kind of quantity'  (or a
> 'dimension'), and thus a subtype of 'particular quantity' to which the
> 'length of Rod23' belongs.  We need that object, because it also  
> applies
> to the 'diameter of Rod23', which is a different property, but a
> comparable one.
>
>> 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".
>
> But we need the concept 'magnitude of quantity' to relate "equivalent"
> quantity values:  (1.3, metre) and (51.2, inch) refer to the same
> instance of 'length magnitude'.  And, as Pat H pointed out, 'magnitude
> of quantity' is the range of the property "hasLength": (thing) has
> length (magnitude).
>
>> 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:
>>
>> - 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)
>>
>> We can still make use of Pat's hasLength function, provided that  
>> its domain
>> is now "state of rod".
>
> Yes.
>
>> 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:
>>
>> 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:
>>
>> - 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"
>
> This is simply wrong.  I don't believe that B-28 is a quantity value.    (02)

Agreed. This is about mereology: a batch sounds like a mereological  
sum, or perhaps simply a set of things. Either way, not (directly) to  
do with dimension and units.    (03)


> And it is not clear from the description that 'batch of X-1234' is a
> particular quantity.  This "batch" is not an amount that can be
> referenced to a unit; it is rather a specific grouping of things.
>
> A "batch" (1) could be a quantity, e.g., a "batch" of chocolate is 100
> litres; a "batch" of nails is 50 kg; and a "batch" of widgets is 192
> "count" (or "each").  But a "batch" (2) that is a scheduled named unit
> of product is a physical object whose size is 1 "batch" (1).  The  
> _name_
> of batch B-28 is "B-28".  The _size_ of batch B-28 is "1 batch" or  
> "192
> count".  And the "size of batch B-28" is a particular quantity.
>
>> 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.
>
> And unrelated to the issue.
>
>
>> 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.
>
> I agree with this, but I'm not sure how it relates to the issue Pat C
> raised:
>
>>>> 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.
>
> I think this is an open question.  To some extent, it comes down to  
> the
> philosophical approach used to derive the concepts.
>
> The VIM begins with the idea that there such physical properties as  
> the
> length of a given stick.  This is the philosophical concept  
> "property":
> something intrinsic in the individual stick.    (04)

Careful. Im not sure that the VIM requires tropes. The phrase "length  
of a given stick" can be understood as referring to a trope - in which  
case, the length of a given stick A is *never* the same as the length  
of another stick B, even when they are the same length - or it can be  
taken to refer to a property in the normal sense, the way I was  
suggesting - in which case, to say that A and B have the same length,  
you simply equate their particular lengths. I vote for the second.    (05)

PatH    (06)

>  It then derives an
> abstraction that is the class of all such properties, and it calls  
> that
> class "quantity".  Then it goes to its intent: the idea in the VIM  
> is to
> quantify these properties -- give each "a number with respect to a
> reference."  And that takes us to 'kinds of quantities' and  
> 'magnitudes
> of quantities' and 'measurement units' and 'quantity values'.
>
> So the concept is important in peeling the onion.  Pat's point is that
> it is not necessarily important in cooking with the peeled onion.
>
> Once we have the abstraction that is 'magnitude of quantity', we can
> re-model the original intrinsic properties as binary relations:
>   (thing) 'has <subtype of quantity>' (magnitude)
>
> Then we can define 'quantity values', each of which represents a  
> unique
> 'magnitude'.  And this allows us to recast the original property  
> once more:
>   (thing) 'has <subtype of quantity>' (quantity value)
>
> And this is the familiar model that is in common use.
> Pat's point is that if this is where we want to end up, we may not  
> need
> to have a class in the ontology whose instances (the original
> properties) are now modeled as reifications of these propositions.   
> And
> I agree that this is a worthwhile question.
>
> My position, for the nonce, is that it helps us to have all the  
> concepts
> that trace the VIM approach.  Following Mark Linehan's observation, it
> keeps us from becoming confused about the different possible  
> meanings of
> 'quantity'.  But when we reach the stage of defining the normative
> ontology, we may find it useful to lose some of the concepts that were
> simply on the analysis path, rather like first-stage rockets.
>
> The VIM goes on to deal with the fact that we cannot know the truth of
> any such proposition.  We must measure the (thing) to yield a  
> (quantity
> value) and the measurement process itself introduces "uncertainty".
> Whether our ontology is to go there, and if so, how far, is a separate
> question for the WG.
>
> -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
>
>
>    (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>