Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

SUO: RE: RE: RE: Re: General Design




All:

I've only been monitoring this forum for a few months, but only recently
have I read comments about the need for an ontological framework to be
"evolutionary", to avoid being rigidly constrained by axioms, etc. I am very
gratified to hear such comments.

-----

JF: As someone pointed out in a previous thread, try telling engineers at GM
that their products are anything other than automobiles!

TJ: me, perhaps? Well, ok, I'll say it. I do suspect that most engineers at
GM would say that their products include other things than automobiles.

As someone who has designed databases in over a dozen industries, my point,
in the automobile morphing into some other kind of vehicle example I
presented a few weeks ago, was that the notion that we have a hard and sharp
line distinguishing such things as automobiles from the rest of the entirety
of what's out there, is usually illusory. My experience in designing
business databases leads me to suspect that given a set of a few dozen
various vehicles, suitably different from one another, a roomful of GM
engineers would NOT each come up with the same partitioning of that set of
vehicles into automobiles vs. non-automobiles. And even if it happened to,
that would be the exception rather than the rule.

So what? Well, for one thing, vagaries of these semantic sorts are not
restricted to the (pejoratively) "philosophical" middle layer. They permeate
the lower, get real, layer as well, the layer where those concepts show up
as names of database tables and/or expressions used in the definitions of
those tables. The real world engineers, and other business subject matter
experts (SMEs, as we call them), do NOT have a clear conceptual grasp of
their subject matter, one which a reasonably articulate database analyst
could extract with a suitable set of questions. What such experts DO have is
an ability to interpret the result sets they get from their queries, result
sets which "mean" much less to inexperienced business users of the database
they came from.

My "customer" example, in an earlier email today, is one illustration of
what I mean. Here's another.

A manufacturing company subtypes its Parts table into Raw Material (RM)
Parts, Work in Process (WIP) Parts, and Finished Goods (FG) Parts. It also
subtypes its Standard Bill of Material Components (SBOM) table into the same
three categories.

This set of database tables has been in use for three decades, ever since
they purchased their current materials management system.

In the course of several weeks of JAD (joint application development)
sessions, the SMEs informed me that some manufacturing plants take in WIP
produced in other plants, and manufacture finished goods out of that WIP. In
those plants, the SBOMs don't begin with raw material, but rather with this
WIP. Other plants sometimes manufacture WIP, not FG, and send that WIP to
those other plants.

That's because raw material is defined as stuff purchased from outside
vendors, stuff which therefore appears on POs (purchase orders). WIP doesn't
appear on POs (otherwise the receiving plant might have to pay sales tax on
it!), and isn't purchased from outside vendors, so it isn't RM. But a WIP
Part, out of Inventory, will be designated as a lowest level Part in an SBOM
structure. However, those lowest level Parts, the ones used as input to the
first step in the Work Order (WO) which uses that SBOM, are instances of the
RM subtype of the SBOM table. So here's a WIP Part that is considered an
instance of an RM component of an SBOM!

