At the CETIS conference this year, Lorna organised a session offering Roundtable about technical issues facing projects engaging with Open Educational Resources – as most of the attendees were drawn from the UKOER programme. Although there will doubtless be more refined versions of this list I’ve created a first pass of the issues. The full list is on slideshare: http://www.slideshare.net/RJohnRobertson/cetis09-oer-technical-roundtable . The tweets from the session are on http://twapperkeeper.com/Cetis09find/. The issues list is probably more usable via slideshare but to give an impression:
The morning sessions a the recent JISCRI deposit tools show and tell meeting in London (DepoST) offered a whirlwind of elevator pitches for the many existing repository deposit tools. Details of the tools from the pitches have been neatly captured by David Flanders on the JISCinvolve blog.
In the midst of the afternoon sessions there where a few of us with an interest in learning materials (and particularly Open Educational Resources) who had a think about what might be different about a tool for depositing learning materials in a repository (Rory McNichol, Richard Davies, Julian Tenney, Pat Lockley, Phil Barker, J.M.Gray, Antony Corfield and myself). In our discussions we didn’t talk that much about mechanisms but focused more on the features that such a tool might require. [Subsequently Phil has blogged an inital view on the possible deposit/ harvest mechanisms http://blogs.cetis.org.uk/philb/2009/10/28/feed-deposit/ – his post is about the questions we need to address now; this post and our discussions on the day looked at the what next question]
Our short list of possible differences centered, not on technical diferences as much on the importance of context. In particular the context of the use of the learning material. We thought that future developements should look not only at the deposit of a learning material but also consider the ongoing ‘deposit’ of usage information in some form- allowing the repository to gather feedback about the resource. From this point, it’s fair to say that our conception of a deposit veered somewhat towards including elements of a repository interface (tool or otherwise) that would allow discovery and ongoing data excahnge about a learning material. As such the following isn’t so much of a requirements specification as a trying to pin down information from the user or other systems that would help improve how learning materials are managed and accessed.
Our shortlist of key features was:
- richer user profiles both for depositors and users
- resources to include a link to the source/ master object
- import asset plus usage info (such as which courses it’s used for) from VLE
- import asset plus usage info (such as comments and tags) from Web 2 tools
- need support for instituional management and release of assets
Having written this I’m very aware that SWORD works because it’s so simple. Partly this is because putting papers into repositories is, mostly, a one directional technical process [it is of course a much more interactive social/ political / administrative process] and SWORD has been very careful to limit in what it is trying to do. Consequently any work in this area looking to expand the scope of deposit tool/ repository interface functionality should be very cautious in adding mandatory extras. However, feedback and usage information are becoming increasingly important for scholarly communciations and data sets are likely to prove to be much more interactive resources (in a similar way to learning materials) as how they’re being used is key information). In a similar way institutions (as well as authors) are increasingly becoming the creators and/or distributors of resources so the ‘corporate’ deposit interface is likely to become more prominent.
Our discussion created more questions than answers in my mind, but it’s clear that, however deposit tools develop, we’d like them to be able to capture more context, but that this has to be done in lightweight ways that reuse rather than recreate information – we’ve had complex standards that ask for this type of information for a while but we have always asked users to input it.
Our full discussion is pictured below.
A few quick items of interest form the web this week. Two offer a perspective of the process of making standards (looking at OAI-PMH); another is an interview with Brian Lamb reviewing the history of Learning Object Repositories.
Talking to DC [Washington] (Adam Bosworth, Adam Bosworth’s Weblog)
In a post based on his experiences with standards development, Adam outlines seven guidelines for good standards development
- Keep the standard as simple and stupid as possible.
- The data being exchanged should be human readable and easy to understand.
- Standards work best when they are focused.
- Standards should have precise encodings.
- Always have real implementations that are actually being used as part of design of any standard.
- Put in hysteresis for the unexpected.
- Make the spec itself free, public on the web, and include lots of simple examples on the web site.
Making Standards that Work (Dorothea Salo, The Book of Trogool)
Relfecting on Adam’s post, Dorothea relates some of those principles to her own experience and view of standards development in particular commenting on OAI-PMH.
OAI-PMH is an interesting example because it’s so widely used and, as Dorothea says, so simple. When it works, it works well (even if we might now like to change some of it to be more web friendly). However, metadata sharing works best in defined communities. When OAI-PMH doesn’t work, it’s a mess as frequently it’s the data harvesters who notice but who are dependent on the data providers (and potentially also their technical support) to change anything. Interestingly the OAI-PMH Static repository specification pushed some of the emphasis back onto the data provider – as their base information in xml had to be valid xml before it would be mediated by a gateway (but SRs are a whole other story with lots of potential but their own problems.)
The Sordid History of Learning Object Repositories or, a chat with Brian Lamb (Jim Groom, bavatuesdays)
One of the interesting things about the UKOER programme is how much freedom projects have to choose how they are going to store, describe, manage, and share their resources. They are using a wide variety of approaches, which include repositories, content management systems, and web pages of rss feeds. They’re also using a wide variety of ways to descibe stuff. All of the approaches though are some way from the sort of educational world which the original learning object repositories envisaged and which Brian Lamb reflects on here:
http://bavatuesdays.com/the-sordid-history-of-learning-object-repositories-or-a-chat-with-brian-lamb/. I still think repositories have a lot to offer the management of learning materials but they’re not the only option, are better as part of a wider suite of tools, are really hope they aren’t going to ask users about semantic density. To my mind Brian’s relfections highlight a number of reasons why the UKOER programme is implementation nuetral.
I’ve also realised that I’ve not yet pointed to a related resource from CC Talks about OERs A chat with Stephen Downes on OER http://creativecommons.org/weblog/entry/17860 I was also going to talk about Pete Johnston’s latest installment about Simple Dublin Core but that’ll have to wait for another day (http://efoundations.typepad.com/efoundations/2009/11/simple-dc-revisited.html)