Rich, (01)
That is what I said: (02)
RC> I don't see SQL as more difficult to write type hierarchies
> in than FOL... (03)
But there are many different ways to use FOL to support type
hierarchies. Systems that are designed to support types provide
one good way, and they provide tools, notations, and methodology
that way the path of least resistance. (04)
RC> Why would a different form of FOL than SQL be any better at
> type hierarchy development? Explanation appreciated if provided. (05)
For example, following is a "constraint" stated in controlled
English. To illustrate the difference, I'll map that constraint
into typed and untyped predicate calculus: (06)
For every company c,
exactly one manager in c is the CEO of c;
every employee of c except the CEO reports to the CEO;
the CEO of c does not report to any employee of c. (07)
Typed predicate calculus (using A for the universal quantifier,
E for the existential quantifier, and E! for exactly one): (08)
(A c: Company)
(E! m: Manager)(in(m,c) & CEO(m,c)) &
(A e: Employee)((in(e,c) & e?m) -> reportsTo(e,m)) &
~(E e1: Employee)((in(e,c) & reportsTo(m,e1)) )) (09)
In untyped predicate calculus: (010)
(A c)(Company(c) ->
(E! m)(Manager(m) & in(m,c) & CEO(m,c)) &
(A e)((Employee(e) & in(e,c) & e?m) -> reportsTo(e,m)) &
~(E e1)(Employee(e1) & in(e1,c) & reportsTo(m,e1)) ))) (011)
Some observations: (012)
1. The number of keystrokes for typed PC is slightly less than
for controlled English, and the number for untyped PC is
slightly greater. (013)
2. But the readability of controlled English is vastly greater
even for logicians who know the notations very well. (014)
3. With suitable tools for supporting controlled English, it's
possible to derive the type hierarchy and constraints from
a notation that can be read by the domain expert. (015)
4. My recommended notations for human users are versions of
controlled English (or other natural languages) supplemented
with diagrams (such as the UML diagrams and others). (016)
5. My recommended notations for computer processing are
Common Logic as a general interchange language, which can
be translated to a wide variety of computer-oriented
notations. For example, see the diagram in slide 5 of (017)
http://www.jfsowa.com/talks/cl_sowa.pdf (018)
RC> So optimization is only good for restructurable queries without
> real time constraints. (019)
There are three kinds of optimizations: (020)
1. Static improvements that can be determined from the statement
of a program in a language such as C or Fortran and the
knowledge of the hardware to which it is translated. This
kind of optimization was done very well for the original IBM
Fortran compiler in 1958. (And by the way, many compilers
written today don't optimize the code as well as that old
1958 Fortran compiler, but some are far more sophisticated.) (021)
2. Dynamic optimizations that take into account the environment
and data at the time the code is executed. This is the
kind of optimization that has been applied to SQL queries
since the 1970s. It is necessary because the same WHERE
clause in SQL may have to use different data accesses to
optimize the code for different keys and indexes on the DB
tables and different sizes of the tables. Today's optimizers
by IBM, Oracle, and others can produce very good code. (022)
3. Data replication, restructuring, etc. I agree that current
SQL database systems don't do that, and the SQL tools are
not set up to do that. But such optimizations could be
implemented in new systems, at least in a semi-automated way. (023)
RC> Database replication ... is a commonly applied method that
> is completely beyond the abilities of the optimizers. (024)
I agree that current optimizers don't do it, but it can be done. (025)
RC> Generating English from the database seems to be about as
> hard as translating English statements into database updates.
> Technical manuals are usually way behind the latest changes,
> and provide relatively unreliable information for most projects. (026)
You didn't read the slides and the published papers that they
pointed to. I did not say that we translated English to DB
updates. That legacy re-engineering project first analyzed
the COBOL and SQL code. Then it *related* the English
documentation to the code in order to check for inconsistencies.
And it flagged those inconsistencies. (027)
It also found statements in the documentation that correctly
described the data and file structures. Those were the ones
that were put into the English glossary. (028)
That was not a research project. It was project that a major
consulting firm estimated would take 40 people 2 years (for
80 person-years of effort) to study the documentation and
compare it to the COBOL code. But with the VivoMind software,
it was completed in 16 person-weeks. (029)
John (030)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (031)
|