This does work! And it will continue work, because the alternative data
structures I designed will be used for a data warehouse, not to replace this
"legacy system" database. Mapping, done in an ETL layer ("extract, transform
and load") will translate this WIP/RM confusion into a clearer structure.

What structure? Simple this, that while the subtypes of Part are indeed RM,
WIP and FG, the subtypes of SBOM are not. SBOM subtypes, instead, are
Starting Item (SI), Intermediate Item (II) and Ending Item (EI). Most
plants, and most SBOMs, start with RM as leaf nodes, and end with FG as the
root node; i.e. they direct the manufacture of finished goods from raw
material. (By the way, just as RM is what appears on a PO issued to an
outside vendor, FG is what appears on an Invoice issued to an outside
customer.)

In changing the set of tables, I changed the SME's ontology. The old
ontology worked because it warped the interpretations surrounding it to
compensate for its inherent confusion. Some of those interpretations were
expressed in program code, of course. But others were understood only by
experienced SMEs, and had to be conveyed, word of mouth (such delicate
issues seldom make their way into formal documentation), to less experienced
business users.

Does my new ontology better represent the real world of this company's
manufacturing processes? Well, it does a better job(!) until a better
ontology comes along. The old one seemed fine, i.e. seemed to represent what
the company was doing, until my alternative came along.

Better to say, as good pragmatists, that my ontology is just better than the
older one, not a better representation. How is it better? Simply that the
code which manipulates the database to retrieve data about the company's
manufacturing will be simpler than the code which performs the corresponding
function against the legacy database. "Better" means "part of a total
information system which more fully and clearly presents ontological
sameness and differences to its users, and which maintains its database out
of a simpler codebase".

The SMEs all agree that power users can write SQL against my ontology which
eschews WIP and RM as lowest level nodes in a SBOM, while the best of such
users must rely on intermediate derivative tables, created via procedural
program code, before they can query the legacy database for the same
information. They agree that there will be little gap between their
understanding of this part of the manufacturing process and the
understanding of less experienced business users, than there currently is
with the legacy system database.

So what? So let's get rid of the notion, which I have found in several
contributions to this forum, that down to earth engineers and other business
experts know the real stuff, and that we effete intellectual philosophers
and logicians are just playing around with airy fairy stuff. On the
contrary, an ability to engage in conceptual analysis -- an ability I gained
from an analytic philosophical education -- will always reveal that that
down to earth business knowledge is a tissue of hitherto unquestioned
assumptions, not by a long shot necessarily the best ontology for the
business those experts are in. It just takes a little training in the
Socratic elenchus.

OK, "tissue" is a bit too strong. But I do frequently change a company's
ontology, as expressed in their database schemas, when I design a data
warehouse. These changes are not forced on the SMEs. They, and the DBAs and
programers who are involved, see them as improvements. (They also see them
as OUR insights, not mine. Good JADs work like that. Database analysts / JAD
leaders, who just ask "What is a bill of material?", "What is a customer?",
and write down the answer, will just reproduce the ontological assumptions
of the past in newer technology. Active analysts / JAD leaders, of which I
consider myself one, will challenge the SMEs. In the bad cases, we end up
drinking hemlock. But in the good cases, what results is OUR improvements,
not mine, and a set of SMEs prepared to go out and passionately proseletize
for the improved ontology.)

Now a question. Some of the other participants in this forum work for
businesses -- manfacturing companies, perhaps insurance companies, health
care companies, credit reporting companies, etc. Has your experience been
different? Do you feel it is NOT our role to challenge the engineers and
other SMEs, to initiate a process of changing accepted ontologies? If you do
feel that, then I guess you would feel that all the ontological problems
exist in that middle "philosophical" layer. I, on the other hand, use a
background awareness of that layer to improve the lowest level ontologies of
my clients.

Tom Johnston




-----Original Message-----
From: owner-standard-upper-ontology@majordomo.ieee.org
[mailto:owner-standard-upper-ontology@majordomo.ieee.org]On Behalf Of
Fowler, Julian
Sent: Tuesday, August 12, 2003 6:02 AM
To: West, Matthew R SITI-ITPSIE; John F. Sowa; Jon Awbrey
Cc: Kenneth Fields; Ontology; protege-discussion@SMI.Stanford.EDU; SUO;
cg@cs.uah.edu
Subject: SUO: RE: RE: Re: General Design



Matthew, John et al

I agree fully that constrained models restrict their utility (outside their
original design intent - sometimes, though, such constraints are important
to understanding and making use of the meaning of data governed by/described
by those models).

I take something else, however, from John's comment about the inherent
danger of imposing an axiomatic structure.  Not only are the structures
likely to become restrictive over time (implying a need for change, or for
"fudging" of the ontology to make newly-discovered or newly-interesting
information fit with it), but the intermediate levels between
"thing/top/universal/whatever" and useful terms/concepts may themselves be
problematic.  From a somewhat oversimplified perspective, (some) top-down
ontologies and generic data models tend to have the form:

thing
philosophical-stuff
useful-stuff

and for many analysts, programmers, and subject/domain experts trying to use
such a framework, the philsophical-stuff is seen as confusing, unnecessary,
and (as John points out) introducing a new vocabulary in which to express
what should be familiar and well understood concepts.  As someone pointed
out in a previous thread, try telling engineers at GM that their products
are anything other than automobiles!

There is, of course, a key role for the philosophical-stuff components of
such an ontology: without it we may not be able to establish correspondences
(and therefore enable communication) between my-useful-stuff and
your-useful-stuff.    In many cases, though, the necessary abstractions to
enable communication need not be at the highly generic (thing,
philosophical-stuff) level.  Therefore, an approach that recognizes this and
can, within an evolutionary/automated system capture and exploit the natures
of:

- my-useful-stuff context
- your-useful-stuff context
- my-useful-stuff-and-your-useful-stuff context

and their inter-relationships is likely to be more fruitful (and
comprehensible to a wider user community) than seeking/imposing a stable
axiomatic framework for absolutely-everybody's-useful-stuff.

Julian

-----Original Message-----
From: West, Matthew R SITI-ITPSIE [mailto:matthew.west@shell.com]
Sent: 2003-08-12 09:43
To: John F. Sowa; Jon Awbrey
Cc: Kenneth Fields; Ontology; protege-discussion@SMI.Stanford.EDU; SUO;
cg@cs.uah.edu
Subject: SUO: RE: Re: General Design



Dear John,

A word of support.

> Of course, not.  The main reason why WordNet is more flexible than
> Cyc, Sumo, Dolce, or any other axiomatized ontology is simple;
>
>      The axioms get in the way.
>
I have spent many years trying to improve the quality of data models
in Shell and elsewhere. By far the biggest problem has been that
data models impose constraints that simply aren't true (except in
some limited set of circumstances). As a result I have become very
conservative about constraints or axioms.


