<?xml version="1.0" standalone="yes"?>
<Paper uid="W98-0211">
  <Title>How to build a (quite general) linguistic</Title>
  <Section position="4" start_page="0" end_page="76" type="intro">
    <SectionTitle>
2 Motivation
</SectionTitle>
    <Paragraph position="0"> Within linguistics and computational linguistics, diagrams play a crucial role in representing the content of theories (the use of trees to define inclusion hierarchies, for example), in standing as informal demonstrations of the truth of particular claims and, therefore, in sharing ideas with the community as a whole. Popular graphical devices include trees, attribute-value matrices (AVMs), e.g. (Pollard and Sag, 1994), and conventions such as those used in Discourse Representation Theory (DRT) (Kamp and Reyle, 1993). It has been clear for a number of years that the linguistic community would benefit from a general purpose &amp;quot;diagram editor&amp;quot; allowing users to construct and manipulate diagrams. A large range of uses exists for such a program, including the debugging of existing grammars, the construction and delivery of teaching and drilling materials and the production of diagrams for publication in some media or other. Even more generally, such a system offers a way of defining and interacting with documents with complex structure.</Paragraph>
    <Paragraph position="1"> Why hasn't the community produced such an obviously desirable program? First, change has been a characteristic of the technical devices used in many branches of linguistics. Further, it seems in principle impossible to predict which graphical conventions are likely to gain currency in linguistic discourse and publications. Moreover, if diagrams can vary in unpredictable ways, there might seem to be no hope of providing a uniform interface for the user. A consequence of these factors is that the implementation and maintenance costs of such a program appear unacceptably high, perhaps unquantifiably so.</Paragraph>
    <Paragraph position="2"> There seem to be two responses to this situation.</Paragraph>
    <Paragraph position="3"> One response, as seen in the tree editors described by (Paroubek et al, 1992) and by (Calder, 1993) and in the feature structure editor designed by (Kieffer and Fettig, 1995), is to fix a relatively small amount of graphical devices and restrict the operations defined over, and potential combinations of, those devices (perhaps to the extent that only operations which don't violate consistency with respect to a particular grammar are allowed).</Paragraph>
    <Paragraph position="4"> An alternative response is to aim for the generality of the kind seen in the general field of diagram editing and visual programming, of which (Viehstaedt and Minas, 1995), other papers from that source, and (Myers et al, 1990) are good examples. And, of course, constructing diagrams by hand in a generic drawing package represents a common, but in extremis measure. There are several reasons why, for our purposes, generality is a disadvantage.</Paragraph>
    <Paragraph position="5"> First, generality in this context typically goes along with complexity in the mathematical objects  to be depicted, often requiring the use of sophisticated layout algorithms, cf. (Battista et al, 1994). Second, there is a corresponding complexity in the specification of diagrams. That complexity may require arbitrary computation to be performed and therefore demand the power of an unrestricted programming language to describe that computation.</Paragraph>
    <Paragraph position="6"> Finally, it seems to be an assumption of such approaches that the well-formedness of a diagram should equate with the consistency of the interpretation of that diagram in the domain represented by the diagram. See (Serrano, 1997) for a clear statement of this position. This is much too strong a requirement in the cases of interest to us: one may wish to construct an inconsistent AVM, for example, precisely to verify that some other processor correctly detects the inconsistency. One may also wish to construct diagrams in formalisms which are undecidable, for example formulae in first or higher order logics. In that situation, it cannot make sense to ask an editor to enforce consistency. In the end, in an appropriately general system, it should be possible to decide on a case-by-case basis whether consistency with respect to the domain in question should be enforced.</Paragraph>
    <Paragraph position="7"> We discuss in the next section how the design we present here obviates these problems, and allows the inexpensive and portable implementation of an appropriately general editor.</Paragraph>
  </Section>
class="xml-element"></Paper>