The Learning Registry: Rough Guide for Contributors

Update:  For clarity, this is a piece of documentation for a specific group rather than a “regular” blog post. It may be of wider interest but it makes a number of contextual assumptions…

This document assumes that you have some familiarity with intent of the Learning Registry (LR) and that you are interested in contributing information about your resources. It lists a few things to consider before you get into the detail of the how to guide. More extensive information is available from the Learning Registry document collection. This document draws on that documentation (By US Dept of Ed, SRI International, and others) and feedback from the LR development team. It’s primary audience are those in the UK community thinking about in contributing metadata/ paradata/ resources. It’s intended to help technical managers get a quick overview of the issues in contributing to the Learning Registry test node and forthcoming experimental node at MIMAS.

Preparing your data

The primary purpose of the LR record is to indicate the existence, location, and owner of the resource and related metadata and paradata. The LR allows you to submit full or partial metadata, and to (optionally) include the resource itself as payload. The more metadata you submit, the more discoverable your resources become. It does allow you to optionally include some basic information about resources to support filtering and browsing you can opt to include original records in the data rather than referring to them. The LR does not care what metadata formats you use (though data consumers who discover your information through the LR might…).
Contributors submit/push data about their resources to a node which distributes that data to other nodes in the system. In itself the LR will not harvest/ gather information about your resources, you need to actively contribute it.

However, there are issues of local practice that you may want to consider prior to the process of sharing your data. In particular – how are you identifying your resources (e.g. does it have a cool uri? and how are you exposing any usage/activity data which you have about those resources (the paradata format developed alongside the learning registry might be useful).

Mechanisms for LR deposit

Contributors have to create a signature (OpenPGP key pair) for themselves on the LR (anonymous contribution is not permitted). This is a relatively simple self –registration process and will let users interact with the LR test node. However, contributors should note that to contribute to the live LR they will need an agreement with a given live node which has opted to accept their signed data.

The LR uses JSON rather than xml and offers a number of approaches to publishing data, these are:

Policy and License Issues

Please note the LR requests that any data you create or publish to the LR is clearly licensed. A Creative Commons Zero (CC0) or Attribution (CC: BY) licence are good options [Reccommended by both the Learning Registry, JISC, and UK Discovery]. You should ensure that you have the rights to assign this licence if it not already assigned and that the data you publish conforms with appropriate data protection and privacy laws. whatever data you submit to the LR is likely to move between legal jurisdictions.

Creative Commons Licence
The Learning Registry: Rough Guide for Contributors by R. John Robertson is licensed under a Creative Commons Attribution 3.0 Unported License.

JISC and MIT: comparing notes on ed tech

A few weeks ago I had an opportunity to join a conversation between JISC and MIT OEIT ( to exchange information about current initiatives and possible collaborations. The general themes of the conversation were openness and sustainability. There was an agreed sense that, currently, “Open is the new educational tech” (Vijay). The areas of strategic interest, competencies, and knowledge of open institutes are now central to much educational development. JISC’s work in many diverse areas has contributed to the growth of openness both the successive programmes of work connected to repositories (including the cultivation of developer happiness) and more recently the JISC and HEA OER programme.

Vijay outlined some of the thinking that MIT OEIT are doing around innovation and sustainability outlining where they fit in that cycle and the limiting dependencies of innovation. In a four stage innovation cycle. MIT OEIT are mostly involved in the initial incubation/ development phase and the early implementation phase. They’re not in the business of running services but they need to ensure that their tools are designed and developed in ways which are congruous with sustainability. One key point in their analysis is that the limiting factor for innovation is not your organisational growth (whether the size of the project, design team, or facilities) but the growth of nascent surrounding communities in other parts of the value chain.

As a result, MIT have found that sustainability and embedding innovation isn’t just about more resources it’s about basic design choices and community development. Openness and open working allows the seeding of the wider community from the outset and allows a project to develop competencies and design skills in the wider community). This resonates with some of observations made by OSS Watch and Paul Walk. We then discussed the success of the Wookie widget work carried out by Scott Wilson (CETIS) and how that has successfully developed from a JISC project into an Apache Foundation incubator

The conversation continued around the tech choices being made in the UKOER programme noting the strength in the diversity of approaches and tools that have been in use in the programme and the findings that appear to be emerging- there is no dominant software platform, choices about support for standards are being driven, in part, by the software platforms rather than a commitment to any standard. [I’ll blog more on this in January as the technical conversations with projects are completed]. We also noted upcoming work around RSS and deposit tools taking place both following on from the JISCRI deposit tools event and emerging from the UKOER programme [see Jorum’s discussion paper on RSS for ingest]

Brandon then highlighted the SpokenMedia project ( creating tools to automatically transcribe video of lectures both for to enable better search and to make materials to be more accessible and scannable. The tools achieve up 60% base accuracy and are trainable up to 80% accuracy. MIT hope this will make lecture video significantly more browseable and are exploring the release of an api for this as an educational service.

We then discussed some projects working in areas that support bringing research data into curriculum. MIT have a series of projects in this area under the general name of STAR ( which provide suites of tools to use research data in the classroom. One successful implementation of this is STARBioGene allows Biology students to use research tools and materials as part of the core curriculum. Some of the STAR tools are desktop applications and some are cloud-based, many have been made open source.
The wider uptake of the project has contributed to the development of communities outside MIT who are using these tools – as such also it’s an example of growing the wider uptake community outlined in their innovation cycle. One consideration that it has raised about communities of use is that some of the visualisation tools require high performance computing (even if only needed in small bursts). The trend toward computationally intensive science education may create other questions of access beyond the license.

Another interesting tool that we discussed was the Folk Semantic Tool from COSL at Utah State University: on the one hand it’s another RSS aggregator for OERs, on the other, for users running Firefox and Greasemonkey it’s a plugin to add recommendations for OERs into any webpage (which runs off a single line of javascript).

MIT: M.S. Vijay Kumar & Brandon Muramatsu JISC: David Flanders, John Robertson (CETIS)

From the web: tools for project management and how to contract developers

Over on the IE blog Andy McGregor has a useful annotated list of some of the online tools that he has used to help with programme management.

Many could be just as useful projects – distributed or not.

On a related note David Flanders has a useful and extensive reflection and how to guide on contracting out software development.

Upcoming CRIG unConference

At the end of this week JISC’s Common Repositories Interfaces Group (CRIG) are holding a two day meeting to look at the key scenarios affecting repository interfaces.

Our discussions for the two days are going to build on a series of teleconferences organised by the CRIG support project – WoCRIG which have just been podcast. I’m both excited about this meeting and a little nervous.

I think that the support project are doing a good job of stirring us up to move forward the work of CRIG and helping us engage with and shape the next stages of repository interface interoperability. For the next stage of this work, this meeting, they’ve organised an unConference. Two days of informal thinking, discussing, and getting at the core of the interoperability issues related to repositories. I’m looking forward to it for what I know I’ll learn, for the chance to contribute, and for the chance to actually just have time to sit down and talk about these things.

The nervousness on my part comes from the unknown – I’ve never been to an unConference before and although the idea is good – to have discussions about what people want to talk about and to cut out the fairly predictable presentation part of a meeting and so to get at the eureka moments that usually happen alongside but not actually in conferences – I’m aware of how much, for me, those eureka moments come along because I’ve been sitting for extended periods of time for my mind to go off at tangents while half listening to a presentation which may or may not be relevant to my thoughts.

Anyway I guess it’s a bit like a codebash for ideas – and that’s no bad thing.