[Top] [All Lists]

Re: [ontolog-forum] Is there something I missed?

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "John F. Sowa" <sowa@xxxxxxxxxxx>
Date: Sun, 01 Feb 2009 01:12:56 -0500
Message-id: <49853D68.7040104@xxxxxxxxxxx>
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)

<Prev in Thread] Current Thread [Next in Thread>