While I like the simplicity of Ullman's proposal, I don't think it will fly
commercially. Given that I can do more with SQL based systems (including
complex data transfer between distributed systems), I don't know why this
technology/language will be picked up in the market place. 

Comment on Hull's requirement list and KQML/KIF

I like the enumeration of the requirements that Rick has placed. These were
the requirements we addressed with our implementation of a KQML server. Here
is my sales pitch on our implementation of KQML.  Our implementation of KQML
for anybody doing research is free (source code distribution). In addition,
it is actually integrated with relational databases through ODBC, will be
integrated with CORBA. Finally, our work at OMG may allow us to be in the
lead with implementing whatever is approved through the OMG spec. process.
For all this reason, the community of researchers may want to think about
using LogicWare. 

Additionally, our experience in supporting the requirements outlined by Rick
led us to a different implementation path than the one he proposes w.r.to
using subset of KIF. 

On data and knowledge transfer:

We looked into integrating several different types of information sources
when we implemented our KQML server. This included 

        - information from product databases whose ontology was expressed
using PDES/STEP EXPRESS

        - information in object databases but accessed through OQL like
interface

        - information in Open OODB database

        - information in relational databases but accessed through OLE
object interfaces 

        - information in Compound Document file systems (Apple Bento)

        - information in Compound Document Databases (Lotus Notes)

        - information in WWW

        - information in knowledge bases in tools such as KEE or ART

All of these types of information/knowledge sources provide a more or less
object oriented interface. All of the commercial world is moving to
providing object oriented models of information in different types of
repositories. Successful knowledge based system tools use frames. The
easiest and simplest way to deal with information in these databases was not
by using an intermediate language that was based on predicate calculus, but
one based on frames. Therefore, we implemented a Simple Object System that
removes lots of the extraneous stuff that AI frame people did (for
performance and other reasons) on top of a subset of MIT scheme. This makes
the core information and knowledge transfer language small, tight, and
easily implementable by other developers. The whole server can run in a foot
print of less than 500k on Windows machines. We call the language SIMPLE. We
use KQML to support information transfer between distributed copies of
SIMPLE servers (internal name Sloth - lazy evaluated Scheme). 

Since MIT Scheme can support continuations as full class objects, it is very
easy for us to think about supporting behavior transfer (i.e., mobile code
with state). While we have not implemented this functionality, we can do it
very easily or any one of you could do it also.
 
Therefore, what I would like to recommend as a basis for developing the
information integration language is our system - LogicWare. It runs on all
the platforms you would want it to run on and there is team people who will
support it for you. This way you all can focus on the core added value that
the information integration language brings. My belief is that the core
value added will be in the area of the appropriate programming metaphor
supported by the language.



Sankar Virdhagriswaran                         Phone: (508) 287 4511
Crystaliz Inc.                                 Fax:   (508) 287 4512