FrontPage

Helping GLAMSs / cultural heritage organisations make content re-usable; helping programmers access cultural and historic content through open cultural data

 

Hello!  You're probably here for:

• museum, gallery, library and archive APIs and machine-readable data sources for open cultural data

•  cool stuff made with cultural heritage APIs

• making good APIs...

 

If you have some free time, the list of APIs needs to be tidied up a bit, and open cultural data releases (such as images online) could be put on a separate page - feel free to dive in and help out!

 

This started as a site for sharing, discussing, arguing (nicely) over and hopefully coming to some common agreements on APIs and data schemas for museum collections in the UK or worldwide but these days most of that content is retained purely for historical purposes. We've also had great discussions on Broadening hack days and problems open data could fix - join in! The #lodlam hashtag on twitter often has interesting links and conversations, as does #musetech.

 

Event history (going back to the 2010s)

Broadening Hack Days meetup

 

LOD-LAM London meetup

 

LOD-LAM (Linked Open Data for Libraries, Museums and Archives), San Francisco, June 2-3: LOD-LAM live blog

Session notes for: LOD-LAM microdata and schema(dot)org ;

LOD-LAM crowdsourcing, annotations and machine-learning

LOD-LAM Messy data and same-as

LOD-LAM crowdsourcing session notes

 

 

Linking Museums III - working with 'people' records

 

Notes from Linking Museum II meetup from London, September 27, 2010
Notes from the first Linking Museums write-up from the first 'Linking museums: machine-readable data in cultural heritage' meetup.

 

LODLAM-London October 6 (with Open Knowledge Foundation)

 

 

About

A note on definitions - this is about access to and re-use of cultural heritage data.  I'm pretty acronym agnostic, and apart from the resources required to re-write output scripts, I don't think acronyms compete.  Wikipedia defines 'API' (application programming interface) as "a set of functions, procedures, methods or classes that an operating system, library or service provides to support requests made by computer programs" - there's some discussion of implementation formats on the wiki if you want to dive in.  I find the navigation on wikis a bit annoying: here's a link of all the pages in this wiki so you can get a good overview of what's on the site.

 

If you want to get in contact, try @mia_out on twitter (unless your account is restricted, of course), or get my email address from the register your interest page.  Or just leave a comment somewhere appropriate!

 

What you can do - if you work in a museum

Any or all of these would be useful:

• Upload or copy and paste some examples from your collections data schemas - whether that's nicely marked up xml, a table structure from the databases that feed your website, even plain old HTML from an online page.
• Link to your API
• List the functionality of your API (through documentation, examples, whatever)
• Talk about how you decided how to implement your API
• Share your questions, unresolved issues
• Explain the project to your collections documentation people, and ask for their help
• Subscribe to the 'recent changes' feed, and pop in when you see something that interests you

 

What you can do - if you are a developer

• Try any of the APIs listed, report back - was it useful, could it be made more useful?
• Tell us what do you look for in an API, or link to APIs you think are done really well
• Subscribe to the 'recent changes' feed, and pop in when you see something that interests you

 

I'm not terribly sure how to organise a discussion like this, so I'm open to suggestions.  I'd also like to see some collections people contributing so feel free to invite non-technical people.

 

Please feel free to edit pages or add any stuff that you think might be of use.  If commenting feels more natural than editing a page, go for it.