The methodology, designing formats and data consistency

The Events methodologyopenevsys-data-model

OpenEvsys, or Open Events System, is based on theEvents methodology for recording violations, also called “who did what to whom” or “wdw2w. An event is similar to the concept of a case, and is a story containing information
on acts, victims, perpetrators, sources and interventions.

  • Each event can have one or more victims
  • Each victim can have one or more violations (acts)
  • Each violation can have one or more perpetrators
  • Each event can have one or more sources (a source can also be directly linked to a victim)
  • Each even can have one or more interventions (an intervention can also be linked to a victim)

It is worth starting by reading the first seven chapters of the HURIDOCS manual called Events Standard Formats, where this methodology is fully explained.

You also need to read the introduction to the HURIDOCS Micro-thesauri (its only three pages), where we explain the rules for numbering thesauri terms. This is important if you want to adapt the thesauri (aka taxonomies or controlled vocabularies) in OpenEvsys or create your own.

Also useful are the two introductory manuals, What is monitoring and What is documentation.

Patrick Ball’s book “Who did what to whom” is an excellent backgrounder for understanding data models for recording your information on violations.

Designing formats for monitors

In order to capture information systmatically, its important to equip your investigators or monitors with a form. Forms should not be too long, but should capture the essential fields that you need, such as:

  • The main facts about the case (who are the victims, what are the acts, who are the perpetrators, when and where did the violations happen).
  • Enough personal data to correctly and uniquely identify a person. Sometimes persons may have the same names, so you will need to use additional fields to distinguish between two homonyms (place fo birth, date of birth, mother’s name). This will vary from country to country, for example in some countries people have ID card numbers.
  • Who collected the information, where, and when?
  • Did the sources give their informed consent on using their testimony in ways that may reveal their identity?
  • What interventions were made, and was further actions needs to be taken?

When designing your intake form, you need to consider the final purpose of your documentation project: what information are you collecting, and why? If you plan submissions to UN special rapporteurs, for example, then you need to ensure that your form is adapted to their requirements. Some rapporteurs have special formats, you can find them here.

To get you started, sample forms can be downloaded here:

Classic event format, Word document
Event format, flexible (use one person sheet for each victim, source or perpetrator, and as many free text sheets as needed).

Ensuring consistent data collection and data entry

Collecting data and entering it into a database requires a minimim of care and supervision to avoid inconsistencies, both at the level of data collection and data entry. If your data is inconsistent, retrieval and analysis will become unreliable. Common problems: monitors omit to collect certain important details, or have a different understanding of the definitions they are documenting. Likewise

Inconsistency is a common problem and exists in most human rights databases, but it can be kept to a minimum by taking the following measures:

  • Train your monitors on how to document events, to make sure they share a common approach. The easiest way is to give them the narrative of several cases, then ask them to code them into your intake the form, then review the results with them and agree on a common approach. The same training can be given to data entry clerks.
  • Review the incoming forms and provide regular feedback to monitors when you find mistakes. Ask them about any challenges they may face, for example certain types of information may be difficult to get (for example respondents may not know their date of birth). Don’t forget to provide positive feedback when the information is complete and consistently filled in.
  • Likewise, verify the quality of the work of your data entry clerks and provide them with regular feedback. If you are managing a large scale data entry process with several clerks, a “Friday review meeting” can be the opoprtunity to discuss challenging cases, inconsistencies you have found, and keep your team on the same track.
  • In addition to an intake form, equip your monitors with a glossary of violations. A glossary is simply a list of the 10-20 violations that you are documenting, with a layman’s definition of each one.
  • Likewise, write up a data entry manual, also called coding manual, explaining to your data clerks how each field in the database, is to be completed. For example, what to do if a key detail is lacking, or how to record a date when only the year is known (and not the month and day).
  • You also need to agree on a convention for naming persons. This will usually have the following format: Last name, first name, middle names. But this will depend on the custom in your country. Refer to the HURIDOCS manual “How to record names of persons” for more details.

We also recommend to closely read and re-read HRDAG’s core concepts, which will help you plan your data entry process and gain awareness of typical problems like bias and inconsistency in data entry. Its only one page, but it will save you from a lot of pitfalls.