Matthew West
Principal Consultant
Shell Information Technology International Limited
Shell Centre, London SE1 7NA, United Kingdom

Tel: +44 20 7934 4490 Other Tel: +44 7796 336538
Email: matthew.west@shell.com
Internet: http://www.shell.com


> -----Original Message-----
> From: John F. Sowa [mailto:sowa@bestweb.net]
> Sent: 11 August 2003 21:11
> To: Jon Awbrey
> Cc: Kenneth Fields; Ontology;
> protege-discussion@SMI.Stanford.EDU; SUO;
> cg@cs.uah.edu
> Subject: SUO: Re: General Design
>
>
>
> Jon,
>
> I am on my way to California tomorrow, and I have a million things
> to finish up before I leave.  So I'll have to wait until later,
> perhaps this weekend, to send more info.
>
> > Perhaps you can explain to us how "'knowledge soup' -- the
> loosely organized,
> > semi-structured mix of whatever people have in their heads"
> can be canned in
> > FOL cans, because this is a problem that has exercised me
> for way too many
> > years now, and though I may say "I think I can" till I can
> not say it any
> > more, I just can't make myself believe that can be done any
> more, not
> > in that "direct and literal" (DAL) fashion with which ontologicists
> > keep on trying to curry favor with the geists of atomists past.
>
> Of course, not.  The main reason why WordNet is more flexible than
> Cyc, Sumo, Dolce, or any other axiomatized ontology is simple;
>
>      The axioms get in the way.
>
> That simple observation is heresy, which will bring down more threats
> of excommunication than a gay bishop.   But it is a fact:  the reason
> why anybody wants axioms is to make their ontology more precise and
> better adapted to whatever little niche they currently inhabit.  But
> if you want an ontology that is general enough to apply to anything
> and everything, you can't live with a hot-house pansy that can only
> survive when every weed in sight has been extirpated.
>
> > Failing that, and GOL knows any sensate person ought to
> know that it's failed by now,
> > the only still "logical" alternative seems to be something
> like the indirect approach,
> > via the explicit recognition that our models are
> abductively approximate analogues of
> > the real thing that is ever out there, beyond us, and thus
> that we have no choice but
> > to begin in more amorphous, proto-formal settings like sign
> relations, taking serious
> > Peirce's notion of "logic as (a specialized form of) semiotics".
>
> My proposed solution is based on some principles that I have been
> preaching for as long as anybody has been willing to listen (which
> isn't very long, for most of them):
>
>   1. You cannot build a hierarchy by drawing trees (or lattices)
>      by hand -- you must have tools that can derive the hierarchy
>      automatically from whatever set of distinctions are embodied
>      in the ontology.  (One example of such a tool is the Toscana
>      implementation(s) of Formal Concept Analysis (FCA), but there
>      are also other similar tools that could be used.)
>
>   2. You cannot assume that any given hierarchy is fixed for all
>      time -- it is only fixed until somebody adds another axiom.
>      If their axiom makes a new distinction, they will push a
>      button to run the hierarchy-derivation program to redraw the
>      lattice.  If you're lucky, the new axiom won't change very
>      much.  But if you're unlucky, it might reorganize everything.
>
>   3. If you need to preserve your axioms as long as anybody is
>      using some application that depends on them, then you can't
>      let people push buttons that will change your hierarchy just
>      because they want to change theirs.  The net result is that
>      the total hierarchy bifurcates, trifurcates, or multifurcates
>      into incompatible contexts, modules, microtheories, or
>      whatever you want to call them.
>
>   4. Meanwhile, nobody wants to learn a new language with a totally
>      different vocabulary just because somebody decided to make
>      a new distinction.  Therefore, they just recycle their old
>      words and force the lexicographers or WordNetters to add more
>      word senses or synsets.   And then you have to add more ropes
>      (or pointers) to align the terminological hierarchies with
>      the multipicity of axiomatized hierarchies.
>
> And as you pointed out, Peirce recognized these problems a century
> ago.  He explained, as you said, that any theory of logic is merely
> a subset of the broader theory of semeiotic, which he designed to
> accommodate all these ways that people and other sentient beings
> organize their ways of making sense of what they experience.
>
> So I really shouldn't complain too much that people have been
> ignoring what I've been preaching since 1987, since they have
> been ignoring what Peirce was preaching for at least a century
> or more before that.
>
> John
>
>