Chapter 10: Writing Mediators.
10.1 -- Introduction: The basic steps for writing
a mediator involves creating the target mediator file (MediatorName.med),
writing predicate, truth, directory, and data declarations, defining the
necessary predicate rules, and then entering the mediator file into the
either the primary, or personal mediator catalog file (hermes.cat).
Chapter 4, Ingres domain and
mediator example, and Chapter 7,
mediator language, provide much of this material (mediator / domain syntax)
but little procedural guidance. This chapter, then, lays out the basic
10.2 -- Writing predicate declarations. The mediator
author must begin by visualizing the problem at hand and the available
data sources -- Next they must craft questions (queries) which when answered
adequately would provide sufficient information to resolve the problem.
Section 7.2.1 covers actual
predicate declaration syntax; This section simply reminds the author to
write predicate declarations (using descriptive predicate names and short
but pertinent descriptor-strings) for all expected query masks..
10.3 -- Writing truth declarations. This required
mediator entry, covered in section x-x, defines the type and range of the
returned query confidence value.
10.4 -- Writing directory declarations. These
optional entries, syntactically described in section
7.2.2, define additional data source paths for the search engine. By
default, the system searches for data files in the working directory (created
at runtime). Declaring additional paths allows the search engine to other,
perhaps mediator specific, directories for referenced data files.
10.5 -- Writing data declarations. These entries,
syntactically described in section
7.2.3, define the mediator data sources (and underlying structures)
referenced later in predicate rules.
10.6 -- Writing predicate rules. For every predicate
there exists at least one predicate rule body which contains a chained
list of literal elements (see section
7.4) which define the actual data access and query processing. Where
more than one predicate rule body exists, Hermes attempts query
resolution using the first available rule body; Should that rule body fail,
it attempts resolution via the next available body, progressing down the
list until it either succeeds or runs out of rule bodies.
10.6.1 -- Data type conversions: A low-level
but important issue in integrating various software with Hermes
is translating between Hermes data types (chapter
5). There are some general differences between Hermes data types
and those typically supported by external software. Some of these differences
are best resolved in the domain interface, and are discussed in section
11.5. Some differences are best resolved in the mediator, and are discussed
For the boolean data type, many external databases simply use an integer
or character. That is, the representation can vary not only with the software
but with the database. A particular database may represent a boolean value
as 1 or 1, "t" or "f", "y" or "n", etc.
For character types, it is convenient in Hermes to differentiate
between a name, a file, and a string, while most external databases simply
support a string type.
The following example illustrates a general approach
for resolving type differences in a mediator using type conversion functions.
This version of the University Ingres supplier_part relation
contains the name and an image showing the part and a boolean flag indicating
whether the part is currently on order. The data types available in Ingres
are essentially integer, real, and string. The ingres domain interface
in Hermes can process dynamic queries using these types. For other
types -- namely boolean, name, and file -- the
conversion is done in the mediator using type conversion functions as shown
in Fig 10-1 above.
In this example, the Picture is a string
in the database and a file in the predicate with the string:file
function in the rule making the conversion. The save operator
then stores the see (Picture):1 action so that an interactive
user can view the picture of the part.
Likewise, the OnOrder flag is a string
in the database and a boolean in the predicate, with the string:boolean
function in the rule making the conversion. For converting an integer or
string to a boolean, the mediator author needs to know which values represent
true or false in the database: 1 or 0, "t" or "f", "y" or "n", etc. A simple
query can be used to determine this information. Using the standard boolean
type instead of arbitrary integers or strings makes the query interface
simpler for both the interactive user and for client applications.
The any, boolean, integer, number and string domains
provide various functions for converting from one type to another. The
conversion is that the domain name is the type name of the inputs and the
function name is the type name of the output. For example, the any:string
function converts any data type to a string.
10.7 -- Appending a mediator catalog file.
As discussed in chapter 8, Hermes
supports two mediator catalog files; The primary catalog resides in the
same directory as the Hermes executables whereas a secondary catalog
file may exist in individual user's Home directories. In this respect,
authors should enter new or experimental mediators into their secondary
catalog file (residing in their Home directory).