Ed, (01)
The following point near the end of your note is critical: (02)
EB> Being careful, 'tolerance' and 'uncertainty' are entirely
> different things, as I mentioned in a previous email. Tolerance
> is the allowable variance from the specified quantity, where that
> difference allows the measured object to meet the functional and
> physical requirements; uncertainty is the amount by which the
> measurement may be different from the actual magnitude of the
> quantity. In complying with a tolerance, one has to ensure that
> the worst case measurement error gives a value that is still
> within the tolerance. (03)
This distinction is related to the difference between science
and engineering. Uncertainty is inevitable in both. Tolerance
is an engineering constraint on the permissible variance in the
construction of some artifact. (04)
EB> The problem is that the scientific usage and the commercial
> usage are significantly different in this area. (05)
It depends entirely on what commercial application your talking
about. Does your company make meat balls or ball bearings?
Many commercial applications "push the envelope" to the extremes
of science, and others can be done with stone-age technology. (06)
EB> I would prefer that the units of measure ontology not go deeply
> into 'measurement' at all. My point was that 'measurement' is
> the meat of the VIM, and that affects its way of modeling 'quantity'. (07)
If you're making meat balls, you're not going to use high-precision
instruments. But if you're making silicon chips, all the issues
of measurement are critical. Both applications are commercial. (08)
Even if you restrict the range of applications to a single domain,
such as medicine, you have to accommodate everything from a nurse
measuring a patient's height to high-precision instruments for
microsurgery. (09)
EB> We use the value "180cm" in practice, as if there were a
> 'quantity magnitude' to which it refers. It is not clear to me
> that the VIM agrees that there is one. (010)
Ordinary language, even among engineers and scientists, typically
omits any details that are not in the immediate focus of attention.
But that doesn't mean that the speakers are ignoring the details. (011)
If and when the details are significant, the engineers are certainly
aware of them. The VIM document, for example, was largely written
by and for engineers. They wouldn't have devoted so much attention
to the details if they weren't relevant to their "day jobs". (012)
To return to a theme I've discussed many times before: (013)
1. Even for a particular field or industry, there is a wide
range of applications that treat the same subjects and topics
at many different levels of detail and precision. (014)
2. The details necessary at the most precise level are usually
omitted in broader discussions or contexts. (015)
3. Therefore, there is no such thing as a one-size-fits-all
ontology, even for a particular field or enterprise. (016)
4. But all the people in the field or enterprise have to
talk to one another, at least at some broad level. (017)
5. Therefore, the upper levels of the ontology will resemble
terminologies with very few detailed axioms. But there
will have to be families of microtheories that axiomatize
those details for each of the tasks and applications. (018)
John (019)
_________________________________________________________________
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 (020)
|