Re: Ontology-based EDI

Fritz Lehmann <>
Date: Thu, 15 Dec 1994 23:44:05 -0800
From: Fritz Lehmann <>
Message-id: <>
Newsgroups: bit.listserv.edi-l
Subject: Re:  Ontology-based EDI
Summary: Fritz lays out the practical road ahead for ontology-based EDI
References: <>
Organization: GRANDAI Software, Irvine
Precedence: bulk
     Ken Steel wrote on the list edi-l (usenet: bit.listserv.edi-l):
-----begin quote----
> [my comments on form versus content of Electronic Data
>          Interchange (EDI) standards EDIFACT and X12 are omitted]
>...the current Basic Semantic Repository (BSR)
>proposals, including that of ISO, have no machine-usable semantics
>for the data elements  -- there is only a general English definition of
>the meaning.  The BSR proposals (or the "BIM") are a good first step
>until someone creates usable formal definitions in an appropriate semantic
>network or logical language like Conceptual Graphs or KIF.  The data elements
>and values will be defined in terms of more primitive concepts -- these will
>have to be drawn from a repository of agreed-upon concepts in an
>underlying "ontology" of real-world things and relations.  My EC Workshop talk
>was called "Machine-Negotiated Ontology-Based EDI" and it outlined this
>approach. Steel presented his ICSDEF message and it was clear to me that A: he
>is right on this, and B: he does not go far enough (yet) to establish common
>(real-world) semantics between the system sending a message and the target

Please show us how you would solve those problems in a practical
way using your ontology approach.
Ken Steel
--------end quote-----------

     I cannot lay out the practical scenario in detail
here; several details are covered in the draft I submitted
to the Electronic Commerce Workshop  -- you have a copy.

     Roughly, I think the best approach now is as follows:

     1. Recognize the difference between the semantics (content)
and the forms of existing EDI standards X12 and EDIFACT.
Jettison the obsolete forms entirely (as you have championed)
and concentrate on formalizing the _intended_meanings_ of the
data elements and values, using a common ontology and an 
appropriate knowledge representation language.  In my opinion,
the best language is Conceptual Graphs which will be part of
the Conceptual Schema Modelling Facility standard (CSMF).  There
are other good contenders such as KIF (also in the CSMF) as well
as half a dozen others like SNePS, HOL, KL-ONEs, CYC-EL, etc.

     2. Recognize that "qualifier codes" and the like are
hopelessly inflexible, outdated and semantically unnecessary.
If you need a certain "Date" to mean "The date on which the
seller becomes aware that the shipper has obtained the signed
receipt of the buyer" then SAY SO in the initial, negotiated
definition of the transaction series (describe it formally,
not in ambiguous natural language).  This kind of date will
be defined in terms of agreed-upon conceptual meanings, called
the "shared ontology".  Complicated concepts can be created at
any time from simpler concepts, and the structure and meaning
will be available for the computer to act upon.

    3. Recognize that building ontologies is a lot of work,
that this work is being done now at various universities and
corporations around the world, and that the base-level ontology
building is not suited to business people NOR to Information
Technologists  -- it is work for ontologists, artificial
intelligence people, business domain modellers, people now 
doing semantic database or enterprise integration, and (for some
of the lowest ontological levels like time, space, causality, etc.)
even some philosophers.  Suitable systems have already begun to
emerge in the ARPA Knowledge Sharing Effort, the CYC Project,
the Pangloss Project, and many proprietary systems.  I am involved
in the CCAT project (Conceptual Catalogues/Ontologies) using
Conceptual Graphs, and we intend to exploit and unify all 
sources of ontologies when ever possible, making a unified
system of freely available "off the shelf" ontologies of subjects
from abstract algebra, to time and space and assemblies, to business
activities, law and medicine.

     4. Recognize that the coming fusion of higher level EDI
