Europeana and the case for a public API Jeremy Ottevanger, Museum of London and Leicester University
Why an API?  The business case pt. 1 <ul><li>How Europeana gains </li></ul><ul><li>Increased participation </li></ul><ul><...
Why an API?  The business case pt. 2 <ul><li>How museums, libraries and archives gain </li></ul><ul><li>Use of our own dat...
Use cases for MLAs <ul><li>Search own catalogue in entirety within and IFrame (HTML output) </li></ul><ul><li>Embed search...
Use cases for MLAs (cont.) <ul><li>Mash the EDL record with shop information </li></ul><ul><li>Integrate EDL content with ...
Use cases: strategic bodies and partnerships <ul><li>e.g. in the UK, MLA London, Renaissance North East,  the Great Fire o...
Use cases for third parties <ul><li>Build a timeline of renaissance art and artists fed with details of artworks from EDL ...
Sharing data and functionality <ul><li>Web Services, SOAP </li></ul><ul><ul><li>Infrastructure, data exchange, intra-organ...
The UK sector's view <ul><li>MCG list discussion </li></ul><ul><li>Role and purpose of EDL </li></ul><ul><li>Barriers to e...
MCG suggestions <ul><li>based on established metadata models/standards/schemas that allow multiple sources and minimise da...
The shape of an API: functionality 1 <ul><li>Catalogue data access </li></ul><ul><li>catalogue data search, parameters to ...
Functionality 2 <ul><li>User data access and editing </li></ul><ul><li>requires authentication of agent accessing the API ...
Functionality 3 <ul><li>User data management </li></ul><ul><li>authenticated access for agent. Server-side access only? </...
Functionality 4 <ul><li>Collection data management </li></ul><ul><li>Ingest, update </li></ul><ul><li>Rights management </...
Technology suggestions <ul><li>Characteristics </li></ul><ul><li>Light </li></ul><ul><li>Simple </li></ul><ul><li>Consumab...
What else can EDL offer? <ul><li>My half-baked ideas: </li></ul><ul><li>A PURL service. </li></ul><ul><li>A registry of mu...
Upcoming SlideShare
Loading in …5
×

Europeana WP3 API Presentation: Paris 4/3/2008

731 views
665 views

Published on

