<?xml version="1.0" standalone="yes"?>
<Paper uid="A92-1038">
  <Title>Datenbank-DIALOG and the Relevance of Habitability</Title>
  <Section position="4" start_page="0" end_page="241" type="intro">
    <SectionTitle>
3 Comparisons
</SectionTitle>
    <Paragraph position="0"> A central concern ill querying databases are cornparisons between various kinds of objects. Comt)arisons involve a relation between values associated with a dimension and units of measure. Values may be given explicitly or implicitly by derivation (thus including superlatives).</Paragraph>
    <Paragraph position="1">  Linguistic means for expressing colnparison vary widely. Usually, comparison is associated with gradable adjectives and adverbs in various syntactic constructions: hal ein hgheres Gehalt (Aux+A/NP); verdient mehr (V+Adv); rail einem hgheren Gehall (A/PP). The interpretation of those expressions should be the same. Datenbank-DIALOG uses a compositional semantics and separates the lexical item from the underlying semantic relation, which may be shared by different words.</Paragraph>
    <Paragraph position="2"> More prol)lerns arise when specifying the value for the cornparison: ein hb'heres Gehalt als 20.000,-; ein Gehalt yon mehr als 20.000,-; mehr als 20.000,- Gehalt; verdient mehr als 20.000,-. The comparative and the value may be adjacent or not, and show up a.s PPs, complex determiners or adverbial phrases. All these constructions map onto the same semantic representation, a relation, a value along with a dimension and a unit--thus allowing to compare values with different units--and a compared object. This assures a uniform semantic treatment.</Paragraph>
    <Paragraph position="3"> In verdicnl mehr als Dr. Haid the value is specified only implicitly by referring to the salary of Dr. Haid.</Paragraph>
    <Paragraph position="4"> Despite the different structure of the corresponding SQL queries the user will hardly notice this fundarnental difference. For a habitable system it is necessary to provide solutions to both types of comparisons. Datenbank-DIALOG recognizes the different interpretations by the semantic type associated with the value of the phrase to be cornpared. If the value has the correct dimension, it may safely be inserted a.s an argulnent into the cornparison relation. Otherwise, Datenbank-DIALOG constructs a subquery giving the value by using the dominating relation and fitting the comparison object into the &amp;quot;subject&amp;quot; slot of the attribute. The resulting structure is processed analogously to a top-level query. As a consequence, anal)hora resolution may be apl)lied enabling Datenbank-DIALOG to give a correct interpretation of Weri verdient mehr als seini Vorgeselzler'? Domain predicates need not uniquely deterrnine the relation and attributes of a corresponding predicate in the database. Datenbank-DIALOG splits the interpretation of an utterance into two stages: An interpretation in the domain model, i.e. a caseframe, which is then mapped (using a translation table) to an interpretation in the database lnodel, i.e. a DB-caseframe.</Paragraph>
    <Paragraph position="5"> This approach allows to interpret superficially similar queries as quite different SQL queries. Attributes with the same meaning stored in different tables (nursesalary vs. doctor-salary) can be treated as well as derived attributes (salary computed from basic + variable salary)--in short, the user should not need to know about the actual encoding of information. An interesting instance of this prillciple is the interpretation of Wieviele Patienten behandelt Dr. Haid. Whereas in one database rnodel the imrnber of patients is stored explicitly and can be treated analogously to the salary above, other database models contain this &amp;quot;attribute&amp;quot; only implicitly: the number of patients haz to be computed (counted) by the SQL query. To obtain these quite different interpretations, only a different mapping of the (contents of the) argurnent-slot of the predicate Treatment in the translation step between domain and databa.se level is required. A special case (where irnplicit attributes must be made explicit) are queries involving the comparison of two subqueries. This cannot be expressed in a single SQL query.</Paragraph>
    <Paragraph position="6"> A ternporary table has to be created containing the relevant count-attribute together with information on the object hearing that attribute. The actual comparison can then be made with the now explicit attribute.</Paragraph>
    <Paragraph position="7"> Most problems with comparatives also occur with superlatives and are dealt with in an analogous way.</Paragraph>
    <Paragraph position="8"> One interesting phenomenon which has no direct parallel in comparative structures shows in Welcher Arzl, der in der Ambulanz arbeilet, verdient am meislen? In most cases Who has the highest salary among the doctors working in the casualty department? is the most plausible interpretation and should be preferred. To produce this reading, a kind of copying has to he performed: not only must the dominating relation be copied but also the restrictions on the subject slot (i.e., on the bearer of the attribute) have to be inherited. In Datenbank-DIALOG this copying works on the ca.seframe representation, and thus is able to handle restrictions resulting from different syntactic constructions, such as the lexicon (Ambulanzarzl), APs (in der Ambulanz arbeitende Arzl), PPs (Arzt aus der Ambulanz), NPs (Arzt der Ambulanz) and relative clauses ( Arzt, der in der Ambulanz arbeitet). All these constructions end up as modifications in the case-frame due to the compositional nature of our approach.</Paragraph>
    <Paragraph position="9"> Thus a unified solution for inheritance of modifiers in their various forms is achieved.</Paragraph>
    <Paragraph position="10"> A correct comparison is only possible if compared values are of the same dimension and share a unit of measure. Differences and incompatibilities may arise in different places: frorn special formatting conventions (e.g. 20000, 20.000,-, $20), when the user specifies a dimension and unit of measure verbatim (e.g. &amp;quot;10 Meter&amp;quot;), from the database, where coinparable columns may be a.ssociated with different units of Inca.sure. Datenbank-DIALOG solves this problem--by defining a normalized form azsociating values with units and transformation rules between measures of different units--at the scanner level (l)atterns, e.g. (late formats), at the parser level (linguistic information to fill the slots in the normalized value frame), at the interpretation level (procedures to transform constant values from one unit to another), at the database level (transformation fimctions of the query language).</Paragraph>
  </Section>
class="xml-element"></Paper>