Re: EDI with real email@example.com (Scott M. Dickson)
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 12 Aug 1994 12:32:15 -0800
From: firstname.lastname@example.org (Scott M. Dickson)
Subject: Re: EDI with real semantics
Cc: email@example.com, firstname.lastname@example.org
This is a response to a message from Fritz Lehman dated 7/28/94 posted to
the edi-new, cg and srkb lists. I agree in large part with what he said.
Since his message was lengthy, I will omit quoting the numerous areas of
agreement and focus on those areas where I differ or have some information
> The "edi-new" list is a good development. I feel that it
>could be even a bit more up-to-date on the possibilities of "new
>EDI", though, based on the archived messages I've seen.
I agree with this, the only question is, "How new?" Fritz goes on to cite
some areas of active _research_ which hold a lot of promise for greatly
enhancing the utility and ease of implementation of EDI (or "EKI").
However, something needs to be done in the meantime; standardizing the
legal interpretations of transactions, extending them to forms (i.e., "This
form contains data for this type of transaction [which has a defined legal
interpretation]"), tagging form data elements, and a protocol for automated
negotiation of transaction data can all be done without waiting for the
results of knowledge representation and exchange research.
>... What is happening in the outside world, though, is a transcending of
>mere data bases and data transactions, towards "knowledge bases"
>and "intelligent agent transactions".
There is quite a bit of this in the "outside world" of the research
community and some dabbling in businesses with advanced technology
organizations. We're all waiting with baited breath to see Telescript and
what it can do and what the marketing department means by "intelligent".
[and waiting ...]
> There is a movement going on worldwide for what is called
>"knowledge sharing" -- including the ARPA Knowledge Sharing Effort
>in the USA and similar efforts in Europe. Unlike current EDI,
>this aims to transmit the _meaning_ of data along with the data.
>This requires at least some (machine-negotiated) sharing of an
>"ontology" or a concept-system for describing things and events in
>the real world.
The ANSI X3H4 committee had a project to write a technical report on
defining a Conceptual Schema for use in an Information Resource Dictionary
System (now usually called a Repository). The Conceptual Schema is
intended to unify the schemata of databases with overlapping subject areas
at a conceptual level, so that the databases can be treated as a unified
whole for access. This report notes the need for an ontology for the
Conceptual Schema and surveys some source material. There has been some
delay at ANSI in getting the report published, so I don't have a reference,
but the report is available as noted below.
>Concepts like "person", "order", "time",
>"destination" and "payment" have formal conceptual definitions.
They're formally defined, based on the ontology and whatever formal
definition primitives you have (usually some variant of first-order logic).
Getting a good ontology so that the wide variety of things referenced in
trade transactions can be constructively defined from a manageable set of
ontological primitives is "tricky".
> A well-known attempt at this in the Artificial Intelligence
>community is the CYC project led by Lenat and Guha at MCC in
>Austin, Tex. This is one of several different concept-systems; no
>one concept-system serves all purposes, but they must have some
>common ground in order for disparate systems to communicate.
I'd hate to have to bring up CYC in order to do EDI, at least today or next
year. Still, at some point, what now seems "large" will probably be quite
reasonable for the task.
>A similar system is part of the proposed ANSI IRDS Conceptual
>Schema, in which databases describe their subjects, and
>themselves, in "metadata" that are logically and even
>philosophically based on structures of basic conceptual
I mentioned this above. The work on conceptual schemas has been
transferred to the X3T2 committee, "Information Interchange and
Interpretation". There is also work at ISO/IEC JTC1/SC21/WG3 Rapporteur
Group on Conceptual Schema Modeling Facilities (CSMF).
>Another is the related enterprise-integration system
>of Ontek, Inc. in Laguna Hills, Cal.
Thanks for the plug.
>The designated languages for
>these systems are Conceptual Graphs, the Knowledge Interchange
>Format (KIF), and CYC's Epistemological Language, all of which are
>machine-usable enhancements of symbolic logic -- "position-
>independent" -- and are nearly inter-translatable.
Ontek's is a somewhat different from the others, and the CSMF effort has a
little SUMM (Semantic Unification Meta Model) thrown in, along with
modeling languages like IDEF, NIAM, etc.
>Since these are logic-based-systems using semantic primitives,
>they have completely extensible semantics and they won't get
>obsolete due to an outdated specialization level.
... IF the primitives are correct. Also, just because the definition
_system_ won't become obsolete doesn't mean the definitions in it won't
become obsolete. Concepts like current EDI elements, segments,
transactions, etc. would be defined in the system and those definitions
could be superseded as is the case now. However at least you would be
starting with a formal definition and would have some hope of computing the
impact of the change.
> At present the EDI standards have a notion of the price paid
>for a product, but no notion of what that product is, nor its
>proper specification parameters. There is just a human-readable
>description, an arbitrary designated part-number, or something
>similar. These too are becoming obsolescent. The PDES/STEP
>standards for manufacturers are now beginning to emerge
>(complicated standards for product descriptions and
>specifications; they now cover machined shapes, CAD
>specifications, assemblies, electronic components and some other
>areas). These will eentually be extended to almost all areas of
>commerce. These are also being linked into the "knowledge level"
>and defined conceptually, so that, coupled to intelligent EDI, a
>computer will "understand" automatically that a Purchase Order to
>ship four Mack Trucks in one Post Office Mailsack is ill-advised.
>Similarly, U.S. Government procurement will have built-in machine
>safeguards against certain unsound, nonsensical or illegal
One can purchase a great variety of things, only some of which are physical
artifacts. PDES/STEP has focused on the geometric and material description
of physical artifacts. One can also purchase services, corn in the future,
real estate, hours of a person's time, insurance, a business, a patent, the
fulfillment of a requirement, ad infinitum. The description of product in
the sense of thing to be purchased will require a very rich ontology.
> The "generic" or universal ontologies may allow novel
>intersector transactions (i.e. between different industries).
>Concepts of automobile distribution may not be known to a currency
>trading system, and vice-versa, but if the two need to communicate
>it should be possible for them to exchange sequences of long and
>painstaking definitions (based on generic ontology) until a valid
>transaction between them becomes feasible.
This is true as long as all the information required by one party to
complete a transaction is available from the other party. There are also
complexity problems associated with the matching of parts of definitions.
This becomes a massive theorem-proving exercise.
> Among other reasons for having a formal "ontology" is so that
>other kinds of systems within an enterprise can communicate
>intelligently with the EDI program. This includes Management
>Information, CAD data, accounting systems, manufacturing, etc.
>The same "widget" ordered by the Army could appear first in the
>EDI RFQ transaction, then in the Purchase Order, then in the CAD
>design system, then in a Numerical Control program for machining,
>then in a CIM shop-floor program, then in Inventory, then in
>Accounting, then in a Shipping router, then in a final EDI
>confirmation, then in the Army's logistics system, etc. The same
>entity, the widget, has a different (and incompatible)
>representation in each program now, so intercommunication is
>nearly impossible. These programs do have different purposes and
>need different information, but they can be integrated at the
>knowledge level, and EDI should fit in to this integration scheme.
>This is a general example of current "enterprise integration"
This is one scenario the IRDS Conceptual Schema was meant to address. Each
department would have its own database. How do you integrate their schemas
into one conceptual schema. It would be nice to determine the full status
of an order with a single request. It would also be nice to be able to
determine how much profit or loss you made on a part and how, for instance,
a change in the machining program would impact the profit or loss on future
> The fact that EDI transactions have
>the effect of changing ownership and generating legal obligations
>means that much of the semantics will ultimately depend on
This means that the ontology will have to provide for uncertainty,
uncertainty will be part of the definitions of the constructs and any
inference mechanisms will have to be tolerant of uncertainty. Law is a
combination of written code, tradition and often conflicting
interpretations of those.
>I would be very interested to see what the "new-EDI" thinkers (and
>the EDI Establishment) have to say about this kind of advanced
>programme for EDI. I myself don't think it's really a question of
>"whether" it will be done for EDI -- just "when".
This will be driven by requirements, cost and available technology. There
are things that can be done for EDI now, without waiting until the output
of the Knowledge Sharing Effort and the ontologists are ready for prime
time. Of course, it is good to pay attention to the status of those
efforts, since they can be of so much benefit to EDI in the future. It
would be helpful to put together a crude time line, outlining possible
near-term and far-term improvements. Then we can talk about (on edi-new)
tagged forms and knowledge-based EDI without arguing about whether they are
not new enough or currently impracticle.
For anyone who needs a copy of the Conceptual Schema for the IRDS technical
report (about 400 pages) before it's published by ANSI (we're still
waiting), please e-mail me for instructions.
Thanks for your time,