<?xml version="1.0" standalone="yes"?>
<Paper uid="E95-1025">
  <Title>ProFIT: Prolog with Features, Inheritance and Templates</Title>
  <Section position="3" start_page="180" end_page="182" type="metho">
    <SectionTitle>
2 The ProFIT Language
</SectionTitle>
    <Paragraph position="0"> The set of ProFIT programs is a superset of Prolog programs. While a Prolog program consists only of definite clauses (Prolog is an untyped language), a ProFIT program consists of datatype declarations and definite clauses. The clauses of a ProFIT program can make use of the datatypes (sorts, features, templates and finite domains) that are introduced in the declarations. A ProFIT program consists of:</Paragraph>
    <Section position="1" start_page="180" end_page="181" type="sub_section">
      <SectionTitle>
2.1 Sort Declarations
</SectionTitle>
      <Paragraph position="0"> In addition to unsorted Prolog terms, ProFIT allows sorted feature terms, for which the sorts and features must be declared in advance.</Paragraph>
      <Paragraph position="1"> The most general sort is top, and all other sorts must be subsorts of top. Subsort declarations have the syntax given in (1). The declaration states that all Subi are subsorts of Super, and that all Subi are mutually exclusive.</Paragraph>
      <Paragraph position="2"> Super &gt;\[Sub,,..., (1) It is also possible to provide subsorts that are not mutually exclusive, as in (2), where one subsort may be chosen from each of the &amp;quot;dimensions&amp;quot; connected by the * operator (Erbach, 1994).</Paragraph>
      <Paragraph position="4"> Every sort must only be defined once, i.e. it can appear only once on the left-hand side of the connective &gt;.</Paragraph>
      <Paragraph position="5"> 2Similar, but less efficient compilation schemes are used in Hirsh's P-PATR (Hirsh, 1986) and Covington's GULP system (Covington, 1989).</Paragraph>
      <Paragraph position="6">  The sort hierarchy must not contain any cycles, i.e. there must be no sorts A and B, such that A#B, andA&gt; B&gt; A.</Paragraph>
      <Paragraph position="7"> The immediate subsorts of top can be declared to be extensional. Two terms which are of an extensional sort are only identical if they.have a most specific sort (which has no subsort), and if all features are instantiated to ground terms. If a sort is not declared as extensional, it is intensional. Two intensional terms are identical only if they have been unified.</Paragraph>
    </Section>
    <Section position="2" start_page="181" end_page="181" type="sub_section">
      <SectionTitle>
2.2 Feature Declarations
</SectionTitle>
      <Paragraph position="0"> Unlike unsorted feature formalisms (such as PATR-II), where any feature can be added to any structure, ProFIT follows the notion of appropriateness in Carpenter's logic of typed feature structures (Carpenter, 1992), and introduces features for particular sorts. For each sort, one must declare which features are introduced by it. The features introduced by a sort are inherited by all its subsorts, which may also introduce additional features. A feature must be introduced only at one most general sort. This makes it possible to provide a notation in which the sort name can be omitted since it can be inferred from the use of a feature that is appropriate for that sort.</Paragraph>
      <Paragraph position="1"> This notion of appropriateness is desirable for structuring linguistic knowledge, as it prevents the ad-hoc introduction of features, and requires a careful design of the sort and feature hierarchy.</Paragraph>
      <Paragraph position="2"> Appropriateness is also a prerequisite for compilation of feature terms into fixed-arity Prolog terms. Each feature has a sortal restriction for its value. If a feature's value is only restricted to be of sort top, then the sortal restriction can be omitted. The syntax of feature declarations is given in (3).</Paragraph>
      <Paragraph position="4"> Feature, : Restrn\].</Paragraph>
      <Paragraph position="5"> The following declaration defines a sort binary_tree with subsorts leaf and internaLnode. The sort binary tree introduces the feature label and its subsort adds the features lefl_daughler and right_daughter. If a sort has subsorts and introduces features, these are combined in one declaration. null binary_tree &gt; Ileal, internal_node\] intro \[label\].</Paragraph>
      <Paragraph position="6"> int ernal_node intro \[left_daughter:binary_tree, right_daught er: binary_tree\].</Paragraph>
    </Section>
    <Section position="3" start_page="181" end_page="181" type="sub_section">
      <SectionTitle>
