Implementing semantic frames as typed feature structures with XMG

This work presents results on the integration of frame-based representations into the framework of eXtensible MetaGrammar (XMG). Originally XMG allowed for the description of tree-based syntactic structures and underspecified representations of predicate-logical formulae, but the representation of frames as a sort of typed feature structure, particularly type unification, was not supported. Therefore, we introduce an extension that is capable of handling frame representations directly by means of a novel -dimension. The aim is not only to make possible a straightforward specification of frame descriptions, but also to offer various ways to specify constraints on types, be it as a contiguous type hierarchy or a loose set of feature structure constraints. The presented extensions to XMG are fully operational in a new prototype.

foremost, it allows for a choice between minimal and maximal models of type constraints.As a consequence of this, our approach also allows for anonymous types, hence types that result from the conjunction of defined types, but that are not defined themselves in the type signature.We will precisely explicate this distinction in Section 4. Finally, our work aims at providing the grammar writer with multiple means of expression, for example, in permitting him/her to make use of loose type constraints or connected type hierarchies, or both.This degree of flexibility is often not found in other grammar implementation frameworks that support typed feature structures.We hypothesize that other frameworks are mainly concerned with the syntactic component of the grammar, while we focus on the conceptual semantics whose structure (and how it comes about) seems to be much less predetermined.
The paper proceeds as follows.The next section briefly illustrates the grammatical objects that we are concerned with, and Section 3 then shows the proposed factorization, which crucially guides the implementation with XMG and also justifies the employment of frame unification.After this, we explain the formalization of frames as a sort of typed feature structure in Section 4, and the basic concepts of XMG in Section 5.This will be essential to understand the usage and compilation details of the new <frame>-dimension, the presentation of which follows in Section 6.Finally, Section 7 concludes the article.Moreover, a complete code example based on analyses from Section 2 and Section 3 is presented in the Appendix.

a frame-based semantics for ltag
We will use the state-of-the-art work of Kallmeyer and Osswald (2013) on integrating frame semantics into Lexicalized Tree-Adjoining Grammars (LTAG) as a starting point.One important motivation for developing a frame-based semantics for LTAG is found in the straightforward account for the well-established distinction between lexical and constructional contributions to the overall meaning.An example of this sort of contrast is displayed in (1): (1) a.The ball rolled into the goal.b.John rolled the ball into the goal.
[ 187 ] Both sentences involve the same verb of directed motion, rolled, but the two instances nevertheless differ with respect to the linking of the subject with the conveyed event semantics.While in (1a) the subject the ball is the moved object, in (1b) the subject John is causing the motion rather than undergoing it.The trigger for this semantic shift seems to be the lack or existence of the direct object (both under the presence of a directional PP), hence the construction type, as this constitutes the crucial syntactic difference between (1a) and (1b).
In the framework of Kallmeyer and Osswald (2013), the syntax of these constructions lies in the scope of the LTAG component.An LTAG consists of a finite set of phrase structure trees, the elementary trees, that can be combined (by means of two basic operations, substitution and adjunction) to generate larger trees. 4Since we are dealing with a lexicalized TAG, each elementary tree must include at least one non-terminal leaf, the lexical anchor.Furthermore elementary trees are constrained through the valency properties of their anchors.Usually each non-terminal leaf corresponds to exactly one syntactic argument, and vice versa.
The proposed LTAG analyses of (1a) and (1b), shown in Figure 1, differ with respect to the elementary trees that are associated with the two instances of rolled, say the intransitive rolled int and the transitive rolled tr :5 since syntactic arguments are represented as non-terminal leaves, the elementary tree for rolled int lacks the object NP slot that the elementary tree for rolled tr has.The difference in meaning is therefore attributed to the different elementary trees that a given verb may anchor.
Since elementary trees, but not the anchoring verbs, are held responsible for different linking patterns, it is straightforward to abstract away from the concrete anchor by just considering the yet unanchored elementary tree, which is commonly called the tree template.An example of such a tree template is shown on the left in Figure 2, wherein the site of lexical insertion, here of rolled, is marked by the

