Relevant Canonical Genre Families

Introduction

There are some apparent substantive similarities between the concept of canonical genres in SFL and work that has been undertaken in the realms of Artificial Intelligence (AI) and Software Engineering. Although theoretically unrelated to these, genres considered here have similarities to some of the approaches developed in AI that seek to address questions of the representation of meaningful situations in discourse. For example, the concept of a frame was developed by Minsky (1975) as a way of representing in the form of a data structure, knowledge about a stereotypical situation as well as including expectations and presumptions about the situation. An alternative representation of knowledge is in the form of scripts and plans, developed by Schank and Abelson (1977). Like these AI concepts, canonical genres can also be used to represent knowledge but perhaps a closer analogy is the notion of a pattern.

The use of the concept of a pattern is now widespread, but its origins in “technical” analysis and design applications dates to the work of Christopher Alexander, Emeritus Professor in Architecture at University of California, Berkeley, and his colleagues, at the Centre for Environmental Structure. They developed an entirely new approach to architecture, building and planning based on two big ideas (Alexander, Ishikawa & Silverstein, 1977). The first “big idea” is that people always rely on certain “languages” that allow them to articulate and communicate an infinite variety of designs within a formal system that gives them coherence. In effect, Alexander et al (1977) proposed that the built environment could form a kind of language, the parts of which could be reused in many ways. This language would then enable people to build any kind of building or any aspect of the built environment. While they did not use any theory of communication as a foundation for this “language”, nonetheless their work foregrounds the significance of communication to discipline.

The second “big idea” is that the standard units of this architectural language are patterns. Specifically, patterns are reusable (that is, generic) answers to architectural design problems. Their book offers 250 such patterns, including answers to questions like the optimum height of a window or the amount of space a neighbourhood should have reserved for green spaces. In what was, no doubt, a practical solution to a vexing problem of describing these patterns, but actually became a defined aspect of this work, each pattern was described in the same way, employing a problem statement, a discussion of the problem, with an example, and a solution. The importance of this approach for architecture is that it was a systematic way of approaching design activities. Significantly, patterns could be corrected until they became as general as possible and reused within the architectural domain in many different ways.

In one of the most recent and interesting cross-fertilizations between technical disciplines, software engineers adopted these ideas about patterns and pattern languages from the pattern movement in architecture. Despite the fact that software engineering produces advanced technologies, much of the effort is still at the level of hand coding. As with most arts, it is very difficult to explain how to make good software. Most good programmers have a deep knowledge of what they are doing but find it extremely difficult to describe and, therefore, transfer that knowledge.