Re: SEMIS Bulletin
Folks,
I would like to endorse Bill Burkett's comment:
BB> One point I will strongly echo from my STEP experience
> is Pete Kirkham's observation: the SW/W3C community has
> no idea how difficult it is to obtain agreement on a
> common understanding of the meaning of elements of
> a data standard.
There are four problematical words in that statement:
"agreement", "common", "understanding", and "meaning".
The hardest step is going from a vague notion to a
clear specification of a single person's "meaning"
or "understanding" in any language. The presence or
absence of a formal model theory or inference engine is
totally irrelevant to that first, most difficult step.
It does not make any difference whether you use KIF,
CGs, OWL, predicate calculus, SQL, or EXPRESS -- that
first step is just as hard with any of them.
If that first hurdle has been overcome, the next step
of getting "agreement" on a "common" representation
is not easy, but it's more manageable. If you have
two or more precise definitions of the term Widget,
you can often reach agreement by defining a general
Widget type as a common generalization and defining
A-Widget, B-Widget, and C-Widget as subtypes. People
might still disagree about which subtype is best,
but at least they know what they're talking about.
Inference engines can be very helpful in checking
specifications for consistency and in classifying
the specifications according to types and subtypes.
However, the people who have been doing practical
work have not found "reasoning" to be important.
I believe that there is a simple explanation:
1. It is a theorem of model theory that any set of
first-order axioms (i.e., specifications) for
which there is a formal model must be consistent.
2. The people who are doing practical work with SQL
and EXPRESS almost always begin with concrete
examples of the kinds of things they are trying
to specify.
3. Those examples, when translated to ground-level
assertions, constitute a specification of a formal
model for which the axioms are true.
4. Therefore, the methodology used by most users of
SQL and EXPRESS guarantees that their axioms are
consistent, and there is no need for a theorem
prover to confirm that point.
Although I do believe that work on decidability and
complexity is valuable, I don't believe that an
inference engine is absolutely necessary for many
practical applications.
BB> I do think that STEP has a long lead in trying to do
> the kinds of things that are described as goals of the SW,
> but it didn't have an "entire infrastructure" focus. The
> objective of STEP was to define a standard data format
> for (initially) exchanging a complete product specification
> between hetergeneous CAD/CAM systems (though the objectives
> have grown substantially over the years)...
I agree that very few groups have "an entire infrastructure
focus", but all these groups inevitably interact -- even
within a single business, the financial people talk to sales
people who talk to manufacturing who talk to engineering who
talk to research who talk to finance. Different groups might
focus on different aspects, but there is no clear partitioning
of the subject matter.
BB> EXPRESS is billed as an "information modelling" language,
> but is basically (IMHO) just a data modelling language. It
> is a synthesis of object and ER modelling concepts and does
> not have any formal logic basis - or at least that was not
> a design intent. That EXPRESS has the power of FOL (as John
> observes) I am guessing is a by-product of the ER/relational
> influence on the language design....
Three comments:
1. Manufacturing deals with physical objects, but any
description, classification, or enumeration of those
objects is inevitably going to be information or data.
So all of these notations will deal with data.
2. I agree that the EXPRESS designers didn't intend to use
logic, but they did intend to be precise. And precision
in any language, including English, means that you're
using the basic words of first-order logic: SOME, EVERY,
AND, OR, NOT, and IF. You can't escape logic (at least
informally) and still have an implementable specification.
3. In the example below, I comment on the similarity between
EXPRESS and SQL, which is not an accident.
I mostly agree with Matthew West's comments. I'd just like to
make one remark:
MW> "Simple" data modelling languages have essentially the
> same power as Description Logics. However, EXPRESS has a
> constraint language as well, and this raises the power to
> something close to FOL.
I would say that the difference is how much knowledge about
the subject matter you decide to include in the specification.
I have no quarrel with using DLs for some useful subsets, but
the database people have demonstrated that the SQL version of
FOL is essential for the constraints and queries that arise
in a very wide range of applications. Futhermore, they have
demonstrated that it can be efficiently implemented and used
on gigabytes and petabytes of data.
Michael Gruninger wrote:
MG> I have never seen a proof of any characterization of the
> expressiveness of EXPRESS. I have never seen a model theory
> or a proof theory, either, so I don't know how you can
> formally talk about EXPRESS inference tools.
A few years ago, I had been working on standards committees
with Jim Fulton from Boeing, who is very familiar with logic,
KIF, and the EXPRESS/STEP work. He was well aware that most
people working on EXPRESS are not familiar with logic, but
he also showed that EXPRESS was capable of expressing logical
constraints, although in a rather clusy SQL-sort of way.
I am not aware of any publication that gives a formal proof
of equivalence and certainly not a model theoretic foundation.
Jim was interested in using KIF for that purpose, but I think
Boeing management was not interested in supporting that effort.
In any case, I suggest the following tutorial for examples:
http://www.steptools.com/library/express-x/e-x-ch1.pdf
Following is an exerpt from that tutorial, which defines a
mother_in_law relation (which is called a VIEW):
VIEW mother_in_law;
FROM him, her:subject, birth:issue, knot:union
WHERE knot.husband :=: him;
knot.wife :=: her;
birth.child :=: her;
NOT EXISTS (knot.end_date);
SELECT
man : label := him.forename;
woman : label := her.forename;
mum_in_law : subject := birth.mother;
END_VIEW;
And following is a statement that Philip's mother
in law is Queen Mum:
#380=MOTHER_IN_LAW ('Philip', 'Queen Mum', #20);
I am not an expert in EXPRESS, but given its similarity
to SQL, its use of EXISTS as an existential quantifier,
FOR EACH as a universal quantifier, and the Boolean
operators AND, OR, and NOT, I would surmise that it is
at least as expressive as SQL, which can state an
arbitrary first-order constraint or query.
Following is a draft of the EXPRESS-X Language Reference
Manual:
http://www.steptools.com/library/express-x/n088.pdf
John Sowa