. . NP
Figure 2: Tree template and frame-semantic representation of the transitive motion construction from Figure 1, taken from Kallmeyer and Osswald (2013, Fig. 26) complex node labels will be explained presently.The right side of Figure 2 shows the event semantic contribution of the tree template in the format of a typed feature structure, here represented as an attribute value matrix (AVM).Typed feature structures are a common representation format of frames (see Petersen 2007), which, according to [ 189 ] Fillmore (1982), Barsalou (1992) and others, are considered a proper representation of mental concepts. 6As can be seen from the example, features describe semantic participants and components (agent, theme, …), while feature structures correspond to conceptual objects, restricted by the type (causation, activity, …) that they are associated with.The boxed numbers, finally, are base labels which serve to mark inequalities and correspondences in the syntax-frame interface.Furthermore, they guide the unification of (subparts of) frames, as can be seen in the next section.
Because tree templates, just as elementary trees, span an extended domain of locality,7 the linking of positions within the tree template to positions within the frame-semantic representation can be achieved rather directly.In Figure 2 it is indicated by co-occurring boxed numbers.For example, the subject NP-leaf is linked with the actor role(s) of the frame, eventually causing the unification of the actor role and the frame of the substituting NP-tree.Note that the nodes of tree templates carry (non-recursive, non-typed) feature structures, which include, among others, interface features such as i(ndividual) and e(vent).8Following the terminology in Kallmeyer and Osswald (2013), we call couples of tree template and frame-semantic representation an elementary construction.
The composition of frame representations is moreover guided by a globally defined type hierarchy, which determines (i) the unifiability of types and the resulting type, and (ii) the set of appropriate features (and their value types) of a type, the appropriateness conditions.Regarding event types, Kallmeyer and Osswald (2013) Kallmeyer and Osswald (2013, Fig. 16).
the more general types dominating the more specific types.Note that the type hierarchy may also contain anonymous types, e.g.activity ∧ motion, which are usually not available in other frameworks.Roughly speaking, anonymous types make it possible to assign appropriateness conditions to a conjunction of types rather than just to a single type.The details will be explained in Section 4.
In this work we are neither concerned with the unification of frame representations following syntactic composition, nor with the preceding process of lexical insertion that triggers the unification of lexical and constructional frame components (see Kallmeyer and Osswald 2013, Fig. 13), but rather with the metagrammatical framework of XMG.Metagrammars are a tool to describe static elementary constructions such as in Figure 2, consisting of a tree template and a fixed typed feature structure.It might therefore seem unnecessary to employ all aspects of typed feature structures in metagrammars, particularly unification.However, this assumption is not warranted.Unification of types and feature structures is also found in the metagrammatical domain once the factorization of elementary constructions of the kind in Figure 2 is taken into account.This will be shown in the next section.[ 191 ] factorization of tree templates and frames Richly structured grammatical objects like those in Figure 2 make necessary some kind of metagrammatical factorization, once a large coverage grammar gets compiled and maintained (Xia et al. 2010).Metagrammatical factorization is a process to define recurring subcomponents of grammatical objects, which can then be combined in at least two ways: in a transformation-based fashion, known as the metarule approach (Becker 1994(Becker , 2000;;Prolo 2002), or in a purely constraint-based, monotonic fashion as is the case in XMG (following Candito 1996).In addition to the benefit in terms of grammar engineering, however, Kallmeyer andOsswald (2012a,b, 2013) claim that metagrammar factorization can be also used to reflect constructional analyses in the spirit of Construction Grammar (Kay 2002;Goldberg 2006).By this perspective, both the lexical material and the "constructions" used contribute meaning.
Taking these two aspects into account, Kallmeyer and Osswald (2013) propose to factorize the tree template and the frame in Figure 2 along the lines of Figure 4.9 Boxes stand for the resulting factors or classes (i.e.classes in the sense of XMG), consisting of descriptions of a tree and a frame fragment.The inclusion relation between boxes is to be understood as a representation of inheritance or instantiation, so that the class of the comprising box inherits from, or instantiates, the class of the included box.Double edges (indicating identity constraints over nodes or base labels), dashed edges (non-strict dominance), ≺* (non-strict precedence), and ∨ (disjunction) are elements of the description language.Figure 4 then illustrates that the tree-frame couple in Figure 2 is a model of the class n0Vn1pp(dir), which combines the classes n0Vn1 and DirPrepObj.Combining two classes essentially means that all associated information is unified, from which a minimal model is resolved (see Section 5).Note that Figure 4 shows only a part of the proposed factorization.For example, the class n0Vn1, also taken from Kallmeyer and Osswald (2013, Fig. 4)   minimal model, which only holds, however, if minimal models are said to consist of the smallest set of nodes that satisfy the description.In XMG, by contrast, minimal models just consist of a set of nodes mentioned in the description, and nothing more.Hence, from point of view of XMG, n0V has two minimal models, one with one VP node, and one with two VP nodes.In order to resolve only the former one, one could additionally apply polarization, or "colours" (Crabbé and Duchier 2005), onto the nodes.Fortunately, the question how many minimal models there are is irrelevant for the point made here and throughout the article.
[ 193 ] structional facet: it only contributes to the frame representation, but no tree descriptions.Now the question is whether the combination of frame representations, following the combination of two classes, should be considered a unification of typed feature structures.It is not hard to see that this is justified.A particularly good example is found in the combination of the frame representations of n0Vn1 and n0Vn1pp(dir) in Figure 4.Even though they have different types, namely event and causation, the resulting type is supposed to be causation.According to the type hierarchy in Figure 3, causation is a subtype of event.Hence this is in line with regular type unification, but exceeds a plain union of feature structures.Therefore the unification of typed feature structures should be already supported at the metagrammatical level.The same holds for the verification of appropriateness conditions, of course.Note that, as can be seen from Figure 4, the flexibility of frame unification is fostered by base labels when unifying the frame of DirPrepObj with a subpart of the frame of n0Vn1pp(dir).
The graphic representation of the metagrammatical factorization in Figure 4 and Figure 5 remains at a rather informal level and the question arises: how could this be translated into XMG code?Since the original XMG did not give a satisfying answer due to reasons of usability and completeness (which we will cover in Section 5) we will [ 194 ] develop and justify a new <frame>-dimension in Section 6.But first we will review the underlying notions: frames as typed feature structure with base labels, type hierarchies and unification.In what follows we largely, but not exclusively, adhere to the definitions in Kallmeyer and Osswald (2013), while streamlining them according to our terminology and taste.What is not needed from Kallmeyer and Osswald (2013), however, are (non-functional) relations, because they do not appear in the frame representations of elementary constructions, other than, e.g., in the frame representations of the anchor lexicon (Kallmeyer and Osswald 2013, Fig. 13).11So we will ignore the notion of (non-functional) relations, and instead dwell on type inference and the minimal and maximal models of feature structure constraints.It is this choice between minimal and maximal models, as well as the general availability of anonymous types, which makes the presented extension to XMG particularly flexible at describing a type system.And it is this flexibility, among other things, which sets our extension to XMG apart from current frameworks for HPSG.
Let us start with the building blocks of typed feature structures, which are settled in the signature: Definition 1 (Signature) A signature is a tuple 〈 A, T, B〉 with a finite set of attributes (or features) A, a finite set of elementary types T , and an infinitely countable set of base labels B.
The set of elementary types is accompanied by special types ⊤ and ⊥ that are useful in feature structure descriptions and feature structure constraints (see below).⊤ is the most general type, unifiable with every other type, whereas ⊥ is unifiable with none of them.Within Boolean expressions, ⊤ corresponds to 'true' and ⊥ to 'false'.Base labels are commonly boxed natural numbers, thus B = { 0 , 1 , 2 , . ..}.
Based on a given signature, typed feature structures are defined as follows: Definition 2 (Base-labelled typed feature structure) Given a signature 〈 A, T, B〉, a base-labelled typed feature structure is a tuple 〈V, δ, τ, β〉 with • V , a finite set of nodes, • τ : V → 2 T , a total typing function, and We call types in 2 T , i.e. elements of the powerset of T , conjunctive types in order to distinguish them from elementary types.
We follow Kallmeyer and Osswald (2013) in that we do not specify a type hierarchy immediately, but treat it as a model of feature structure constraints, i.e. generalized feature structure descriptions.12Therefore the following notations can be directly borrowed from Kallmeyer and Osswald (2013, (3)), omitting only those parts of their definition that deal with relations.Note that we extend δ by feature paths in the usual way. 13efinition 3 (Unlabelled feature structure description) Let 〈V, δ, τ, β〉 be a feature structure over the signature 〈 A, T, B〉 with v, w ∈ V , t ∈ 2 T and p, q ∈ A + , then the satisfaction relation |= between nodes and feature structure descriptions is defined as follows: As such, unlabelled feature structure descriptions apply to nodes of a feature structure.For example, the root node of the causation frame in Figure 4 satisfies the following conjunction of descriptions: (2) = effect mover ∧ cause : activity ∧ effect goal : ⊤ By adding base labels, we can explicitly assign descriptions to nodes within a feature structure.Therefore, in contrast to unlabelled ones, the labelled feature structure descriptions are satisfied by feature structures as a whole: 14 Definition 4 (Labelled feature structure description) Let F = 〈V, δ, τ, β〉 be a feature structure over the signature 〈 A, T, B〉 with p, q ∈ A + and l, k ∈ B, and let ϕ be an unlabelled feature structure description.The satisfaction relation |= between feature structures and labelled feature structure descriptions is defined in the following way: The unlabelled descriptions in (2) can be straightforwardly labelled in order to be satisfied by the causation frame as a whole: (3) = effect mover ∧ 0 cause : activity ∧ 0 effect goal : ⊤ Note that 0 actor .= cause actor is equivalent with 0 actor ≜ 0 cause actor (see Kallmeyer and Osswald 2013, fn. 14).We adopt the convention to write l instead of l ε for some label l.This allows us to write 1 ≜ 2 for expressing the value identity of labels 1 and 2 .Concerning the subsumption relation on feature structures, we can transfer the fairly standard definition from Kallmeyer and Osswald (2013), which they extend by base labels.

Definition 5 (Subsumption, ⊑) Given feature structures
As usual, the definition of unification builds on subsumption: 14 From the general shape of labelled feature structure descriptions it follows that they can only describe feature structures where every node is reachable from some labelled node via a (potentially empty) attribute path.In fact, this is why these labels are called base labels.[ 197 ] Definition 6 (Unification, ⊔) Let F 1 , F 2 , F 3 be feature structures.F 3 is the result of the unification of F 1 and F 2 , iff F 3 is the least specific feature structure such that F 1 ⊑ F 3 and F 2 ⊑ F 3 .
The specificity of feature structures is determined by the number of nodes, the specificity of the assigned types and the size of the base labelling function.Note that, in cases of unification such as in Figure 4, feature structures (and corresponding interface variables) are relabelled beforehand, so that they come with disjoint sets of labels.The identity of certain labels can then be imposed through additional identity statements.
Feature structure constraints consist of universally quantified, unlabelled features structure descriptions, i.e. descriptions that hold for every node in the feature structure.Kallmeyer and Osswald (2013) restrict them to Horn clauses for reasons of tractability. 15Definition 7 (Feature structure constraint) Given unlabelled feature structure descriptions ϕ 1 , . . ., ψ) where quantification is over the nodes of the described feature structure.
The following list shows different kinds of feature structure constraints (mostly taken from Kallmeyer and Osswald 2013, (12) 16 Note that ⇔ in (4) is not part of the description language but indicates the equivalence of descriptions.[ 198 ] Implementing semantic frames with XMG responds to an ISA-relation, namely activity being also an event.An ISNOTA-relation can be expressed by type constraints of the kind in (4b).Note that the use of negation in the consequent is equivalent to a clause with a conjunctive antecedent and a 'false' (⊥) consequent.Not only can the antecedent be complex, but also the consequent, even though this is reducible to a conjunction of simpler implications, as shown in (4c).The last two examples in (4d) and (4e) contain attribute-value terms.Constraint (4d) represents an appropriateness condition, namely a condition on the type activity concerning the value type of its attribute actor.Finally, (4e) adds a constraint about the token identity of the values of the attributes agent and actor (if agent has a value).Constraints of this sort, where every conjunct consists of a feature-value description or a path equation, can be characterized as feature-value constraints. 17 crucial decision concerns the model of feature structure constraints, as it can be seen as maximal or minimal.The difference is made visible in Figure 6  Roughly speaking, a maximal model of type constraints allows for anonymous types (indicated with dots in Figure 6) as long as they are not explicitly excluded.With minimal models it is the other way We therefore concentrate on feature structure constraints in the shape of type constraints, appropriateness conditions and feature-value constraints.
[ 199 ] around: anonymous types are forbidden as long as they are not explicitly allowed.In both cases they could be introduced (or excluded) by constraints such as in (5a), where the antecedent consists of a conjunction of elementary types.In Figure 6, a ∧ c and a ∧ b ∧ c are anonymous types.It is shown in (5b) that these anonymous types can bear feature-value constraints as well.18 (5) a. a ∧ c ⪯ ⊤ b. action ∧ motion ⪯ actor .= mover (Kallmeyer and Osswald 2013, ( 12e)) The preceding remarks were concerned with elementary types.However, as we learned in Definition 2, the typing function τ assigns sets of elementary types, the conjunctive types.They are included for good reason, since they help to treat elementary types and anonymous types in a uniform way, and eventually to facilitate the definition and implementation of unification. 19In the following, we treat conjunctive types as a model of type constraints, and, on this basis, explicate what it means to be minimal or maximal.
Definition 8 (Model of type constraints) Given type constraints TC over a signature 〈 A, T, B〉, a set T of conjunctive types over T is a model of TC, if T satisfies the type constraints from TC in the following way: The model T of given type constraints is said to be maximal, if T is the largest set of conjunctive types that satisfies them.On the other hand, T is said to be the minimal model, if T includes just those conjunctive types of the maximal model that correspond (i) to elementary types, and (ii) to conjunctive types that make up the left side (i.e. the condition) of a type constraint.
The type hierarchies from Figure 6 for elementary types are repeated in Figure 7 for conjunctive types.They are now based on ⊆ rather than ⪯.We say that conjunctive type t1 is the subtype of t2 , if t1 ⊃ t2 .The definition of the most general common subtype is equally simple.It is easy to see that, whenever type constraints have the shape of Horn clauses, the maximal model over conjunctive types T forms a meet semi-lattice (a bounded complete partially ordered set) 〈 T , ⊆〉.Hence, there is a most general common subtype for any two unifiable types.This does not necessarily hold for minimal models that are confined to elementary and certain anonymous types. 20In order to obtain uniqueness of the most general common subtype for any two unifiable types, it can be necessary to add further anonymous types to T (the Dedekind-McNeille completions).Theses completions are computed by the compiler that will be described in Section 6.3.2.A conjunctive type t corresponds to an elementary type t, if t is the smallest set that contains t according to the model.Otherwise, if there is no t to which t corresponds, t is an anonymous type.Similarly, t corresponds to some conjunctive type t′ , if t is the smallest set of a model that contains t′ .Moreover, it can be useful to also express subtype relations among elementary types t 1 , t 2 ∈ T .We say that t 1 is the subtype of t 2 , if for t1 , t2 ∈ T that correspond to t 1 and t 2 it holds that t1 is a subtype of t2 .
Before proceeding to the next section, two further aspects of the feature logic used here and in Kallmeyer and Osswald (2013) should be mentioned.Firstly, it cannot account for reverse type constraints, which refer to dominating nodes (Rainer Osswald, personal communication, July 23, 2014).A case in point is the set of relational concepts such as the mother example from Petersen and Osswald (2014, Fig. 11.5), where mother is said to constrain the existence of a dominating node, connected with a mother edge.Hence, if mother was treated as a type (a subtype of, e.g., person), this constraint could not be expressed, at least not as a part of its appropriateness conditions.Secondly, what seems to be missing so far from the definition in Petersen (2007) is the notion of the central node of a frame, i.e. the node that tells us what the frame "represents" or "refers to".We think, however, that the notion of central nodes is reflected, and generalized, in the present formalization by the notion of base labels.By reappearing in the interface features on the syntactic side, they serve to connect frame nodes with linguistic entities, and nothing else seems to be expressed by central nodes.Dimensions are the crucial elements of a class.They can be equipped with specific description languages and are compiled independently, thereby enabling the grammar writer to treat the levels of linguistic information separately.The standard dimensions are <syn> for the syntax, and <sem> for the semantics. 21 The <syn>-dimension allows one to describe TAG tree templates (or fragments thereof).An example is shown in Figure 8 for the <syn>dimension of class Subj from Figure 4.It includes two sorts of statements, namely those like 'node ?S [cat=s]' that instantiate nodes of the trees, and those like '?S->?SUBJ' which determine the relative position of two nodes in the trees by referring to dominance and linear precedence. 22Note that variable names are prefixed with a question mark ('?').The <sem>-dimension, on the other hand, includes descriptions of a different language, for which a different compiler is used.Since this could be a candidate for hosting frame descriptions, we will have a look at <sem> more closely below.Different as they may be, one crucial commonality of all the dimensions pertains to the joint access 21 Crabbé et al. (2013, 601) also mention the fairly technical dimension <dyn>, more commonly called interface, which helps to express the coreference of variables from different dimensions.Recently Duchier et al. (2012)

have introduced a dimension for morphology; see also Lichte et al. (2013).
22 There is also available a notational alternative with bracket structure.
[ 203 ] to local variables declared in the same class.These shared variables constitute a direct interface between otherwise separated dimensions.The combination of classes takes place outside the <syn>-and <sem>-dimensions.Figure 9 shows an example where the two classes Subj and VSpine are reused by the class n0V.First Subj and VSpine are instantiated and assigned a variable, then the encapsulated, yet exported, variables from Subj and VSpine can be accessed via the dot operator (e.g. to impose identity).When the metagrammar is compiled, first a set of descriptions for each class under evaluation (triggered by value statements such as in Figure 9) is accumulated, and then the accumulated descriptions are resolved to yield minimal models.In the case of <syn>, the solver computes tree templates as minimal models, which is to say that only those nodes that are mentioned in the description are included.The final result can be explored with a viewer, or exported as an XML file in order to use it for parsing (e.g. with the TuLiPA parser, Kallmeyer et al. 2008).

Frame descriptions in the <sem>-dimension?
As mentioned before, the <sem>-dimension is designed to contain underspecified, flat formulae of predicate logic (borrowing from Bos 1996).In fact, it is rather straightforward to reformulate frame descriptions in first-order predicate logic (Kallmeyer and Osswald 2013, Sec. 3.3.3).Concerning the signature, attributes can be represented with two-place predicates, while types can be seen as one-place predicates.The functionality of attributes is imposed by the following axiom for all a ∈ A, given some signature 〈A, T 〉: [ 204 ] (6) ∀x∀ y∀z(a(x, y) ∧ a(x, z) → y = z) (Kallmeyer and Osswald 2013, (6a)) The reformulation of feature structure descriptions and feature structure constraints is equally unproblematic: (7) a. p : t λx∃ y(p(x, y) ∧ t( y)) b. p .= q λx∃ y(p(x, y) ∧ q(x, y)) c. a p λxλz∃ y(a(x, y) ∧ q( y, z)) (Kallmeyer and Osswald 2013, ( 7) Following this approach, a frame representation such as 0 [ actor 1 ] would be translated into the two-place predicate actor(?0, ?1), using regular XMG variables.A more detailed example based on the class n0Vn1pp(dir) is shown in Figure 10.While the reformulation of frame descriptions via two-place predicates is straightforward, it is far less obvious how to account for feature structure constraints and the axiom of functionality.As far as type constraints and the type hierarchy are concerned, there seems to be a chance to simulate them with sets of type predicates.This approach is pursued in Figure 10.The construction of those type simulating sets (TSSs), as we call them, could proceed as follows: given a signature 〈A, T 〉 and a type hierarchy such as the one in Figure 10, we say that t ∈ T is simulated by the minimal set of predicates P t (?X ) for some variable ?X , if P t (?X ) is assembled in the following way: for every t ′ ∈ T , if t ′ reflexively and transitively dominates t in , then t ′ (?X ) ∈ P t (?X ); else if t and t ′ have no common subtype, then ~t′ (?X ) ∈ P t (?X ), where '~' stands for negation.To give an example, P locomotion (?X ) for the type locomotion in the type hierarchy of Figure 10 would be the set {activity(?X ), motion(?X ), ~causation(?X ), locomotion(?X )}.It is easily seen that the size of some P t (?X ) crucially depends on the position of t in , and on the size of T .Note that TSSs do not fully match conjunctive types, due to the insertion of negated type predicates.
[ 205 ] (a) ... <sem>{ actor(?0,?1); theme(?0,?2); cause(?0,?5); actor(?5,?1); theme(?5,?2); effect(?0,?4); goal(?4,?3); %% causation type event(?0); ~activity(?0); ~motion(?0);~locomotion(?0);causation(?0); %% activity type event(?5); activity(?5);~causation(?5)} ... One basic problem of this approach is that so far XMG does not interpret the predicates of the <sem>-dimension, but merely accumulates them for later use.Hence XMG allows for, e.g., the coexistence of predicates theme(x 1 , x 2 ) and theme(x 1 , x 3 ) with x 2 ̸ = x 3 , which conflicts with the required functionality of feature predicates.But even if XMG was enhanced to verify the functionality of predicates, at least three disadvantages would remain: (i) TSSs have to be provided by the grammar writer, (ii) they have to be included in the XMG descriptions as a whole, and (iii) unifying sister types with a common subtype will yield a TSS that does not immediately reveal the elementary type of [ 206 ] the common subtype.The latter disadvantage might be more of an aesthetic kind, but the first and the second one clearly have an impact on usability.Modifying the type hierarchy in the context of a large grammar would make necessary a meta-metagrammar, that would automatically recompute the TSSs and adapt the parts of the XMG descriptions, where TSSs were used.Rather than considerably modifying and extending the solver of the <sem>-dimension, let alone the available description language, we present a novel <frame>-dimension in the next section, which is closely adjusted to the peculiarities of frame representations and frame composition.6 the implementation of typed feature structure descriptions and constraints Implementation entails two operations: specification and compilation.
We will deal with the first one in Section 6.2, when introducing specification languages for feature structure descriptions and constraints.The compilation of frame models based on these specifications is then covered in Section 6.3.First, however, the technical prerequisites for extending the XMG compiler are to be outlined.

Architecture and extensibility of XMG
The XMG project started in 2003 with the goal of providing a means to write large scale tree-based grammars, i.e.Tree Adjoining Grammars and Interaction Grammars (Perrier 2000).Originally, the compiler was written in Oz/Mozart, a language which is not maintained anymore.For this reason, and in order to build a compiler more in line with the project's ambitions (regarding modularity and extensibility), it was necessary to restart the implementation from scratch.The new implementation started in 2010 and is sometimes called XMG-NG or XMG2. 23The compiler is now written in YAP (Yet Another Prolog) with bindings to Gecode for solving constraints.The extensibility is provided by automatic code generation using Python.
With this new version, an XMG compiler can be built from a combination of elementary compiler units.These elementary units are called bricks, and correspond to the set of compiling steps of a metagrammatical language.A brick can correspond to a description language (e.g. the TAG description language of the <syn>-dimension), to a subpart thereof (e.g. the feature structure language used by the <syn>-dimension), or to a solver (e.g. the tree solver used by the same dimension).Every part of the compiler is a brick, even the control language allowing one to express conjunction and disjunction, and a compiler is built by picking bricks and plugging them together.In this process, the parser for a new metagrammatical language, and all the other compiling steps, can be automatically assembled according to the way the bricks are plugged together, to generate a whole compiler for this language.The idea is that every brick holds a fragment of compiler, dedicated to a fragment of language (described by a set of context-free rules).Whilst combining these language fragments to build a full language, the compiler fragments are also contributed to a full compiler.
Hence, when extending XMG by components that are able to handle typed feature structures, we can take advantage of the compiler's modularity to add another module, dedicated to this new task.Such a module, for example a new dimension, can be equipped with a dedicated specification language and compiler.

Specification languages
The design of the specification languages that we present in the following subsections is guided by certain goals, ideas and examples.Firstly, we try to adhere to the notation in the definitions in Section 4 as closely as possible.Secondly, we try to remain consistent with the coding style that already exists in XMG, though being largely unrestricted in principle from a technical point of view.Thirdly, and most importantly, we aim at specification languages that are inherently consistent, lightweight, transparent, and at the same time flexible.In doing so, we share certain elements from specification languages proposed in other work, but, as far as we know, our combination of these elements has not been presented elsewhere.
A complete code example based on the type hierarchy from Section 2 and the factorization from Section 3 is presented in the Appendix.

Specification of the signature
For the specification of the signature, that is to say attributes, types and base labels, the global fields frame_types and frame_attributes are available: frame_types = {event,activity,motion,causation,...} frame_attributes = {actor,theme,goal,...} Base labels correspond to XMG variables and do not need to be declared globally.
6.2.2 Specification language for feature structure descriptions Feature structure descriptions are specified within the <frame>-dimension of a class, which comes with a dedicated language and compiler.The mode of operation of the compiler is detailed below in Section 6.3.1.We make use of the following description language, which is basically a simple bracket notation: 24 Unsurprisingly, type and attr stand for a type and an attribute from the signature, while var is an XMG variable.Borrowing the notation from Definition 7, attr:type is an attribute-value pair.Figure 11 then shows the description language in action, while mimicking the AVM representation of the frame.Note that the order of descriptions within a pair of brackets is generally unrestricted, as well as the number of type expressions (in order to fully support conjunctive types).
The specification language furthermore follows the definitions in Section 4 in that it allows for the abbreviated specification of paths, namely as a sequence of attributes separated by whitespaces.Hence, actor:?1, theme:?2, cause:[activity, actor:?1, theme:?2], effect:?4[mover:?2,goal:?3] ]} bol =.For example, the meaning of [actor:?1,cause actor:?1] could also be expressed with [actor=cause actor:?1]. 25he use of XMG variables not only enables one to avoid path equations, and eventually to mimic AVM representations, as we just demonstrated, but they may also serve to link semantic components with positions in the syntactic tree, as can be seen from Figure 12, where the actor role and the NP-slot of the subject are linked in this way.It shows that XMG variables may play the role of base labels in labelled feature structure descriptions (see Section 4).
Finally, it might be instructive to compare the specification language for feature structure descriptions proposed here with alternatives that are used elsewhere, particularly in grammar development tools for HPSG.The ALE/TRALE system (Götz et al. 1997;Carpenter et al. 2003), for example, is rather similar in this respect.The only major difference is found in the path specification, where attributes are separated with the colon, which happens to be also the attributevalue separator.This overloading might be disadvantageous -and in fact path equations then entail a different way of specifying paths.In LKB (Copestake 2002), on the other hand, paths are encoded with dots instead of colons, while the whitespace acts as the separator in attribute-value pairs.This being merely an alphabetical variant of our proposal, there are other differences, notably the types being placed outside the feature structure brackets.Still, these differences seem rather marginal.

