David Leal wrote: (01)
> Alternative approaches
> ----------------------
> I agree that the usefulness of reifing "particular quantities" is a
> difficult issue. (02)
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. (03)
> 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) (04)
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. (05)
> 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". (06)
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). (07)
> 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". (08)
Yes. (09)
> 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" (010)
This is simply wrong. I don't believe that B-28 is a quantity value.
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. (011)
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. (012)
> 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. (013)
And unrelated to the issue. (014)
> 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. (015)
I agree with this, but I'm not sure how it relates to the issue Pat C
raised: (016)
>>> 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. (017)
I think this is an open question. To some extent, it comes down to the
philosophical approach used to derive the concepts. (018)
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. 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'. (019)
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. (020)
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) (021)
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) (022)
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. (023)
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. (024)
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. (025)
-Ed (026)
--
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 (027)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (028)
_________________________________________________________________
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 (029)
|