Re: Ontological EDI & Wittgenstein
fritz@rodin.wustl.edu (Fritz Lehmann)
Date: Fri, 30 Sep 94 05:13:51 CDT
From: fritz@rodin.wustl.edu (Fritz Lehmann)
Message-id: <9409301013.AA04526@rodin.wustl.edu>
To: 0004574792@mcimail.com
Subject: Re: Ontological EDI & Wittgenstein
Cc: cg@cs.umn.edu, edi-new@tegsun.harvard.edu, srkb@cs.umbc.edu
Sender: owner-srkb@cs.umbc.edu
Precedence: bulk
Lynn Betts' thoughtful message on EDI-new pointed out
that any attempt to define a model of business activities
precisely is soon superseded by changing conditions
and missions. As soon as a 'universal' definition
is settled upon, a new group of participants shows up
with some real-world exceptions. Scott Dickson of
Ontek and Nitin Borwankar of Sybase have made similar
points, and I agree with them. As I said earlier, I
think there is middle ground between overspecifying everything
(so that it is inflexible and obsolescent) and specifying
nothing at all. This middle ground can be attained with a system of
semantic constraints (rather than precise definitions) and
what Scott Dickson called a 'taxonomy' for EDI.
The need for ontology-based integration (of all hetero-
geneous data systems, including EDI) is based on looking
at where the money is spent. Over 70% of corporate and
government software costs go toward "maintenance". The
bulk of "maintenance" involves translating data formats from
one system to an incompatible system (updating a legacy sytem
or getting two or more different systems to share data).
This is a multi-billion dollar expense for government and
industry. Some sophisticated schema-integration tools have
been created, notably by Navathe and his colleagues, and there
has been theoretical work by Geller and others on using the
pure structure of records to assist in mapping data from one
system to another. But everybody comes up against the fact
that they can't trust the field-names and record-names, and
the fact that records about the same subject-matter are
differently arranged by different designers. Formal tools can
only help so much. The real obstacle is that the computer has
no idea (criterion on which it can act) of what the data is
_about_. A human being has to read the documentation and
address questions like "Does 'vehicle' for system A include
aircraft, as in system B, and if not, how can we use B's database
of vehicles for the 'vehicle' records needed by A?" As long as
the documentation (if any!) is in natural language, the
meanings are unavailable to the computer. If the meaning of a
field or record, in a real-world ontology, is provided for
two systems, the translation can be automatic -- except for
those borderline instances which require real human judgement.
Without this, all translations, tedious and routine though they
be, have to be done by hand at great expense by programmers
and systems analysts. This is a whole industry.
In EDI you have the same problem. Either you translate
from your local data structures to and from EDI, or you use
a tool that helps you structure your records to match EDI in
the first place. The latter doesn't make the problem go away,
because the rest of your enterprise will not be aligned to
to the EDI standard, so the translation of data formats must now
take place within the enterprise. Even with helpful translation
aids, human hand-translation is required. This is the big
money drain. (In fact even afterwards, human beings often end up
doing the the entire "E"DI processing when the EDI system is
used as mere email of forms written and read by human beings.)
I continue to believe, as Scott Dickson also said,
that EDI is an easier field for the ontology approach than the
general field of database integration, because we
already have some agreed-upon constraints which are fairly
obvious (if lengthy to state) from the existing standards.
The flexibility comes from the "negotiated ontology" aspect
that I've been pushing. To answer Lynn Betts, consider: a new
trading partner is presented with a proposed ontological
agreement (all by machine); it can respond by saying "No,
for me any container can be a packaging unit, not
just the X12 list in Element 211. I send liquids in sealed
pipes." This fits her scenario because the responding
system is declaring an exception to the previously
agreed-upon rule. As long as there is _some_ common
ontological ground (common primitives), every transaction
set between any two partners can have negotiated
definitions. This would also interact with the "business
rules" of each partner, which could be expressed in terms of
the ontology.
(NOTE: It is clear that there are different levels of "newness"
discussed on the edi-"new" mailing list. Many people are interested
in the long term future direction, but many others are
concerned with nearer term solutions to lower-level EDI
problems. Edi-new seems to be a diverse email list. All
of us can look at the subject-lines of the messages to see whether
the thread is interesting to us, and ignore the other threads.)
Yours truly, Fritz Lehmann
GRANDAI Software, 4282 Sandburg Way, Irvine, CA 92715, U.S.A.
Tel:(714)-733-0566 Fax:(714)-733-0506 fritz@rodin.wustl.edu
=============================================================