Ed, (01)
I certainly agree with that point: (02)
EB> Tolerance is an external constraint. It is an "engineering
> constraint" (03)
And the whole purpose of this exercise is to support applications.
That is technically known as 'engineering'. So the UoM should
have sufficient slots and hooks to support engineering. (04)
EB> Most commercial usage, however, is not very scientific. Of
> course, there are some highly scientific commercial applications,
> and yes, they are very sensitive to measurement issues. (05)
Certainly. We must support both. That support must be compatible
with the level of detail and precision that the applications use. (06)
EB> So the ontology must be correct with respect to arbitrary
> applications, which means we have to understand "tolerance".
> The question is: how deeply do we go into "measurement" and
> "uncertainty"? (07)
For applications that fry potato chips, shallow. (08)
For applications that fabricate silicon chips, deep. (09)
That would probably require two versions: UoM deep and UoM shallow. (010)
EB> Measurement science is not about the requirements; it is about
> the nature and quality of the measurements themselves. (011)
Right, and we are developing engineering ontologies for a wide
range of applications that have very different requirements
for the amount and precision of the scientific details. (012)
EB> This is where the ontological rubber meets the "commercial" road. (013)
I agree. But I would add that there is no single commercial road.
Instead, it's a world-wide collection of commercial enterprises
ranging from pushcart vendors on the street to high-tech industries
on the information super highway. (014)
EB> A common scientific and engineering practice is to state a
> measured value as a "scientific number", that is, to the least
> decimal place of uncertainty. (015)
That's a very useful default. But when it's critical, the value
is usually stated explicitly. (016)
EB> So if our ontology is going to be correct at both ends of this
> spectrum, we need to be really careful about the terminology and
> the definitions, and we will definitely be breaking some eggs.
> The alternative, as John has proposed, is to develop two or more
> "microtheories" for different "usage patterns". (017)
Deleting axioms can never introduce an inconsistency, but adding
axioms is much more likely to create an inconsistency. Therefore,
my recommendation is to start with the full-blown theory with
all the qualifications. Then the light versions can be derived
by deleting distinctions and axioms. (018)
EB> Which axioms should be omitted at the highest level? (019)
If by highest you mean most general, I have been recommending
an upper level that is essentially a terminology augmented
with a type hierarchy: (020)
1. That terminology would have all the words and mutliword phrases
from VIM and/or other sources that are considered significant
for the UoM. (021)
2. Each term would have the minimal number of properties and
hasPart relations that are common to all uses. (022)
3. The type-subtype relations could then be derived automatically
by Formal Concept Analysis (FCA). That method creates a lattice
(multiple inheritance) that is guaranteed to be consistent with
the definitions in points #1 and #2. (023)
The next issue would be to link this very sparsely axiomatized
hierarchy to (a) upper level ontologies such as OpenCyc or others
and (b) detailed microtheories such as UoM deep and shallow. (024)
One way to do that is to consider the type UnitOfMeasurement in
the general hierarchy to be a supertype of several different
specializations. Under it could be UoM_shallow, UoM-deep,
UoM_OpenCyc, UoM_Dolce, etc. (025)
That approach creates a very bushy hierarchy, in which the term
UnitOfMeasurement (and every other term in the ontology) is
many ways ambiguous. The next step is to find ways of relating
or even identifying some of the ambiguous subtypes. (026)
For example, if UoM_shallow is derived by deleting axioms from
UoM_deep, some terms won't occur in UoM_shallow. But for every
term that occurs in both, the UoM_deep term is guaranteed to be
a subtype of UoM_shallow. (027)
In order to accommodate all other ontologies, we should certainly
consider all suggestions from any knowledgeable source. But the
official standard can't be expected to resolve all inconsistencies
in every ontology under the sun. I would recommend: (028)
1. The UoM developers (this group and associates) should consider
all reasonable suggestions from knowledgeable practitioners. (029)
2. But this group has to take the ultimate responsibility for
developing the general hierarchy and the UoM deep and shallow. (030)
3. The general hierarchy should define supertypes for all terms
in both the deep and shallow ontologies. It will be organized
as a lattice and tested for consistency by the FCA methodology. (031)
4. The deep ontology will have every term in the shallow ontology
plus some additional terms that are not in the shallow ontology. (032)
5. Every term in the shallow ontology will be a supertype of some
term in the deep ontology and a subtype of some term in the
general hierarchy. (033)
6. Every term in the deep ontology will be a subtype of some term
in the general hierarchy. (034)
7. The UoM developers should try to be as consistent as possible
with the VIM document and with all the ontologies in widespread
use (such as OpenCyc, DOLCE, SUMO, BFO, WordNet, and any others
that may be considered). But since many of those sources are
inconsistent with one another, the UoM cannot reconcile the
irreconcilable. It will have to make choices that simplify and
systematize the overall structure while having a considerable
amount of compatibility with any broad consensus that emerges. (035)
EB> And what is a "magnitude"? (Which takes us back to the question
> of whether the 'quantity kind' "length" refers to a subclass of
> 'particular quantity' or to a subclass of 'quantity magnitude'.) (036)
My attitude toward axioms is based on the refrigerator principle: (037)
When in doubt, throw it out. (038)
If you leave the ontology underspecified or you omit words that
aren't absolutely necessary, you reduce the chances of being
inconsistent with other systems that have made other definitions. (039)
In short, I would avoid defining terms that are not absolutely
necessary for the applications we need to support. The deep
ontology will have more details that are not in the shallow
version, but neither one should use words that are not necessary
for applications that require units of measure. (040)
John (041)
_________________________________________________________________
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 (042)
|