6.2.3
Specification language for feature structure constraints We have seen in Section 4 that feature structure constraints can beand in practice are -specified in different ways, namely either on the basis of a set of single constraint statements, or on the basis of a connected type hierarchy.Therefore one important aspect of the specification language for feature structure constraints is its versatility.Instead of dictating what direction to follow, the grammar writer should have several options at hand from which a suitable one may be chosen on a case-by-case basis.
Concerning the specification of feature structure constraints, two options are provided: a loose set of constraint statements, or a type hierarchy.The former are collected in the global field frame_ constraints: The specification language for constraints largely integrates the specification language for (unlabelled) descriptions, while it adds -> as a symbol for generalized implication (⪯ in Definition 7).Similarly, a distinction is made between type constraints, appropriateness conditions and feature-value constraints, to which we confine ourselves in the following.An example is provided in Figure 13.Note that the antecedent and the consequent of -> may consist of more than one description separated by whitespaces, in which case the descriptions form a Cartesian product in the following way: The other option is to specify feature structure constraints in the shape of a connected type hierarchy.For this the field frame_type_ hierarchy is available and should be used in the following way: An example of this way of specifying a type hierarchy was already included in Figure 13.Similarly to frame_constraints, only unlabelled feature structure descriptions are admitted, but unlike frame_ constraints, the implication symbol -> is missing.Instead squared  3 from Kallmeyer and Osswald (2013) brackets receive a second interpretation where they correspond to types.In other words, the set of feature structure constraints enclosed by a pair of brackets constitute the type constraints and appropriateness conditions for exactly one type.If there are several type expressions, then they form a conjoined type.And if another pair of type-denoting brackets is embedded, then this is a subtype of the embedding type.This squared bracket notation is introduced in the Hierarchy part of the syntax definition of frame_type_hierarchy, and it is also the only one that is used in the example in Figure 13.Note here that frame_type_hierarchy can only express a proper subset of feature structure constraints, since constraints with feature structures in their antecedents are excluded from this representational format in general.Fortunately, constraints like these may be specified in parallel in the frame_constraints field.
Finally, there is the possibility to set a flag to trigger either the maximal or the minimal model of feature structure constraints: use hierarchy (maximal|minimal) with dims (frame) [ 213 ] At the time of writing, minimal models are compiled by default.

