The basic building blocks of any database system are the ENTITIES that system represents. The entities the task force isolated as fundamental to database design for human rights agencies are listed below. The entities are defined only very generally; later we will discuss each in much greater detail.
NAME - a list of all the people and organizations in the database. These may be victims, perpetrators, or information sources. A certain person may be a victim of one violent act and a source of information about other acts. Whatever their role, all the people and organizations should be maintained in a common list. [see entry in Glossary]
EVENT - the context in which the database tracks different acts (sometimes called a "case"). An event is the context or frame an agency uses to make sense of a sequence of concrete acts. An event is not an act. For example, if the agency hears that a particular person has been arrested, the arrest is an act, not an event. The arrest act would be part of the event, connected to other relevant acts. An event might be compared to a film; each frame of the film would be an act. See the Diary section, below. [see entry in Glossary]
INTERVENTION - actions taken by family members, the human rights agency, or others on behalf of victims. As with Event, interventions are composed of acts, although intervention acts are quite different from event acts. [see entry in Glossary]
These three entities (NAME, EVENT, INTERVENTION) are called BASIC entities because they are used to give form to the LINK and VOCAB entities.DIARY - a special kind of entity used to track complex links between other entities. Diary records represent information according to the RULE-STRUCTURE defined in a RULE (see the glossary for more detailed definitions of the capitalized terms). Rules fall into one of the following three RULE-TYPEs: act, biography, or relationship. Section 6, entitled "Rule-types with rule examples and rule-instance examples," gives a detailed description of the rules and their structures. The following paragraphs are to describe the conceptual basis for each of the three rule-types. [see entry in Glossary]
ACT - a concrete, indivisible occurrence between two NAMEd entities (i.e., two people, two organizations, or a person and an organization) that happens at a specific point in time. The following instance is an example of an instance of an act-of-violence rule: On 11.08.1988, at 11 am, Lt. Mendoza executed by shooting Juan Pueblo. This act, along with others (e.g., Mendoza's arrest of Pueblo, threats Mendoza previously made against Pueblo, etc.) might be associated with an event. The human rights agency recording the information might use the event to connect individual acts into a useful, coherent form for their work. The act is something very precise which happened in the world, whereas the event is the context or frame that the agency puts on a series of acts. There are many kinds of acts -- see Section 6 for a complete list of act rules with examples. [see entry in Glossary]
BIOGRAPHY - a status experienced by a person from a starting time to an ending time. For example, the following is an example of an instance of the military-biography rule: From 01.01.1988 until 01.01.1989, Lt. Mendoza was the operations officer of the 3rd Brigade. This biography moment, along with others (e.g., other jobs Mendoza held in the military, his educational record, party militancy), is associated with Mendoza's record in the NAME database. There are many kinds of biography moments -- see Section 6 for a complete list of biography rules with examples.[see entry in Glossary]
RELATIONSHIP - a connection between two entities (two people, two organizations, or a BASIC entity with a VOCAB item) which may or may not have beginning or ending times. For example, the following is an example of an instance of the relationship-kinship rule: Juana de Pueblo has been married to Juan Pueblo since 15.05.1962. This relationship, along with others (their children, colleagues, neighbors), helps define the social context in which the agency's data exists. There are several kinds of relationships -- see Section 6 for a complete list of relationship rules with examples. [see entry in Glossary]
VOCAB - a controlled vocabulary list. Vocab items include items such as geographical terms, specific types of violence, occupations, etc. [see entry in Glossary]
Vocab is more than a controlled vocabulary list, however. The items in Vocab are organized into sets of related categories. VOCAB items also include field names and entity titles. Any item might contain a subcategory of items. Any given item plus its position in a category, and that category's position relative to other categories, is called a descriptor.
Because different human rights agencies have different needs, we build on an idea developed in the HURIDOCS formats that a given entity might have a variety of fields. That is, the field structure of the entities is not fixed by our data model. For example, the EVENT table might or might not contain fields for information about Supporting Documents (HD#123), Date of Entry (HD#124), or Date Received (HD#125) (see Dueck et al. 1993a for the fieldname references). All three of these fieldnames would be records in the Vocab table. The only required field in any entity is its primary key, which is a code number or id field which uniquely identifies that record among all records in the database.
One of the ways that uncertain field structures can be managed at the database level is to represent information by using the fieldnames as part of the data. A complete explanation of this technique would be too extensive to present here, although it is introduced in the abstract fields and SQL implementation sections below. The basic idea is that instead of a list of fields attached to each key, the key exists in one table with "uncontrolled" information -- unvalidated strings, numbers, etc. The "controlled" information associated with the key is kept in another table (called the CV data table in the example below), linked by the entity's key. The field name which defines the controlled information is kept in one field of the CV data table. The value of the field is kept in a third field. This technique permits each field to have multiple values (by repeating the entity_keys and field_names in multiple records), and permits fields to be added or deleted without changing the database structure. This technique is the basis for the description RULE defined in Section 6.
| Entity Table | CV data table | |
| entity_key | ----------1:m--------- | entity_key |
| uncontrolled data | field_name | |
| field_value |
Vocab also includes the roles that entities play vis-a-vis one another in complex links. For example, in an act-of-violence, a perpetrator does something to a victim. "Victim" and "perpetrator" are roles that particular people or organizations play in a particular act. As we discussed in the Diary section, a concrete act is represented by a link between two NAME entities. This connection will be considered at greater length in the following section, but for now note that these roles are also included in the Vocab table.
As we suggested in the introductory section, for the purpose of this paper, the actual content of the entities is not as important as how the entities relate with each other. For our purposes, it is only necessary that each record in each entity (e.g., each person or organization recorded in NAME) be uniquely identifiable by some code, called a primary key. We leave all other discussion of the content of the entities to other materials, specifically Dueck et al. 1993a.