Date: Wed, 6 Sep 95 15:34:03 -0700
From: Jeff Ullman <ullman@DB.Stanford.EDU>
To: hull@kibblesnbits.cs.colorado.edu
Subject: Re:  languages for I3
Cc: vs@cs.umd.edu

Let me offer a strawman to give you the idea of what I think we need.

All I^3 mediators and wrappers will offer an interface that
accepts nonrecursive datalog with stratified negation, using
prolog syntax, as queries and will return the result as a
file consisting of tuples with character string components with '\n'
separating fields and '\t' separating tuples.

All I^3 mediators and wrappers will offer an interface that allows
the queryer to get an informal description of the meaning of predicates
or other constants as they may appear in queries.

Note there is nothing about shipping or storing knowledge.
I don't think it is appropriate to require all components to be
able to store "knowledge."
I'm not sure whether it makes sense to set a standard for knowledge-representation
for those that do.
				---jdu


================================

Date: Wed, 6 Sep 1995 20:24:13 -0400
From: vs@cs.UMD.EDU (V.S.Subrahmanian)
To: ullman@DB.Stanford.EDU
Subject: Re:  languages for I3
Cc: hull@kibblesnbits.cs.colorado.edu

I'd like to offer a couple of friendly amendments to Jeff's strawman
idea.

1)  All I3 mediator and wrappers will offer an interface that accepts
    nonrecursive datalog with stratified negation.  These rules may be
    syntactically represented in somewhat different ways in different
     languages (e.g. the LISP-like flavor of LOOM/SIMS may represent the
     same rules in a differnt syntax from the Prolog-like syntax of
     Jeff's message).

2)  I think it may be too restrictive to require that the results are
    files.  In some applications that access sources that return data
      that consist of arbitrary structures (e.g. BLOBs), we may want
    to deal with more complex structures.  However, I agree that 
     all systems should be able to deal with *at least* files returned
    by external data sources.

3)  II agree with Jeff's point about interfaces.  But in addition, I'd
    like to suggest that all I3 mediators and wrappers  offer "query
    servers" that canbe called by external programs.  Such a query 
    server can be called by a client desiring to access heterogeneous
    data sources.

4)  Knowledge is just another form of data, the only differnce is that
    the kinds of operations we want to perform on it are different from
    the standard operations on relation-like data. It may therefore be
    appropriate to think of wrappers specifying abstract data types --
    data structures with associated sets of operations.  We can then think
    of DBMSs and knowledge sources as instantiations of ADTs.

Please feel free to knock these ideas down !

Best,
VS


========================================

Date: Wed, 6 Sep 95 17:47:07 -0700
From: Jeff Ullman <ullman@DB.Stanford.EDU>
To: ullman@DB.Stanford.EDU, vs@cs.umd.edu
Subject: Re:  languages for I3
Cc: hull@kibblesnbits.cs.colorado.edu

1. syntax:  it's trivial, but essential.
If we don't pick one syntax for the language, then there is no
limit to how many syntaxes we have to specify.
And worse, no limit to the number of translators we need to provide
as a community resource.
If we have one standard syntax whose *symantics* is a subset of what everybody
can handle, then everybody writes a translator from the standard to
their internal syntax, and we're done.

4. Yes, knowledge is sort of data, but the question is whether we
*store* data/knowldge/whatever at mediators or not.
Facilitators are in business to accumulate D/K from random sources,
and I believe they will exhibit bizarre behavior as a result,
whenever they are used to do anything nontrivial.
I suppose we need to put a K-representation language on the agenda as
well.  Sigh.
				---jdu