6.3
Compilation Within XMG2, the compilation of feature structure descriptions and constraints leads to representations which are used in the Prolog component of the system.Therefore we will be mainly concerned with Prolog data structures in the following.Note that, other than with tree descriptions in the <syn>-dimension, no underspecification is involved, and therefore the compiler for feature structure descriptions and constraints employs no constraint solving in the proper sense.

6.3.1
Compilation of feature structure descriptions Typed feature structures are decomposed into two parts during compilation: types are compiled separately from feature structures.For the latter, we can reuse the XMG module (or brick) for untyped feature structures, which is already applied to feature structures in the <syn>-dimension.The module falls back on attributed variables and association lists, which are predefined data structures in Prolog.Attributed variables behave like common variables, the only difference being that they come with encapsulated attributes that can be accessed with dedicated commands only, and for which the standard unification algorithm can be customized.They are basically used here in order to replace the standard list (or term) unification by type unification and set union.Association lists, on the other hand, consist of key-value pairs with unique keys, thereby supporting the functionality of features within feature structures.When a typed feature structure is declared, an attributed variable with two attributes is created: one attribute for the type and one for the feature-value pairs.Types are represented by bit vectors, basically Prolog lists over {0, 1}, that get unified by means of element-wise Boolean operations (see the next section).A set of feature-value pairs, on the other hand, is represented by an association list, whose values can be attributed variables again and thus induce recursion, i.e. feature structures of arbitrary depth.When two declared feature structures are unified, the compiler unifies their attributed variables in two different ways, namely with type unification on their type attribute and with set union on their association lists.
[ 214 ] The check on the well-formedness of the generated structures is performed dynamically during their creation.This includes checking the appropriateness conditions (i.e. for invalid features or specific types of feature values) and computing type unifications.Contrary to the <syn>-dimension, the <frame>-dimension does not come with a description solver.
When the descriptions in the frame dimension are compiled, a number of instantiations and unifications of attributed variables is executed.It is important to note that the unification has to be explicitly specified by means of variable equations.Hence the compilation result may consist of several unconnected feature structures, as the compiler does not search for a minimal connected model that satisfies the processed feature structure descriptions.Furthermore note that, as unification is deterministic, there is at most one model for each accumulation.