Kicking off a discussion of the merits of an API for the EDL project.

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
731
On SlideShare
0
From Embeds
0
Number of Embeds
21
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Europeana WP3 API Presentation: Paris 4/3/2008

  1. 1. Europeana and the case for a public API Jeremy Ottevanger, Museum of London and Leicester University
  2. 2. Why an API? The business case pt. 1 <ul><li>How Europeana gains </li></ul><ul><li>Increased participation </li></ul><ul><li>Preparation for the Semantic Web/Web 3.0 </li></ul><ul><li>Increased use – centralisation is not the only answer </li></ul><ul><li>A bigger brain and deeper pockets </li></ul>
  3. 3. Why an API? The business case pt. 2 <ul><li>How museums, libraries and archives gain </li></ul><ul><li>Use of our own data, our own way </li></ul><ul><li>Functionality we can’t provide ourselves </li></ul><ul><li>Dissemination of their data via third parties </li></ul><ul><li>Their content, socially situated </li></ul><ul><li>Management of and access to </li></ul><ul><ul><li>Implicit UGC </li></ul></ul><ul><ul><li>Explicit UGC </li></ul></ul>
  4. 4. Use cases for MLAs <ul><li>Search own catalogue in entirety within and IFrame (HTML output) </li></ul><ul><li>Embed search results in page with AJAX or JSON </li></ul><ul><li>Search subset (a &quot;collection&quot;) within their catalogue </li></ul><ul><li>Map a set of themed objects </li></ul>
  5. 5. Use cases for MLAs (cont.) <ul><li>Mash the EDL record with shop information </li></ul><ul><li>Integrate EDL content with site search in multiple languages </li></ul><ul><li>In the teaching resources section of the site, pull out 6 specific objects or a set of KS3 items to accompany a worksheet </li></ul>
  6. 6. Use cases: strategic bodies and partnerships <ul><li>e.g. in the UK, MLA London, Renaissance North East, the Great Fire of London Partnership </li></ul><ul><li>Combine all London museums for a cross-Hub search </li></ul><ul><li>UK-wide listings of content for KS1, 2, and 3 </li></ul><ul><li>Show all items and related people associated with the Great Fire of London,1666 </li></ul>
  7. 7. Use cases for third parties <ul><li>Build a timeline of renaissance art and artists fed with details of artworks from EDL </li></ul><ul><li>Local history society shows a listing and map of museums and archives holding material tied to Slough </li></ul><ul><li>Coins and medals collectors' site mashes up reference material from the Celtic Coins index with object records from EDL </li></ul><ul><li>The Universit à di Ferrara integrates palaeolithic tools from EDL into their course materials </li></ul><ul><li>Flickr, VLEs.... </li></ul>
  8. 8. Sharing data and functionality <ul><li>Web Services, SOAP </li></ul><ul><ul><li>Infrastructure, data exchange, intra-organisation </li></ul></ul><ul><ul><li>Complicated, losing ground? </li></ul></ul><ul><ul><li>“direct to Web 3.0” mode </li></ul></ul><ul><li>Social Web/Web 2.0 </li></ul><ul><ul><li>Light tech, relatively easy </li></ul></ul><ul><ul><li>An API is just an interface – you can embed semantics in a web page </li></ul></ul><ul><ul><li>Rapid growth – APIs and platforms </li></ul></ul><ul><ul><li>Community development </li></ul></ul><ul><ul><li>....and still a step towards Semantic Web </li></ul></ul>
  9. 9. The UK sector's view <ul><li>MCG list discussion </li></ul><ul><li>Role and purpose of EDL </li></ul><ul><li>Barriers to entry and to aggregation </li></ul><ul><li>The API question... </li></ul>
  10. 10. MCG suggestions <ul><li>based on established metadata models/standards/schemas that allow multiple sources and minimise data loss. </li></ul><ul><li>feature most of the functionality that can be accessed from the back-end </li></ul><ul><li>T&Cs requiring that UGC be flexible enough to allow any reuse with attribution </li></ul><ul><li>API key for differentiated access to services </li></ul><ul><li>enable “crowd-sourced” user-generated metadata </li></ul><ul><li>lightweight: REST, XML, RSS, JSON </li></ul>
  11. 11. The shape of an API: functionality 1 <ul><li>Catalogue data access </li></ul><ul><li>catalogue data search, parameters to include anything used on the Europeana site, e.g. </li></ul><ul><ul><li>GUID </li></ul></ul><ul><ul><li>date </li></ul></ul><ul><ul><li>name </li></ul></ul><ul><ul><li>related person </li></ul></ul><ul><li>GIS mediating layer for location-based search </li></ul><ul><li>related event </li></ul><ul><li>categories, subjects, themes </li></ul><ul><li>UGC-centred search (presumably largely around tags) </li></ul><ul><li>curated sets, including mediating content </li></ul><ul><li>translate </li></ul><ul><li>compare </li></ul><ul><li>rights management data </li></ul>
  12. 12. Functionality 2 <ul><li>User data access and editing </li></ul><ul><li>requires authentication of agent accessing the API by key or domain name. Server-side access only? </li></ul><ul><li>registration/login of user (OpenID?) </li></ul><ul><li>view core user profile. Cannot edit core data (managed directly in Europeana) </li></ul><ul><li>view and add/edit catalogue-linked data for a user – specific to the catalogue owned by that key-holder? Tags, descriptions and notes, groups </li></ul><ul><li>view and edit uploaded content for a user </li></ul>
  13. 13. Functionality 3 <ul><li>User data management </li></ul><ul><li>authenticated access for agent. Server-side access only? </li></ul><ul><li>manage and report on collected user data related to the organisation’s collections, by object/collection etc. rather than user. </li></ul><ul><li>Statistics on implicit and explicit UGC – search patterns, tags, favourites, etc. </li></ul><ul><li>Needs a GUI too! </li></ul>
  14. 14. Functionality 4 <ul><li>Collection data management </li></ul><ul><li>Ingest, update </li></ul><ul><li>Rights management </li></ul><ul><li>Aggregations, collections </li></ul><ul><li>Thesauri, taxonomies </li></ul><ul><li>Server-side only </li></ul><ul><li>Hey, we might actually want formal web services here… </li></ul><ul><li>… but this is definitely the domain of another work group! </li></ul>
  15. 15. Technology suggestions <ul><li>Characteristics </li></ul><ul><li>Light </li></ul><ul><li>Simple </li></ul><ul><li>Consumable server- or client-side. </li></ul><ul><li>Well-supplied with ready-rolled scripts and code snippets </li></ul><ul><li>Compatible with established metadata standards, but ideally not only sector-specific ones </li></ul><ul><li>The recipe </li></ul><ul><li>REST </li></ul><ul><li>XML and JSON </li></ul><ul><li>XML flavours might include RSS/Atom, geoRSS, CDWALite, XHTML with microformats, SPECTRUM for XML, OAI-PMH built around DC </li></ul><ul><li>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. </li></ul>
  16. 16. What else can EDL offer? <ul><li>My half-baked ideas: </li></ul><ul><li>A PURL service. </li></ul><ul><li>A registry of museums’ online presence </li></ul>

×