Mediator languages—a proposal for a standard: report of an I3/POB working group held at the University of Maryland, April 12 and 13, 1996

  • Authors:
  • Peter Buneman;Louiqa Raschid;Jeffrey Ullman

  • Affiliations:
  • University ofPennsylvania;University of Maryland;Stanford University

  • Venue:
  • ACM SIGMOD Record
  • Year:
  • 1997

Quantified Score

Hi-index 0.00

Visualization

Abstract

The DARPA Intelligent Integration of Information (I3) effort is based on the assumption that systems can easily exchange data. However, as a consequence of the rapid development of research, and prototype implementations, in this area, the initial outcome of this program appears to have been to produce a new set of systems. While they can perform certain advanced information integration tasks, they cannot easily communicate with each other.With a view to understanding and solving this problem, there was a group discussion at the DARPA Intelligent Integration of Information/Persistent Object Bases (I3/POB) meeting in San Diego, in January, 1996; and a further workshop was held on this topic at the University of Maryland in April, 1996. The list of participants is in Appendix A. The idea emerging from these meeting a was not to force all systems to communicate according to specified standards, but to agree on the following:• A minimal core language, or Level 1 option, which would be a restriction of the object-oriented query language OQL, such that it will accept queries for relational databases. We recommend that all system components be able, at a minimum, to accept queries in this syntax, provided they address concepts (e.g., relations or classes, attributes or instance variables) known to that component. There must be a simple protocol to determine the schema of a system (its set of supported concepts).• A simple format for representing answers. This could also be a fragment of OQL and will be included in the core language specification.• A set of extensions, one of which could be full OQL, and would handle complex structures and abstract types (with methods). Other extensions will be needed to support rules (e.g., definitions of terms that can be shared among components), semistructured data (for self-describing objects), and shared code. A system component could support one or more of these extensions, independently, and there should be some simple protocol to determine the particular extensions that are supported.