[sc34wg3] FYI: Contexts (was Classes vs. Instances)

[Mason, James David (MXM)]

-----Original Message-----
From: standard-upper-ontology at ieee.org
[mailto:standard-upper-ontology at ieee.org] On Behalf Of John F. Sowa
Sent: Friday, April 21, 2006 2:59 PM
To: standard-upper-ontology at listserv.ieee.org; cg at cs.uah.edu
Cc: Nigam Shah; 'Paul Prueitt'; 'Alan Ruttenberg'; 'Paul J. Werbos';
bniemann at cox.net
Subject: Re: Contexts (was Classes vs. Instances)

Folks,

This discussion about the problems of adding context information and other
features to OWL illustrates some fundamental principles:

  1. A notation that is deliberately restricted in order to
     facilitate one kind of algorithm is not likely to be
     particularly good for purposes other than the one that
     the notation was specifically designed to handle.

  2. OWL and other DLs are optimized for one kind of inference
     engine.  Prolog, SQL queries, and some rule-based systems
     are optimized for backward-chaining inference engines.
     CLIPS, SQL triggers, and other kinds of rule-based systems
     are optimized for forward-chaining inference engines. Still
     other notations are optimized for other kinds of inference
     engines, statistical methods, learning methods, etc.

  3. Although I have often been critical of some of the design
     choices underlying Cyc, I do support their idea of letting
     the knowledge engineers focus on representing knowledge in
     the most natural way for the application domain, and not
     forcing them to suboptimize their representation for some
     particular algorithm.

  4. The differences between different versions of logic, such
     as propositional logic, Aristotle's syllogisms, binary
     relations vs. n-ary relations, description logics, Horn-clause
     logic, first-order logic, higher-order logic, modal logics,
     metalevel logics, context logics, etc., can be recognized
     very quickly and efficiently by a simple syntactic analyzer.

  5. There's no need to force users who don't know logic very well
     to anticipate what inference engine should be used for their
     problems and to shoe-horn their thinking into some predefined
     pigeon holes.  Instead, let them use the form of expression
     that is the most natural for them.  Then let the computer
     analyze those expressions and select whatever subset of logic
     and whatever inference engine is suitable for the problem at
     hand.  In fact, it's possible to have a dialog in which the
     users and the system negotiate and modify the representation
     through a cooperative design collaboration.

  6. That is roughly what Cyc does:  provide a very general notation
     that is supported by a variety of different inference engines.
     Given any particular problem, they let the system determine
     which subset of logic to use and what inference engine(s) to
     apply.  My criticisms of Cyc are not that they should restrict
     their notation, but rather that they should be even more general
     and more flexible in the options they support.  Among other
     things, I would put more emphasis on induction, abduction,
     and analogy.  (I wouldn't discard deduction, but I'd treat
     it as just one of many methods of reasoning.)

  7. And by the way, Cyc does support a version of contexts and the
     option of having multiple contexts with different subsets of
     the knowledge base available in each.  It also supports metalevel
     reasoning about the contexts and what knowledge is available
     or should be added to any of them.

Although I have been critical of Cyc, I am even more critical of the Semantic
Web because that has gone in the *opposite* direction.
Instead of learning from Cyc and doing something better, they have gone back
to the pre-1984 technology that was the starting point when the Cyc project
was begun.

Cyc isn't the only thing that the SemWebbers ignored.  They also ignored the
lessons of SQL and UML -- two widely used technologies that are not as good
as they should have been.  Those two systems have not been improved, partly
because the available tools have been constrained by the requirement for
backwards compatibility.
But the SemWeb broke compatibility without making any advances.

The SemWebbers try to excuse themselves by saying that they are trying to do
something less ambitious than Cyc in expressive power, but more ambitious
than Cyc in the amount of data they process.
But that sounds like Bush trying to explain the Iraq War.

In fact, no design study for the SemWeb or Iraq examined all the options in
order to determine what should be done or how to coexist with and
interoperate with other systems.  The *only* design document that was used
for the SemWeb was Tim B-L's layer cake, which proposed Unicode, URIs, and
XML at the bottom and expressed the hope that magic would somehow occur at
the top.
Unfortunately, there's no magic in either Iraq or the SemWeb.

There's a lot more that could be said, and following are some pointers to
related reading.

John Sowa
__________________________________________________________________

The following slides discuss the continuum between informal and formal
knowledge representations and some of the issues of mapping one to the other:

    http://www.jfsowa.com/talks/cmapping.pdf

An analysis of the problems of knowledge representation in general and some
of the limitations of current approaches:

    http://www.jfsowa.com/pubs/challenge.pdf

A paper on contexts, metalevel reasoning, and modal logic:

    http://www.jfsowa.com/pubs/laws.htm