In this section, we will describe an application of our work to intelligent terrain reasoning that involves integrating terrain map data, relational data, and planning packages (developed at the US Army Corps of Engineers). The purpose of such an integrated system is many-fold. It can be used as a basis for vehicular navigation in disaster relief situations (e.g. floods, earthquakes, volcanic disasters, etc.), as well as in military mission planning applications. In these applications, a user, who may either be a human or may be an autonomous vehicle, may be interested in posing queries of the following types:

• (Unknown Destination) Given a location, find a place that has an airfield as well as certain types of ammunition. Presumably these resources are needed in order for the autonomous/manned vehicle to satisfy its mission.

• (Route Properties) Furthermore, no point in the route may be less than 4 miles from an enemy outpost. In this example, in addition to the fact that the destination is unknown, we have the fact that the query asks not only for a route to this unknown destination point, but it asks for a route that satisfies certain desiderata, i.e. which satisfies certain conditions that require accessing external databases (e.g. to figure out where enemy outposts lie).

A route planner (which we will call RP) has been implemented at the US Army Topographic and Engineering Center. Given two points, this route planner will find an optimal, least-cost path between these two points (if one exists). Thus, for instance, the query

RP:route((35,70), (200,98))

returns the set of least-cost paths from the origin point, (35,70) to the destination point (200,98) that are found by the Army's route planner.

We illustrate how this example may be solved within the HERMES framework, using RP as a domain. For this, let us suppose that we have a relational (PARADOX) database containing a relation called facilities having the schema (Name,Facility). Thus, this relation may contain a tuple of the form (awasa,airport) denoting that the place, Awasa, has an airport. Other tuples in the relation facilities may be similarly interpreted. Suppose there is another (DBASE) database containing a relation called supplies having the schema (Place,Item) -- an example tuple in this relation is (awasa,gas) specifying that gas is available at Awasa (In practice, these relations will contain much more detail, but we keep them simple here in order to facilitate presentation.).

Using HERMES, we have integrated the following four domains -- RP, DBASE, and PARADOX -- along with a spatial database that identifies points (xy-coordinates with place names). We have written a mediator that may be used to solve this example using the rule given below.

Query 1: Let rte1 be a ternary predicate such that rte1(O,D,R) is satisfied iff R is a route from the origin to an unspecified destination such that the destination has an airfield as well as certain types of ammunition. For this, we may define the following clause in the mediator:

rte1(O,D,R) <-

in(P1,PARADOX:select=(facilities,facility,``airfield'')) &
in(P2,DBASE:select=(supplies,item,``ammunition'')) &
=(P1.place,P2.place) &
in(D,SPATIAL:findpt(P1.place)) &
in(R,rp:route(O,D)).

To obtained the result from a given location l, we can pose the query

<- rte1(l,D,R).

This is then processed as follows: PARADOX is invoked which SELECTs all tuples from the facilities relation that have the an airfield facility. P1 is then instantiated to one of the selected tuples. Next DBASE is then queried to SELECT all tuples from the supplies relation that have the item field set to ammunition. P2 is instantiated to one such tuple. A check is made to see that P1 and P2 have the same place field. In other words, this ensures that single place is found with both ammunition and an airfield? If not, the HERMES inference engine looks for other possible instantiations of P1 and P2 that satisfy these constraints. Finally, the xy-location of the place P1.place is computed using the spatial domain, instantiating D, and RP is called to find a route from the origin l to D.

Solving the second query is somewhat more complicated because of the additional requirement that no enemy outpost lies within 4 miles of any point on the route. Let us suppose that the SPATIAL domain contained in our solution to Query 1 above has a special function called range that takes a point P and a radius Rad as inputs and returns all enemy outposts within Rad units of P.

Query 2: We define a new predicate called rte2 as follows.

rte2(O,D,R) <- rte1(O,D,R) & good(R).
good(nil) <-
good(cons(H,T)) <- goodpoint(H) & good(T)
goodpoint(H) <- is({},spatial:range(H,4)).

Note the use of the special HERMES predicate ${\tt is}$ described earlier.

We have also been developing a mediator in HERMES for law enforcement applications. The general problem is best illustrated with an example. Consider the problem of identifying all people P who have been recorded, by surveillance cameras, as having met with an individual X (for instance, X may be a Mafia chief like Don Corleone), who live within a hundred mile radius of Washington DC, and who work for a suspected front company ``ABC Corp.'' Solving this problem may require access to a wide variety of data sources and furthermore, require recourse to diverse reasoning paradigms as well. For example, it may be necessary to

• access a background face database containing pictures (e.g. passport pictures) of individuals. In this face database, the identity of the photographed individuals is known.

• access a database containing surveillance photographs, that might have been obtained by surveillance cameras.

• access face-extraction algorithms to extract the ``prominent'' faces from the images generated by the surveillance camera.

• access methods of matching faces extracted from the surveillance data by the face-extraction algorithm, so as to be able to figure out who appears in which images.

• access a relational database (PARADOX) of phones and addresses.

• access a spatial database in order to determine whether a given address lies within 100 miles of Washington DC.

• access a second relational database (DBASE) about the employees of ABC Corp.

We define the following three mediating rules.

seenwith(X,Y) <-

