An essential area of focus for cultural heritage scholars should be application programming interfaces, or APIs. APIs are, in very simple terms, code libraries assembled by web service companies to enable third-party applications to communicate with the web service platform. Though an API is an interface, it is invisible to the human eye; indeed, it’s an interface that facilitates computer-to-computer communication. Within the domain of cultural heritage, there is incredible potential create tools that can revolutionize not only the presentation of collections, but the way that people experience and interact with cultural heritage. But before we can leverage APIs in useful ways or even build APIs of our own, I think it’s important to think about the implications of utilizing these interfaces.
APIs often include software development kits (SDKs), documentation, and other tools for web developers to use to leverage the functionality of the web service for their own projects – be they mobile or desktop applications, websites, or other varieties of tools. For instance, any access point that people read and write tweets from that isn’t the web-based interface at twitter.com is built using Twitter’s API – even their own official desktop and mobile applications. APIs also enable mash-ups of web service data, such as contextualizing photographs geographically by mashing up the Google Maps API and the Flickr API.
You might think of an API in terms of a restaurant (web service) with a smorgasbord of meal choices and combinations. The kitchen is a chaotic place that can produce any combination of food on the menu. Your server gives you a menu (API documentation) from which you learn the correct protocols to order and all of the available food choices from this restaurant. You place your order (send a programming call) and, if you’ve followed protocol to the correct specifications, the kitchen will send out your meal (the desired data) in a manner consistent with your order. This metaphor illustrates that an API is not one tangible object, but a set of protocols that an organizations uses to mediate access to data within their web service. This interaction between third-parties and organizations constitutes an almost social transaction wherein a set of complex power relations are at play.
Twitter is one API that many DHers are already using and analyzing. It’s a powerful API based on the sheer number of users as well as the volume of data that Twitter makes available per tweet. Depending on an individual user’s settings, one tweet contains several datapoints such as location, the application the tweet originated from, as well as user data like picture, name, and bio – this is on top of the actual content of the tweet which may include mentions, hashtags, and other meaningful data. Right now cultural heritage and DH scholars often use Twitter as a tool to enable conversation and sharing. Because our field relies on Twitter in a big way, we should think critically about the way that Twitter (the company – with financial interest in our continued use of their product) API constrains and afford the movement of and structure of information in our work. Information is an economy – and like any economy, there are the rich, powerful entities and the disenfranchised. With our insights into the history and nature of human relations as cultural heritage scholars, we need to be aware of this dynamic interplay of companies, data, and users.
Through the construction of API protocols and documentation, companies mediate our access to their data in their web service. Using an API is like a process of negotiation, I think, where third-parties make use of what access points are available through the API at the expense of rules that are set by the providing web service. This means, for instance, that third-parties who use Facebook’s Open Graph API to make their apps more social are submitting to Facebook’s rules about how to access and use data. I use this example because Facebook has, very audaciously and publicly, implemented policies which privilege their corporate interests in favor of the interests of their users. We should be wary of implementing Facebook’s API in relation to heritage work so as not to expose cultural stakeholders to such an unpredictable power relationship.
The bigger lesson here, I think, is two-fold:
- APIs are potent resources. They not only facilitate access to rich pools of data, but they make possible unique ways of repurposing, remixing, and rearranging such data to serve a multitude of purposes, both practical and scholarly.
- We should think of APIs not as inert and agenda-less, but as technologies that drive an economy of information where data is the currency and API users are consumers.
We should be ambitious and imaginative in what we can build with the robust combination of technology and data available to us, but in so doing we must be aware of web of relationships that govern our access to and use of these resources.
Leave a Reply