6.3.2
Compilation of feature structure constraints We are dealing with conjunctive types in the sense of Definition 8. Following a widespread approach (Aït-Kaci et al. 1989;Penn 1999;Kilbury et al. 2006;Skala et al. 2010), conjunctive types are internally represented by bit vectors (or "bit strings"), more precisely by Prolog lists over {0, 1}.The length of these lists is at least the number of elementary types in the signature.Every position in a bit vector stands for the membership of an elementary type in the conjunctive type, which means that a bit vector composed only of zeros is the most generic type (the empty set) and a bit vector composed only of ones is the conjunction of all elementary types.We will present two methods to determine the set of valid bit vectors for a set of type constraints.The first one is a brute-force method that basically applies top-down filtering.The second one is based on subsumption matrices (Aït-Kaci et al. 1989;Penn 1999) and turns out to be more efficient.In the following let T = {a, b, c, d} be the set of elementary types and # a bijective positioning function for bit vectors with # = {(a, 1), (b, 2), (c, 3), (d, 4)}.

Translate type constraints into bit vector patterns of nonvalid
3. Maximal model: Filter the set of bit vectors (representing the virtual types) based on the bit vector patterns in order to identify the valid types.Consequently, if no constraint is expressed, the set of valid types is the powerset of elementary types.
To compute the minimal model it needs an extra step: 3 ′ .Minimal model: Translate elementary types and conjunctive types (on the left side of type constraints) into bit vector patterns of declared types: Then, for each declared type, determine the set of compatible bit vectors from the maximal model and select the bit vector with the fewest 1s.If there is more than one such bit vector, compute the bitwise AND over all these bit vectors and add the resulting bit vector to the set of declared types.

