Alter Heritage allows researchers to collect data on how annotators edit cultural heritage metadata containing cultural biases. This data shows what kind of alterations in metadata can make it more inclusive according to annotators. Using the app, it is also possible to study differences of edits between different annotators and different artefacts' metadata. To annotators, Alter Heritage offers an interactive environment for editing metadata. They can perfrom such actions as adding new content (for example, a new metadata field or a keyword), removing content, hiding parts of metadaata from the view, attaching notes and warning to metadata fields and keywords (for example, to signal about the usage of biased terminology). Try out all the functionality in the live demo.
To determine which metadata editing functionality the web app should have, we used the domain analysis approach. We collected domain documents, such as guidelines, policies, recommendations from the cultural heritage domain on how to make metadata more inclusive. From these documents, we extracted phrases with concrete actions on making changes in metadata. Based on the actions, we formulated use cases and scenarios. Subsequently, we formulated the functionality requirements. You can find the whole process of elicitation in this Google Sheet: the tab "documents" contains a list of the domain documents we selected; "requirements_elicitation" shows the process of finding actions, formulating use cases and scenarios; "functionality" groups scenarios and describes the resulting functionality.
Alter Heritage is built with HTML, CSS, and JavaScript, running on a Node.js server. It utilises the Fetch API to parse JSON-files with the metadata of artefacts and POST requests to save annotators' edits. See the source code in metadata_editor/http_root.
There are 5 JSON-files for each user stored on the server:
- consent: stores user’s consent to participate in the study (True/False); rewritten only once when a user gives their consent;
- original metadata: this file is never rewritten; it is retrieved only when a user wants to restore the original metadata;
- user modified metadata: loaded into the interface; this file is rewritten with the browser-stored data;
- responses: user’s responses to questions;
- submitted: records whether objects were submitted by a user.
A user gets a URL to the annotation containing their unique ID (like https://alterheritage.project.cwi.nl/#ekaw24demo); all files for this user are suffixed with the same user ID (for example, 'consent_ekaw24demo.json');
- a user consent file is loaded, a user sees a consent screen; without a consent, a user cannot participate; if a user clicks “Begin”, a consent is given, and the process begins; users give their consent only once;
- a unique user file with 6 objects is loaded;
- users can navigate across all 6 objects before and after making changes; their changes and responses are stored in a browser;
- users can submit their edits only after answering obligatory questions;
- submitted objects are marked both in the interface and on the server (the “submitted” file);
- users can restore the original metadata; all their edits will be lost, their responses to questions will stay;
- users will be notified of the task completion once they submit all 6 objects;
- users can make changes in their edits and responses and resubmit objects multiple times;
If a user closes the app and reopens it, their submitted edits will be saved; the consent screen won’t appear again.
Alter Heritage by Andrei Nesterov (CWI), Laura Hollink (CWI), Jacco van Ossenbruggen (VU) is licensed under Creative Commons Attribution-ShareAlike 4.0 International
