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.
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.
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.
4. Database views are expressed as Horn-clause statements. 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.
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):
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.
> 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. 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.
> 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.
> 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.)
> 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. And if the semantic web is limited
to that subset, it is guaranteed to be obsolete before it even gets
off the ground.
John Sowa