The repository model can easily be combined with other models. For example, if we go further with the library example, we could easily design something very similar to the events standard. Think, for instance, that the books described above are located in a library that loans these materials to library members. In order to do so, library members would constitute another entity with properties such as id, sex, age, email, telephone and educational level. The other main entity would be the loan itself, described with properties such as the loan period, the permission to take the material to home or to read at the library, etc. This library loan structure could be summarized in the sentence: What do we loan to who?, similar to the event standard. A similar structure is used in many shops to register customers, orders and products: Who ordered what? Or What do we sell to who? Track complaints data model Complaint reception and management is a recurring task for national and international institutions in the human rights field. Data models for tracking complaints are essentially based in the stages of the complaint handling process. This case study covers the development of an information system to handle victim’s complaints at a human rights organization. It shows how information needs were identified for a specific project and how they were converted into technical requirements for the database, including the data structure reflected in the data model. Monitoring judicial response data model Similar to the previous case, monitoring judicial response demands a model that covers the different stages of the judicial process and also includes a comprehensive description of relevant entities such as judicial instances. The SUMMA database, created by the Center for Justice and International Law and explained in detail in this case study, constitutes a good example of how information should be registered and structured to facilitate its retrieval by users and how to provide aggregated information regarding cases. 13