2.3 Sorted Feature Terms
</SectionTitle>
      <Paragraph position="0"> On the basis of the declarations, sorted feature terms can be used in definite clauses in addition to and in combination with Prolog terms. A Prolog term can have a feature term as its argument, and a feature can have a Prolog term as its value. This avoids potential interface problems between different representations, since terms do not have to be translated between different languages. As an example, semantic representations in first-order terms can be used as feature values, but do not need to be encoded as feature terms.</Paragraph>
      <Paragraph position="1"> Sorted feature terms consist of a specification of the sort of the term (4), or the specification of a feature value (5), or a conjunction of terms (6).</Paragraph>
      <Paragraph position="2"> A complete BNF of all ProFIT terms is given in the appendix.</Paragraph>
      <Paragraph position="4"> The following clauses (based on HPSG) state that a structure is saturated if its subcat value is the empty list, and that a structure satisfies the Head Feature Principle (hfp) if its head features are identical with the head features of its head daughter. 3 Note that these clauses provide a concise notation because uninstantiated features can be omitted, and the sorts of structures do not have to be specified explicitly because they can be infered from use of the features.</Paragraph>
      <Paragraph position="5"> saturated ( synsem ! local ! cat ! subcat ! &lt;elist ). hfp ( synsem ! local ! cat ! head ! X dtrs ! head_dr r ! synsem ! local ! cat ! head ! X ). Note that conjunction also provides the possiblity to tag a Prolog term or feature term with a variable (Var ~ Term).</Paragraph>
    </Section>
    <Section position="4" start_page="181" end_page="182" type="sub_section">
      <SectionTitle>
2.4 Feature Search
</SectionTitle>
      <Paragraph position="0"> In the organisation of linguistic knowledge, feature structures are often deeply embedded, due to the need to group together sets of features whose value can be structure-shared. In the course of grammar development, it is often necessary to change the &amp;quot;location&amp;quot; of a feature in order to get the right structuring of information.</Paragraph>
      <Paragraph position="1"> Such a change of the '~feature geometry&amp;quot; makes it necessary to change the path in all references to a feature. This is often done by introducing templates whose sole purpose is the abbreviation of a path to a feature.</Paragraph>
      <Paragraph position="2"> ProFIT provides a mechanism to search for paths to features automatically provided that the sortal restrictions for the feature values are strong enough to ensure that there is a unique minimal path. A path is minimal if it does not contain any repeated features or sorts.</Paragraph>
      <Paragraph position="3"> 3These clauses assume appropriate declarations for the sort elist, and for the features synsem, local, cat, subcat, head, dtrs and head_dtr.</Paragraph>
      <Paragraph position="4">  The sort from which to start the feature search must either be specified explicitly (7) or implicitly given through the sortal restriction of a feature value, in which case the sort can be omitted and the expression (8) can be used.</Paragraph>
      <Paragraph position="5"> Sort &gt;&gt;&gt; Feature ! Term (7) &gt;&gt;&gt; Feature ! Term (8) The following clause makes use of feature search to express the Head Feature Principle (hfp).</Paragraph>
      <Paragraph position="6"> hfp( sign&gt;&gt;&gt;head !X dtrs!head_dtr} &gt;&gt;&gt;head!X ).</Paragraph>
      <Paragraph position="7"> While this abbreviation for feature paths is new for formal description languages, similar abbreviatory conventions are often used in linguistic publications. They are easily and unambiguously understood if there is only one unique path to the feature which is not embedded in another structure of the same sort.</Paragraph>
    </Section>
    <Section position="5" start_page="182" end_page="182" type="sub_section">
      <SectionTitle>
2.5 Templates
</SectionTitle>
      <Paragraph position="0"> The purpose of templates is to give names to frequently used structures. In addition to being an abbreviatory device, the template mechanism serves three other purposes.</Paragraph>
      <Paragraph position="1"> * Abstraction and interfacing by providing a fixed name for a value that may change,</Paragraph>
    </Section>
  </Section>
  <Section position="4" start_page="182" end_page="183" type="metho">
    <SectionTitle>
