Anders Tell wrote (of CCTS): (01)
>> In comparison with other ontological technologies one can
>> observe that it has significantly less formalism (if any at all),
>> less rigor, less expressiveness, less researched foundation,
>> fewer critical reviews, etc. (02)
I fully agree with this, but there may be more problem in the practice
than in the concept. One can attach rigorous definition to clear and
well thought out natural language taxonomies. One problem with CCTS is
that the current libraries repeat the confusion in certain concepts that
was created by some bad taxonomic decisions in EDIFACT 20 years ago.
The further problem is the assumption that an entity is an amalgam of
all the attributes assigned to it by uncoordinated groups with different
viewpoints. In most cases, the concept in the union of all the
viewpoints has a population on which none of viewers would agree, and
the intersection is empty. The CCTS proposed solution is a mechanism
for defining a viewpoint ("context") as a surface in a discrete
8-dimensional space, in which four of the dimensions are themselves
undefinable. (03)
> In comparison with technologies
> such as UML2, OWL, DL, CL, KIF, IKL etc. one can easily see CCTS
> limitations and in some cases awkwardness. It *looks* like them
> but the rigor is not there. (04)
In UML2, the rigor is largely of a different kind, but yes. (05)
Some wag described CCTS as "a formal mechanism designed to support reuse
of data elements by careful disagreement on the concepts". (06)
John Sowa wrote:
> For most applications, a *terminology* of words and phrases used
> in the domain is extremely important. Adding more axioms to
> make the definitions more precise can be counterproductive. (07)
Experience teaches that this is true, but less often true than its
antithesis -- that axioms can clarify what otherwise passes for
definitions. At issue is whether the definitions are accidentally or
intentionally ambiguous. (08)
> The reason is (or should be) obvious:
>
> 1. Most people who enter data or read the reports are not lawyers
> or logicians. (09)
Yes. In practice, this means that they lack the discipline to read the
definitions of the terms used, and have no hesitation about adding their
own assumptions about those terms. The question is whether the person
who has the job to review the practice and guide those people has that
discipline. (010)
> 2. Using logic or legalese with all the qualifications spelled out
> in excruciating detail makes the definitions unintelligible to
> most of the people who use the terms. (011)
Absolutely. And yet, financial accounting, public law, OSHA guidelines,
ISO 9000 practices do exactly this in excruciating detail. That is why
organizations have experts who create the procedures that guarantee
conformance. (012)
> 3. If most common occurrences fall within the precise definitions,
> the data entered by the users will be correct most of the time. (013)
This is true only with the word "precise" before "definitions". Most
definitions in exchange standards are not "precise" in the sense that
you can clearly determine whether a particular thing qualifies or
doesn't. In my experience, differences in business practices and
engineering practices cause the same general concept to have importantly
different implementations in different businesses. And teams of experts
making the standards are often unwilling to tighten the definitions
enough to _reveal_, let alone _mandate_, assumptions about the
practices. So what is "most common" to one will not be the same as what
is "most common" to another. And when they must work together, the
assumption that what is "most common" to US is also "most common" to
THEM is often incorrect -- THEIR center may prove to be OUR outlier. (014)
> 4. But for items that fall close to one or another extreme case
> specified by the formal definition, the probability that the
> data item is correctly entered is extremely unlikely. (015)
Yes. But the problem is that "correct" is now in the eye of the
beholder. When what THEY do is an outlier to US, some of the data THEY
create will be "incorrect" from OUR point of view, but not THEIRS. (016)
If we try to write down the axioms, and definitions that reflect them,
an axiom that we take for granted as a behavioral or conceptual boundary
may address what is to them an unimportant distinction in how they do
business. The axiom alerts us both to the fact that it is an important
distinction in our ability to work together -- we both have to be clear
as to where that boundary lies (in the "most common" _joint_
occurrences) and that we can both live with that placement. (017)
> 5. Any computer program that depends critically on the precise
> definitions as specified in #2 is guaranteed to blow up in
> unpredictable ways at unpredictable moments. (018)
Yes, like the 3-Mile Island disaster. And any program that depends
critically on unstated axioms in imprecise definitions will do the same,
like the Mars landing. (019)
This is more a matter of software engineering than axiomatic definition. (020)
> Nothing in any proposed ontology has overruled the old GIGO
> principle: Garbage In -- Garbage Out. (021)
True. But axiomatic definition allows software to assist humans in
identifying Garbage rather than masking Garbage In and amplifying the
effect in the Garbage Out. (022)
Axiomatic definition isn't really for the consumer. It is an enabler
for competent software. But the effort to do it can force the domain
experts to make better definitions for the consumer, or to document
their agreements to disagree in language the consumer can understand. (023)
When you see a specification with a Note that begins: "The above
assumes that ..." or "The above does not distinguish X from Y", you know
that someone was thinking about the axioms for that specification, even
if she didn't phrase them in CL. (024)
-Ed (025)
--
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 (026)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (027)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (028)
|