Discussion in this section will draw heavily from theory presented more fully in Ball (1993).
This implementation has two principal objectives: first, to implement all the different RULE-TYPEs in a single table, and second, to allow the user to view simultaneously all the RULE-INSTANCEs in which a given BASIC entity is involved. Secondary benefits include the ability to include multiple BASIC links in each ROLE. Considering the example above, in which an instance of the act-of-violence rule had more than one perpetrator. In this situation, multiple perpetrators can be attached to the
Consider the following data from the data rendering examples.
| ACT | ||||||
|---|---|---|---|---|---|---|
| rule | subject | action | object | event | loc. | date |
| a. | 60 | 05.211 | V0050290 | E005029 | 26.1 | 19891201 |
| RELATION | |||||
|---|---|---|---|---|---|
| rule | party | party | quality | date | notes |
| a | P1 | P2 | married | 19620000 | |
| BIOGRAPHY | |||||||
|---|---|---|---|---|---|---|---|
| Rule | person | status | situation | level | date | date | notes |
| e | P5 | mil.ac | student | grad | 19610000 | ||
in the abstract fields model, the information above would be represented in two related tables, LINK and DIARY. The information in the LINK structure would appear as follows:
| LINK | |||
|---|---|---|---|
| diary_id | role | data_id | table_ptr |
| 001 | sub | 60 | name |
| 001 | action | 05.211 | vocab |
| 001 | obj | V0050290 | name |
| 001 | event | E005029 | event |
| 001 | loc | 26.1 | vocab |
| 001 | date | 19891201 | date |
| 002 | fparty | P1 | name |
| 002 | sparty | P2 | name |
| 002 | quality | married | vocab |
| 002 | date | 19620000 | date |
| 003 | person | P5 | name |
| 003 | status | mil.ac | vocab |
| 003 | sit'n | student | vocab |
| 003 | level | grad | vocab |
| 003 | date | 19610000 | date |
LINK need not be human readable because what a person needs to make sense of in a rule-instance is the entire rule-instance -- not a single role in the instance. A human-readable summary of the instance is contained in Diary.title_info. By storing the LINK as compressed binary key information, the LINK record can be reduced to about 12 bytes. The size of the LINK record is important because there will be very many of them. In the diary table, the following would appear:
| DIARY | |||
|---|---|---|---|
| diary_id | rule_type | title_info | notes |
| 001 | act-of-violence | victim severely beaten | |
| 002 | relation-family | P1 and P2 marry | |
| 003 | bio-education | P5 graduates from the military academy | |
As in LINK, the diary_id and rule_type fields can be stored in internal binary forms. Each RULE-INSTANCE in the abstract model is represented by one DIARY record and an indefinite number of records in LINK. All the LINK records that pertain to a single RULE-INSTANCE are related to the master record for the rule instance in DIARY by common key values in diary_id. All the BASIC entity key information is contained in a single field, LINK.data_id. DIARY.title_info contains a human readable form of the information stored in the collection of records in LINK that are associated with this DIARY record.
Given this structure, it is easy to browse all the links associated with a given BASIC entity record in xBase. The following code is from FoxPro, but the logic would be similar in compatible DBMS'. Assuming that we are in the work area of the entity we want to view, and the record pointer is positioned at the record we want (NB: '&&' indicates a comment in Fox):
select DIARY set order to diary_id select LINK set order to data_id set relation LINK.diary_id into DIARY && LINK --m:1--> DIARY select <BASIC entity> set relation <BASIC>.data_id into LINK && BASIC --1:m--> LINK select DIARY browse fields DIARY.title_info && BASIC -- 1:m --> DIARY
Any given BASIC record yields m Diary records. The Diary browse shows only those records associated by some link to the record in the BASIC entity we're analyzing. This can be a very powerful analytical tool, and runs quickly even with very large data files.
The most difficult part of managing an implementation of this model is the meta-data. In other words, how should the system manage the RULE definitions? The most obvious solution is to store rule definitions in program code. There are a variety of possibilities which afford greater flexibility, for example, the solution presented below, in Section 9.3. See Ball (1993) for an xBase implementation of the same ideas. A fuller explanation of the ideas would be beyond the scope of this paper.