RE: SEMIS Bulletin
Dear John,
Some points below.
Matthew West
Streamline Business Information Architect for Supply Chain Management
Shell Information Technology International Limited
Shell Centre, London SE1 7NA, United Kingdom
Tel: +44 20 7934 4490 Mobile: +44 7796 336538
Email: matthew.west@shell.com
Internet: http://www.shell.com
http://www.matthew-west.org.uk/
> -----Original Message-----
> From: John F. Sowa [mailto:sowa@bestweb.net]
> Sent: 27 May 2004 04:16
> To: Michael Gruninger
> Cc: cg@cs.uah.edu; artem@cs.wayne.edu; cl@philebus.tamu.edu;
> standard-upper-ontology@listserv.ieee.org
> Subject: 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.
MW: I would not characterise SQL as a "simple" data modelling
language. I agree SQL and EXPRESS have similar capabilities.
A simple data modelling language is say a purely graphical
language like Entity Relationship diagrams.
>
> 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
MW: Be careful with this. This is for EXPRESS-X, which is
a language extension to specify the mapping between EXPRESS data
models.
MW: For people with MS Visio there is a free download from
EuroSTEP for creating EXPRESS models using Visio. Included
in this package is a help file with a good description of the
EXPRESS language. This add in was written by the principle
author of the standard. For details see:
http://www.eurostep.com/ and follow dowload, software in the
menu.
>
> 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;
MW: This is defining a view on an existing data model, not
the definition of the model itself.
>
> And following is a statement that Philip's mother
> in law is Queen Mum:
>
> #380=MOTHER_IN_LAW ('Philip', 'Queen Mum', #20);
MW: This is an instance of the view above expressed according
to ISO 10303-21, or just Part 21.
>
> 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
MW: Formally the EXPRESS Language Reference Manual is
ISO 10303-11.
>
> John Sowa
>