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