RE: SUO: What the marketplace needs from us.
Hi John;
> -----Original Message-----
> From: John F. Sowa [mailto:sowa@bestweb.net]
> Sent: Wednesday, April 30, 2003 2:54 PM
> To: Eric Peterson
> Cc: standard-upper-ontology@ieee.org; cg@cs.uah.edu
> Subject: Re: SUO: What the marketplace needs from us.
>
> Eric,
>
> To a certain extent, I agree with your conclusions about what kinds
> of ontological representations are the easiest to relate to current
> programming practice, especially the O-O languages such as Java.
>
> But if you look at relational databases, you will find representations
> that require full first-order logic. And there are new technologies
> that could become commercially more significant if the ontologies
> supported a richer subset of logic.
>
> In your note, you started with a statement of part of the problem:
>
> > My customer needs to tie together large numbers of structured
> > data sets into one seamless analytical environment. They need
> > to share that seamless picture with other groups.
>
> But the next sentence is not a statement of the problem, but
> an assumption about one particular kind of solution:
>
> > They need a robust object model to support such
> > a seamless environment.
[ELP] Here is my rational:
A relational data model will not yield OO classes for our Java
programmers without a lot of hard work.
An ontological data model would be my choice but is a hard sell.
Relational and object relational schema can be derived automatically
from an object model.
I stand by my asserted assumption.
>
> If the object model is similar to current O-O languages, then
> that would explain the interpretation of what you saw:
>
> > To that end, Im not looking for, Horn clauses or free form axioms.
> > Im looking for what I call structural axioms. Structural axioms
> > specify the object-oriented subset of a logical theory -- namely
> > entities, type inheritance, other relations, relation argument
> > typing (arg x Isa), etc.
>
> Popular O-O languages, such as Java, are based on declarations of very
> limited expressive power. Everything else must be represented in
> procedural code. But if you were using an object-oriented Prolog or
> other logic-programming system, you would find that most of the
procedural
> code in Java would be represented by Horn clauses.
[ELP] I don't at all disagree. But I'm not yet that good of a salesman.
>
> I admit that logic-programming languages have not yet made much of a
dent
> on the programming community, but relational databases, which support
> the world economy, are giant logic-based systems. And, by the way,
> when Ted Codd learned about Prolog, his first reaction was "I wish
> I had invented that!" Following is the kind of logic used in an RDB:
>
> 1. The database itself is a large collection of ground-level clauses,
> which use the existential-conjunctive subset of logic (the only
> operators are existence and conjunction).
>
> 2. Negations are supported, as in Prolog, by a failure to prove.
>
> 3. Queries and constraints can be stated in full first-order logic.
[ELP] I think we need to distinguish between state and the changing of
state. Our hundreds of relational data sources that we are sewing
together don't include stored procedures, or anything having to do with
state change. My experience in this area leads me to find the idea of
federating anything but extensional state as rather exotic.
>
> 4. Database views are expressed as Horn-clause statements.
[ELP] I missed that page in the Oracle 9i specification ;^) I'll agree
that they could be. But regardless, please see below.
>In SQL,
> the "create view" statement defines a "virtual relation" in terms
> of a "where" clause that can use full FOL. Every "create view"
> statement can be translated directly to a Horn clause in Prolog.
[ELP] Database federators needn't (and I would claim shouldn't) care
about much beyond the DB's extensional interface (table definitions).
And if an unmaterialized view acts like a real table, then it can be
treated as like a table. I claim that the means of its creation are
irrelevant to federation. Materialized views, of course, are tables.
>
> Database design and interchange is a very important part of software
> development, and if your ontology supports full FOL, you can derive
> your data definitions, constraints, and views automatically from the
> ontology. And by the way, such derivations are not "blue-sky" theory.
> Following is a paper in which RDB definitions were derived from Cyc
> axioms, which were originally stated in full FOL (using CycL):
[ELP] I was writing Cyc axioms and automating the translation of
flat-file data into Cyc for the early part the project you reference.
But let's remember that we were using a XSB (D.S. Warren's Prolog with
well-founded semantics) as the ultimate target. Section 2 of the paper
states that XSB has an interface to RDBMSs, and that *future versions*
would use the interface. If I were as good of a persuader as Bill
Anderson, I would consider selling my customer on using some version of
Prolog for some of what we are doing. Right now one of my top
priorities is getting my customer to simply sign off on an OODB trial
effort. OODB's have been on the market for about a decade and I'm
struggling hard with even that sell.
[ELP]
>
> Peterson, Brian J., William A. Andersen, & Joshua Engel (1998)
> "Knowledge bus: generating application-focused databases from
> large ontologies," Proc. 5th KRDB Workshop, Seattle, WA.
>
> The authors of that paper commercialized their technology in founding
> the company called OntologyWorks. (See ontologyworks.com) They
> derived Java declarations from the Cyc axioms, but they also derived
> full FOL constraints for the RDB, and they derived Horn-clause code
> for a deductive front end to the RDB.
[ELP] Their work deserves serious attention. They may easily be the
brightest real ontologists/engineers that I've worked with or
encountered.
>
> > They need an upper ontology from which to derive our object model.
> > To me, an upper ontology means chiefly the structural axioms
starting
> > with "Thing" and descending the inheritance lattice a relatively
small
> > number of levels. The focus of that ontology is the actual domain
> > entities such as people, events, places, but includes other
entities
> > and relations needed to properly specify and utilize the these
> > domain definitions.
>
> Yes, that is useful for Java declarations. But it won't express
> database constraints, which require FOL, and database views, which
> require Horn clauses.
[ELP] I'm not sure why I would want to - in the near term - federate
anything but the extensional subset of a relational DB. I have way too
many DB's to federate to worry about peaking in beyond the public
(extensional) APIs. I would be embarrassed to ask anyone for their
store procedures and triggers. That's just not done in the circles I
travel in ;^) And how would knowing the details of how a view was
constructed help me federate the view itself?
> If the ontology language cannot express
> anything beyond that subset, your predictions will be self-fulfilling:
> nobody will ever use a richer subset because their languages won't
> allow it.
I view the structural subset of an ontology as a foundation that must be
in place before adding other axioms. But I'm ***not*** talking about
hobbling the expressive power of the ontological language. I'm talking
about doing first things first.
>
> > Please give us the simple structural definitions with which we can
> model
> > our domains. Horn clauses are wonderful, but they havent yet made
much
> > of an impact on the market place since I first encountered them as
> > an undergraduate a couple of decades ago. And if the marketplace
isnt
> > ready for Horn clauses, it certainly isnt ready for more
sophisticated
> > free-form axioms.
>
> The database marketplace has been using FOL and Horn clauses for the
past
> 30 years. I think its time for the rest of the world to take notice.
We both know the RDBs do not use full FOL or Horne clauses. Oracle does
not support anything resembling the full power of Horne logic - let
alone FOL. Our ability to translate RDB query and definitional syntax
into Horn clauses doesn't support your point in any way that I can see.
And the fact that a relational query based on such syntax behaves
consistently with Horn logic doesn't mean full Horn logic. The same
could be said of an "if <a> then <b>." statement in Fortran.
It would take one seriously qualified fairy God-mother to transform
relational SQL into Horn logic. And I'm not seeing how the subset of
horn logic whith which it behaves consistently, will help me translate
the Horn rules in my ontology. How would I encode "All men are mortal"
in a RDB?
>
> > In the commercial world, Ive found the need to be the same. When
> > Deborah McGuiness helped VerticalNet to set up their ontology
group,
> > she advised the same structural subset of logic. Pat Cassidy and I
> > worked in that ontology group (for Leo Obrst) where we oversaw and
> helped
> > with the knitting together of multiple product catalogues into one
> > seamless product picture.
>
> You have to recognize that Deborah is a member of the Description
Logic
> community, and the DL thought police immediately excommunicate anyone
> who mentions Horn clauses or FOL. (Just ask Bob MacGregor.)
[ELP] That may make them excusive, but it doesn't make them less
relevant to the market place.
>
> > So Im suggesting that if we are not focusing on structural axioms
we
> are
> > not giving the marketplace what it really needs or will soon fund
> seriously.
>
> I have nothing against using the DL subset for legacy applications.
> (And we certainly need to support legacy applications.) But that
subset
> cannot support relational databases.
[ELP] Clearly the extensional structure of RDBs is subsumed within the
OO class definition structure. So, clearly, the extensional subset of
the relational DB can be supported. But maybe I'm missing something in
your claims about federating the intensional DB.
> And if the semantic web is limited
> to that subset, it is guaranteed to be obsolete before it even gets
> off the ground.
I was surprised not to find more expressive power in DAML. I want that
expressive power as much as you, but I feel constrained by the current
needs of my customer and what I perceive to be the needs of the
marketplace. But maybe Jim Hendler would argue that FOL can be
backfilled into DAML and that he was merely focusing on the realities of
DARPA's and the US DOD's needs.
Thanks for taking time to comment,
-Eric