Assign bit vector patterns to elementary types:
b → [ , 1, , ], … 5. Based on the set of valid bit vectors, unification of two types proceeds as list unification, after which the set of valid types is filtered with the resulting bit vector pattern.Finally the matching bit vector with the fewest 1s gets selected.
It is not hard to see that this method gets intractable for larger sets of elementary types, since the set of virtual types grows exponentially, namely with 2 n where n is the number of elementary types.Fortunately, methods based on subsumption matrices tend to be much more space-efficient, although they still come with at least quadratic growth in terms of the number of elementary types.In the following, we adapt the procedure of Aït-Kaci et al. (1989) (see also Penn 1999), and only add to it anonymous types and maximal models: 1. Generate a boolean matrix where rows and columns correspond to elementary types and anonymous types that are subject to type [ 216 ] constraints.An element a i j in the ith row and the jth column has value 1 iff t i ⪯ t j is a valid type constraint. 27Otherwise it has value 0. For example, given type constraints d ⪯ c and a ∧ b ⪯ d, the following preliminary matrix is generated: 2. Multiply the matrix by itself until a fixpoint is reached. 28This ensures that transitive subsumption relations are taken into account.When applied to the preliminary matrix above, we receive the following matrix, where c furthermore subsumes a ∧ b: 3. Each type is assigned two vectors: a subsumption vector taken from the row, and an ISA vector taken from the column (which was also used in the previous filtering approach).Hence the bit vector representation for type a consists of the subsumption vector [1, 0, 0, 0, 1] and the ISA vector [1, 0, 0, 0, 0].The difference of the minimal and maximal model emerges in the use of these vector pairs.4. Minimal model: During unification the subsumption vectors are combined with bitwise AND in order to determine the most general common subtype (Aït-Kaci et al. 1989).To give an example, the unification of the subsumption vectors assigned to a and d results in the subsumption vector of a ∧ b: Otherwise, if the resulting bit vector was not found among the bit vectors of the matrix, the unification does not necessarily fail.It only fails if the resulting bit vector only consists of 0s.
4 ′ .Maximal model: During unification, the ISA vectors are combined with bitwise OR, while the subsumption vectors are ignored.
Hence the unification of a and d yields an ISA vector not found in the matrix: In order to account for constraints on anonymous types, further unification steps can be necessary.For example, upon unifying the ISA vectors of a and b, the ISA vector of a ∧ b has to be added as well: Types that are explicitly ruled out in the type constraints are accounted for by means of extra filtering.For example, a type constraint such as a ∧ d ⪯ ⊥ would give rise to a filter based on the pattern [1, , , 1, ], which would be applied to the resulting ISA vector after unification.
For each one of the computed valid types, i.e. the assigned ISA vectors, XMG also computes the set of appropriateness conditions.Once again, this step uses the technique of vector pattern matching: when a valid type matches a pattern corresponding to a appropriateness condition, the appropriateness condition is added to the list of appropriateness conditions for this type.These lists can be used in other precompilation steps to check for cyclicity in the feature structure constraints, and for their incompatibility.
[ 218 ] Implementing semantic frames with XMG At the end of the compilation process, the bit vectors can be easily mapped back to conjunctive types and the corresponding elementary type, if it exists.

