elhadad1997fcl continued

more notes on elhadad1997fcl

so what does a lexical chooser do?

The first question is what a lexical chooser should take as input. Given the notes from before, the obvious no-duh answer would be "well, the output of the content planner"... which would be "structures from the application domain selected during content planning, possibly augmented with discourse relations". You also want stuff about discourse and speaker intent, but that can all come from the planner.

Ok, so what does it output. Again the no-duh answer, "the input to the syntactic realiser" (golf clap), and this would be something more like... oops. They don't say explictly. I guess it means "go pick up a SURGE [or your favourite syntactic realiser] manual". Point is that the lexical chooser picks one paraphrase based on the input, and feeds that to your realiser.

I feel a bit uncertain about this, but I'll suppose that this does not neccesarily preclude minor syntactic variations. The lexical chooser would choose between

• The 6 AI assignments require programming
• AI has 6 assignments which involve programming

Since choice basically is "realise this relation with the verb 'require', and that one with the noun 'assignments'"; but not really any of the closed-class words (the function words), and no word on how they're supposed to be combined. It would be syntactic realiser which would then select between

• The 6 AI assignements require programming
• Programming is required by the 6 AI assignements

I think the SURGE manual says this anyway. Naturally, this decision can be made with the help of input passed through from the lexical chooser.

Anyhoo...

The 3rd piece of the puzzle is how we get from input to output. Really, what does a lexical chooser do? There are two tasks to perform, associated with decisions to make

• phrase planning (syntagmatic decisions) - from conceptual net to tree of thematic roles
• lexicalisation proper - (paradigmatic decisions) for each piece of the thematic role tree, choosing among the alternate lexicalisations for that role. The tricky part to this is that you can't make these choices independently of each other; one choice engender constraints on other choices, constraints back-propagate, all that nasty business.

The paper describes this as a two phase process, each with floating constraints. I wonder if there are cases where phase 2 constraints can force you backtrack up to phase 1 and start over, though... or if I'm just not understanding this right.

phrase planning

Skimming over this. Sorry, not what we're working on right now. Would be nice for general culture though.

merged realisations

I'm not worrying too much about merged realisations either. Again, good for general culture, but for the moment, not my problem. Something I can imagine is shunted off to "some other system" in the sky (like, this system).

cross-ranking realisations

This might be more interesting. The question is how do you map thematic structure onto syntactic structure, especially when some things can be mapped on different ranks. Same thing can be expressed as a verb, adjective, conjunction, etc [the word "but" can mean so much...]. This was a bit tricky for me to read because I didn't really know what an argumentative evaluation was, just treat it as some constraint you have to meet.

I was quite confused by the notion of expressing constraints in a unification-based formalism. I can understand that you get unification failures from two different ground values, but how do you express something like "this feature must be expressed"? From reading, I get the impression that it's because FUF has special mechanisms, noted by two keywords. One keyword is GIVEN, which basically means "this feature is expressed". If you look at Figure 16 on page 221, you can see two values for {process ao}: GIVEN and some other feature structure. So, that keyword is not a value per se, it's just some extra annotation you add into the feature. Another such keyword, by the way, is ANY, which tells FUF that you want to postpone unification on that feature until the very end. I guess not understanding that there were these extra mechanisms that tripped me up.

The feeling I get is this: you've got a constraint that you're trying to apply somewhere whilst doing your lexicalisation. Lexicalisation is top-down breadth first: for the current node, pick a word/category, instantiate, now flesh out your thematic kids. If I understand correctly, you also have these constraints that you're trying to express SOMEWHERE (they're cross rank), and in order to do that, you need to make provisions for the current constraints not to be realised at this level, but somewhere down the road. Why this sucks is that you could be happily doing your lexicalisation search, drilling all the way down to bottom, procrastinating like hell on one constraint or the other, until you realise at the very end... whoops. Can't meet that constraint. One of my previous lexicalisations was bad because it ultimately does not allow me to fulfill all my constraints.

So, backtracking is a problem.

One thing I'm shaky on is this distinction they seem to make between deterministic decisions and non-deterministic ones. How can you just "map to the first slot found in the constituent tree that can account for it?" Aren't just inherently searching anyway?

