First, on the type of information to be dealt with.

I believe Peter's suggestion is going in the right direction but not far
enough. I agree with the idea that a query language that supports querying
of commonly found structures is a very useful functionality. However, the
structures that we run into in the product development domain do not map
easily to record, sets, etc.

Parts and assemblies of parts are often tree structures. Additionally, parts
are described using associative dimensions which are parametric descriptions
on the values of part dimensions. Part libraries (used in manufacturing
domains) are used to instantite parts which might have similar geometric
appearance (closed part library) or different geometric appearance (open
part library). Therefore, the structures found in manufacturing tend to have
a need to represent meta class information (for part libraries for example),
navigational support that cannot be supported with SELECT type queries
easily, and a need to support evaluation of expressions to set the values of
attributes (for associative dimensioning). This is why we ended up selecting
a simplified frame representation because it supported all of the 3
requirements. 

Second, on the interchange aspect.

Many of query languages suggested by Peter (e.g., OQL) assume a synchronous
infrastructure for returning the results of a query. This assumption does
not scale. Consider deploying the information integration language over the
scale of WWW. If one assumed a synchronous transport layer, then the client
process and the server process will lock as this request is served.
Additionally, since cursoring on the returned result is to be expected as
part of the same session, one can expect that light weight clients such as
Windows 95 (and event NT) to quickly crash or time out. As a related
example, the W3C consortium folks are implementing the next generation HTTP
protocol called HTTP-NG on an asynchronous RPC layer to support scalability.
If we want to support the scalability of the Web itself, then we need to
think about a information interchange protocol that is asynchronous.
Fortunately, KQML is designed to be an asynchronous mechanism to transfer
information.

Third, on the language aspect.

As I mentioned above structured queries do not work for the type of
structures that we run into. Mind you, I am not arguing that structured
queries are not useful. They are. However, one needs to atleast support a
way to allow domains to implement their own extensions. The KQML "evaluate"
message does this.

KQML as it exists is too large and needs to be tightened up. However, it
does serve the needs for a new language. If we take the suggestion made by
Ullman or Peter, then we are done. We don't need to invent another one. We
can pick SQL, OQL, or some variation thereof. 

Of course, this approach will not address the requirements of information
integration with domains that have complex structures, extensibility of the
information integration language, and scalability.

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