• http://infteam.jiscinvolve.org/2009/11/03/part-1-of-2-report-on-depost-deposit-tool-show-tell-meeting-2009-12-10/
• http://infteam.jiscinvolve.org/2009/11/03/part-2-of-2-evaluation-of-the-deposit-tool-show-and-tell-features-and-flows-of-deposit/

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.

Notes about features of a repository deposit tool for learning materials