The NP Specification Interface

The interface between the text-planner and the NP-planner is in the form of an attribute-value matrix, the attributes of which are:

1. Cat: the function of the NP being produced. The NP-planner allows a wide range of NP functions, not only referring, shown in figure 2 and discussed below:
   1. Referring: an NP which uniquely or non-uniquely refers to the referent. More delicate options can be specified, such as refer-by-name, refer-by-type, or refer-by-pronoun; and also whether the reference should be unique or not.
   2. Describing: an indefinite NP giving an arbitrary number of the entity's attributes without attempting to be definitive.
   3. Classifying: an indefinite NP which provides only the superclass of the item, e.g., this is a brooch
   4. Defining: for generic entities, an NP which provides the entities defining characteristics, e.g., a necklace is an item of jewellery worn around the neck
   5. Eliciting: a wh- NP for the referent. Eliciting can be selective, e.g., which designer or non-selective, e.g., Who.

    
    
   
   Figure: System Network for Nominal Function
   

   If referring-np is selected, various sub-types of reference can also be preselected through this slot (the specification of the Cat can be logically complex).

   If no preselection is made by the text-planner, the system will decide NP function on the basis of constraints and defaults. For instance, in the usual case, the text-planner will specify only referring-np, and leaves it up to the NP planner to choose the exact type of reference.

   In some cases, the system will override the preselection if it is incompatible with the referring environment. For instance, if the text-planner specifies refer-by-name, but no name information is provided for the entity, then a choice between refer-by-type and refer-by-pronoun will be made. The NP-specification can thus be seen to offer a flexible interface, allowing the text-planner to determine the amount of control it desires to assert.

2. Sem: the referent of the NP, an entity in the information graph (or a set of such entities if desired, realised as either a coordinated NP, or using plural anaphora).
3. Syn: the slot to be constructed by the NP-planner, a syntactic structure.
4. Orth: the slot to hold the eventual surface string for the NP. If the sentence planner provides a filler for this slot, then NP-planning is avoided and the string is used. ILEX thus allows canning of NPs when needed.
5. Agenda: a list of fact-ids which are to be incorporated into the NP if possible. The aggregation module uses this slot to state its requirements from the NP, which facts the NP is to express.
6. Restrictions: a list of fact-ids which should not be used in the NP. For instance, we might wish to avoid generating the sentence Other jewels designed by Jessie M. King include a brooch designed by Jessie M. King. To avoid such sentences, we place the fact-id of the `designer' fact into the Restrictions field for the mention of the brooch. The designer fact will not then be used as a referential restrictor.

A sample NP-specification is shown below:

...where FN-48 and FN-56 are facts to include in the reference, and FN-59 is a fact to avoid.

Problems of Modularity: One of the problems of a clean separation between NP-specification and NP-planning is that it might not be possible to incorporate all facts on the informing agenda into the NP. However, given that NPs syntactically allow any number of non-referring post-modifiers, our planner will handle any arbitrary number of facts on the agenda. However, in terms of intelligibility, too many post-modifiers will produce unintelligible NPs. We make the simplifying assumption that the text planner uses some metrics (simple or complex) to avoid overloading the NP. We are merely providing a mechanism to support NP-planning once the agenda is specified.