Now Ian Mulvany talking about Mendeley and how they use APIs – both publishing and consuming.

Try to expose all the metadata being added by users via an API – a “social catalogue”. This enables ‘discovery’, but not ‘delivery’ – this is where Mendeley can make use of external APIs – such as the WorldCat API.

Mendeley invest in APIs because

• It helps them extend their product, but integrating data/functionality from other places
• It enables others to extend their product – they don’t have time to build everything that users are asking for. E.g. Android client built by users, as company didn’t have the resource

Mendeley uses WorldCat registry to find/suggest appropriate OpenURL resolver depending on users location – as most users won’t know what an OpenURL resolver is, or what the detail are.

Mendeley uses OAuth – which means they can integrate with institutional repositories and a users own publications in Mendeley – going to be live soon (working with JISC, Symplectic and University of Cambridge on this – http://jisc-dura.blogspot.com/). Learnt a lot about consuming their own APIs in this project – and uncovered bugs…

“We should have built the API first, and the product second” – the fact they didn’t now creating work. Now they are creating a new application for libraries, and building API first. Ian firmly believes this is a better approach.

Ian’s top 10 tips for API provision:

• first API, then app
• use your own APIs (and he believes Mendeley should do this more)
• make an (API) interface you would use yourself
• provide lots of example docs – coders like to do stuff quickly – if they can get something working from an example quickly, they’ll then invest
• version your API – backwards compatible
• put rate limits in place
• work with a 3rd party to provide keys
• have clear licensing
• engage with your community
• promote, promote, promote, promote, promote

In terms of consuming:

• know what you want to do
• define the value – this may be service delivery, or could be development of skills for developers etc.
• measure the value – otherwise difficult to prioritise future developments
• understand the SLA
• if it’s important – have a backup plan – dependence on 3rd party is a risk which you should manage
• don’t wait on API for page loads – found that Mendeley homepage was waiting for a response from an API was down, and so the page didn’t load…
• get on the mailing list/dev group
• look for good example code
• don’t be afraid to pay – if it’s important, it’s worth paying for
• use Mendeley’s APIs 😉

I’m at the OCLC EMEARC meeting today, talking and hearing about APIs. Having done my bit at the start, now trying to relax into the other presentations before questions and general discussion at the end.

Now Antonio Tejada and Hans-Siem Schweiger are talking about Citavi which combines Reference Management and Knowledge Organisation. Citavi designed to help with searching, retrieving results, acquiring materials – all of these require interaction with library sources. Citavis supports adding data manually, from file upload, browser extensions and via APIs.

Manual entry is error prone and time consuming

File upload – uses standard formats (RIS/BibTeX); supported by a wide range of catalogues and databases; but still time consuming

Browser Extension – e.g. looks for embedded metadata in the page (e.g. COinS) or find standard identifiers in the page (e.g. ISBN) and import data

APIs – eliminates the browser – you don’t need to go to lots of different sources on the web. Fastest mechanism. Direct. Integrates in the workflow much better. However cost of implementation can vary quite a bit – it all depends on the API – some very fast (e.g. z39.50 can do in minutes now, but custom APIs can be more difficult)

Citavi Features which use APIs:

• Online search – integrated into the Citavi application
• Retrieve by identifier (e.g. DOI, ISBN, PubMed ID)
• Import formatted bibliography – can take a bibliography from a word file and Citavi will run a search for each item in the bibliography
• Find Library Locations
• Find Full Text
• Check availability with OpenURL (seems like this actually just pushes user to their local resolver?)

Universities can get site license for Citavi – allows library to create a special settings file with authentication details for databases (that are not IP authenticated)

Challenges for Citavis using APIs:

• Administrative challenges
• Some libraries don’t want to be accessible (at least via a desktop application)
• Catalogues that charge by the record for metadata
• Inconsistent communication – e.g. change of settings on library system, don’t inform Citavi
• Technical challenges
• Custom catalog software – missing or inconsistent standards support and inconsistent field mapping
• Legacy data – not as well-structured; inconsistent data entry

Going forward:

• Geographic search (WorldCat Search API)
• Enhanced availability search (WorldCat Registry and OpenURL Gateway)
• Acquisitions management (WMS Acquisitions) – Citavi didn’t anticipate this, but some libraries using Citavi to manage acquisitions processes
• Metadata – looking at authority control (WorldCat Identities); Alternate editions (xISBN); ISSN lookup (xISSN)