This aims to support users who want to do lexical selection directly from an input other than GenI style flat semantics.

The requirement here is for you to provide some means of converting the custom semantics to a GenI semantics

See Configuration if you want to use GenI with a custom lexical selection function.

The result of the lexical selection process

Performs standard GenI lexical selection as described in http://projects.haskell.org/GenI/manual/lexical-selection.html

This is just defaultLexicalSelection lifted into IO

Helper for defaultLexicalSelector (Standard GenI lexical selection is actually pure)

This is just

• defaultLexicalChoice
• defaultAnchoring
• defaultPostProcessing

missingLexEntries ts lexs returns any of the lexical candidates lexs that were apparently not anchored succesfully.

TODO: it does this by (wrongly) checking for each lexical item to see if any of the anchored trees in ts have identical semantics to that lexical item. The better way to do this would be to throw a subsumption check on top of items reported missing, because it's possible for the trees to add semantics through unification.

Select and returns the set of entries from the lexicon whose semantics subsumes the input semantics.

chooseCandI sem l attempts to unify the semantics of l with sem If this succeeds, we use return the result(s); if it fails, we reject l as a lexical selection candidate.

mergeSynonyms is a factorisation technique that uses atomic disjunction to merge all synonyms into a single lexical entry. Two lexical entries are considered synonyms if their semantics match and they point to the same tree families.

FIXME: 2006-10-11 - note that this is no longer being used, because it breaks the case where two lexical entries differ only by their use of path equations. Perhaps it's worthwhile just to add a check that the path equations match exactly.

The LexCombine monad supports warnings during lexical selection and also failure via Maybe

Note an anchoring error

defaultAnchoring schemata lex sem implements the later half of lexical selection (tree anchoring and enrichement). It assumes that lex consists just of the lexical items that have been selected, and tries to combine them with the tree schemata.

This function may be useful if you are implementing your own lexical selection functions, and you want GenI to take over after you've given it a [LexEntry]

Given a lexical item, looks up the tree families for that item, and anchor the item to the trees.

Combine a single tree with its lexical item to form a bonafide TagElem. This process can fail, however, because of filtering or enrichement

See http://projects.haskell.org/manual/lexical-selection on enrichement

Helper for enrich (enrich by single path equation)

Helper for enrichBy

enrichFeat av fs attempts to unify av with fs

Note here that fs is an Flist [GeniVal] rather than the usual Flist GeniVal you may expect. This is because it comes from SchemaTree which allows non-atomic disjunctions of GeniVal which have to be flatten down to at most atomic disjunctions once lexical selection is complete.

missingCoanchors l t returns the list of coanchor node names from l that were not found in t

Split a lex entry's path equations into interface enrichement equations or (co-)anchor modifiers

seekCoanchor lhs t returns Just node if t contains exactly one node that can be identified by lhs, Nothing if it contains none.

It crashes if there is more than one such node, because this should have been caught earlier by GenI.

matchNodeName lhs n is True if the lhs refers to the node n

matchNodeNameHelper recognises “anchor“ by convention; otherwise, it does a name match

The lemanchor mechanism is described in http://projects.haskell.org/manual/lexical-selection

The name of the lemanchor attribute (by convention; see source)

setOrigin n t marks the nodes in t as having come from a tree named n

Standard post-processing/filtering steps that can take place after lexical selection. Right now, this only consists of paraphrase selection

Rule out lexical selection results that violate trace constraints

True if the tree fulfills the supplied trace constraints