discussion and conclusion
In this article, we presented recent efforts to extend the grammar engineering framework XMG in order to deal with frame representations in the format of typed feature structures.Because metagrammatical factorization involves the composition of feature structures and types along given feature structure constraints, the full power of unification on typed feature structures is needed in XMG.We showed that the simulation of typed feature structures within the <sem>-dimension comes with severe disadvantages concerning the implementation of types and type unification.Therefore a new toolkit was developed, including a novel <frame>-dimension, which is adjusted to the peculiarities of typed feature structures and type unification, and which should eventually reduce the burden for the grammar writer.The article explained the main components of this toolkit: the specification language, for which a comprehensive code example is included in the appendix, and the compilation procedure, which uses bit vector encodings of types.
While the focus was on the theoretic foundation of the proposed extension and its proof of concept, aspects of computational complexity and the possibilities for optimization (e.g.regarding the size of bit vectors) were largely set aside.Undoubtedly, there is room for future improvements of the compiler.It has to be stressed, however, that compilation with XMG is not as time-critical as parsing, because XMG compilation is part of the preprocessing (Kallmeyer and Osswald 2013, 56).Nevertheless it would be interesting to see how compilation time scales as a function of the size and structure of the type hierarchy, and whether this is relevant given theoretically justified conceptual type systems.As no complex examples of the latter kind are known to us, this remains to be seen. 29We are aware, of course, that the issue of complexity will become more critical once these resources are used for parsing.Note that, while the presented extensions to XMG are fully operational in a recent prototype, a compatible lexical component as well as a parser have yet to be implemented.
Regardless of complexity issues, it could be useful to separate the sources and compilation procedures for global feature structure constraints on the one hand, and local feature structure descriptions within the <frame>-dimension on the other hand.The reason is that at some point the feature structure constraints should stabilize, given that they represent cognitive concepts, and therefore constant recompilation triggered by changes in other parts of the metagrammar would be superfluous.At the current stage of research, however, as the development of frame representations is still ongoing, we think that metagrammars are the right place to implement and to experiment with feature structure constraints.
Finally it remains to be stressed that the combination of the <frame>-dimension with the <syn>-dimension is by no means privileged.The <frame>-dimension can also be used to implement standalone frames, or to implement recent frame-based accounts to morphological decomposition (e.g.Zinova and Kallmeyer 2012), thereby considerably widening the scope of XMG.

