OpenCulture

Some of you may be aware that the Collections Trust is mid-way through rolling out the Culture Grid, a new service which brings digital content produced by museums, archives and libraries to a mainstream audience via services like Google, Flickr, Wikipedia and the BBC.

More information about the Culture Grid - what it is and how it works - is online on the Collections Trust’s YouTube channel at:

http://www.youtube.com/user/CollectionsTrust

The development of the Culture Grid has now reached the point where we have to decide whether to require services that want to make use of Culture Grid content to sign up for an API key - a unique key which essentially ‘registers’ them as a service that draws content from the Culture Grid.

Why would we want to register them? Well, it gives us a connection, and ultimately opens up the possibility of tracking their services and how they are making use of the Culture Grid. This could provide us with valuable insight - not only for our own purposes, but also to feed back to organisations that are contributing content to the Culture Grid.

Why wouldn’t we? It kind of goes against the principle of ‘openness’ (although some, like UKOLN’s Paul Walk question whether this is really the case). The ideal model, in some ways, is for anyone, from anywhere to be able to ‘consume’ Culture Grid data without hindrance or login - the better to encourage an active development community repurposing the content into new services and platforms.

I posed this question ‘to key or not to key’ on my Twitter account the other day and got a fantastic response, of which a digest is provided below. What I’d like to do now is open out the debate - We’re planning to build APIs based around existing industry standards such as SRU (1) and OAI-PMH (2) and also to build on APIs provided by infrastructure software components such as SOLR (3)”

(1)    http://www.loc.gov/standards/sru/specs/search-retrieve.html
(2)    http://www.openarchives.org/OAI/openarchivesprotocol.html
(3)    http://wiki.apache.org/solr/IntegratingSolr

Do you have any needs that can’t be fulfilled by these? Do you run a service based on this or other approaches? What is your view on the relative merits of controlling access to API?

Your responses will decide our policy, and ultimately how ‘openly’ we can make collections data available from museums, archives and libraries. Tell us what you think!

Here are the responses to my Twitter enquiry (anonymised to protect the innocent):

ORIGINAL MESSAGE: To key or not to key? Should the Culture Grid require an API key, or ditch it to be more open (but risk losing all that lovely usage data)?

• I went for no key for initial Sci Museum API for Cosmic Collections competition - for this qual more useful than quant feedback

• UKOLN had a Good APIs project which covered best practices based on developers advice. @mariekeguy can give u link

• Ah. Therein lies the rub for us also. I’d say prioritise grabbing usage data, but cater for openness as much as possible too.

• Key, I think. At least for now. Better to understand usage n stuff.

• we’ve developed one for Magic Studio, can find out effort for you if you like?

• Probably not. You’re thinking about all the same issues we are. Openness vs concentration of data, as @LorcanD would say.

• …but make the key autogenerated and easy to get to, Yahoo! style. No “wait for authorised email” stuff. That pisses devs off

• keys are useful if you need control or to limit rate of usage, but overhead to manage. RESTful stats poss, talk to Marieke Guy?

• a propos of concentration and openness et al see interesting @andypowe11 pres http://bit.ly/3hQtAI

• re good API design, http://tr.im/Cfa1 links to excellent post from Alex-from-Migratr’s on developer friendly webservices http://tr.im/Cfaf

• not clear why an API key requirement precludes ‘openness’. Suggest you go with keys if you can bear the management burden

• Good APIs project blog, which @mariekeguy led, is at http://blogs.ukoln.ac.uk/good-apis-jisc/

• Yes @andypowe11’s slides shld be required reading for ppl like me inheriting the ‘JISC IE’ services. Excellent. But..

• or use 3rd party to cope with traffic / management overhead, ie. Guardian with http://www.mashery.com/

• argument also for concentrataion and scaling up needs to surface too. Fewer compelling voices there.

• API key OK I think, but pref not tied to specific app or domain.

• cd make key optional but incentivise usage by offering developers stats on their own usage

And, as a side-thread, the following:

• @NickPoole1 I trust you are also giving due thought to the design of your URIs? eg http://bit.ly/asc11 :-0

• I quite like DOIs - not sure about the rest of the world though? @ostephens probably has an opinion?

• DOIs still divide opinion. Why have a DOI when you can have a URI etc. Same old arguments

That’s what Twitter had to say. What do you think!?

This entry was posted on Thursday, October 22nd, 2009 at 1:24 pm and is filed under Consultation, General, Grid, Linked Data, Nick Poole. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.