* Partial evaluation,
</SectionTitle>
    <Paragraph position="0"> * Functional notation that can make specifications easier to understand.</Paragraph>
    <Paragraph position="1"> Templates are defined by expressions of the form (9), where Name and Value can be arbitrary ProFIT terms, including variables, and template calls. There can be several template definitions with the same name on the left-hand side (relational templates). Since templates are expanded at compile time, template definitions must not be</Paragraph>
    <Paragraph position="3"> Templates are called by using the template name prefixed with (c) in a ProFIT term.</Paragraph>
    <Paragraph position="4"> Abstraction makes it possible to change data structures by changing their definition only at one point. Abstraction also ensures that databases (e.g. lexicons) which make use of these abstractions can be re-used in &amp;quot;different kinds of applications where different datastructures represent these abstractions.</Paragraph>
    <Paragraph position="5"> Abstraction through templates is also useful for defining interfaces between grammars and processing modules. If semantic processing must access the semantic representations of different grammars, this can be done if the semantic module makes use of a template defined for each grammar that indicates where in the feature structure the semantic information is located, as in the following example for HPSG.</Paragraph>
    <Paragraph position="6"> semantics (synsem ! local !cont ! Sem) : = Sem.</Paragraph>
    <Paragraph position="7"> Partial evaluation is achieved when a structure (say a principle of a grammar) is represented by a template that gets expanded at compile time, and does not have to be called as a goal during processing.</Paragraph>
    <Paragraph position="8"> We show the use of templates for providing functional notation by a simple example, in which the expression (c)first(X) stands for the first element of list X, and ~rest(X) stands for the tail of list X, as defined by the following template definition. null</Paragraph>
    <Paragraph position="10"> The member relation can be defined with the following clauses, which correspond very closely to the natural-language statement of the member relation given as comments. Note that expansion of the templates yields the usual definition of the member relation in Prolog.</Paragraph>
    <Paragraph position="11"> Y, The first element of a list ~, is a member of the list.</Paragraph>
    <Paragraph position="12"> member (@first (List), List).</Paragraph>
    <Paragraph position="13"> ~, Element is a member of a list Y, if it is a member of the rest of the list</Paragraph>
    <Paragraph position="15"> The expressive power of an n-place template is the same as that of an n+l place fact.</Paragraph>
    <Section position="1" start_page="182" end_page="183" type="sub_section">
      <SectionTitle>
2.6 Disjunction
</SectionTitle>
      <Paragraph position="0"> Disjunction in the general case cannot be encoded in a Prolog term representation. 4 Since a general treatment of disjunction would involve too much computational overhead, we provide disjunctive terms only as syntactic sugar. Clauses containing disjunctive terms are compiled to several clauses, one for each consistent combination of disjuncts.</Paragraph>
      <Paragraph position="1"> Disjunctive terms make it possible to state facts that belong together in one clause, as the following formulation of the Semantics Principle (s em_p) of HPSG, which states that the content value of a head-adjunct structure is the content value of the adjunct daughter, and the content value of the other headed structures (head-complement, headmarker, and head-filler structure) is the content value of the head daughter.</Paragraph>
      <Paragraph position="3"> For disjunctions of atoms, there exists a Prolog term representation, which is described below.</Paragraph>
    </Section>
    <Section position="2" start_page="183" end_page="183" type="sub_section">
      <SectionTitle>
2.7 Finite Domains
</SectionTitle>
      <Paragraph position="0"> For domains involving only a finite set of atoms as possible values, it is possible to provide a Prolog term representation (due to Colmerauer, and described by Mellish (Mellish, 1988)) to encode any subset of the possible values in one term.</Paragraph>
      <Paragraph position="1"> Consider the agreement features person (with values 1, 2 and 3) and number (with values sg and pl). For the two features together there are six possible combinations of values (l&amp;;sg, 2&amp;sg, 3&amp;sg, l&amp;pl, 2&amp;pl, 3&amp;pl). Any subset of this set of possible values can be encoded as one Prolog term. The following example shows the declaration needed for this finite domain, and some clauses that refer to subsets of the possible agreement values by making use of the logical connectives &amp;quot; (negation), &amp; (conjunction), or</Paragraph>
      <Paragraph position="3"> verb(sleep, -(3&amp;sg)).</Paragraph>
      <Paragraph position="4"> verb(am, l&amp;sg).</Paragraph>
      <Paragraph position="5"> verb(is, 3&amp;sg).</Paragraph>
      <Paragraph position="6"> verb(are, 2 or pl). np('I' , l&amp;sg) .</Paragraph>
      <Paragraph position="7"> np(you, 2~agr).</Paragraph>
      <Paragraph position="8"> This kind of encoding is only applicable to domains which have no coreferences reaching into them, in the example only the agreement features as a whole can be coreferent with other agreement features, but not the values of person or number in isolation. This kind of encoding is useful to avoid the creation of choice points for the lexicon of languages where one inflectional form may correspond to different feature values.</Paragraph>
    </Section>
    <Section position="3" start_page="183" end_page="183" type="sub_section">
      <SectionTitle>