appendix: complete code example
The following code example covers the implementation of the type hierarchy in Figure 3 and the factorization of the prepositional object construction in Figures 4 and 5.

Figure 4 :
Figure 4: Metagrammatical factorization of the elementary construction from Figure 2. Boxes stand for the resulting factors or classes.Double edges indicate identity constraints, dashed edges indicate non-strict dominance, ≺* is non-strict precedence, and ∨ is disjunction.
Figure 5: Metagrammatical factorization for the transitive elementary construction.

4
base-labelled typed feature structures: formal definitions Figure 6: Examples of a maximal and a minimal model of type constraint Figure 7: Example of maximal and minimal models of type constraints over conjunctive types

20
For example, say T = {a, b, c, d}, TC = {c ⪯ a ∧ b, d ⪯ a ∧ b}, then T ={{}, {a}, {b}, {a, b, c}, {a, b, d}}  satisfies TC and only contains the conjunctive types that correspond to elementary types in T .However, {a} and {b} have more than one most general common subtype in T , namely {a, b, c} and {a, b, d}.[ 201 ]

5a
brief introduction to xmg XMG (eXtensible MetaGrammar,Crabbé et al. 2013) stands both for metagrammatical descriptions and the compiler for these descriptions.Such descriptions are organized into classes that can be reused (i.e."imported" or instantiated) by other classes.Borrowing from object oriented programming, classes are encapsulated, which means that each class can handle the scopes of their variables explicitly, by declaring variables and choosing which ones to make accessible for (i.e. to "export to") other instantiating classes.The namespace of a class is Figure 8: The <syn>dimension of class Subj Figure 9: Example of the combination of classes