[Top] [All Lists]

Re: [ontolog-forum] History of AI and Commercial Data Processing

To: "John F. Sowa" <sowa@xxxxxxxxxxx>
Cc: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Ed Barkmeyer <edbark@xxxxxxxx>
Date: Mon, 29 Jun 2009 17:08:22 -0400
Message-id: <4A492D46.6060607@xxxxxxxx>
John,    (01)

Yes, we have very different ways of saying things, and very different 
emphasis, I think.    (02)

you wrote:    (03)

> LISP is the result of addressing problems that are far more complex
> than the ones for which COBOL and FORTRAN were well adapted.     (04)

LISP was designed with a paradigm suitable for different problems.    (05)

COBOL was designed to be readable by business persons, particularly 
those in financial operations.  And I agree that most of those problems 
were simple in concept.  But it is that class of problem, and the COBOL 
"record" approach to solution, that gave rise to database technologies.    (06)

FORTRAN was designed to do engineering mathematics, and many such 
problems are not "simpler" than AI problems.  The trick is in converting 
the real-world problems to problems that can be solved by numerical 
approximations to the calculus.  FORTRAN was also widely used for 
Operations Research methods in the 1960s and 70s.  (A group I worked 
with used it to solve shortest-path problems and relaxation problems.) 
Around 1960, FORTRAN replaced assembly language as the dominant language 
for the image analysis community.  And FORTRAN was the basis for 
SIMSCRIPT -- the American rival for Simula -- as an early discrete 
simulation language.  (And while I would never claim that it was the 
best tool for the job, I used Fortran for my first major programming 
application -- an expert system: a program for assigning matches in a 
chess tournament using the Swiss system, for the U.S. Intercollegiate 
Chess Championship of 1963.)    (07)

My view of programming has always been that you design an algorithm for 
solving the problem at hand.  Then you determine a rendering of that 
algorithm into the language available.  Some languages make some 
algorithms easier to phrase.  But, as long as the language has functions 
and some complex information structures, you can create a "service 
language" (a function library) that makes phrasing the algorithms 
workable.  With differences in pomp and circumstance, that is what good 
LISP programmers do, and it is the heart of "object-oriented programming".    (08)

> Without AI research, LISP would not have been invented,    (09)

I suspect that is true.  But that same era gave us IPL5 and SNOBOL and 
other languages with non-Algol paradigms.  And all of those were about 
something we would now call AI.    (010)

> but by the mid 1990s,
> the state of the art had progressed to where LISP in C clothing
> (i.e., Java) became a very successful language.    (011)

For a change, I won't disagree with this at all. ;-)  OTOH, I think most 
software engineers would be shocked by John's assertion that Java is 
"LISP in C clothing".    (012)

John's contention echoes my observation above -- that the "semantic 
distance" between LISP and OOPLs is not that great, although the 
languages have radically different terminologies and grammars.  The 
unifying concept is "applicative programming".  Java is an inherently 
procedural language that is designed to allow programmers to create an 
applicative function language and to write applicative statements.  LISP 
is an inherently applicative language.    (013)

The observation I would make is that not all AI is primarily applicative 
programming.  There are whole segments of AI that are all about 
probabilities and statistical algorithms, and in those areas, Java is 
barely adequate and LISP is poor.  (And that is because the languages 
designed to support such algorithms were Fortran and later C; and the 
high quality function libraries are written in and for those languages.)    (014)

> ...
> Yes, I believe that the technology for extracting information
> from texts in an automated or semi-automated way is rapidly
> developing.  I believe that our little company has some leading
> edge products, and we're trying to stay ahead of the pack.
> In any case, I think the pack is not very far behind.  When
> the products start coming out, they will make hand-written
> ontologies like Cyc as obsolete as tables of sines and cosines.    (015)

I'm not so sure.  Even assuming the extraction is reliable, and 
self-testing, the problem is to find text that was written with the same 
kind of discipline and attention to consistency that has been lavished 
on carefully crafted ontologies.  Scientists tend to write that way, 
because it is part of their discipline to make no claim broader than 
what is supported by the evidence and analysis.  But in many other 
trades, including many engineering disciplines, insight and 
generalization is the hallmark of the respected texts, even though the 
authors acknowledge that there are many exceptions.  The idea is to 
cover 90% of the cases with a few useful concepts, promoting an 
understanding of the domain that isn't confused by a wealth of details. 
  And the best texts identify the warning signs for exceptional cases as 
well.  But for ontologies, there is no For90% x qualifier (except in 
fuzzy logic).    (016)

A colleague pointed out to me that biologists are uncomfortable saying 
things like "every X is a Y".  They prefer to say, "an X is considered 
to be a Y".  What they mean is: "Every X has all the properties of Ys 
that we know about or care about.  But it is possible that we will 
discover some obscure common property of Ys that Xs don't have, or that 
the biophysical way in which X actually exhibits some property is very 
different from most Ys."  That is the scientist's discipline.  It is a 
problem for those who take an epistemological view of ontologies.  It is 
much less a problem if we consider ontologies to be knowledge engineered 
to some purpose(s) at some time.  Upon reflection, many respected texts 
constitute knowledge engineered to a purpose (and time).  And as such, 
they are just as good as any other carefully crafted ontology.    (017)

-Ed    (018)

Edward J. Barkmeyer                        Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263                FAX: +1 301-975-4694    (019)

"The opinions expressed above do not reflect consensus of NIST,
  and have not been reviewed by any Government authority."    (020)

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    (021)

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