Skip to content
This repository has been archived by the owner on Jan 25, 2024. It is now read-only.

AMNH API Portal

Jump to bottom
Mike Caprio edited this page Mar 23, 2017 · 27 revisions

A Unified Online Gateway for AMNH APIs

Hackathon Findings

The prototype for a unified Library API and a portal for museum APIs is currently in development and will eventually push to production.

  • The Library is collaborating with the Museum's IT Department and the Digital Group to develop the required infrastructure and security for this project
  • IT Department has set up an instance of ElasticSearch on a dev machine for testing
  • Library is setting up a dev VM for the node.js application
  • The Library has refined functional requirements of the Library API to include an implementation of Metasearch
  • The Library's technical team is familiarizing itself with the various API's (Omeka, ArchivesSpace, xEAC, DSpace, Sierra) - we are using Postman and the command line for testing

Considerations for future Hackathons

  • Dev VM available for prototypes - once the Hackathon is over, this will spare time and effort in getting prototypes into development after the fact
  • Test all APIs beforehand and make sure that the appropriate permissions are assigned to the usernames given to the programmers making API calls
  • Ensure that all indexes are up to date that the programmers are scraping
  • Test all of the ports to ensure that they are open on whatever network the programmers are using

Hackathon Projects

Background

Since its inception, the AMNH Research library has been collecting and generating significant amounts of data pertaining to the Museum's historic halls, exhibitions, expeditions, scientific departments, publications, rare materials and ephemera. In recent years, the Research Library has focused on digitizing its collections and making much of the digital content available online using open source applications and open data standards.

NASA's own API site at api.nasa.gov as an example

Making the Research Library's digital content available as machine-readable data and accessible via an API not only enables data sharing within AMNH, but allows for other institutions to leverage our digital assets to enrich their own collections and make valuable connections to related content. The challenge here is to make an easy to use and accessible API portal and/or series of APIs that enables better and faster access to specific types of resources across all library systems.

For an API example: it may make sense to have a "Person" API that unifies and pulls all person related data from every information system. What are the practical considerations for creating such an API call? It may make sense to create an API response which both collects common data into one dictionary, and also maintains dictionary records for all the data from each individual information system. What will fit the use cases of the other challenges? You may need to prioritize the creation of some APIs over others depending on the needs of other participants and their challenges.

The resulting code for an AMNH API Portal can be shared with the wider world in hopes that similar institutions can may adopt a similar solution for opening up their data. We see this API portal being used by the public, librarians, archivists, researchers, developers, educational institutions, and AMNH staff. Additionally, similar institutions may adopt our code base for the API portal or for combining resources into a single API, especially as many of the underlying information systems are open source projects themselves, and your work can potentially become a contribution back to that core open source project.

The library systems below are extensively explained and documented on the Online Resources And Data Sets page and must be used for this challenge: Omeka, DSpace, WordPress, Sierra, xEAC, ArchivesSpace

We are relying upon your experience in developing APIs and API portals to help us determine the best way to organize access to this collection of systems. Multiple challenges in this hackathon are using the same library server resources - in many ways, the teams working on this AMNH API challenge will be the "heart" of the entire hackathon, as they will need to collaborate and coordinate with other participants working on other challenges that will use the API wrappers they create. It will be crucial to discuss overall API strategy with other challenge teams to determine what types of API calls will be needed.

Solutions

Below are a few example sites from other institutions who have created API portals:

And here are a few possible solutions:

  • Create the code/web site for the repository for any API's created during the Hackathon and for the existing information system APIs. This repository will also be a prototype for a Museum-wide API portal for any Museum department to park APIs, along with relevant documentation.

  • Create unified library system API calls. This will require several teams, perhaps working on different collections of unified APIs. You will need to determine what kinds of API calls make sense based on what is available in the REST API documentation for each of the systems, and what the other hackathon challenges may require in terms of API calls.

  • Sharing Vocabularies Administration Tool. Consistency is the key to creating useful metadata. We need a centralized tool for controlling vocabularies used in the museum: to share locally controlled names and pull controlled names from trusted sources such as the Library of Congress. This app would allow the Library to organize, share, and update terms with other departments in the museum. Synonyms of variant or alternative terms should also be searchable but directed to the controlled term. A few types of Ontologies: Persons, Corporations, Subject headings, Format, Titles (variant titles), Geographical location, Roles, Location of material (local). This tool would allow us to: Add/Delete terms, Update lists automatically, Identify dupes in order to establish one controlled term for each name, Assign synonyms, Plugin to existing databases for auto-suggestions from our pool of terms.

  • Sharing Vocabularies Browser Extension. It would be supremely useful to create some kind of browser extension which would allow a user to enter a name into a text box, and display an "autocomplete" style selection of choices that map to the appropriate possible controlled vocabulary terms. In other words: "Teddy Roosevelt" as an input would return the correct controlled term "Roosevelt, Theodore, 1858-1919" as well as "Roosevelt, Theodore, 1831-1878". The user would then be able to select the correct term, and it would automatically populate a field on the current web page. This could potentially work with any web system, and always be up to date using a shared vocabulary API.

Resources

Challenges --|-- Online Resources And Data Sets --|-- Code of Conduct --|-- Home

Challenges

Online Resources And Data Sets

Museum Stakeholders

Home

Clone this wiki locally