basic semantic concepts with the lower level ontological systems
(defining the former in terms of the latter) can proceed "from
above" (from the EDI target-concepts, namely the needed data
elements and values) and simultaneously "from below" (as ontologies
are built-up and perfected).  You don't have to wait for the
ontologists to get things right.  Start NOW with very careful
definitions of EDI "Basic Semantic Units" in careful, lawyerly
English.  Pretend you are a judge deciding an EDI lawsuit and you
have to hand down a doctrine of whether a party who contends
that something is a "Target Currency", say, (EDIFACT element 
6343:007 at present) is in fact justified in calling it that.
That means you specify conditions that must apply to any "Target
Currency" unambiguously and uncontrovertedly.

     5.  At the same time the above is being done by EDI
theorists, a "middle level" ontology of business models will
also be created.  Notions of "buyer", "carrier", etc. and their
relevant functions will be carefully defined.  (It is by no
means trivial; when a person trades dollars for francs, is
he/she the buyer or the seller?)  EDI data elements and values
will be defined in terms of universal (consensus) business
models and an agreed-upon ontology of the real world.  When
two parties (who have never traded nor negotiated before)
say "Last Acceptable Shipping Date" (in the appropriate
Conceptual Graphs form) they will both mean exactly the same
thing because they both commit to the same base ontologies
and the same definition.  The definition itself can be added to
your ICSDEF message.  New data elements and values and new meanings
can be unambiguously defined at will in any machine-negotiation.

     6. Recognize that most business users will not be able
to define things skillfully at the conceptual level in a
formal language like Conceptual Graphs or formal logic.  But they
will be able to use specialized (not fully general) parts
of natural language.  Two things are needed: mappings from
natural language words into their underlying meaning-concepts
(Pangloss, Wordnet, the Summary Schemas Model, thesaurus
systems, etc. are already ready to tackle this), and helpful
tools to guide the user and interrogate him/her with examples
and counterexamples of concepts to insure that the definitions are
really what is intended (these tools don't exist right now, but
they are emerging from the Knowledge Acquisition community).

     7. Recognize that EDI does not exist in a vacuum.  As I
said in my lecture, the EDI challenge is nothing but a special
case of the basic database integration and system interoperability
     "One system, set up in a certain way for certain
      purposes, has to communicate information to another
      system, set up a different way with different data-
      names and structures (and maybe for different purposes)
      but with subject-matter common to both systems."
The only special thing about EDI is that EDI messages are exchanged
between legally distinct parties and create real, enforceable
legal obligations between them.   The top people in the integration/
interoperability world now recognize that SEMANTIC integration
is the only way to solve the problem, using shared ontologies
exactly as I have described.  ARPA for one has made this a top
research priority, and the CIKM-94 conference (Information and
Knowledge Management) at NIST was dominated by this notion.
A White House representative at a plenary session even joked
about "the White House position on shared ontology."  My team
is now in vogue, and research on this is accelerating at long
last.  EDI will probably not lead in this field, but it is a big-
money application ripe to take advantage of work being done
in related areas.  EDI standards can do a real service by providing
large sets of pragmatically necessary real-world target-concepts
that need to be grounded in the ontologies.  Simultaneously,
related standards like STEP (for descriptions of products) will
be grounded in the same ontologies.  Then an EDI "Request for
Proposals", say, can formally define the desired product, along
with desired terms, and every EDI participant worldwide
can _automatically_ decide whether its capability matches
or is subsumed by the described product, and answer with a
Proposal.  Interoperability will go way beyond the "business
forms" mentality of "old-EDI".

     That's as much detail as I'm willing to give here.  In
summary: Forget formats, concentrate on _detailed_ definitions of
and constraints on the Basic Semantic Units, study Conceptual
Graphs if you want to tackle the formal level, and build 
consensus on reliable, uncontroversial business models.  "Forget
formats" does _not_ mean forget EDIFACT and X 12; it means
forget their antiquated data specifications and study intently
the meanings of their data elements and values.  Also study all
the interrelationships among data elements, segments etc. in
order to spot needed cures for the many defects. "Qualifier codes"
will be dumped in favor of genuine semantic network descriptions
of intended meaning.

     As I said a few months ago on the "edi-new" email list, it's not
a question of whether all this will happen -- it's a question
of when.

                          Yours truly,   Fritz Lehmann
GRANDAI Software, 4282 Sandburg Way, Irvine, CA 92715, U.S.A.
Tel:(714)-733-0566  Fax:(714)-733-0506