Discovery

update from Joy Palmer

Over the last couple of months we’ve been meeting regularly to firm up our approaches for the case studies and supporting guidance materials (‘we’ being me, David Kay, Owen Stephens, Jane Stevenson, Adrian Stevenson, Diana Massam, and more recently Ed Bremner from UKOLN). We’re also committed to running a series of workshop events from May through to September, so there’s been lots of discussion of who we’re targeting and what we want to achieve in all of this.  We’ll be saying more soon about the case studies, but in terms of guidance materials and workshops, here’s what we’re thinking so far:

Guidance materials

The Discovery key ‘themes’ are the cornerstone for the case studies and also all guidance materials:

• Adopting open licensing – guidance
• Establishing reasonable terms and conditions
• Using easily understood data models
• Deploying persistent identifiers/URIs
• Implementing (and using) APIs
• Establishing data relationships (interoperability/standards)
• Optimising content for discovery via the web
• Ensuring data is sustainable
• Collecting data to measure use

We have all agreed that these materials are not ‘how to’ guides, but guidance for the libraries, museums and archives sector on how to get started, questions to ask, as well as demystification/ explanation of key concepts for educated but non-technical audience (to boost confidence in decision-making).

We’ll will need to get the balance right – not assuming too much knowledge, but at the same time not patronising our audience.  They’ll be available in a variety of formats, including text guides, multimedia clips, examples from the case studies, and links to relevant sources (especially those created by UKOLN and CETIS).

As we create content and plan for the workshops we’re thinking about what questions audiences will come with. Here’s a few I prepared earlier – admittedly coming from my own experience:

What’s a persistent URI? How is this different to a URL? What does ‘persistent’ mean? How is this different to a unique URI? A cool URI? Why does it matter if my API is RESTful? Why is it better than Z39.50? My developer/systems provider tells me X API is better, but we’ve been using X for years – which is right?

Right now, Adrian Stevenson is developing the first sample ‘overview guide’ for us to look at and refine as a standard approach (probably on APIs).  The information for each will include:

Definition and context

e.g: What do we mean by an API? What are some examples? Are all APIs made equal?

 e.g. What do we mean by an ‘identifier’?

Common misconceptions/assumptions (evidence from our discussion shows we’ll have our work cut on on this one when it comes to defining an ‘identifier’)

Why does it matter? This will tie back to local and perhaps broader business cases and drivers.

What might this mean for you and your institution? Here we’ll link back to the case studies and examples, and also provide questions for people to use to assess their own contexts and inform ‘next step’ decisions.

Workshop Approaches

We’re thinking of running three workshops twice:

1. A Licensing Clinic
2. Making the most of your data on the web
3. An ‘Un’ developer hands-on development event (Awful title, I know. Bear with me here, and read on – this is where we could use some feedback)

Each workshop will be designed to provide attendees with a stronger background knowledge, help them ask the right questions, and complete a plan to tackle them.

The Licensing Clinic will work to demystify the differing licensing types, and discuss tactics institutions can take in making licensing decisions. We know that based on the success of the OKFN recent workshop there is a real appetite for this type of content, but we hope Discovery’s will be different in its focus on practical action plans – the ‘clinic’ approach.

The ‘Un’developer event? This workshop idea is less well-formed in our heads – both in terms of audience and objectives. But its emerged as an idea after quite a bit of discussion and our collective hunch that there is a community out there of ‘tech savvy web enthusiasts’ who aren’t professional developers/programmers, but who can do a lot for their organisation in terms of implementing change to enhance web discoverability (and already do). They are often responsible for their institution’s website, for example. Their job descriptions don’t say ‘programmer’; but every so often they write some sort of script to make things work; they may have tried mashing data or working with yahoo pipes or google APIs.  They might use Code Academy, but they’re perhaps not confident enough to post to stackoverflow.com.  We know a good proportion of the institutions we’re addressing through Discovery simply don’t have access to technical programmers – even system support can be a real challenge to secure.  But out there are a lot of individuals figuring out the web side of things themselves and getting on with it.  We want to figure out if by supporting this group, we can help embed some of the Discovery technical principles on the ground.

Sidenote: This is not all to say we’re not going to be doing anything specifically for developers.  Quite the contrary.  Other hack events are going to be planned in collaboration with DevSCI later on this year.

—-

So feedback is very welcome — particularly from those who might recognise themselves (or not) in that un-developer group.  Are we onto something here? Let us know your thoughts and questions (comment here, or tweet #ukdiscovery, or email me directly at joy.palmer@manchester.ac.uk)

This entry was posted on Wednesday, February 1st, 2012 at 5:33 pm and is filed under Joy Palmer. 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.