Chapter 7: The Mediator Language.

• 7.1 -- Introduction: The basic components of a mediator are its declarations and rules: Mediator declarations declare the types, locations, and data processing rules used for answering queries. Mediator rules are statements, or if-then conditions, annotated with truth values which indicate answer confidence or certainty. This chapter provides the formal syntax for Hermes mediators, along with some examples and usage explanations.
 
• 7.2 -- Hermes mediator declarations: Two kinds of declarations in a mediator, namely the predicate and data declarations, declare data types used by the mediator. The directory declaration declares the data file locations. The include declaration declares additional mediators for inclusion in the current mediator.
 
•  7.2.1 -- The predicate declaration declares the name, description and term-types, if any, for a mediator predicate. The pred-name token is the predicate name and descriptor-string is an English description of the predicate. The syntax for the term-types is defined in section 5.3. Hermes any and number types, which can be used in domain function declarations (see sections 6.2.6 and 6.2.5 respectively) cannot be used in predicate declarations. However, complex data types can be used in predicate declarations.


WebHermes predicate descriptors use a simple HTML-like markup syntax to map additional functionality from predicate variables to web controls.

• ${VarName} within a descriptor denotes values web hermes will return; This allows result application from one query to a secondary query input (and thus the formation of conjunctions).

• &{VarName} within a descriptor denotes values which can be entered from the web browser.

• *{VarName} within a descriptor denotes values which must be entered from the web browser.

