It is possible to track human rights violations very precisely using rules defined as simply as above. There is, however, a trade between defining very simple rules, and defining rules that reflect an agency's specific needs and the specific forms of information that they receive. The simpler the rules are, the less chance there is that an agency will inadvertently introduce ambiguity into their data. However, the more elaborated the rule definitions, the more fully the agency can represent information of particular interest to them.

The rules we elaborated in section 6 are the minimum set of rules that a HURIDOCS compatible database must represent. The abstract field and SQL implementation examples are designed in order to permit very precise and thorough customization of the rules such that each agency can represent information in a form very close to how they receive and understand that information. The standard relational model, on the other hand, is designed only to represent the simple rules defined above. It would be adequate for many agencies' needs -- especially for those agencies that do not have extensive resources to devote to computing personnel and hardware.

One way to balance the goal of simple rules with the goal of very thorough rules is to build elaborate controlled vocabulary lists. For example, consider the following narrative. "Juan Pueblo was arrested by the National Police on July 19, 1979, and taken to their headquarters. While there, they tortured him by blows to the head and thorax, and by immersing him in contaminated water, and by giving him electric shocks to the thorax with an apparatus."

In the standard representation described above, all of the tortures the National Police subjected Juan Pueblo to can be classified by the act-of-violence rule -- but we will need a list of controlled vocabulary items (in the "action" column) which includes many items.

However, some agencies might want to design slightly different rules for all of these different kinds of tortures. Below there are three different rules to represent different kinds of torture.

In the first example, there is ONE rule type for ALL acts of violence. The rules are simple, but the controlled vocabulary list is more complicated. In the second example, the rules are more complicated, but the controlled vocabulary lists are simpler. One advantage of the more complicated rule system is that the rules reflect even more closely what the narrative describes. In systems that store rule information as "meta-data," such as the abstract field and SQL models presented below, there is little penalty for adding rules. But in the standard relational model, it is difficult to handle more than a few RULE-TYPEs.

So far, we've discussed these rules only as they are classified according to structure. To users, however, rules make sense in substantive terms: rules about violence are together, rules about legal process are together, etc. Organizing rules by structure is not always quite the same as organizing rules by meaning. It is the job of the programmer to build an interface which organizes all the information according to whatever makes most sense to the user. A good interface will be the difference between an incomprehensible system and a friendly one.

Notice that systems defined as "HURIDOCS compatible" are NOT "compatible" with each other in the sense that people can simply trade disks and use each other's data. The very structures of the tables may well be different between two compatible systems. Any two systems which want to share information directly need to establish an exchange format, including field structures, file organization (DBF, ascii, etc.), and most importantly, a common organization of controlled vocabulary items.