SUO: RE: RE: Missing ingredient
Dear Tom,
You mention my name often enough that I feel I should respond.
See 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: 21 October 2003 16:51
> To: jim.s3@juno.com; standard-upper-ontology@ieee.org
> Subject: SUO: RE: Missing ingredient
>
>
>
> Jim:
>
> Jon's response seems to be: respect for relevant theory that
> is part of the
> standard undergraduate curriculum.
MW: I agree with Jon on this.
> Murray's seems to be: tie-in to
> implementation technologies like Java and XML. My own is:
> start working
> bottom-up, and start talking in terms intelligible to serious database
> professionals.
MW: I agree with Murray on this.
>
> Several of my earlier emails to this forum expand on these
> suggestions. To
> summarize them:
>
> 1. Start working bottom-up.
>
> 1.1 Our goal, I take it, is to increase the semantic
> interoperability of
> databases.
MW: Well I think you are wrong about this. The only reason I can find
for worrying about axiomatisation of concepts is so that you can
reason with them, i.e. the motivation is principally AI at some level.
> The means, I take it, (although I have found no
> description of
> any such thing on the SUO website) is to create a
> registration framework for
> real world databases. When registered into that framework,
> the semantics of
> individual tables in individual databases is formally declared.
> Inter-database queries, then, across thusly registered
> tables, can return
> result sets whose semantics is as well-specified as are the
> semantics of the
> nodes in the registration hierarchy.
MW: This would be useful, and would need FOL to define the mappings
between the concepts in these remote systems and the concepts in
your integrating ontology, but you don't need to axiomatise your
ontology itself.
MW: This is, by the way, exactly the sort of problem that ISO 15926
and ISO 18876 is intended to support in its current form.
>
> 1.2 A GUI for such a registration process could be developed
> regardless of
> the state of agreement or lack of it on whatever it is we
> keep discussing in
> this forum. A low-level, perhaps industry-specific, ontology, could be
> developed. Perhaps with Matthew West's help, in the oil and
> gas industry.
> Registration of tables from different Shell databases, into
> this hierarchy
> (two levels would be required to demonstrate effectiveness,
> with anything
> more just contributing to verisimilitude).
MW: It is extremely unlikely we would do this, it would mean other
people could see what we were interested in. What we are doing in
some engineering design is specifying our data requirements from
the contractor in terms of ISO 15926, so that it acts as an interlingua
for handover of the design. We actually use a relevant subset in
some of our systems.
>
> Earlier emails of mine elaborate on how this would work.
> (These are the ones
> in which I explained how different are the semantics of basic
> concepts like
> customer, across companies, across databases.)
MW: I agree they are.
>
> 1.3 As these low-level, industry-specific registration frameworks are
> generalized upwards, they will eventually meet the SUO work, being
> specialized downwards (by us, I assume). Then they meet, and then
> non-wheel-spinning work can really begin. Re-alignments at
> the lower levels
> of the integrated hierarchies will extend the reach of upper-level
> categories down to working databases and tables. Our
> upper-level work will
> bear fruit by bringing better upper-level generalizations to
> bear on these
> databases and tables than would have been reached via a bottom-up
> generaliation effort alone. Re-alignments at the upper and
> middle levels of
> our hierarchies/ontologies would also take place, as theory
> awakens from its
> dogmatic slumbers as Customer, Salesperson and Bill of
> Material tables come
> knocking at their door.
MW: My experience is that the gap between what we are talking about
directly and things like customer, product, etc is really quite
narrow. There is a wealth of detail if you try to catalogue products
of course.
MW: The gap I find is the very informal definitions you find of these
concepts, and as you note, the variation in them.
>
> 1.4 I realize there are people with a nuts and bolts bias,
> who would reject
> this BOTH top-down AND bottom-up approach, and say instead
> that the best
> upper level categorizations will be those reached by
> extending real, honest,
> blue-collar database work upwards, as high as it needs to go,
> but no higher.
> Of course, we don't find many such folks in this forum. I
> also realize there
> are people with a bias towards theory, who would reject this
> BOTH top-down
> AND bottom-up approach, and say instead that the best upper
> lowest level
> categorizations, i.e. the best semantics of specific tables
> in specific
> working databases, will be those reached by extending
> serious, formalized
> mathematical reasoning downwards, as low as it needs to go,
> but no lower.
MW: Not very likely to be correct though, since database design
should always take into account the processing the table is
expected to support, anad not just the nature of the things it
is used to represent.
> The work here that I've seen thus far does suffer from this
> bias. I think
> that bias runs the risk of condemning whatever we do to
> irrelevance -- not
> that anyone would ever label our results as such, of course.
> Whatever we do
> eventually achieve, we will call it victory, and move on.
>
>
> 2. Start talking in terms intelligible to serious database
> professionals.
>
> 2.1 An example is the recent discussion of Matthew West's
> proposal for a 4D
> ontology. Many of us seemed reluctant to accept Matthew's
> work, even as a
> starting position, because it was not axiomatized.
MW: To be fair it was only a few that expressed this concern,
which applies just as much to OpenCyc.
> Now most
> working database
> professionals have never axiomatized a relational database. I've read
> descriptions of the process, but never done it myself. Nor,
> apparently, has
> Matthew.
MW: Not quite sure what you mean here. You might mean "How do you
axiomatise the constraints in the database structure?" I do know how
to do that and have done it. You might mean "How do you translate the
natural language definitions of the tables into FOL axioms?" This is
certainly harder because the axioms that apply are not necessarily
always stated in definitions, which are often of an ostension
(pointing) nature.
> But given that it can be done, and that we know how
> to do it, the
> requirement to do it in a specific case, Matthew's to wit,
> simply reflects
> the top-down bias prevalent in this group.
>
> And so this was, as I see it, a procedural pivot point in the
> (at least
> recent) history of this working group. EITHER: Reject
> Matthew's work because
> it isn't axiomatized (and thus isn't in a form where we can
> work out its
> implications (theorems), criticize it from the perspective of
> formal logic,
> and generally do all those things academics think we must do before we
> attempt to put anything to work in the real world). OR:
> accept it in the
> form in which it was presented, with the knowledge that a set
> of relational
> schemas can be axiomatized in well-known ways, when we chose
> to do so. To do
> this -- to start working with Matthew's material -- and do it without
> pre-destining the outcome to failure, I suggest, must be to accept the
> psyche-jerking paradigm shift of working bottom-up, from less
> then perfectly
> spelled-out assumptions, messing around in the real world
> until various
> patterns (ontological ones, in our case) rise up out of the murk.
MW: Which fortunately we have agreed to do.
>
> Please excuse the (possibly distracting!) flights of poesy.
> But my line of
> work, in a dozen industries or so over the past two decades, has been
> precisely messing around in the ontological murk. And I have
> seen, and have
> helped to uncover, a lot of patterns that are both powerful
> and beautiful.
> (Several "case study" emails of mine, a couple of months ago, tried to
> describe this process and some of these patterns.)
>
> I see little inclination, among the dominant academic
> subculture in the SUO,
> to make this effort. Instead, I see this attitude, that we
> must axiomatize
> everything, we must link everything into the IFF, SUMO, etc. We must
> continue to use the language of category theory, set theory,
> propositional,
> predicate and modal logic. Only then can we look to the
> world. Only then
> will we have a framework robust enough to withstand the
> stresses of being
> put to work. Only then can we move to implementation without
> finding at some
> point that we have to tear it down and start all over.
>
> In response I will say, to the academics in this group, that
> if you can't
> reach beyond your mathematical formalizations and communicate
> and work with
> business professionals like Matthew and myself, then that
> doesn't bode well
> for the introduction of your results into a community in
> which people like
> Matthew and myself will be the only ones even attempting to
> speak to you.
> Thus, speaking our language is a necessary step in gaining
> acceptance for
> your work.
MW: This I agree with. There is no point saying to potential
users of our work, that they shouldn't expect to be able to
understand what we are doing until they have undertaken several
years study reading a significant pile of books. If we are not
able to extract the learning and present it in a simple way
that potential users can grasp quickly, then we will fail to
achieve anything that has significant use. People don't use
what they don't understand.
>
> I also claim that working from the bottom up will produce a
> better result
> than continuing with a top-down, formalize first and
> formalize completely
> mentality. Or, more accurately, doing some bottom-up work,
> getting into the
> middle range, and then combining our results with top-down
> work already
> completed. Revise a little upwards. Revise a little
> downwards. Implement the
> imperfect results. Iterate indefinitely.
>
>
> I have mentioned Matthew's name but, of course, I do not
> speak for him.
MW: No, but I agree with most of your sentiments.
> Perhaps his employer is not the right sponsor for such an effort, nor
> Matthew the right person to lead such an effort.
MW: For Shell this is still skunk works stuff.
>
> For my own part, I have developed working ontologies, i.e. relational
> database schemas, in about a dozen industries. I also have
> some background
> in formal logic, and a pretty good philosophical background
> in ontology. But
> while I refresh and extend my understanding of the relevant
> mathematics, by
> continuing to listen in to this group, I won't have much to
> contribute if
> all contributions must first be expressed in the canonical
> dialect. But if
> there is a place for folks like Matthew and myself here, I'm
> willing to hang
> around, and to contribute as and when I can.
MW: I think there is enough convergence.
>
>
> 3. Looking at your question again .....
>
> 3.1 Your question was, specifically, how to reuse the starter
> documents. My
> answer has been to work bottom-up, from funded business database
> development/enhancement projects, until we reach a point
> where the starter
> documents are relevant. Then muddle around. Change the
> documents. Change the
> data models and database schemas. Implement and iterate.
MW: Well that's kind of how the Lifecycle Integration Schema
got developed.
>
> By way of clarification, I'd like to end by describing one
> way I think we
> should NOT attempt to reuse those documents. I think we
> should not attempt
> to find a database development (or, better, a cross-database semantic
> interoperability) project, preferably one on which someone
> like Matthew or
> myself is working, and introduce the IFF and SUMO documents into the
> project, making presentations about them to the development
> team, and just,
> somehow, putting the darn things to work. That won't work.
> (I'm personally
> appalled at how messy the SUMO ontology is, but that's a
> subject for another
> time.) It is also, I think, another manifestation of the
> top-down mentality.
> "We have these really good, mathematically rigorous, starter
> documents.
> Let's put them to use".
MW: Well you would learn a lot from doing it ...
>
> No. Let's not. Instead, let's muddle around for awhile until we have
> something to which they can be usefully applied. Like's
> Matthew's model,
> perhaps? In the world of working relational databases, that
> usually means
> what's called a fully-normalized, logical, "enterprise" data model. In
> particular, one with more than the usual amount of
> supertyping. Further
> remarks would just take us deeper into the dialect of the
> working database
> professional and so are not, at this point, useful.
>
>
> I end here with a smile, realizing that my response to your
> inquiry, Jim, is
> several times longer than Jon's! And, pace my email of
> yesterday evening,
> contains more distracting language than Jon's as well!
>
> The hardest errors to condone
> In others
> Are one's own.
>
>
>
>
>
> -----Original Message-----
> From: owner-standard-upper-ontology@majordomo.ieee.org
> [mailto:owner-standard-upper-ontology@majordomo.ieee.org]On Behalf Of
> jim.s3@juno.com
> Sent: Monday, October 20, 2003 11:24 PM
> To: standard-upper-ontology@ieee.org
> Subject: SUO: Missing ingredient
>
>
>
> SUO,
>
> There are many ingredients needed to brew a
> successful standard.
> We have a few ingredients, including some starter documents, a diverse
> group of experts, a charter from an accredited Standards Developing
> Organization (SDO), and a forum to conduct work.
>
> I see the key missing ingredient as: 'A growing number of
> organizations attempting to reuse any of the starter documents, and
> willing to submit suggested changes.'
>
> If we had this ingredient,
>
> 1. The suggested changes would help us improve the
> documents, and
> also build consensus, assuming these individuals joined the SUO WG.
>
> 2. The improvements would matter to at least one organization
> that is actually building something that needs the
> improvement. This is
> important, because the quantity of these improvements is hopefully
> feasible to handle, whereas, the quantity of 'improvements
> for the sake
> of improvement' is infinite and would prevent completion and
> balloting of
> a document.
>
> 3. As the number of users grows, the document moves
> closer to a
> market-accepted de facto standard. IEEE approval will not be enough.
> Some level of market adoption must be achieved.
>
> So, how do get organizations to attempt to reuse any of our
> documents? Or, if they are doing so, how do we get them to
> submit their
> suggested changes?
>
> Any thoughts?
>
> Jim Schoening
>
> ________________________________________________________________
> The best thing to hit the internet in years - Juno SpeedBand!
> Surf the web up to FIVE TIMES FASTER!
> Only $14.95/ month - visit www.juno.com to sign up today!
>
>