Anway, backtracking is a problem; got a big search problem on your hands. To reduce backtracking, they introduce a mechanism which smells a bit like a cut (only the opposite; it's not 'stop backtracking beyond this point' but 'leap up to this point'). The idea is the grammar writer can annonate alternations as being able to affect one constraint or another. Whenever we hit the problem that oops, that constraint wasn't realised, we aren't going to dick around backtracking all around our search tree. We look at the missing constraint, and then we jump up to the choice point that our grammar writer said was important. Something like that, right? Cut but inside-out.

where this all fits in

I guess that was a false alarm. Hard to articulate my worry really; just a sudden feeling of panic, a feeling that I suddenly didn't know how all the pieces fit together. My dividing of the world into surface realisation (what I'm doing), and everything else (what other modules are doing before they talk to me) felt supremely inadequate, or somehow that once all the important lexical choice decisions were made; eh... all this polarity business, not so interesting. It's mostly a matter of trying to see where all the pieces fit in, what my job is, so to speak.

elhadad1999scp

Flipping back to the syntactic realiser, just trying to figure out how it uses its input. Looked through the tables in the appendix and tried to mentally extract some value out of them. Table 1 and 2 maps you from process to list o participants. Table 3 goes from mood to (dunno) realisation stuff. Three kinds of input you can provide:

• ideational - via process, participants or lex-roles (if no lex-roles, the system looks up participants on the basis of process?)
• interpersonal - via the mood feature
• textual - via the focus feature

Is that the idea? If you want to run throug these systems, you specify values for these features? And then the rest happens by magic... uh... unification, I mean?

elhadad1997fcl

Slowly making my way through a re-read of elhadad1997fcl, mostly so our discussion tomorrow can be semi-productive, and also because I want to have a good idea how GenI's lexical selection process differs from other systems and/or what kind of input I can expect us to have.

Am getting increasing self-conscious about our inability to handle recursive feature structures with reentrancy. I guess you could say we've got reentrancy, but no recursion, but then that doesn't get very hard. Problem is that it makes it a bit tricky to just pop from one system to another. I wish somebody would write an FS library for Haskell. Maybe me, one day, when I decide I have the time to (1) learn how to do it (2) code the sucker up (3) test it (purrrfect for QuickCheck). It would be a nice library, useful for anybody who wants to do NLP.

But the reading is going slow. It doesn't help that I'm coming in to work so late (lunchtime) and leaving so early (dinnertime), but I haven't flipped into discipline mode. Sleep bi-polar. Either I'm being really good and doing 22h00/05h45; or I'm sort of straggling off to bed around 03h00 and getting in after noon. The other problem is that reading can be boring. Well, not so much that; it just requires you to Purposely Concentrate, you know flip a switch and Bing! you're concentrating. And that was never something I was good at. It's hard to resist the temptation to just wander off and go check or mail, or see how the Haskell wikibook is doing, or just do anything other than sit down and concentrate. What a pity, because in the medium term, reading is extremely rewarding, you know that great feeling you get when you actually understand something and see how it fits in with all the other stuff? Yeah, I'm not even talking about reading being good for you (faut se nourrir scientifiquement); just in terms of sheer pleasure, reading can be loads of fun... but only in the medium/long term. You have to fight yourself over the short-term i'd-rather-be-doing-something-else hump.

the notes

Lexical choice is all about associating concepts to words. Not an easy job. First of all, you're dealing with a many-to-many situation; one concept could map to several words and vice versa. Choice is also subject to constraints from many sources: syntax, semantics, the lexicon [e.g. collocations], the domain [words have different meanings in different fields], pragmatics. Having a pipeline architecture for your lexical chooser isn't a a very good idea either, because the constrains are multi-directional. Syntactic constraints could affect semantic ones, etc. Another thing which makes this job tricky is that some constraints can float - appear at different levels in linguistic structure. Note that generation algorithms only handle the easier "structural" constraints, which are consistently expressed on a given linguistic rank.

where do you do lexical choice?

The article argues that lexical choice should be an independent module between content specification and syntactic realisation. Those of us working with reversible grammar generators tend to do it as sort of "by-product" of realisation. So the SFG people (although they handle their semantic constraints during content specification; e.g. their realiser input already has the semantic stuff figured out -- but wait don't we as well?). Arguments why this is not the best way to do things are

1. limited range of possible constraints -- they doubt that pragmatic constraints can be taken into account for example
2. hard or impossible to deal with floating constraints (need "global knowledge of interaction between semantic units").

There's also a paragraph after this that shows why just doing it as part of content planning is a bad idea (combinatorially expensive? need to read more carefully).

so what does a lexical chooser do?

Eh... we're supposed to go have drinks or something. Guess I'll have to pick this up tomorrow.