[Top] [All Lists]

Re: [ontolog-forum] [ontology-summit] UN/CEFACT Core Components and Onto

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
Cc: dmconnelly@xxxxxxxx, mrowell@xxxxxxxx
From: Ed Barkmeyer <edbark@xxxxxxxx>
Date: Tue, 07 Apr 2009 12:24:09 -0400
Message-id: <49DB7E29.2080308@xxxxxxxx>
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)

<Prev in Thread] Current Thread [Next in Thread>