XMG for TAGs and IGs An Example-Based Presentation Joseph Le Roux - - PowerPoint PPT Presentation

XMG for TAGs and IGs

An Example-Based Presentation Joseph Le Roux and Yannick Parmentier June 20, 2007

Introduction

◮ Users always want new features!

Introduction

◮ Users always want new features! ◮ How to add a new type of information to XMG?

Introduction

◮ Users always want new features! ◮ How to add a new type of information to XMG? ◮ It depends on what is to be added:

Introduction

◮ Users always want new features! ◮ How to add a new type of information to XMG? ◮ It depends on what is to be added:

◮ Extending a Data Structure ◮ e.g. polarised features

Introduction

◮ Users always want new features! ◮ How to add a new type of information to XMG? ◮ It depends on what is to be added:

◮ Extending a Data Structure ◮ e.g. polarised features ◮ Extending the Solver ◮ e.g. colours and other principles

Introduction

◮ Users always want new features! ◮ How to add a new type of information to XMG? ◮ It depends on what is to be added:

◮ Extending a Data Structure ◮ e.g. polarised features ◮ Extending the Solver ◮ e.g. colours and other principles ◮ Adding a New Dimension ◮ e.g. semantics, interface

Outline

XMG Architecture Overview Core Language Example Extending a Data Structure Definition Changes in the Compiler Changes in the VM Extending the Solver Dynamic solver Example Principles Adding a Dimension Motivation Implemented Dimensions How to Add a New Dimension

Outline

XMG Architecture Overview Core Language Example Extending a Data Structure Definition Changes in the Compiler Changes in the VM Extending the Solver Dynamic solver Example Principles Adding a Dimension Motivation Implemented Dimensions How to Add a New Dimension

XMG Architecture

XMG software:

XMG Architecture

XMG software:

Compiler

in: a metagrammar (classes, DCG)

• ut: S-Code

XMG Architecture

XMG software:

Compiler

in: a metagrammar (classes, DCG)

• ut: S-Code

Virtual Machine

in: S-Code

• ut: List of multi-dimensional descriptions

XMG Architecture

XMG software:

Compiler

in: a metagrammar (classes, DCG)

• ut: S-Code

Virtual Machine

in: S-Code

• ut: List of multi-dimensional descriptions

Constraint Solver

in: α Description (1-dimension)

• ut: α List

The core language

◮ A language to combine tree fragments:

Class ::= Name → Content Content ::= Description | Name | Content ∨ Content | Content ∧ Content

The core language

◮ A language to combine tree fragments:

Class ::= Name → Content Content ::= Description | Name | Content ∨ Content | Content ∧ Content

◮ A language to describe tree fragments:

Description ::= x → y | x →+ y | x →∗ y | x ≺ y | x ≺+ y | x ≺∗ y | x[f:E] | x(p:E) | x = y

Example

SubjectCan → X [cat:s] Z ↓ [cat:n] Y [cat:v] Active → X [cat:s] Y ⋄ [cat:v] Intransitive → SubjectCan ∧ Active (∗)

Example

SubjectCan → X [cat:s] Z ↓ [cat:n] Y [cat:v] Active → X [cat:s] Y ⋄ [cat:v] Intransitive → SubjectCan ∧ Active (∗) Intransitive → X [cat:s] Z ↓ [cat:n] ⋄Y [cat:v]

Example

SubjectCan → X [cat:s] Z ↓ [cat:n] Y [cat:v] class SubjectCan declare ?X ?Y ?Z { <syn>{ node X [cat=s]; node Y [cat=v]; node Z [cat=n](mark=subst); X -> Y; X -> Z; Z >> Y } }

Outline

XMG Architecture Overview Core Language Example Extending a Data Structure Definition Changes in the Compiler Changes in the VM Extending the Solver Dynamic solver Example Principles Adding a Dimension Motivation Implemented Dimensions How to Add a New Dimension

Adding polarised features to XMG

◮ Goal: Generate Interaction Grammars ◮ Syntactic Structures: Polarised Tree Description ◮ We need polarised features:

Adding polarised features to XMG

◮ Goal: Generate Interaction Grammars ◮ Syntactic Structures: Polarised Tree Description ◮ We need polarised features:

◮ x[f:E] ⇒ x[f,pol,E] ◮ pol ∈ {=, +, −, ≈}

Changes in the Compiler

This modification consists in:

• 1. adding new syntactic constructions to the parser for

features node N[cat =+ n, funct =- X, gen = Y, num=~ Z]

Changes in the Compiler

This modification consists in:

• 1. adding new syntactic constructions to the parser for

features node N[cat =+ n, funct =- X, gen = Y, num=~ Z]

• 2. checking the AST (features vs. properties)

Changes in the Compiler

This modification consists in:

• 1. adding new syntactic constructions to the parser for

