- The Design for Diversity Learning Toolkit - https://des4div.library.northeastern.edu -

A Culturally Sensitive API? / Sonoe Nakasone

This study path is based on the Mukurtu case study and two articles, and presents problematic aspects of access for cultural heritage materials that can be perpetuated by systems of automatic data access and harvesting.  

by Sonoe Nakasone, Community Archivist, University of North Carolina at Chapel Hill Libraries

Abstract

This study path is based on the Mukurtu case study and two articles.  The Mukurtu study presents problematic aspects of access for cultural heritage materials that can be perpetuated by systems of automatic data access and harvesting.  This short assignment asks students to keep in mind these issues for accessing indigenous materials while informally exploring and assessing some popular APIs.

Prerequisite knowledge

Learning Objectives

Where you’re going to be at the end:

What kind of path this sets you on:

This study path includes three related activities:

Reflection/Discussion Prompt [1]

Assignment [2]

In-Class Exercise [3]

Activities

Reflection/discussion prompt (20+ minutes)

You don’t need to share: Reflect on a possession of yours that has great sentimental value or a person you know that has possessions they attach great sentimental value to.  What is missing from APIs as they are commonly used in libraries, archives, and museums that would disadvantage you and these possessions?

Assignment (2+ hours)

As individuals or in groups, students will develop functional requirements for an API that attempts to address problematic features of APIs raised through the Mukurtu case study.  Functional requirements describe what that a system needs to do in order to achieve the desired outcome. Functional requirements do not dictate how something is to be achieved. The templates in the “Resources” section below are suggested formats for the assignment deliverables.

Option for more technical classes: Depending on the scope, level of technical detail, and skill of the course, additionally, the instructor may choose to ask students to outline plans for executing the functional requirements, provide a sample output, or even the build the API.

Hands-on activity (30 minutes)

Students will explore and review documentation of existing APIs to look for elements that might alleviate or illustrate issues of access and bias discussed in the Mukurtu case study and the articles below. Students and instructor will briefly share and discuss their findings with the class.

API documentation is often intended for developers, so the language is often highly technical. Instructors may need to modify this activity for students with less technical background by evaluating technical level of documentation or providing summary documents.  Instructors should evaluate screen reader potential for students with low or no vision. Below is a list of APIs, but the instructor may want to include additional or other APIs.

API documentation:

iiiF image API documentation [4]

Twitter Standard Search API documentation [5]

Resources

Readings

Hennessy, K., Wallace, R., Jakobsen, N., & Arnold, C. (2012). Virtual Repatriation and the Application Programming Interface: From the Smithsonian Institution’s MacFarlane Collection to “Inuvialuit Living History” | museumsandtheweb.com. http://www.museumsandtheweb.com/mw2012/papers/virtual_repatriation_and_the_application_progr [6]
Hudson, L. (2017, July 20). Technology Is Biased Too. How Do We Fix It? FiveThirtyEight. https://fivethirtyeight.com/features/technology-is-biased-too-how-do-we-fix-it/ [7]

Resources

Mukurtu Case Studies  [8]