Text planning for Technical Orders

In Sec. , we discussed three different approaches to text planning: those based on schemata [McK85,LP95]; those based on planning by means of plan operators [Hov88,MP93,WAB91]; and those that don't plan for the global structure of the text, but generate text incrementally by means of local strategies [Sib92].

We already mentioned in Sec. that a local approach such as Sibun's doesn't seem appropriate for technical orders: her approach seems to be most effective when the structure of the text is not deeply nested, namely, when there are many equivalent objects to be described at the same level of embedding. However, technical orders are both more deeply embedded, and more rigid in structure, as we will show in Sec. : in particular, the choices that arise concern the macro structure of the text, rather than specific objects to be included.

It is our opinion that a schema based text planner is more appropriate for NL generation from PaT-Nets than a full fledged plan based text planner, for the following reasons.

• First, the text to be produced is not free instructional text, but it is in the form of technical orders. Technical orders have a somewhat predefined, rigid structure, discussed in Sec. , that lends itself to be encoded as discourse schemata. In fact, some of the knowledge about the high level structure of technical orders is akin to discourse communication knowledge a lá [KKR91] --- see Sec. .
• Second, NL generation from PaT-Nets is not performed within an interactive application, but rather, within a (possibly semi-) automatic support system for technical order writers; thus, issues for which the intentional structure of discourse is crucial, such as replanning to answer follow up questions, are not as relevant as in e.g. an interface to an expert system that has to explain how it reached certain conclusions.
• Third, building a new plan-based text planner requires more effort than building a schema-based one; planners such as the one in [MP93] are available, but its authors themselves criticize it as not being principled enough.
• Fourth, PaT-Nets provide a well specified and constrained domain representation, that can be seen as providing a skeleton of a text plan in itself. For modularity, it is not advisable to generate directly from PaT-Nets, but rather, it is better to interpose a level such as that of discourse schemata or plan operators between the text planner and the domain representation; however, schemata may be sufficient for this application.
• Finally, NL generation from PaT-Nets seems to require careful consideration of the two following issues, rather than of text planning in itself:
  • the level of detail at which instructions have to be generated, which includes decisions e.g. about whether to describe specific arcs and subnetworks;
  • sentence planning, both at the level of sentence structure, and at the level of lexical choice. In fact, while the global structure of technical orders is somewhat rigid, as we will show in Sec. , the structure of the sentence seems to afford more flexibility. For example, in the F16 instructions, we find the well-known alternation of purpose and means clauses. An example of purpose clause is the infinitival clause in italic:

    To disconnect hydraulic test stand from system A, perform steps 12 through 15. For system B, perform steps 16 through 18.

    An example of means clause is the following by + -ing construction (in italic):

    All personnel engaged in refueling shall discharge electricity from their persons by touching a static ground cable or grounded object before each operation.

    These two constructions can often be used interchangeably in instructions; the previous example could be rephrased as follows, by transforming the main clause in a purpose clause (in italic), and the means clause in the new main clause:

    To discharge electricity from their persons, all personnel engaged in refueling shall touch a static ground cable or grounded object before each operation.

    However, while the two clauses are semantically interchangeable, one form is often preferred to the other because of other constraints on their usage that depend on the surface organization of text, as discussed in [VM95]. Studying these kinds of constraints affecting surface structure appears to be more pertinent to generating technical orders than a detailed study of text planning strategies.

• High level structure of technical orders
  • Input conditions.
  • Subprocedures.
  • Follow on maintenance.
  • Stylistic features.
• Domain communication knowledge
  • DCK in Technical Orders.