• 7.2.2 -- The directory declaration declares data file directory paths for the search engine; They can occur anywhere in a mediator file but are typically placed at the file beginning or near rules which cite the directories. Hermes directory paths must end with the slash character '/' as listed in Fig. 7-4 (Note: PC versions use the backslash '\' rather than the Unix '/' slash). The Hermes search engine looks for referenced data in declared directory paths, following listed order, prior to checking the current working directory. Should a mediator file omit such directory declarations, then the search engine checks only the current working directory for data files.
 
•  7.2.3 -- The data declaration declares the target domain, source file, and structure for referenced data files. The term-type token allows structure declaration -- actually, the returned data type -- for the referenced data file (see section 5.3 for term-type syntax). As stated above, mediator data declarations cannot contain the generic number, or any, term-types.

   Note that the data types listed in Fig. 7-6 correspond to familiar database concepts where a relation is a set of records, a quadtree is a set of points, and so forth. Moreover, the quadtree and relation domain data declarations use the '@' notation to specify a (remote) host data file server (See section 5.11).

    As described in section 6.2.3, Hermes calculates domain function output types based on mediator data declarations referenced through the domain function call -- If the domain function return type is defined by a domain catalog data function, then the mediator file must include data declarations for the referenced domain data files.

• 7.2.4 -- The include declaration can be used to include one mediator file in another, allowing system-wide access to commonly used mediator actions. The included mediator-file must be declared in the mediator catalog (see Chapter 8) and is referenced via the include command by file name only; Hermes derives the target mediator file directory from the mediator catalog file.

    Fig. 7-8 lists a short mediator of common file display functions. To call these predicates from within another mediator, the author need only specify the declaration "include ('actions.med')." within the mediator file. This capability directly supports modular system development -- Larger mediator applications, such as a multimedia system, can be derived from smaller key components like integrated text and image databases.
 
 

• 7.3 -- Mediator terms can be constants, variables, functions, array elements or record fields. Variables and constants retain the definition characteristics specified in the types chapter (see section 5). Domain functions typically consist of the domain name, the function name, and argument terms. Since Hermes defines functions using terms, functions can be recursively nested.

• 7.3.1 -- Array elements can be accessed using the subscript notation '[ ]'. The term before the brackets must evaluate to an array. The term enclosed by the brackets '[ ]' must evaluate to an integer between 1 (position of the first array element) and the array size (the last array element).



• 7.3.2 -- Record fields can be accessed using the dot notation '.'. The term before the field dot must evaluate to a record. The term following the field dot '.' must be the name of a field in the record.

• 7.4 -- Literals form the elements of predicate rule bodies.

• 7.4.1 -- Predicates are analogous to typical verb forms; When used in clause form (see section 7.5) they make statements about the terms they contain. Query predicates form questions regarding the addressed terms (section 7.6). Additionally, Hermes annotates its predicates with real-valued expressions to indicate the predicate confidence level. Normal truth values range from 0.0, for no certainty, to 1.0, for total certainty (Hermes will, however, accept truth values outside this range); Citing from the top down in Fig. 7-13 we find that predicate p is true with a certainty of at least 50 percent, "supplier3" has 27 of "part5" available, some supplier can supply some number of "part9", and that "part4" is hot with at least 75 percent certainty.

• 7.4.2 -- Comparison literals: Hermes supports a typical set of comparison operations, which evaluate to true or false, used to test terms for equality, inequality and ordering. Working left to right, the comparison operators listed in Fig. 7-14 retain the usual mathematical meanings of less-than, less-than-or-equal, equal, not-equal, greater-than-or-equal, and greater-than. Hermes mandates that compared terms be of the same type and must be constants (instantiated) at evaluation time. For further clarification, a specific breakdown of comparison operation subtleties with respect to Hermes types follows:

• For boolean constants, false measures less than true.
• The numeric constants, integer and real, follow typical mathematical ordering.
• Character based constants, such as name, file and string, follow the host machines character set ordering.
• array evaluations follow the element ordering (starting with the first element). Two arrays measure equal if they contain the same element count and every corresponding pair of elements (first, second, third, etc.) proves equal.
• record evaluations follow the field ordering (starting with the first field); Two records prove equal if every matching fields evaluates equal.
• Hermes supports set evaluations using the equal = and not-equal <> operators only; All other comparison operations will generate an error when applied to data sets since element based set ordering remains undefined (there is no way to say whether {a b} ? {b a}, where ? Is one of <, <=, >=, or >). Note: Since Hermes sets are by definition unordered, set equality evaluations require sorting the sets (a side-effect) prior to comparison.

• 7.4.3 -- Instantiation: When faced with two constants, the equal = operator invokes an equality comparison as documented in 7.4.2 above. Where one term remains a variable, however, the equal = operator causes Hermes to instantiate the variable with the other term's value (typically a constant or domain function return value).
 
     The ingres:select domain function, cited in Fig. 7-15, causes the Hermes search engine to iterate through a list of supplier records selected for a specific part. Should the user query cite a specific supplier, as in Fig. 7-16, then the equality operator highlighted in Fig. 7-15 gets evaluated as a comparison between the current records Supplier field value and the specified Supplier constant. Where the user requests a general list of part suppliers (i.e. variable Supplier as in Fig. 7-17), then the highlighted equality operation becomes an instantiation -- Hermes instantiates the predicate Supplier variable with the current record's Supplier field value and moves on to the next rule. 
 
 
 
• 7.4.4 -- The constant and variable literals each take one variable as their term and are used to determine whether the target term is of the type indicated; The constant literal evaluates to true if its term is instantiated to a constant, otherwise it returns false. Likewise, the variable literal returns true if its term is un-instantiated (and thus still a variable).
 
    Hermes constant and variable literals serve two basic purposes. First, domain function inputs must all be constants when the domain function evaluates; the constant literal acts as a safety to ensure this. Second, the constant and variable literals provide a simple means to select among available predicate rules (where more than one exists) based on input (which input terms are constants). In this respect, the mediator author can tailor predicate rules to vary according to input and ideally provide the most efficient function calls to answer the query. In theory, there can be 2ⁿ versions of a rule where n is the predicate arity which corresponds to term instantiation combinations. In practice, many cases can be simplified or combined; A binary table (see Fig. 7-20) often proves useful for visualizing potential rule case combinations and partitions (Note: Consider only predicate terms which apply to domain function inputs).
 
 
 
 
 
 
 
 
 
 
     The rule table in Fig. 7-20 shows the eight (three variables: 2³ = 8) potential constant / variable term combinations for the supplier_part relation (see Fig. 7-19). For this mediator, the author chose to ignore selections by quantity; The mediator thus ignores the Quantity term and focuses only on the Part and Supplier terms with constant / variable tests. This effectively drops the constant / variable term combinations to four (highlighted in Fig. 7-20) as the remaining combinations render duplicates for the Supplier and Part term combinations. Additionally, the current ingres:select domain function can select on only one condition at time. With this in mind, the mediator author combines two cases, rule one and three from the Fig. 7-20 table, into the first mediator predicate rule in Fig. 7-19. Thus the mediator provides only three rules to address the four (highlighted) term combinations.
 
    The first predicate rule applies where just the Part term is, or where both Part and Supplier terms are, instantiated (constant) and draws on the authors fore-knowledge regarding the supplier_part relation status; Since the data file commonly holds more distinct part entries than suppliers, it's more efficient (more selective) to select by Part than by Supplier. Where both terms are constant, Hermes processes the equality = operator as a comparison, vice instantiation operation. Thus the search engine will iterate thru the selected records until it either matches the given Supplier constant, returning true, or it runs out of records and returns false. Otherwise, the first rule returns a list of suppliers, and available quantities, for the specified part.

    The second predicate rule applies for cases where the user provides the Supplier but not the Part term, Hermes executes the ingres:select domain function on Supplier, rendering a list of parts and quantities available from the given supplier.

    The final predicate rule, applicable where both Part and Supplier terms remain variable, causes Hermes to retrieve all relation records via the ingres:all domain function.

 
• 7.4.5 -- The default literal enables Hermes to instantiate the target-variable term with a constant if the term remains un-instantiated at execution time; If target-variable term is already instantiated at execution, then the literal simply returns true and Hermes skips to the next rule entry. If the value-term calls a domain function, then it gets evaluated to a constant prior to target-variable instantiation. Note: Both arguments, target-variable and value-term, must evaluate to the same Hermes type. Additionally, if the value-term remains variable at execution time, Hermes will issue a run-time error.
 
     A typical default literal use is to ensure that a variable has a value as a domain function input. The factory predicate called in Fig. 7-22 instantiates the FactoryLongitude and FactoryLatitude values based on the predicate Factory name input. Next, the default literal ensures that the Radius term is instantiated prior to allowing the quadtree:range domain function execution.

    Another default literal use might be to ensure that a variable has a an input comparison value (see reference comparison section example i.e. default (NeedQuantity, 1)
 

 
• 7.4.6 -- The in and out literals determine array, or set, membership of a given element. Moreover, the in literal provides a mechanism for iterative processing of target data record (such as domain data) source.



• 7.4.6.1 -- The in literal is a membership function which returns true, or false, when the first term, test-term, is instantiated as a constant and either does or does not exist as an element of the tgt-list-term .
 
    Fig. 7-24 shows perhaps the most common form of Hermes in literal usage where the predicate invokes the in literal with a variable test-term and domain function call for the list. This causes Hermes to iteratively instantiate the test-term with the current tgt-list-term values (derived here thru the quadtree domain) and complete the remaining rule literal processing. Upon issuing a predicate solution, the search engine then backtracks to the in literal, increments the list cursor and instantiates the test-term with the next available list element. This continues until Hermes processes all tgt-list-term elements at which point the in literal fails, causing a false return value.
 
    Hermes also allows direct data file access through the in literal calls such as in (R, 'parts.hrm'). This proves logically equivalent to the call in (R, Hermes:all('parts.hrm')). The difference, however, is that the first version accesses the file directly to retrieve each element, while the second version copies the whole 'parts.hrm' file to a temporary, and then retrieve each element from the temporary file. Note: For proper access, 'parts.hrm' file must be declared in the Hermes domain using a data declaration (see section 7.2.3).



• 7.4.6.2 -- The out literal returns true when the first term, test-term, is not an element of the second term, tgt-list-term. (otherwise it returns false). Mediator authors typically use the out literal to provide exceptions to a general rule; Fig. 7-26 lists a predicate rule which filters out yellow, orange or red cars from the selected database records. As with the in literal, the tgt-list-term can directly reference a Hermes data file through calls such as: out (Color, 'badcolor.hrm').

• 7.4.7 -- The is literal (short for intermediate storage) writes domain function results to a Hermes standard data file. Should the file already exist at run-time, Hermes overwrites it. Hermes typically uses the is literal to store intermediate query results for further processing; Fig. 7-28 shows a mediator solving the minimum_cost rule by temporarily storing selected part supplier records to the costs.hrm file (via the is literal), and then finding the minimum cost supplier record through the Hermes:mimimum domain function. Note: Use of the is literal mandates a data declaration in the mediator file for the target storage file.
 
 
 
 
 
 
 
 
 
 

• 7.5 -- Hermes predicate clauses can be either facts or if-then rules which state something about the data.

• 7.5.1 -- A fact is a predicate containing no variables or domain functions. Facts are generally stored in external databases, but they can also be stored in a mediator (see Fig. 7-30)

• 7.5.2 -- A rule contains a head (the "then" part), which is a predicate containing no domain functions; and a body (the "if" part), which is one or more literals of any type. Rules have been illustrated repeatedly in previous examples.
 
 

7.6 -- Hermes queries typically ask data questions by instantiating specific variables of the appropriate mediator predicates. Queries most often involve only one predicate such as that in Fig. 7-31 which requests prices and suppliers of "widget4". Hermes supports compound queries as well; Fig. 7-32 requests a list of suppliers offering widget4 at a cost of 50 or less. It sometimes proves more efficient, however, to write an additional predicate which captures the compound query functionality.

Web Accessibility