| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Finally, you can manage your Google Docs, uploads, and email attachments (plus Dropbox and Slack files) in one convenient place. Claim a free account, and in less than 2 minutes, Dokkio (from the makers of PBworks) can automatically organize your content for you.

View
 

Making good APIs

Page history last edited by Mia 2 weeks, 1 day ago Saved with comment

Useful links and background reading on APIs

 

How can museums improve the usability of collection APIs? Evaluating the Usability of Museum APIs, Villaespesa, E., Nadel, K., Estigarribia, A., Tankha, M. and Korshakova, E. (2021), Center for Digital Experiences at Pratt Institute.

 

Cultivating APIs in the cultural heritage sector: Lessons from an internship at Europeana, MSc thesis by Jolan Wuyts

 

User experience design for APIs

 

Producing linked open data for cultural, historical and scientific data

Karma has been used to produce to convert records from the Smithsonian American Art Museum to the Europeana Data Model. Further information (PDF).

 

Why an API?

JISC report, December 2012: The advantages of APIs: How to jump the information gap

Written for the higher education sector, but a useful primer for non-technical museum staff too.

 

Because it'll help Google find your content and events. From the Google Webmaster blog: Introducing Data Highlighter for event data

'Data Highlighter is a point-and-click tool that can be used by anyone authorized for your site in Google Webmaster Tools. No changes to HTML code are required. Instead, you just use your mouse to highlight and "tag" each key piece of data on a typical event page of your website... If your page lists multiple events in a consistent format, Data Highlighter will "learn" that format as you apply tags, and help speed your work by automatically suggesting additional tags. Likewise, if you have many pages of events in a consistent format, Data Highlighter will walk you through a process of tagging a few example pages so it can learn about their format variations. Usually, 5 or 10 manually tagged pages are enough for our sophisticated machine-learning algorithms to understand the other, similar pages on your site.'

 

On museum data

Museum Data Exchange: Learning How to Share

'This article describes the free or open source tools; lessons learned in harvesting museum data; findings from the data analysis; and the state of data sharing and its applications in the museum community.'

 

Reprogramming The Museum,Luke Dearnley, Powerhouse Museum, Australia

'This paper looks at how the Powerhouse Museum's collection data API launched in 2010 quantitatively and qualitatively improves upon the access provided by the download dataset previously offered, as well as how the tracking methods were built into the API to ensure that the project is best able to adapt to the user needs of API developers. It provides details on the lessons learned and suggests best practices for API development in the cultural sector.'

 

A list of what some developers want from a museum API, based on responses to the Carnegie Museum of Art's question 'Developers: What would you love to see in an open museum API?' (Thanks Frankie Roberto for pointing me to this post)

 

A Museum Mapping for the Real World

Dominic Oldman on the British Museum's work on Conceptual Reference Model (CRM). 'The following provides a summary of the mapping for a typical British Museum object based on some key CRM properties (it is not comprehensive and does not describe all elements). As you will see the CRM closely follows the events and concepts that many museum staff find familiar and uses real world descriptions rather than the technical labels commonly found in databases tables. The CRM differentiates itself from other aggregating frameworks because it does not attempt to strip down data sources into a common set of fields but instead provides a model for harmonising rich and complex data sets, from whatever source and however formed, to derive the maximum benefit.'

And their mapping as a Word document: The BM Mapping in a Nutshell

 

On archive data

Access to online archival catalogues via web APIs (PDF), Richard Lehane, State Records NSW

'This paper describes State Records NSW’s Open Data Project and the development of a web API to the online catalogue, Archives Investigator. In the course of developing the web API, a new experimental user interface to the catalogue was also built. Key features of that new interface are described.'

 

Discusses the context in which machine-readable access was provided, the internal benefits, the lack of independent re-use of the data, and how the interfaces can help researchers 'reframe their queries in archival terms' to better use the site, e.g. 'the search engine itself reframes the user’s question into an archival one. The  three-part division of descriptive entities is consistent with Chris Hurley's conception of archival description as comprising three essential types of entity: documents, deeds and doers.'

 

Other papers from the 2012 International Council on Archives Congress are available.

 

On library data

Brewing your own linked data: Resources compiled by Tim Sherratt and Paul Hagon for a workshop at VALA2014.

 

On API, markup design

LODLAM Patterns is a new site collecting design patterns - solutions to common problems - for linked data in cultural heritage

 

There's been some discussion on extending schema.org's markup to deal with historical data e.g.

WebSchemas/HistoricalDataSchema e.g. 'extensions to schema.org to address historical and genealogical (family history) scenarios' but most of the discussion on https://github.com/historical-data/schema seems to be about genealogical records.

 

30 APIs To Look At When Planning Your API

 

Make your Museum API, part 1: Ruby. Advice on getting started.

 

JISC's 2009 Good APIs project, project blog archive and Marieke Guy's API Good Practice Project Report.

 

HuNI Ontology provides a useful overview of the ontologies, schemas, subject vocabularies and languages the Australian ​Humanities Networked Infrastructure (HuNI) project is looking at using.

 

Mapping to the Europeana Data Model (EDM) is another way of getting more benefit by linking to existing datasets.

 

APIs Using and creating Application Programming Interfaces from the UK Government Service Design Manual

 

Naming Principles (microformats.org)

API Craft - a community around the craft of building an API

 

Digital Classicist's list of sites with Very clean URIs ('no "cruft", meaning no ".cgi",".php",".asp","?","&","=" and the like'), for inspiration

 

72 Open data good practices (a checklist)

 

How to use APIs (resources for learning)

Learn about APIs by learning to use some: Build real-life apps with APIs at CodeAcademy.

 

This code4Lib article on 'HTML5 Microdata and Schema.org' is 'an introduction to Microdata and Schema.org. The first section describes what HTML5, Microdata and Schema.org are, and the problems they have been designed to solve. With this foundation in place section 2 provides a practical tutorial of how to use Microdata and Schema.org using a real life example from the cultural heritage sector. ... Issues with applying these technologies to cultural heritage materials will crop up along with opportunities to improve the situation.'

 

Introduction to APIs by Owen Stephens has two introductory exercises that show you how to access APIs without writing any code.

 

Sometimes the best API isn't an API

Simple text-based CSV (comma-separated value) files might be easier. They can be exported from many collections management systems and saved out from Excel files, and they can be opened in many text editors, databases and speadsheet applications.

 

SPARQL – What’s up with that? by neil.mayo has a section on 'Problems with SPARQL endpoints': 'some of these are due to the nature of RDF and SPARQL, and require a reconception of how to find information. Others are instances of unhelpful presentation; SPARQL endpoints are generally pretty opaque, but this can be alleviated by providing more documentation. With the amount of work it takes to prepare the data, I am surprised by how few providers accompany their endpoints with a clear list of the ontologies they use to represent their data, and at least a handful of example queries.'

 

Comments (1)

Mia said

at 11:48 am on Jul 12, 2013

Also worth a look: Notes from the 2013 LODLAM summit by the BBC's Yves Raimond http://www.bbc.co.uk/rd/blog/2013/06/notes-from-the-2013-lodlam-summit

You don't have permission to comment on this page.