In this demo paper, we present the web application Alter Heritage. Its goal is to support researchers in collecting domain experts' knowledge about inclusive cultural heritage metadata. While stakeholders in the cultural sector have been formulating strategies to mitigate biases in metadata, there is little empirical knowledge on how the metadata can be revised for inclusivity by users. With Alter Heritage, researchers can study what kind of alterations users make in artefacts' metadata to make it inclusive, how these alterations difer per artefacts and users. We develop the app's core metadata editing functionality based on requirements elicited from existing practices and guidelines in the cultural heritage domain. The data gathered via Alter Heritage will contribute to understanding of the specific alterations that make digital artefacts' metadata more inclusive.
What users learn about cultural heritage on the websites of GLAMs (galleries, libraries, archives, and
museums) largely depends on metadata. Thanks to the metadata, users can search through artefacts and
get contextual information about them: dates, places, keywords, textual descriptions, and relations to
other artefacts. Apart from useful information, metadata can also transmit cultural biases. For example,
subject terms from controlled vocabularies may be ofensive towards marginalised communities.[
To address biases in the metadata of artefacts, stakeholders in the cultural heritage domain have
been developing strategies.[
We select 14 domain documents, such as the guidelines and strategies mentioned above. From these documents, we elicit requirements: which functionality the web app must ofer to annotators in order to realise the suggestions on making the metadata inclusive. We implement the functionality for 38 user actions extracted from the documents, design the web app interface, and run a pilot with three users.
CEUR
ceur-ws.org
While multiple tools have been developed specifically for the cultural heritage domain to gather
annotations (see related work in [
The Alter Heritage demo is available online1 as well as its code with open licence and documentation.2
We use the domain analysis approach to elicit the web app requirements from the domain documents.[
First, we select domain documents about inclusive metadata strategies. We find them with keywords 3 using the Web search engines, academic repositories, and applying the snowballing method: following the references in the initial set of documents. While some documents are broad and general, others contain concrete actions. We targeted the latter ones and selected 14 documents in total (see the list in the documentation). Our aim was not to collect an exhaustive list of documents, but to collect a diverse set of actions of how metadata can be altered to increase its inclusivity.
Second, from the documents, we extract phrases with actions on making metadata inclusive. In total,
we identified 48 actions. For each action, we formulate use cases: which user performs an action and
how. For these use cases, we have only one type of user – an annotator. We specify use cases with 41
scenarios that illustrate how annotators might perform actions in practice using the web app.[
Third, covering all the scenarios, we outline the web app functionality. In Table 1, we provide an example of how we adapted suggestions from the domain documents into the web app functionality. The full table with actions, use cases, scenarios, and the functionality based on them is available in the documentation.
The requirements elicited from the domain documents concern only annotators editing metadata. Apart from them, we formulated additional requirements associated with how researchers would manage the annotation task: loading and displaying metadata, saving and retrieving annotators’ input.
When annotators access Alter Heritage, they begin with a consent screen showing their privacy terms. If a consent is given, annotators see the main screen, which includes instructions, an artefact (an image) and its metadata on the left, navigation and questionnaire on the right (see Figure 1). Annotators can perform multiple actions editing metadata. These actions are applicable to both textual metadata fields
2Documentation: https://github.com/cultural-ai/AlterHeritage 3For example, one of the queries we used was “cultural heritage” AND metadata AND (inclusive OR bias) and subject terms: adding a custom field or a subject term, removing, hiding/showing, and adding a note to them. To textual fields, annotators can also add a warning indicating, for example, ofensive content. The button “Restore” allows annotators to restore the original metadata.
After completing their edits, annotators click “Submit” to send their changes to the server. Unsaved changes are stored in annotators’ browser to allow navigation across artefacts preserving edits. The app notifies annotators when they submit edits and complete the task. Annotators can make more changes even after submission and resubmit them.
For researchers, the annotation tasks can be managed by creating JSON-files. There are 5 JSON-files linked to an annotator: consent, original metadata, edits, responses to questionnaire, and the submission progress. Researchers set ID for each annotator. This ID is used as a hash value in the web app link, for example, #ekaw24demo. The web app checks the hash value to read and write into corresponding files sufixed with the same ID. This way, researchers can distribute diferent sets of artefacts’ metadata to diferent annotators. The initial metadata of artefacts should be put in a JSON-schema, so that the web app could parse and display it. Researchers can indicate explicitly in a JSON-file which metadata fields will be available for editing by annotators. The annotators’ edits are stored separately from the original metadata in the same JSON-schema to ease the before-and-after comparison.
In this demo version, we chose not to implement such functionalities as image manipulation (e.g., cropping) and connecting external datasets (e.g., thesauri for pre-defined subject terms) that would make the annotation process more complex. These features could be realised in future development.
Alter Heritage is built with HTML, CSS, and JavaScript, running on a Node.js4 server. It utilises the Fetch API to parse JSON-files and POST requests to save annotators’ edits.
To test the functionality and interface, we ran a pilot with three users. They edited the metadata of six artefacts, completed the questionnaire, and gave comments during the task. The pilot helped us eliminate errors in interface interactions and understand users’ behaviour. As a result, we made the interface more intuitive based on users’ feedback.
During the demonstration of the app, users will have the opportunity to test all the functionality we implemented and see how the data is being processed in real time. The app will load the metadata of six cultural heritage objects we selected for users to annotate. Originally, we developed and tested the interface in Dutch. For this demo, we will provide an English version.
There are various types of biases that can be found in the cultural heritage metadata. In our demo, we
focus on one use case: (non)inclusive representation of LGBTQ+ people. We obtained artefacts’ metadata
that contains outdated and stereotyping terminology referring to LGBTQ+ people. First, we identified
outdated and ofensive LGBTQ+ terminology in specialised sources, such as Homosaurus 5 and a practical
guide for searching LGBTQ+ related objects in archives.[
In the cultural heritage domain, it is a known problem that cultural biases are transmitted through digital artefacts’ metadata. To mitigate the risks, the stakeholders in this domain have published multiple documents with various strategies. However, to the metadata developers, there is little empirical knowledge available on how metadata can be altered to reduce biases and represent heritage inclusively. We developed a web application Alter Heritage intended for research purposes. The tool’s aim is to gather knowledge on how domain experts alter metadata of cultural heritage artefacts to make their representation inclusive. The core functionality of Alter Heritage was developed according to the requirements extracted from the domain documents, such as policies and guidelines. In Alter Heritage, users can make changes in (biased) metadata: edit, hide from the view, remove, or add content. Researchers can collect these changes to analyse which alterations contribute to making metadata inclusive, how changes difer per artefact or user.
In future work, Alter Heritage could be updated to support more metadata editing functionality, which we left out: images manipulation and support of external thesauri for auto filling of subject terms. Another additional feature could be a user-friendly admin panel for researchers, in which they can set up the desired components in the app interface (such as optional consent screen or questionnaire) and import/export metadata and annotations.
This work is a part of the “Culturally Aware AI” project funded by NWO (Dutch Research Council). We thank the pilot users Thomas Schoegje (Utrecht University), Lynda Hardman (CWI), and Dirk Meijer (CWI) for their input and feedback. Thank you, Dirk, for helping us with the app installation on the server as well.