Europeana and the case for a

public API

Jeremy Ottevanger, Museum of London and

Leicester University
 Why an API?
The business case pt. 1

How Europeana gains

● Increased participation
● Preparation for the Semantic Web/Web 3.0
● Increased use – centralisation is not the only
answer
● A bigger brain and deeper pockets
 Why an API?
The business case pt. 2

How museums, libraries and archives gain

● Use of our own data, our own way

● Functionality we can’t provide ourselves
● Dissemination of their data via third parties
● Their content, socially situated
● Management of and access to
– Implicit UGC
– Explicit UGC
 Use cases for MLAs

● Search own catalogue in entirety within and

IFrame (HTML output)
● Embed search results in page with AJAX or
JSON
● Search subset (a "collection") within their
catalogue
● Map a set of themed objects
 Use cases for MLAs (cont.)

● Mash the EDL record with shop information

● Integrate EDL content with site search in
multiple languages
● In the teaching resources section of the site,
pull out 6 specific objects or a set of KS3
items to accompany a worksheet
 Use cases: strategic bodies
and partnerships
e.g. in the UK, MLA London, Renaissance North East,
the Great Fire of London Partnership

● Combine all London museums for a cross-

Hub search
● UK-wide listings of content for KS1, 2, and 3
● Show all items and related people
associated with the Great Fire of
London,1666
 Use cases for third parties

● Build a timeline of renaissance art and artists fed

with details of artworks from EDL
● Local history society shows a listing and map of
museums and archives holding material tied to
Slough
● Coins and medals collectors' site mashes up
reference material from the Celtic Coins index with
object records from EDL
●
The Università di Ferrara integrates palaeolithic
tools from EDL into their course materials
● Flickr, VLEs....
 Sharing data and functionality
● Web Services, SOAP
– Infrastructure, data exchange, intra-organisation
– Complicated, losing ground?
– “direct to Web 3.0” mode
● Social Web/Web 2.0
– Light tech, relatively easy
– An API is just an interface – you can embed
semantics in a web page
– Rapid growth – APIs and platforms
– Community development
– ....and still a step towards Semantic Web
 The UK sector's view

MCG list discussion

● Role and purpose of EDL

● Barriers to entry and to aggregation
● The API question...
 MCG suggestions

● based on established metadata

models/standards/schemas that allow multiple
sources and minimise data loss.
● feature most of the functionality that can be accessed
from the back-end
● T&Cs requiring that UGC be flexible enough to allow
any reuse with attribution
● API key for differentiated access to services
● enable “crowd-sourced” user-generated metadata
● lightweight: REST, XML, RSS, JSON
The shape of an API: functionality 1
Catalogue data access
● catalogue data search, parameters to include anything used on the
Europeana site, e.g.
– GUID
– date
– name
– related person
● GIS mediating layer for location-based search
● related event
● categories, subjects, themes
● UGC-centred search (presumably largely around tags)
● curated sets, including mediating content
● translate
● compare
● rights management data
 Functionality 2
User data access and editing
● requires authentication of agent accessing the API by key or domain
name. Server-side access only?
● registration/login of user (OpenID?)
● view core user profile. Cannot edit core data (managed directly in
Europeana)
● view and add/edit catalogue-linked data for a user – specific to the
catalogue owned by that key-holder? Tags, descriptions and notes,
groups
● view and edit uploaded content for a user
 Functionality 3
User data management
● authenticated access for agent. Server-side access only?
● manage and report on collected user data related to the organisation’s
collections, by object/collection etc. rather than user.
● Statistics on implicit and explicit UGC – search patterns, tags, favourites,
etc.
● Needs a GUI too!
 Functionality 4
Collection data management
● Ingest, update
● Rights management
● Aggregations, collections
● Thesauri, taxonomies
● Server-side only
● Hey, we might actually want formal web services here…
● …but this is definitely the domain of another work group!
 Technology suggestions
Characteristics
● Light
● Simple
● Consumable server- or client-side.
● Well-supplied with ready-rolled scripts and code snippets
● Compatible with established metadata standards, but ideally not only
sector-specific ones
The recipe
● REST
● XML and JSON
● XML flavours might include RSS/Atom, geoRSS, CDWALite, XHTML
with microformats, SPECTRUM for XML, OAI-PMH built around DC
● eRDF and/or microformats plus a GRDDL profile for our XHTML pages
(search results, records, institutional data), taking the “API” right onto the
web page.
 What else can EDL offer?
My half-baked ideas:

● A PURL service.
● A registry of museums’ online presence