The Standard Relational Model (SRM) is presented in diagram form in Figure 2. As with the first data model, the SRM begins with the four basic tables: the entities (NAME, EVENT, INTVN) and the descriptor table VOCAB).

The SRM differs from the abstract fields and SQL models principally in its handling of the LINK structure. Optimally, all the data in the LINK structure should be in a single table so that all the links from any chosen BASIC entity are immediately viewable -- that is, the user can view all the different ROLEs this entity plays in all the different RULE-INSTANCEs to which it connects. In the SRM, the user can see all the links from any given BASIC entity, but only one RULE-TYPE at a time. That is, the user can view the links from a BASIC entity to other entities of the Act RULE-TYPE, or of the Biography or Relation RULE-TYPE, but only one at a time. This limitation arises because the RULE-INSTANCES of different types are in different tables. INSTANCES of RULES of the ACT RULE-TYPE, for example, are in the ACT table, whereas INSTANCES of the BIO RULE-TYPE are in the BIO table.

This model maps the RULE-STRUCTUREs directly onto three tables, one table each for act, biography, and relationship. The structure of each RULE-TYPE is reflected exactly in the field structure of each table. Because the fields are fixed in this model, each RULE-INSTANCE can accept only one value for each of the ROLEs specified.

For example, in a given act-of-violence rule-instance, there can be only one victim, one violent act, one perpetrator, and one event per rule-instance. If the narrative of the event includes acts-of-violence in which there is, for example, more than one victim, the user must create one rule-instance for each victim. The same is true if there is more than one violent act, more than one perpetrator, etc. This is not a limitation of more sophisticated models.

Note that in the SRM, each RULE-INSTANCE is represented by exactly one record. Further, each ROLE is represented by a FIELD. This is intuitively appealing, and for simpler implementations the SRM can be entirely adequate.

The SRM has several advantages. All implementations of this standard have to maintain a considerable amount of "meta-data," that is, definitions of data separate from the actual table structures. The SRM minimizes meta-data. The RULE-STRUCTURES, at least, are already encoded in the table structures. There are still aspects that need to be defined for each rule: which VOCAB categories fit in which roles, and which entities belong in which roles, still must be defined in program code.

Any implementation of the SRM will require a great deal of tricky user interface programming to assist the user's data entry. All of these models force the user to enter a lot of data -- any tools that we can provide to make his or her job easier will be very useful.