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 procedure.
 
• 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 here:

• 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).

Web Accessibility