Appendix B: I3 Glossary

Draft 8, Gio Wiederhold, 29 March 1995, updated 1,3,16 April, 21 May 1995, 26Jul1995.

This glossary and its base vocabulary were initially established during the I3 (Intelligent Integration of Information) Architecture Meeting in Boulder CO, 8 Nov.1994, sponsored by ARPA and organized by Roger King and Richard Hull of the University of Colorado and refined during the I3 architecture meeting 22 Jan.1995, organized by Mike Genesereth of Stanford University.
Related material on I3 technology can be found in documents of the Stanford Logic Group.
This glossary is Appendix B of the Reference Architecture for I3 document at George Mason University, but it is NOT consistent with this revision of the architecture document. An earlier version (of 18April1995) was consistent, but still incomplete, and is available in postscript.

This glossary has to be brought up-to-date to reflect inputs received during the development of a printable glossary for the Journal of Intelligent Information Systems, to appear spring of 1996.

The original version of the I3 Reference Architecture is also available in HTML form; it is incomplete, but more consistent with this glossary.
On the GMU archive are also available the following source files:

This document was updated by Roger King and Richard Hull at the University of Colorado. and is currently maintained by Ygal Arens and Mike Siegel.
Related information can be found on the I3 Initiative Home Page.
The glossary below is based on contributions by many I3 participants. A recent addition is clarification of the distinction between facilitators and mediators, prepared by Michael Genesereth and Gio Wiederhold (see Section 6). Some references have also been added.
Please email corrections, additions to < gio@cs.stanford.edu > thanks.

This glossary is structured into logical sections:

The terms within the sections are arranged in a logical order, since this HTML document is directly navigable. Terms marked term are defined within this ontology. They are all clickable for navigation. A "|" separates adjacent, distinct defined terms. For users of paper versions, a different order may be preferable.

