Models and outlines

By far most of the work involved in reconfiguration focuses on the class descriptions in the models file. It is important to understand the basic structure of a model before attending to the details of its structure. A model is a metaphor for a very complex data storage and retrieval system. Its advantage is that it conceals the underlying complexity of data structures and represents them in a symbolic form that is relatively easy to discuss and modify.

The gross anatomy of the models file is fairly simple. The file consists of a series of class definitions in no particular order. Each class definition is separated from the next by one or more blank lines (blank lines cannot occur within a class definition). A typical models file may contain descriptions for 20 or so classes. Comments, preceded by the special symbol "//", may be scattered thoughout. The comments are there to make the file easier for humans to read. Anything on a line to the right of // is ignored by the software, whether the // is at the very beginning of the line or somewhere in the middle. You should add comments to your own models file as you modify it so you can remember why you did what you did.

Just to give you a feeling for the appearance, here is the definition for a YAC class. It is not immediately important how its components function; we will explain that in detail later.

      //last revised 5 January 1994

?YAC  Location Position  UNIQUE Map ?Map XREF YAC #map_location
      Contains Locus ?Locus XREF Inside_YAC
      Inside Inside_Fragment ?Fragment XREF YAC
      Size UNIQUE Int Int // length in kb , range in kb
      Status UNIQUE Chimeric
                    Non_Chimeric
                    //maybe add other categories?

Each class definition begins with the name of the class, preceded by a "?" character, in the extreme left column of the file. Thereafter lines are indented rightward (with multiple levels of indentation possible). The model functions as an outline in which the indentations represent sections and subsections. This turns out to be a very efficient way to organize information with different levels of detail. Not surprisingly it works quite well with biological data.

An outline provides a scaffolding to which data is attached. A model is a metaphor for an outline and provides the same functionality. Here is a fanciful outline and its corresponding model:

Loan Application       | ?Loan Name Text
 I.  Name              |       Assets Savings Retirement Float
 II. Assets            |                      Non_Ret Float
     A. Savings        |              Property Residence Assessed Float
        1. retirement  |                                 Date Text
        2. non-ret.    |                       Rental
     B. Property       | etc., etc., etc...
        1. residence   | 
           a. assessed | 
           b. date     | 
        2. rental      | 
etc., etc., etc...     |

Some of the lines in a "real" models file are quite long. When you examine models in an editor that imposes margins, set the margins wide, to 10 inches or more so that the program doesn't wrap a line just because it is too long. It can also help to stretch the window horizontally or select a smaller font. You want to break a line only when it has a "return" character at its end. In addition choose a monospaced font (e.g. Courier) so that indentation is represented faithfully.

Back to Table of Contents