in(P1,facextract:segmentface('surveillancedata')) &
in(P2,facextract:segmentface('surveillancedata')) &
=(P1.origin,P2.origin) &
P1 <> P2 &
in(P3,facedb:findface(X)) &
in(true,facextract:matchface(P1,P3)) &
in(Y,facedb:findname(P3)).

swlndc(X,Y) <-

seenwith(X,Y) &
in(A,PARADOX:select_eq('phonebook',"name",X)) &
in(Pt1,SPATIAL:locateaddress(A.streetnum,A.streetname,A.cityname) &
A.statename, A.zipcode)) &
in(true,SPATIAL:range('dcareamap',Pt1.X,Pt2.X,100)).

suspect(X,Y) <-

swlndc(X,Y) &
in(Tuple,DBASE:select_eq('empl_abc',"name",Y)).

The seenwith predicate access a domain called faceextract that we assume is a pattern recognition package, and that it uses the function segmentface to locate the faces in a set of photographs. The output of the function contain mugshots that can be stored. The extraction procedure returns a list of pairs of the form (<resultfile,origin>) specifying which image in the surveillance data, a given face was extracted from (the origin) and where the mugshot is now stored. The faceextract domain also contains a function called matchface that takes a face (such as those extracted by the faceextract domain) and checks if this face is identical to another face in the mugshot library. Likewise, the seenwith predicate access a domain called facedb containing a function called findface which determines, given a person's name, whether his or her face is in a mugshot library. The facedb domain also contains a function called findname which, given a mugshot in the mugshot library, returns the name of the person involved.

Given that a person Y has been seenwith X, swlndc (for ``seen with and lives near DC''), accesses a relational database to find the address of Y, and then accesses a spatial data management system to determine what (x,y) coordinates, on a map of the DC area, this address corresponds to (using a function called locateaddress). It then determines, using a function called range, whether this address lies within the specified distance from DC.

Finally, a person Y is a suspect just in case swlndc(``Don Corleone'',Y) is true and if he is an employee of ``ABC Corp.'' For this, a DBASE relation called empl_abc is accessed. The above three clauses express the mediator for this example in its entirety (though the individual domains are not completely shown).

Following Wiederhold's pioneering paper on mediators [24,25], there have been several efforts to develop general-purpose methods of integrating multiple databases. In contrast to approaches that specifically deal with integrating multiple databases, we emphasize that our system and framework are applicable to the integration, not only of multiple databases, but also to the integration of multiple software packages (e.g. spreadsheets), and also multiple reasoning paradigms (e.g. path planning, face recognition, terrain reasoning, etc.).

Multidatabases and federated databases form a well-known family of database integration paradigms. In such frameworks, an attempt is made to create a ``global'' integrated scheme from a number of local schema -- then the global schema is queried. Most of the works in this arena are used to integrate multiple relational databases (and in some cases, object oriented databases), identifying schema mismatches, and eliminating them as part of the query processing procedures. Some elegant pieces of work on multidatabases are those due to Litwin et. al. [6,13,14]. In addition, Krishnamurthy, Litwin and Kent [11] define criteria that a language that a language that integrates multiple databases must satisfy. They show how to handle schematic discrepancies. Intuitively, two databases may contain the semantic information, but this information may be represented in different ways (e.g. in one database, all the information may be contained in one relation, while in the other, the same information may be spread over two relations). They define a query language that takes such schematic mismatches into account when handling queries. In a similar vein, Spaccapietra and Parent [21] structural conflicts that arise when multiple databases contain similar, but structurally different data. They show how data across multiple databases can be ``linked'' or ``tied together'' based on common attribute values (even though the attribute names may be different across different databases). Similarly, Bright et. al. [5] and Sciore et. al. [18] develop an array of methods to automatically resolve (using different techniques) semantic conflicts in multidatabases. Their work can be used to contribute to the conflict resolution toolkit that forms part of the HERMES architecture.

Generally speaking, the HERMES system applies to a wide diversity of domains with very different aspects to them such as the path planning domain, the face recognition domain, etc., that are not handled by multidatabases. As such, the types of software packages and the kinds of reasoning performed in systems like HERMES are broader than those in multidatabases. Other recent efforts that are proceeding synchronously with ours, are the SIMS/LOOM effort at ISI [2] and efforts to develop a language called KQML [12]. SIMS is a system that uses an object-oriented language called LOOM to integrate information from multiple databases. Objects in the world are classified into classes and a set of relations that link objects and classes are also stored. Various types of inheritance properties can be expressed in LOOM. Both HERMES and SIMS can benefit from one another in a variety of ways -- for instance, HERMES' generalized domain integration method is applicable to the SIMS model as well. As mentioned, in our Heterogeneous User Interface, the LOOM query language could form an important component therein, allowing users who prefer LOOM's LISP-flavored syntax to express their queries in it. KQML, in contrast, provides a method for communication requests to be made between a mediator and various software packages. Various KQML primitives like ask-if, ask-all, etc. may be used to manipulate belief-states that an agent may have (for example, this agent may a communications module that controls a communication channel). HERMES could benefit from KQML by using KQML agents in order to effect communications across the network. In contrast, KQML could benefit from HERMES by using HERMES' query language to identify and extract relevant information from different data sources, pool them together after identifying/resolving conflicts. We see rich potential interactions with both SIMS and KQML/LOOM.