Section 1: Architecture

  • Architecture = arrangement of components.
  • reference architecture = a guideline and constraint rules for an architecture.
  • component = major building block for an application | configuration. Incorporates tools and possibly domain-specific | knowledge.
  • application = a persistent or transient configuration of components, glue, and HCIs, to solve a customer problem, may cover multiple domains.
  • configuration = an instance of an architecture for a customer | application.
  • glue = Software or rules needed to link components or to interoperate among domains.
  • layers = conceptual, gross categorization of Component | tools in a configuration. The I3 | architecture distinguishes three such layers, each providing a distinct category of service:
    1. Coordination Services = covers resource | discovery, distribution, invocation, scheduling, etc. See Section 3.1 of I3 architecture document.
    2. Mediation Services = covers value-added processing on query text and resulting content, as query relaxation, data filtering and processing>, generating new information, etc. See Section 4.1 of I3 architecture document.
    3. Wrapping Services = covers the use of wrapper and simliar tools which adapt legacy | resources to conform with access standards and conventions used in mediation and coordination. See Section 5.1 of I3 architecture document.
    . Some functions, as resource | access, may be performed as appropriate in any layer.
  • agent = tool which performs a service, either for its owner or for a customer of its owner.
  • facilitator = component which provides coordination | services, as routing | queryies for a customer, may create a configuration. See also Section 6.
  • mediator = component to provide mediation | services to improve information | value being transmitted in response to a customer | query | reformulation and/or content | processing; associated with a responsible owner. See also Section 6.
  • customer = owner of the querying | application program, end-user, or client, who derives value from the services.
  • resource = accessible database, object server, simulation, knowledge base,, . . . ; server; may also be a customer in some configurations. See Section 3.
  • query = request by customer for named information, produces contents.
  • content = information result passed on from a resource
  • service = function provided by a tool in a component for a customer, directly or indirectly. See Section 2.
  • model = formal description of capability of resource or needs of customer.
  • tools = a software program that implements services, typically domain-independent.
  • wrapper = tool to access known resources and translate their objects [FK:94].
  • constraint rules = defining rules for layer assignments for Components, protocols, etc.
  • interoperation = customer | services effectively combining multiple resources and domains.
  • information = data useful to a customer.
  • actionable information = information which causes the customer to initiate events.
  • data = recorded facts, typically maintainable by clerks.
  • text = data, information, or knowledge in relatively unformatted character-based representation.
  • knowledge = metadata, relationships among terms, processing paradigms, . . . , needed to transform data to information.
  • domain = topic area, characterized by internally consistent semantics, as finance, electronic parts, vehicle control, diabetes clinic records, etc., and identifiable experts.
  • metadata = descriptive information about data in a resource, includes domain assignment, ownership, access restrictions, database | model.
  • metaknowledge = descriptive information about knowledge in a resource, includes ontology, domain coverage, ownership, access restrictions, representation
  • metainformation = descriptive information about services, as owner, capabilities, cost.
  • Section 2: Services

    We focus here on services visible to the customer. Alternative configurations may package services differently and render them less visible.
  • Service = Conceptual functionality provided by one or more component, for a customer directly or indirectly. No specific implementation is implied.
  • added-value service = chargeable or billable service.
  • routing = a coordination | service to locate and invoke resources and mediation | service, create a configuration dynamically, will use a directory.
  • scheduling = a coordination | EM>service to determine order of invocation of accesses and other services; optimal scheduling is often based on their estimated | costs or prices.
  • matchmaking = a coordination | service matching of subscribers to advertisers.
  • brokering = a coordination | service to find the best resources.
  • configuration tool = program used in coordination to help select and arrange Components into a specific instance of an architectural | configuaration.
  • description services = meta services that inform customers about services, resources etc., as explanation, resource discovery, impact assessment.
  • directory = service to locate and assess available resources and services, as white pages, yellow pages, etc.
  • query decomposition = determine subsidiary queries to match available services and/or resources.
  • query reformulation = program to optimize or relax | queries, typically require scheduling.
  • content = results produced by resource in response to queries, often voluminous.
  • content processing = mediation | services which manipulate obtained contents, typically to increase information density and relevance, as integration, filtering, content analysis, summarization, seeking exceptions versus a user | model, abstraction, etc.
  • text processing = a mediation | service which operates on text, as search, indexing, categorization, editing, spelling correction, etc.
  • filtering = a mediation | services to improve relevance of query | content | information.
  • ranking = a mediation | service to assign values to retrieved | content | objects.
  • explanation = a mediation | service to present models to customer, may invoke impact assessment.
  • model management = a mediation | service to allow customers and mediator owners to update | models.
  • integration = a mediation | service to combine intermediate contents from multiple, often heterogeneous resources.
  • temporal match = a mediation | service to recognize and resolve time-stamp differences in resource | data.
  • spatial match = a mediation | service to recognize and resolve differences distance measures and granularities in resource | data.
  • reasoning = method used in component | services to draw logical inferences.
  • browsing = services to support customer driven resource | discovery.
  • resource discovery = service searching for resources, complements advertising.
  • indexing = creation of lists to objects (an index) to speed-up access | services.
  • semantic indexing = indexing using indirect terms via an ontology.
  • content analysis = processing of text objects to create information, as abstracts or indexes.
  • access = linking to objects in resources for query, update, or analysis.
  • optimization = rearranging and/or scheduling processing of a query to reduce cost or reponse-time.
  • relaxation = service to produce a relevant superset content of a query, may use an ontology mapping. See Section 4.
  • summarization = service to aggregate data into higher level | objects.
  • abstraction = service to reduce content volume by bringing to a higher level.
  • advertising = resource or mediator | model presentation to a component or customer.
  • subscription = request by a component or customer to be informed of an event, similar to a stored query.
  • monitoring = observing resource or virtual data and creating a triggering actions when state changes occur.
  • updating = transmitting data changes to the resources, requires transaction control. We do not assume that all updates flow that way, but rather that most updates are local to the resources.
  • mediator instantiation = populate a domain-independent | service | tool with domain-specific | knowledge.
  • multi-state services = create, access, monitor, and manipulate state of virtual data (not a well-accepted term [Neches]).
  • activeness = the ability to trigger actions due to an update event, as notify subscriber of events or cause secondary updates.
  • transaction service = service to assure temporal consistency of contents, performed by transaction management
  • impact assessment = services which reports which resources will be affected by queries or updates.
  • estimator = low-level | service which predicts cost and/or performance based on model, statistics, or sampling.
  • caching = holding information at intermediate level to improve performance or resolve temporal mismatches.
  • translation = transforming data into the form and syntax required by the receiver.
  • concurrency control = assuring synchrony of updates to resources, typically assigned to a transaction management system.
  • Section 3: Resources

  • Resource = accessible database, simulation, knowledge base, . . ., includes legacy resources..
  • Legacy resources = Pre-existing or autonomous resources, not designed to interoperate within a general and flexible architecture.
  • event = reason for change in state within a resource or component.
  • object = an identified instance in a resource, customer | model, or a tool; has values for its attributes.
  • value = content metric in customer model, as quality, relevance, up-to-dateness, cost.
  • owner = individual or organization who created or obtained rights to an object, and may derive income from it.
  • owner of service = authorized individual or organization responsible for provided services.
  • database = resource comprising a collection of data with a descriptive schema.
  • warehouse = a database containing or providing access to selected, abstracted and integrated | data from multiple resources. Typically redundant with respect to the source data, unless the sources do not keep historical} data.
  • knowledge base = resource comprising a collection of machine-processable knowledge, often in the form of rules and metadata; enabling accessing and computation over databases or other reources.
  • simulation = resource able to project data into the future, based on a modeland hence generate information.
  • transaction management = assuring that temporal consistency of databases is not compromised by updates.
  • transaction impact = reports which resources are affected by an update to an impact assessment | service.
  • schema = listing of database relations, attributes, and, optionally, classs, relationships, constraints, limits, other metadata. Basis for a resource | ontology.
  • dictionary = listing of terms, expanded index, part of an ontology.
  • database model = formalized description of database | resource, includes schema.
  • interoperability = the capability to interoperate, often used at the transport | layer.
  • heterogeneity = the mismatch found in autonomously developed resources and services, ranges from platforms, operating systems, database systems and models, data representations, ontologies, semantics, and processing paradigms.
  • cost = price of providing a service or accessing an object; can include size of content.
  • price = charges for a service, includes cost, overhead, and profit.
  • deductive database = database able to handle logical rules and process data accordingly.
  • rule = logical statement, unit of processable knowledge.
  • rule management system = domain-independent software to collect, select, and act on rules.
  • active database = database which exhibits activeness.
  • virtual data = data represented by references and procedures.
  • state = an instance or version of a data or information base.
  • change of state = caused by an update, insert, delete action.
  • view = subset of a database | constrained to a domain, and restructured as required.
  • object server = provider of data | objects.
  • hierarchy = model structure which assigns objects to levels, and defines for each object a single ancestor
  • network = model structure with relatively unconstrained relationships among objects
  • restructuring = rearranging data according to an alternate hierarchy or object | model
  • level = a conceptual categorization, where objects at a lower level depend on their ancestors at a higher level.
  • ancestor = object at a higher level, source of inheritable attributes.
  • root object = The ultimate ancestor.
  • view-object [Penguin] = data object constructed from a database | view and model.
  • data warehouse = repository of integrated data from multiple resources.
  • metadata repository = database containing metadata and/or metainformation.
  • Section 4: Ontologies

  • Ontology = the specification of a conceptualization [Gruber:93], i.e., the set of terms and relationships used in a domain, denoting concepts and objects, often ambigious among domains [Example, this document for I3].
  • concept = defines abstraction or aggregation of objects for customer.
  • semantic = pertaining to the meaning of a term, often expressed as a set of relationships.
  • syntactic = pertaining to the format or ordering of terms, often expressed as constraints.
  • class = defines metaknowledge as methods, attributes, ancestry, etc. for object instances assigned to it.
  • relationship = linkage among terms, as reference, is-a, dependency, part-of, subset, . . ..
  • is-a = relationships. among classes, and hence their objects, which inherit attributes from their ancestors
  • merged ontology = ontology created by combining several ontologyiesm may require a mapping.
  • shared ontology = subset of ontologies agreed on by multiple customers.
  • ontology comparator = tool to determine equivalence, subsumption, or intersection of ontologies; used to determine the rules needed for their mapping.
  • ontology mapping = transformation of terms among ontologies, uses matching rules, often needed to link customers to resources.
  • matching rules = statements to define term equivalence among domains, may induce uncertainty.
  • schema transformation = adaptation of a schema to an alternate ontology.
  • editing = processing of text to assure conformance with an ontology.
  • ontology algebra = set of operations to achieve composable merging, subsetting, and mapping of ontologies.
  • uncertainty = augmentation of logic values with ranges or probabilities.
  • temporal consistency = achieved if all data that are not otherwise time-stamped, refer to the same time instance and have the same temporal granularity.
  • historical data = temporal arranged data which is not an updated with new values, but rather {\sl time-stamped} and only appended.
  • domain-specific = scope constrained to a single domain, assumes absence of semantic mismatches.
  • domain-independent = software, tools, and global knowledge applicable to multiple domains.
  • Section 5: Related Terms

    These terms refer to technologies that are often essential to I3 efforts, but not the prime focus of the program.
  • National Information Infrastructure (NII) = collection of accessible services, resources, storage and transport mechanisms.
  • middleware = collective term for wrappers, object | services, mediators, facilitators
  • security = assurance that information is only provided to authenticated and authorized components and customers.
  • privacy = right to constrain | access held by subject described in data.
  • authorization = access or processing rights held by customer.
  • authentication = validation that an identifier belongs to the right customer.
  • encryption = technology to safeguard content from un-authorized customers or invaders.
  • client-server architecture = direct linkage of customers to resources providing data or objects
  • precision = comprehensiveness of contents: (amount retrieved)/(amount available).
  • relevance = usefulness of contents: (amount of interest)/(amount retrieved).
  • resolution = granularity of content [?].
  • responsiveness = adequacy of retrieval speed: 1/(time for first content).
  • hypothetical access = analysis of impact or cost of planned access, based on model.
  • association = inclusion of additional information not explicitly asked by the customer but relevant to the query.
  • type abstraction hierarchy = multi-level | knowledge representation for query | relaxation and semantic indexing.
  • federated architecture = multiple client-server linkages, with a shared schema and ontology
  • human collaboration = interoperation at the costumer | layer.
  • actor = an agent that can operate autonomously and set its own goals. The I3 paradigm does not require actor capabilities.
  • distributed problem solving = interoperation at the coordination | layer with remote resources.
  • agile manufacturing = flexible manufacturing configurations
  • version = a maintained alternative of an object, often needed to maintain consistency with past applications or contents.
  • transport = the actual shipping of uninterpreted data among nodes.
  • node = components in a information network configuration, associated with a site.
  • communication protocols = rules for the glue required for transport among sites.
  • site = source, sink, or forwarding computer in a communication network, denotes a location. Node sharing a site exhibit less heterogeneity.
  • time-stamp = label for an information or data unit that specifies its temporal interval of validity.
  • granularity = size of atomic measurements for data, as seconds, . . . , years; or angstroms, . . ., miles.
  • lock manager = tool control and synchronize access to a resource.
  • Section 6: Facilitators and Mediators (draft 2, 15Mar95)

    In current I3 papers and architecture documentation the differences and similarities between facilitators and mediators is at times unclear and at other times actually misleading. Mike Genesereth, Narinder Singh, and Gio Wiederhold went over the issues and submit jointly the following clarification. We incorporated and welcome comments from the community.

    ROUTING, TRANSFORMATION, and WRAPPING

    The functions in the middleware layer occupied by mediators and facilitators are the routing of requests to approriate resources, while retaing control so that the result can be combined, the processing of teh results to add value by enhancing their information density. Since the resources and processing programs are often in formats not suitable for interoperation wrapping is often required.

    We now address how facilitators and mediators deal with these functions.

    SIMILARITIES

    Mediators and facilitators both occupy the middle layer of the I3 architecture, interposed between data resources and the application programs of the information providers and consumers. Both kinds of programs can provide information integration services of various sorts, including information routing, content manipulation, and format conversion.

    DIFFERENCES

    The essential distinction between a mediator and a facilitator is one of automation and hence dynamics versus human responsibility. The vision inderlying mediators is one where domain experts, equipped with interoperating software modules, provide value-added services for data access and processing over networks [W:89]. The vision underlying facilitators is `one in which any system (software or hardware) can interoperate with any other system, without the intervention of human users or their programmers' [GSS:94].

    By definition, facilitators are required to accept runtime submissions of

    1. metadata about information resources
    2. logical statements relating disparate concepts (usually definitions)
    3. format descriptions
    Facilitators are expected to use this information in converting, translating, or routing information.

    In mediators, the management of metainformation is the responsibility of a human owner. Its definition stated: `A mediator is a software module that exploits encoded knowledge about certain sets or subsets of data to create information for a higher layer of applications.' and the definitition goes on to state `It should be small and simple, so that it can be maintained by one expert or, at most, a small and coherent group of experts' [W:89]. The mediator program, as directed by its owner, tries to

    1. assure stable delivery of services, even when resources change
    2. assess disparity of concepts and maintains tools to resolve them
    3. invoke tools to resolve format differences
    The owners take on the responsibility and authority and may be reimbursed for the value-added information services being provided. While mediators are in general capable of converting, mediating, or routing information, they are not expected to accept runtime submission of metainformation and definitions and format descriptions without intervention of the responsible human parties.

    For example, when a new resource becomes available:

    1. A facilitator will expect a machine-processable description of the new resource, which must be coherent with the existing description used by the facilitator. Then the facilitator can integrate the new resource, or elide an existing one, and the consumer can be immediatly served with the new resource.
    2. The party responsible for the mediator is to be informed of the new resource. The knowledge that defines the value-added function has to be augmented to include teh new capability. The augmentation may be done by the owner, perhaps aided by an automated process if the semantic difference of current and new resource capabilities is modest. A new version of the mediator, with augmented capabilities is then made available, but the owner also has a responsibilty to continue serving current applications.

    RELATIVE STRENGTHS AND WEAKNESSES

    While mediators represent responsible, predictable and stable services. To warrant the use of mediators, there should be significant value-added processing. Data reduction, exception search, dealing with uncertainty among heterogenous resources, and ranking of results are examples. Some tasks will actually require caching of past data. Again, it is the owner of the mediator who assumes responsibility for the correctness of such processing. Facilitators provide automation, rapid response to changing situation and depend on consistency in the ontologies which describe resource capabilities and customer needs.
                                             Mediators  Facilitators
    Flexibility and Generality                  Low         High
    Quality and Efficiency                     High          Low
    

    RELATIONSHIP to I3 SERVICES

    Both mediators and facilitators can provide control and routing, content manipulation, and format conversion. From the primary distinction above we can derive the following conclusions in the main areas addressed by the I3 program.
                                     Mediators             Facilitators
    Control and Routing       determined by human design     dynamic
    Content Manipulation        important to add value    as automation allows
    Format Conversion       usually via wrapper invocation   dynamic
    

    ARCHITECTURE

    Facilitators and mediators can interact with each other and wrapped resources within an information system: facilitators may call on mediators to perform value-added tasks. A mediator may call on a facilitator to establish links to new resources. Both mediators and facilitators can use wrappers to access non-conforming resources.

    In short we can imagine I3 systems of the sort shown below.

            Customer    Customer    Customer        Customer
               |           |           |                |
               |           |           |                |
               |           |           |                |
               |        MEDIATOR       |                |
               |           |           |                |
               |           +------+    |           FACILITATOR
               |                  |    |           |         |
            MEDIATOR           FACILITATOR         |         |
            |      |            |   |   |          |         |
            |      |        +---+   |   +----+     |         |
            |      |        |       |        |     |         |  
            |      |   MEDIATOR  MEDIATOR    |     |         |  
            |      |     |          |        WRAPPER         |  
            |      |     |          |         with           |  
            |      WRAPPER          |       Ontology    conforming
            |         |             |           |        Resource
       conforming     |        conforming       |        with its
        Resource   Resource     Resource     Resource    Ontology
    

    MEDIATOR GENERATORS.

    We also foresee a role for programs capable of generating mediators, routers, translators from formal specifications. In some cases, these generators may work automatically, in some cases interactively with humans.

    Mediator generators are NOT mediators.
    Mediator generators are NOT facilitators.

    NB: A facilitator can be viewed as a ``universal mediator'' -- it emulates a mediator to the extent that automation allows; it does not generate mediators. A mediator can be viewed as a ``petrified facilitator'' -- it requires a human mason restructure its role in system configuration.

    Facilitators and mediators can interact within an information system: Facilitators may call on mediators to perform value-added tasks. They may also generate processing code if the rules they have are sufficiently explicit. Facilitators are critically dependent on formal logic to perform their tasks. Mediators can be fully or partially handcrafted, although they must satisfy similar formal interface requirements. A mediator, typically triggered by its owner, may call on a facilitator to establish links to new resources. Both mediators and facilitators will use wrappers to access non-conforming resources.

    We can also envisage hybrids, but with a hybrid the author has to make clear the new balance, both of the benefits gained and the liabilities incurred. With instant adaptation to changing conditions the human owner of the intermediary software cannot be held responsible. When assigning maintenance responsibilty to a domain expert some responsiveness will disappear.

    Section 7: Project Titles

    (alphabetical, of neccessity always incomplete)
  • ABSE [gensereth@stanford]= KQML APIs
  • ACL [gensereth@stanford]= Agent Communication Language.
  • API = application program interface, glue for software component | interoperation.
  • ARPA Advanced Research Projects Agency of the U.S. Department of Defense, sponsor of the I3 program.
  • BMS =
  • CG [sowa@binghampton] = Conceptual Graphs, representation for FOL statements, compatible with KIF.
  • Digital Libraries [NSF-ARPA-NASA] = program to support document access and interoperation.
  • DLE =
  • DOE [SunSoft, Persistence] = Distributed Objects Everwhere, environment for Client-Server Systems, using Penguin technology to access relational databases in Oracle, Sybase, Ingres and Informix.
  • CML [forbus @Xerox PARC] = ontology for products?
  • CoBase [Chu@ UCLA] = mediator performing query relaxation and association.
  • Commercenet [Tanenbaum@EITech] = product catalog server, see Ted Haynes: The Electronic Commerce Dictionary for related terms.
  • Context Interchange [Madnick @MIT Sloan] = mediation service focusing on transportation and logistics domain.
  • CORBA [@OMG] = CommonObject Request Broker service.
  • COSMOS [Kuokka @lockheed AI] = design interoperation.
  • COSS [OMG] = Common Object Services Specification, generic metainformation, lists expected services in varying detail.
  • CYC [Lenat@CYCORP, Guha @MCC, CyCorp] = integrated knowledge base, focusing on common-sense knowledge.
  • FAST [A-L Neches @isi] = brokering service initiative.
  • H2O [Hull,King@cs.colorado.edu] = design and implementation of multi-state and activeness | services.
  • HCI = human-computer interface, presentation of system to customer, outside of scope of I3 except for needed APIs.
  • HTML = format for internode and internode hypertext linkages, based on SGML.
  • HTTP [Illinois Supercomputer / IETF] = a convention for access to HTML-linked data, implemented intially by MOSAIC and now widely accepted.
  • I3 [Gunning,Neches@ARPA] = Intelligent Integration of Information program, to support interoperation of heterogeneous | components and their contents.
  • IDL [OMG] = program interface description language. describes objects, defines an object model.
  • ILU [PARC] = Inter Language Unification. A generalization of CORBA.
  • Internet [XIWT] = network service, being expanded for the NII.
  • IWSDB [channell @ISX] = support for mediation at Lockheed Georgia F-22 Integrated Weapons Systems Database.
  • KADS [Esprit] = European proposed standard for conceptual modeling.
  • KIF [geneserth@logic.stanford.edu] = Knowledge Interchange Formalism, a general FOL representation for rules, etc. to allow transport of knowledge among sites.
  • knobot [CNRI] = agent to locate information resources.
  • KQML [finin @UMBC et al.] = Knowledge Query and Manipulation Language, protocol for information transport.
  • LOOM [McGregor @isi] = Classification based knowledge-based system.
  • MBUS [Uni.of Illinois] = message bus.
  • NII = National Information Infrastructure. See Section 5.
  • NIIIP (TRP) = National Industrial Information Infrastructure Protocols, consortium of about a dozen companies {IBM [Goldschmidt [artg@vnet.IBM.com], TI, UES, GD, Un.Fl, StepTools, NIST, Lockheed ASC, Taligent}.
  • NIIR =
  • NRI [Bob Kahn @CNRI] = Corporation for National Research Initiatives.
  • OMA = OMG Object Management Architecture Guide OMG, 1995. Available from: OMG Publications, 492 Old Connecticut Path, Framingham, MA 01701, USA, phone +1 508 820-4300, fax +1 508 820-4303.
  • ODMG-93 [ODMG] = proposed standard protocol for object-base access, alternative to SQL-3, formulated by
  • OMG = Object Management Group, Inc. Consortium of 480 companies to develop object-oriented processing industry standards. Meets bi-monthly and publishes varios documents, as a Referemce Architecture.
  • OLE [@Microsoft] = extensible document service broker.
  • OMA [OMG] = Object Management Architecture, overall structure guideline, names COSS. requires use of IDL.
  • Ontolingua [Gruber@EITech, Fikes@ksl] = ontology server {EngMath, bibliography, . . .}.
  • OOODB [thompson@csc.TI] = Open Object Oriented DataBase, persisistent object base system, sponsored by POB. To become publically available in source form.
  • OPENDOC = standard for document interoperation service, competes with OLE.
  • OQL [ODMG] = Object Query Language, to be selected from ODMG, Oracle SQL3, TI OOODB, proposals.
  • Penguin [gio, keller @stanford] = data view object generation from relational databases [B:89].
  • POB [ARPA] = Persistent Open Object-Base program, supports OOODB.
  • RECON [Evangelos Simoudis@lockheed AI] = database mining.
  • SHADE [Mark @lockheed AI] = agile | manufacturing support.
  • SGML = Standard Markup Language, defines device-independent layout for textual data.
  • SIMPLE [Sankar@crystalize] = KQML API, provides PDES support.
  • SIMS [Arens @ISI] = mediator for multi-database integrated query processing .
  • smart yellow pages =yellow pages support which also uses a domain | ontology.
  • SISTO [ARPA] = Software and Intelligent Systems Office (sometims SSTO) of ARPA>, base for I3 efforts.
  • SQL [ANSI] = database access language standard.
  • SQL-3 = proposed extension to SQL, to include object access.
  • STEP [NIST] = multi-level standard for manufacturing objects [MMDF:94].
  • TOOLTALK [sun] = service broker.
  • VODAK [GMD IPSI] = persistent object base, used for multimedia support.
  • White pages = service giving people names, locations, roles.
  • XIWT [@NRI] = cross industry NII team, defined high-level architecture.
  • Yellow pages = service giving information about other services as corporate names, locations, capabilities, cost.
  • Section 8: References:

    [B:89] Thierry Barsalou and Gio Wiederhold: ``Knowledge-directed Mediation Between Application Objects and Data"; Proc. Working Conf. on Data and Knowledge Integration, Un.of Keele, England, 1989 Pittman Pub.

    [CQ:92] W.W. Chu and Q. Chen: ``Neighborhood and Associative Query Answering"; Journal of Intelligent Information System, Vol.1 No.3/4, 1992, pp.355-382.

    [CQ:94] W.W. Chu and Q. Chen: ``A Structured Approach for Cooperative Query Answering"; IEEE Transactions on Knowledge and Data Engineering, Vol.6 No.5, October 1994.

    [CMB:93] W. W. Chu, M. Merzbacher, and L. Berkovich: ``The Design and Implementation of CoBase"; ACM SIGMOD '93, May 1993, pp.517-522.

    [CJB:93] A. Courtney, W. Janssen, D. Severson, M. Spreitzer, and F. Wymore: Inter-Language Unification rel.1.5; Xerox PARC, ISTL-CSA-94-01-01, No.P94-58, May 1994, ftp://ftp.parc.xerox.com/pub/ilu/ilu.html.

    [FFMM:94] Tim Finin, Richard Fritzson, Don McKay, and Robin McEntire: ``{\csc kqml} as an Agent Communication Language''; to appear in The Proceedings of the Third International Conference on Information and Knowledge Management (CIKM'94), ACM Press, November 1994; http://www.cs.umbc.edu/kqml.

    [FKB:94] J.C.~Franchitti, R.~King, and O.~Boucelma: ``A Toolkit to Support Scalable Persistent Base Infrastructures''; in Proceedings of the Sixth International Workshop on Persistent Object Systems, Tarascon, France, September 1994, Springer-Verlag LNCS.

    [G:92] Michael Genesereth: ``An Agent-Based Framework for Software Interoperability''; Procedings ARPA Software Engineering Conference, Los Angeles 1992, Meridian Corporation, Arlington VA, pp.359-366; to appear in AI magazine, 1995.

    [GS:93] Michael R. Genesereth and Narinder P. Singh: A Knowledge Sharing Approach to Software Interoperation; Stanford University, 1993.

    [GK:94] M.R. Genesereth and S. Ketchpel: ``Software Agents"; Comm.of the ACM, Vol.37 No.7, July 1994, pp.48-53.

    [GSS:94] Michael R. Genesereth, Narinder P. Singh and Mustafa A. Syed: ``A Distributed and Anonymous Knowledge Sharing Approach to Software Interoperation"; Proc. Int.Symp. on Fifth Generation Comp Systems, ICOT, Tokyo, Japan, Vol.W3, Dec.1994, pp.125-139.

    [Gruber:93] T.R. Gruber: "A Translation Approach to Portable Ontologies'; Knowledge Acquisition, Vol.5 No.2, 1993, pages 199-200.

    [MMDF:94] KC Morris, Mary Mitchell, Christopher Dabrowski, and Elizabeth Fong: ``Database Management Systems in Engineering"; in the Encyclopedia of Software Engineering, pp.282-308, John Wiley and Sons, 1994; http://elib.cme.nist.gov/fasd/pubs/morris92c.ps % STEP

    [NFFGPSS:91] R.Neches, R.Fikes, T.Finin, T.Gruber, R.Patil, T.Senator, and W.Swartout: ``Enabling Technology for Knowledge Sharing"; AI Magazine, Vol.12 No.3, 1991, pp. 36-56.

    [T:94] Paul-Andre Tourtier: ``A Flexible, Facilitator-based Cooperation Framework"; Proc. Int.Symp. on Fifth Generation Comp Systems, ICOT, Tokyo, Japan, Vol.W3, Dec.1994, pages 101-110.

    [W:89] Gio Wiederhold: Mediation in the Architecture of Future Information Systems, 1989;
    published in IEEE Computer Magazine, Vol.25 No.3, March 1992, pp.38-49;
    republished in Hurson et al: Multi-database Systems: an Advanced Solution for Global Information Sharing; IEEE Press, 1993

    [Wea:90] Gio Wiederhold et al: A Mediator Architecture for Abstract Data Access; Stanford University, Report Stan-CS-90-1303, August 1990.

    [W:91] Gio Wiederhold: ``The Roles of Artificial Intelligence in Information Systems"; in Ras Methodologies for Intelligent Systems, Lecture Notes in AI, Springer 1991, pp.38-51; republished in the Journal of Intelligent Information Systems, Vol.1 No.1, 1992, pp.35-56.

    [W:93] Gio Wiederhold: ``Intelligent Integration of Information"; Proc. ACM SIGMOD Conference, 1993, pp-434-437.

    [W:94] Gio Wiederhold: ``Interoperation, Mediation, and Ontologies''; Proc. Int.Symp. on Fifth Generation Comp Systems, ICOT, Tokyo, Japan, Vol.W3, Dec.1994, pages 33-48.

    End.