features node N[cat =+ n, funct =- X, gen = Y, num=~ Z]

• 2. checking the AST (features vs. properties)

Now, a feature is (feat, (val, pol))

Changes in the VM

Engine.unify: unify((val1,pol1),E1,(val2,pol2),E2) ⇒ unify(val1,E1,val2,E2) unify(pol1,E1,pol2,E2)

Changes in the VM

Engine.unify: unify((val1,pol1),E1,(val2,pol2),E2) ⇒ unify(val1,E1,val2,E2) unify(pol1,E1,pol2,E2)

◮ Idea: A New Class Polarity with method unify ◮ Objects manage their own unification: no need for a new

method in the engine

Changes in the VM

Engine.unify: unify((val1,pol1),E1,(val2,pol2),E2) ⇒ unify(val1,E1,val2,E2) unify(pol1,E1,pol2,E2)

◮ Idea: A New Class Polarity with method unify ◮ Objects manage their own unification: no need for a new

method in the engine

◮ New Data Structure = New Class + unify

Outline

XMG Architecture Overview Core Language Example Extending a Data Structure Definition Changes in the Compiler Changes in the VM Extending the Solver Dynamic solver Example Principles Adding a Dimension Motivation Implemented Dimensions How to Add a New Dimension

Architecture of the TAG Solver

◮ Goal: Constrain admissible structures

Architecture of the TAG Solver

◮ Goal: Constrain admissible structures ◮ Tree Descriptions → Trees

Architecture of the TAG Solver

◮ Goal: Constrain admissible structures ◮ Tree Descriptions → Trees ◮ Syntactic dimension:

◮ Tree Solver: t ◮ Additional Solvers, aka Principles: p1, . . . , pn

Architecture of the TAG Solver

◮ Goal: Constrain admissible structures ◮ Tree Descriptions → Trees ◮ Syntactic dimension:

◮ Tree Solver: t ◮ Additional Solvers, aka Principles: p1, . . . , pn

We build a solver s from t and a selection of pi

The Tree Solver

Each node in the input description is associated with an integer. initNodes for each node (x) we partition the other nodes: equal, above, below, or on its sides:

Eq Up Down Left Right Ni

x

::= node( Eq: {ints} Up: {ints} Down: {ints} Left: {ints} Right: {ints})

Tree Solver

◮ posCstr The input description is converted into relation

constraints on node sets. For instance, the dominance relation x → y can be translated as:

Ni

x→ Nj y ≡ [Ni x.EqUp ⊆ Nj y.Up ∧ Ni x.Down ⊇ Nj y.EqDown

∧ Ni

x.Left ⊆ Nj y.Left ∧ Ni x.Right ⊆ Nj y.Right]

Tree Solver

◮ posCstr The input description is converted into relation

constraints on node sets. For instance, the dominance relation x → y can be translated as:

Ni

x→ Nj y ≡ [Ni x.EqUp ⊆ Nj y.Up ∧ Ni x.Down ⊇ Nj y.EqDown

∧ Ni

x.Left ⊆ Nj y.Left ∧ Ni x.Right ⊆ Nj y.Right]

◮ Ni x.Down ⊇ Nj y.EqDown

Principles

This framework can be extended to solve specific constraints. The idea:

• 1. extension of the node representation (tuple fields),
• 2. definition of additional constraints on these fields.

Principles: Colour

Resource/Need mechanism: semi-automatic Node-merging

Principles: Colour

Resource/Need mechanism: semi-automatic Node-merging

◮ Red nodes cannot unify. ◮ Black nodes may unify with white nodes. ◮ White nodes must unify with black nodes

Principles: Colour

Resource/Need mechanism: semi-automatic Node-merging

◮ Red nodes cannot unify. ◮ Black nodes may unify with white nodes. ◮ White nodes must unify with black nodes

• 1. extension of the node representation: we add a field RB
• 2. definition of additional constraints on these fields:

x ∈ Black ⇒ RBx = x x ∈ White ⇒ RBx ∈ Black x ∈ Red ⇒ RBx = x ∧ Eqx = {x} x → y ⇒ RBx = RBy

Principle API

◮ A principle is an object with methods:

◮ args: new solver attributes ◮ init: internal initialisation ◮ initNodes: additional initialisation of the nodes (new

fields)

◮ postCstr: additional constraints

Principle API

◮ A principle is an object with methods:

◮ args: new solver attributes ◮ init: internal initialisation ◮ initNodes: additional initialisation of the nodes (new

fields)

◮ postCstr: additional constraints

◮ A solver is an object made from several principles, with the

same methods.

Principle API

◮ A principle is an object with methods:

◮ args: new solver attributes ◮ init: internal initialisation ◮ initNodes: additional initialisation of the nodes (new

fields)

◮ postCstr: additional constraints

◮ A solver is an object made from several principles, with the

