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

["West, Matthew R SITI-ITPSIE" <matthew.west@shell.com>]

Dear Tom,

I completely endorse your comments below.


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: Tom Johnston [mailto:tjohnston@acm.org]
> Sent: 12 August 2003 20:30
> To: Fowler, Julian; 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: 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
> >
> >
> 
> 
>