Re: (biassed) summary of the argument so far.

sowa <>
Date: Tue, 8 Jun 93 07:17:20 EDT
From: sowa <>
Message-id: <>
To: interlingua@ISI.EDU,,
Subject: Re:  (biassed) summary of the argument so far.

I would like to wind up this round of discussions, but it is hard to
comment on some points without bringing in new issues that are likely
to spawn further rounds of discussion.

>Just to reiterate: the application of set theory to domains does not, 
>in my view, involve questions of recognition. Of course you are right 
>that visual recognition is a difficult problem: but irrelevant.

To reiterate:  the application of any mathematical theory, including
set theory, to any domain (e.g. carpentry, bridge building, or
counting apples) presupposes some way of recognizing the individuals
and measuring the quantities to which the variables apply.  That "way",
which may be trivial for counting apples, less trivial for carpentry,
and far from trivial for quantum mechanics, is not part of the mathematical
theory, but of the domain to which the theory is being applied.

> ... I also, by the way, 
>have a longstanding belief that 'new' representational ideas are 
>often just old ones in new computational guise, and make it my 
>business to burst such bubbles.

That is an honorable practice, one with which I am in complete sympathy.
But it is also important to recognize distinctions that might not have
been clear in the older forms.  For example, it is traditional to
distinguish propositional calculus from predicate calculus.  That is
a very useful distinction.  But there is another subset that is rarely
discussed in logic books, but which has important computational and
semantic properties:  the subset of logic that has predicates, but only
constants and existential quantifiers, and conjunction as its only
Boolean connective.  This subset is semantically important because it
is capable of describing everything that exists, but it is not capable
of stating any generalizations.

Computationally, it is extremely important -- so important that it
keeps getting reinvented under many different guises.  C. S. Peirce
invented it for his relational algebra of the 1870s (before he invented
quantifiers), and it formed the basis for his relational graphs of the
1880s (before he added negations to form his existential graphs).
It is also the basic subset of logic stored in commercial databases,
whether they are organized in a relational or network form.  And it
was reinvented many times in AI:  it is the basic logic of Schank's
conceptual dependencies (although he would never use the term "logic"
for it) and it is the basic logic of many frame systems.  (Although
for frame systems, it is important to distinguish the definitional
component, which does provide the ability to state some generalizations,
>From the instantiations, which only give you existence & conjunction.)

The point of this longish digression is that new representations often
highlight certain views, perspectives, or structures that may not be
obvious in other representations.  Translating such representations to
a more traditional logic is an important step in understanding them,
but I wouldn't call that "bursting the bubble."  And it is equally
important to recognize the insights that might be more readily
expressed in the new representation that are obscured by predicate
calculus.  (Remember that C. S. Peirce invented the now "traditional"
form of predicate calculus 13 years before he switched to graphs,
which he believed were better suited to showing the structure of logic.)

> ... The frequently cited idea of
>'image-like' as opposed to 'language-like' representations is often
>such a bubble, in my view....

I would say that is much more than a bubble, but I don't want to get
into another argument about it.

>But then there is no need for this term. If you are simply talking about a 
>model(-theoretic model), use the established vocabulary. "Depiction" 
>also has connotations of being image-like, of being computationally 
>useful, of having been invented by J.Sowa (another use-mention confusion :-), 
>and so forth.

If you recall a few months back in these discussions, I was using the
term "model", but I switched to "depiction" only because I was being
accused of using models for purposes for which they were not "intended".

> ... However, it has the problem (compared 
>to the view of a database as a vivid representation, ie as encoding 
>ground facts) that it seems not to capture the intended content....

You keep using that word "intended" in a way that seems to suggest
that it's wrong to use a formalism in any way that is different from
the original inventor's.  In any case, commercial databases evolved
>From file systems, which were "intended" to store and retrieve data
that was manipulated by programs that were written by people who had
little or no knowledge of logic.  Ted Codd was responsible for
introducing some logic into database theory and practice, but most
of the people who use relational databases today use them as little
more than fancy file systems.  To claim that commercial databases 
were "intended" to be used like AI theorem provers is ridiculous.

>Not IN Kif, but you did seem to want to stop people saying some 
>things ABOUT it, which is where I came in.

I was suggesting some new ways of looking at things, which I thought
clarified and simplified certain issues.  I wasn't "stopping" anything.

> I should say that Mike Gensereth indicated that there is a more 
>substantial reason for the inadequacy of the single-nest syntax. 
>He wants to allow one bound variable to  vary over the range of 
>an inner variable, so one can write soeming that means something 
>like 'for all x, whatever its sort is,...", as in for example 
>(using the double-bracket convention):

> (forall ((?x set1) (?y set2)) (forall ((?z ?x)) ...))

>Here the final occurrence of ?x is bound by the first forall, 
>not the second: compare it with 

> (forall ((?x set1) (?y set2)) (forall (?z ?x) ...))

> where the first ?x is vacuous.

Yes, but for that construction, I had suggested the keyword "in"
as a separator between the variable that is being declared and the
variable that designates the set:

   (forall ((?x set) (?y set)) (forall (?z in ?x) ...))

This notation allows you to use the simple notation for type
declarations, and the keyword "in" is much more readable and less
error prone for humans than multiply nested paren's.  (To avoid
making "in" a reserved word, you could have the parser check
whether it was followed by a right paren.)