One of the aims of the day was to attempt to scope some usecases for the JLeRN Experiment, while the technical developers were discussing the implementation of the node and exploring potential development projects. We didn’t exactly come up with usecases per se, but we did discuss a wide range of issues. JLeRN are limited in what they can do by the relatively short timescale of the project, so the list below represents issues we would like to see addressed in the longer term.

Accessibility

The Learning Registry (LR) could provide a valuable opportunity to gather accessibility stories. For example it could enable a partially-sighted user to find resources that had been used by other partially-sighted users. But accessibility information is complex, how could it be captured and fed into the LR? Is this really a user profiling issue? If so, what are the implications for data privacy? If you are recording usage data you need to notify users what you are doing.

Capturing, Inputting and Accessing Paradata

We need to consider how systems generate paradata, how that information can be captured and fed back to the LR. The Dynamic Learning Maps curricular mapping system generates huge amounts of data from each course; this could be a valuable source of paradata. Course blogs can also generate more subjective paradata.

A desktop widget or browser plugin with a simple interface, that captures information about users, resources, content, context of use, etc would be very useful. Users need simplified services to get data in and out of the LR.

Once systems can input paradata, what will they get back from the LR? We need to produce concrete usecases that demonstrate what users can do with the paradata they generate and input. And we need to start defining the structure of the paradata for various usecases.

There are good reasons why the concept of “actor” has been kept simple in the LR spec but we may need to have a closer look at the relationship between actors and paradata.

De-duplication is going to become a serious issue and it’s unclear how this will be addressed. Data will need to be normalised. Will the Learning Registry team in the US deal with the big global problems of de-duplication and identifiers? This would leave developers to deal with smaller issues. If the de-duplication issue was sorted it would be easy to write server side javascripts.

Setting Up and Running a Node

It’s difficult for developers to find the information they need in order to set up a node as it tends to be buried in the LR mailing lists. The relevant information isn’t easily accessible at present. The “20 minute” guides are simple to read but complex to implement. It’s also difficult to find the tools that already exist. Developers and users need simple tools and services and simplified APIs for brokerage services.

Is it likely that HE users will want to build their own nodes? What is the business model for running a node? Running a node is a cost. Institutions are unlikely to be able to capitalise on running a node, however they could capitalise by building services on top of the node. Nodes run as services are likely to be a more attractive option.

Suggestions for JISC

It would be very useful if JISC funded a series of simple tools to get data into and out of JLeRN. Something similar to the SWORD demonstrators would be helpful.

Fund a tool aimed at learning technologists and launch it at ALT-C for delegates to take back to their institutions and use.

A simple “accessibility like” button would be a good idea. This could possibly be a challenge for the forthcoming DevEd event.

Nodes essentially have to be sustainable services but the current funding model doesn’t allow for that. Funding tends to focus on innovation rather than sustainable services. Six months is not really long enough for JLeRN to show what can really be done. Three years would be better.

With thanks to…

Sarah Currier (MIMAS), Suzanne Hardy (University of Newcastle), Terry McAndrew (University of Leeds), Julian Tenney (University of Nottingham), Scott Wilson (University of Bolton).

JLeRN / UK Contributors Learning Registry Hackday

The aim of this proof of concept project is to explore the practicalities of configuring and running a Learning Registry node and to explore the practicalities of getting data in and out of the network. The team are actively seeking any technical developers who would like to experiment with the node and, in order to facilitate this collaboration, CETIS and JLeRN are hosting a technical development day in Manchester on the 23rd of January. This event is aimed at developers contributing (or intending to contribute) data to the Learning Registry or hoping to build services based on the data it provides access to.

If you are interested in attending this event, you can register here. If you’re hoping to come along please also add a note to this Google Doc about what you’re doing, or hoping to do, and any of the issues you’ve encountered so far. If you can’t come along but are interested, please comment / leave a note as well.

JLeRN Blog

The JLeRN Experiment team have a blog (jlernexperiment.wordpress.com) up and running which they will use to disseminate regular progress reports, or as Sarah explained:

“to share all of our adventures, mis-steps, solutions, and creative ideas while working on the Learning Registry. It’s open notebook science in action!”

And the team have already been as good as their word. Nick has written a post on the Node of Mimas, a test node he installed on “a spare machine (he) had lying around” along with samples of the JSON documents the node outputs to illustrate what Learning Registry data looks like. And Bharti has posted a note on Some more exploring… which mentions the challenges of establishing a test node on a Windows Server 2008 machine and issues with getting Nginx setup correctly.

In parallel with the JLeRN experiment, CETIS will also continue to maintain a watching brief on the Learning Registry initiative in the US and will post updates of relevant developments on the CETIS blogs, so watch this space!

Mimas being one of the moons of Saturn obviously….

http://totallylookslike.com/2008/09/05/mimas-totally-looks-like-the-death-star/