2.8 Cyclic Terms
</SectionTitle>
      <Paragraph position="0"> Unlike Prolog, the concrete syntax of ProFIT allows to write down cyclic terms by making use of conjunction: x &amp; ~(x).</Paragraph>
      <Paragraph position="1"> Cyclic terms constitute no longer a theoretical or practical problem in logic programming, and almost all modern Prolog implementations can perform their unification (although they can't print them out). Cyclic terms arise naturally in NLP through unification of non-cyclic terms, e.g., the Subcategorization Principle and the Spec Principle of HPSG.</Paragraph>
      <Paragraph position="2"> ProFIT supports cyclic terms by being able to print them out as solutions. In order to do this, SThe syntax for finite domain terms is Terra,Domain. However, when atoms from a finite domains are combined by the conjunction, disjunction and negation connectives, the specification of the domain can be omitted. In the example, the domain must only be specified for the value 2, which could otherwise be confused with the integer 2.</Paragraph>
      <Paragraph position="3"> the dreaded occur check must be performed. Since this must be done only when results are printed out as ProFIT terms, it does not affect the run-time performance.</Paragraph>
    </Section>
  </Section>
  <Section position="5" start_page="183" end_page="184" type="metho">
    <SectionTitle>
3 From ProFIT terms to Prolog
</SectionTitle>
    <Paragraph position="0"/>
    <Section position="1" start_page="183" end_page="184" type="sub_section">
      <SectionTitle>
terms
3.1 Compilation of Sorted Feature Terms
</SectionTitle>
      <Paragraph position="0"> The compilation of sorted feature terms into a Prolog term representation is based on the following principles, which are explained in more detail in (Mellish, 1988; Mellish, 1992; Schgter, 1993; Erbach, 1994).</Paragraph>
      <Paragraph position="1"> * The Prolog representation of a sort is an instance of the Prolog representation of its supersorts. null * Features are represented by arguments. If a feature is introduced by a subsort, then the argument is added to the term that further instantiates its supersort.</Paragraph>
      <Paragraph position="2"> * Mutually exclusive sorts have different functots at the same argument position, so that their unification fails.</Paragraph>
      <Paragraph position="3"> We illustrate these principles for compiling sorted feature terms into Prolog terms with an example from aPse. The following declaration states that the sort sign has two mutually exclusive subsorts lexical and phrasal and introduces four features.</Paragraph>
      <Paragraph position="4"> sign &gt; \[lexical,phrasal\] intro \[phon, synsem, qstore, retrieved\].</Paragraph>
      <Paragraph position="5"> In the corresponding Prolog term representation below, the first argument is a variable whose only purpose is being able to test whether two terms are coreferent or whether they just happen to have the same sort and the same values for all features. In case of extensional sorts (see section 2.1), this variable is omitted. The second argument can be further instantiated for the subsorts, and the remaining four arguments correspond to the four features.</Paragraph>
      <Paragraph position="6"> $s ign (Var, LexPhras, Phon, Synsem, qstore, Retriev) The following declaration introduces two sort hierarchy &amp;quot;dimensions&amp;quot; for subsorts of phrasal, and one new feature. The corresponding Prolog term representation instantiates the representation for the sort sign further, and leaves argument positions that can be instantiated further by the subsorts of phrasal, and for the newly introduced feature daughters.</Paragraph>
      <Paragraph position="7"> phrasal &gt; \[headed,non_headed\] * \[decl,int,rel\] intro \[daughters\].</Paragraph>
    </Section>
    <Section position="2" start_page="184" end_page="184" type="sub_section">
      <SectionTitle>
3.2 Compilation of Finite Domains
</SectionTitle>
      <Paragraph position="0"> The compilation of finite domains into Prolog terms is performed by the &amp;quot;brute-force&amp;quot; method described in (Mellish, 1988). A finite domain with n possible domain elements is represented by a Prolog term with n + 1 arguments. Each domain element is associated with a pair of adjacent arguments. For example, the agreement domain agr from section 2.7 with its six elements (l&amp;sg, 2&amp;sg, 3&amp;sg, l~:pl, 2~:pl, 3&amp;pl) is represented by a Prolog term with seven arguments.</Paragraph>
      <Paragraph position="1"> Sagr(1,A,B,C,D,E,O) Note that the first and last argument must be different. In the example, this is achieved by instantiation with different atoms, but an inequality constraint (Prolog I\['s dif) would serve the same purpose. We assume that the domain element l~zsg corresponds to the first and second arguments, 2&amp;sg to the second and third arguemnts, and so on, as illustrated below.</Paragraph>
      <Paragraph position="2"> Sagr( 1 , h , B , C , D , E , 0 ) lsg 2sg 3sg lpl 2pl 3pl A domain description is translated into a Prolog term by unifying the argument pairs that are excluded by the description. For example, the domain description 2 or pl excludes l&amp;sg and 3&amp;sg, so that the the first and second argument are unified (l~sg), as well as the third and fourth (3&amp;sg).</Paragraph>
      <Paragraph position="3"> $agr(1,1,X,X,D,E,0) When two such Prolog terms are unified, the union of their excluded elements is computed by unificatation, or conversely the intersection of the elements which are in the domain description.</Paragraph>
      <Paragraph position="4"> The unification of two finite domain terms is successful as long as they have at least one element in common. When two terms are unified which have no element in common, i.e., they exclude all domain elements, then unification fails because all arguments become unified with each other, including the first and last arguments, which are different. null</Paragraph>
    </Section>
  </Section>
  <Section position="6" start_page="184" end_page="185" type="metho">
    <SectionTitle>
4 Implementation
</SectionTitle>
    <Paragraph position="0"> ProFIT has been implemented in Quintus and Sicstus Prolog, and should run with any Prolog that conforms to or extends the proposed ISO Prolog standard.</Paragraph>
    <Paragraph position="1"> All facilities needed for the development of application programs, for example the module system and declarations (dynamic, multifile etc.) are supported by ProFIT.</Paragraph>
    <Paragraph position="2"> Compilation of a ProFIT file generates two kinds of files as output.</Paragraph>
    <Paragraph position="3">  1. Declaration files that contain information for compilation, derived from the declarations. 2. A program file (a Prolog program) that con- null tains the clauses, with all ProFIT terms compiled into their Pro\]og term representation. The program file is compiled on the basis of the declaration files. If the input and output of the program (the exported predicates of a module) only make use of Prolog terms, and feature terms are only used for internal purposes, then the program file is all that is needed. This is for example the case with a grammar that uses feature terms for grammatical description, but whose input and output (e.g. graphemic form and logical form) are represented as normal Prolog terms.</Paragraph>
    <Paragraph position="4"> Declarations and clauses can come in any order in a ProFIT file, so that the declarations can be written next to the clauses that make use of them. Declarations, templates and clauses can be distributed across several files, so that it becomes possible to modify clauses without having to recompile the declarations, or to make changes to parts of the sort hierarchy without having to recompile the entire hierarchy.</Paragraph>
    <Paragraph position="5"> Sort checking can be turned off for debugging purposes, and feature search and handling of cyclic terms can be turned off in order to speed up the compilation process if they are not needed. Error handling is currently being improved to give informative and helpful warnings in case of undefined sorts, features and templates, or cyclic sort hierarchies or template definitions.</Paragraph>
    <Paragraph position="6"> For the development of ProFIT programs and grammars, it is necessary to give input and output and debugging information in ProFIT terms, since the Pro\]og term representation is not very readable. ProFIT provides a user interface which * accepts queries containing ProFIT terms, and translates them into Prolog queries, * converts the solutions to the Prolog query back into ProFIT terms before printing them out, * prints out debugging information as ProFIT terms.</Paragraph>
    <Paragraph position="7"> When a solution or debugging information is printed out, uninstantiated features are omitted, and shared structures are printed only once and represented by variables on subsequent occurences. null A pretty-printer is provided that produces a neatly formatted screen output of ProFIT terms, and is configurable by the user. ProFIT terms can also be output in IATEX format, and an interface to the graphical feature editor Fegramed is foreseen. null  In order to give a rough idea of the efficiency gains of a compilation into Prolog terms instead of using a feature term unification algorithm implemented on top of Prolog, we have compared the runtimes with ALE and the Eisele-DSrre algorithm for unsorted feature unification for the following tasks: (i) unification of (unsorted) feature structures, (ii) unification of inconsistent feature structures (unification failure), (iii) unification of sorts, (iv) lookup of one of I0000 feature structures (e.g. lexical items), (v) parsing with an HPSG grammar to provide a mix of the above tasks.</Paragraph>
    <Paragraph position="8"> The timings obtained so far indicate that ProFIT is 5 to 10 times faster than a system which in~plements a unification algorithm on top of Prolog, a result which is predicted by the studies of SchSter (SchSter, 1993) and the experience of the Core Language Engine.</Paragraph>
    <Paragraph position="9"> The ProFIT system and documentation are available free of charge by anonymous ftp (server: ftp.coli.uni-sb.de, directory: pub/profit).</Paragraph>
  </Section>
class="xml-element"></Paper>