same methods.

◮ DescriptionSolver: function that applies a strategy to

a solver to get solutions. (TAG or IG)

Principle API

◮ A principle is an object with methods:

◮ args: new solver attributes ◮ init: internal initialisation ◮ initNodes: additional initialisation of the nodes (new

fields)

◮ postCstr: additional constraints

◮ A solver is an object made from several principles, with the

same methods.

◮ DescriptionSolver: function that applies a strategy to

a solver to get solutions. (TAG or IG) This solution eases the developement of new principles.

Outline

XMG Architecture Overview Core Language Example Extending a Data Structure Definition Changes in the Compiler Changes in the VM Extending the Solver Dynamic solver Example Principles Adding a Dimension Motivation Implemented Dimensions How to Add a New Dimension

New dimension?

◮ New Information = New Type of Description

New dimension?

◮ New Information = New Type of Description ◮ New Information = New Dimension

Class ::= Name → Content Content ::= Dimension += Description | Name | Content ∨ Content | Content ∧ Content

New dimension?

◮ New Information = New Type of Description ◮ New Information = New Dimension

Class ::= Name → Content Content ::= Dimension += Description | Name | Content ∨ Content | Content ∧ Content

◮ Formally: DCG → EDCG

◮ each dimension has its own accumulator ◮ dimensions share variables

New dimension?

◮ New Information = New Type of Description ◮ New Information = New Dimension

Class ::= Name → Content Content ::= Dimension += Description | Name | Content ∨ Content | Content ∧ Content

◮ Formally: DCG → EDCG

◮ each dimension has its own accumulator ◮ dimensions share variables

◮ XMG: <syn>, <sem>, <dyn>

Semantic Dimension

XMG includes a semantic representation language based on Flat Semantics: Description ::= ℓ:p(E1, ..., En) | ¬ℓ:p(E1, ..., En) | Ei ≪ Ej

◮ ℓ:p(E1, ..., En):

◮ predicate p ◮ parameters E1, .., En ◮ label ℓ (and negation ¬)

◮ Ei ≪ Ej: scope

Interface

◮ 2 Goals:

◮ Lexicon interface (anchoring, hypertags) ◮ Syntax / Semantic Interface

Interface

◮ 2 Goals:

◮ Lexicon interface (anchoring, hypertags) ◮ Syntax / Semantic Interface

◮ Only 1 Data Structure: AVM

Interface

◮ 2 Goals:

◮ Lexicon interface (anchoring, hypertags) ◮ Syntax / Semantic Interface

◮ Only 1 Data Structure: AVM ◮ For historical reasons, interfaces are appended to the

syntax dimension

Hypertags

Example: class ProperNoun declare ?Gen ?Num ?Fun { <syn> { node [cat =+ np, funct =- Fun, gen = Gen, num = Num, pers = @{2,3}] } } Result: cat -> np funct <- ? gen = <1>? num = <2>? pers = 2 | 3

Hypertags

Example: class ProperNoun declare ?Gen ?Num ?Fun { <syn> { node [cat =+ np, funct =- Fun, gen = Gen, num = Num, pers = @{2,3}] }=*[head=[cat = np, gen = Gen, num = Num]] } Result: cat -> np funct <- ? gen = <1>? num = <2>? pers = 2 | 3 head = cat = np gen = <1>? num = <2>?

Syntax / Semantic

◮ Example: Intransitive: Subject: Active: 1-ary relation: S NP↓[idx=X] VP l0:Rel(X) [arg0=X] [subjIdx=X]

⇐

S NP↓[idx=I] VP [subjIdx=I]

∧

S VP ∧ l0:Rel(A) [arg0=A] ◮ Variables are shared across dimensions. ◮ More on this later (Claire)

Adding a new Dimension

◮ XMG: It’s hard!

◮ Modify the parser:

<dim>{...}

◮ Modify the Engine (tweak the dreadful Engine.oz) ◮ Add a New Solver (or not)

Adding a new Dimension

◮ XMG: It’s hard!

◮ Modify the parser:

<dim>{...}

◮ Modify the Engine (tweak the dreadful Engine.oz) ◮ Add a New Solver (or not)

◮ XMG2: It will be easy!

Conclusion

◮ More and more linguistic information

Conclusion

◮ More and more linguistic information ◮ XMG manage different types of information

Conclusion

◮ More and more linguistic information ◮ XMG manage different types of information ◮ Extensibility partially achieved (new DS, principles)

Conclusion

◮ More and more linguistic information ◮ XMG manage different types of information ◮ Extensibility partially achieved (new DS, principles) ◮ Problem: New Dimension

Conclusion

◮ More and more linguistic information ◮ XMG manage different types of information ◮ Extensibility partially achieved (new DS, principles) ◮ Problem: New Dimension

Moral of the story: Extensibility is a key point for grammar developement system.