Вы находитесь на странице: 1из 16

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