The Hackday: Report and Reflections

The JLERN Experiment and JISC CETIS co-organised a Learning Registry Hackday on January 23rd 2012, hosted by Mimas at Manchester University. Lorna Campbell from CETIS has already written a great blog post (which now includes some excellent discussion below the line) summarising some of the issues that were discussed.

I wanted to report from a JLeRN point-of-view what happened at the Hackday, and what we got out of this event. Our aim was to get the UK folk who were already doing stuff around the Learning Registry in a room with those who were starting to think about doing stuff, to talk about use cases. And we wanted to get some technical people in a room with the JLeRN developers to play around with publishing and accessing data through the JLeRN node.

Before JLeRN started CETIS were already on the case in forming a community of interested folk in UK HE. And Pat Lockley, when he was still at Nottingham University (he’s now at Oxford University), attended the first ever Learning Registry Plugfest in the US (see his report here). So we had a room full of early adopters and experts in the Learning Registry, alongside some new folk with great ideas.

Plan for the Day

We started the day with a blissfully brief presentation session, just an hour long before lunch. Lorna Campbell gave us an overview of the Learning Registry and JISC’s involvement with it. I talked everyone through what JLeRN is doing, with the help of this handout, which summarises some of the options from the Learning Registry specification: Communities, Networks, Nodes.  John Robertson of CETIS finished with an introduction to paradata.

After lunch everyone introduced themselves and what their interest in the Learning Registry was. This was where some interesting ideas and use cases started to emerge.

One Outcome: Concrete Proposals to JISC OER RI Funding Call

It also became apparent that several participants were intending to submit project proposals involving JLeRN and/or The Learning Registry to the JISC OER Rapid Innovation funding call. As it turned out, four proposals (that we know of) that were discussed here were submitted; we won’t know whether any of them were funded until March, but it was great to get so much concrete interest out of the day.

Who Came and What They Said

CETIS’s Scott Wilson was there; he was interested in the Learning Registry from the point of view of a project he’s involved in, which is developing “a Widget Store aimed at the UK education sector using a codebase shared across and sustained by a range of other EU projects and consortia”. Scott wanted to see if the Learning Registry could offer solutions for sharing paradata about educational widgets.

With our proximity to the national learning resource repository Jorum, also based at Mimas, we were delighted to see Ben Ryan, the new Jorum Technical Manager, and Steven Cook, one of Jorum’s developers. Jorum has a great interest in usage data and other forms of paradata, and had been promising to share data with JLeRN from the start. This event turned out to be an excellent opportunity for their new technical manager to get up to speed. Plus, Steven Cook, who is working on a framework and dashboard for Jorum usage stats, was inspired to start developing ways to get that kind of data out of Jorum, together with resource metadata, and into a Learning Registry node. Watch this space: Steven will be blogging here!

Tatiana Novoselova and Andrew Green came from the University of Liverpool, bringing with them lots of experience and ideas around sharing data about engineering learning resources. They had already been trying to grapple with the Learning Registry, and found the Hackday helpful in ironing out some technical issues they had been having, partly thanks to Pat Lockley’s presence and support, and partly thanks to the JLeRN technical team. They reported here.

Terry McAndrew came from JISC TechDis, with some great ideas about how the Learning Registry might allow the educational content community to finally start getting some traction on how to usefully share information about accessibility of resources. It’s always been very difficult to get metadata standards to accommodate accessibility data, which is often, basically, about a user’s experience of a resource, or about the features of a resource as they relate to a user’s individual requirements. Lorna’s post summarises this discussion.

Suzanne Hardy and John Peterson came from Newcastle University, full of ideas from the more complex end of the paradata spectrum: their Dynamic Learning Maps as educational context of use / curriculum data around resources. Watch this space: I’d like to get some more out of them about their ideas!

Julian Tenney came from the University of Nottingham with some great ideas about gathering good paradata from users via the Xerte content authoring tools. He felt it important to start to think about ways that content authors and educators will actually be able to contribute contextual data as part of their usual workflow. Another space to watch.

Richard Goddard, formerly of MrCute (Learning Objectivity) and Alastair Hole came from Worcester College of Technology with an idea about developing a tool that will help record actual educational usage of resources (as distinct from merely hits/downloads). Once this data is recorded, wouldn’t it be great to share it via the Learning Registry?

Jenny Gray from the Open University has had an interest in the Learning Registry since before JLeRN, from the point of view of the OU’s LearningSpace, came along and had some fruitful chats with Nick and Bharti, and Pat Lockley, about options for publishing LearningSpace data and paradata in the node. Like Jorum, she’s interested in how to get an OAI-PMH feed into a Learning Registry node. She reported back on her own blog here and followed up with some more thoughts, and questions, on sharing LearningSpace paradata here (to share or not to share?).

Matters Arising

Note: these action points and issues are not a to-do list for JLeRN, or even for the Learning Registry! They are just a note for when future plans are discussed, and for JISC and other stakeholders to take note of.

• We need to more fully develop some concrete use cases. E.g. a simple Accessibility “Like” button that could start to capture accessibility info of use to users.
• We need to develop some demonstrators. E.g. a desktop widget or browser plugin that captures info on user, resource, content, and context of use, with a simple interface.
• We need to think about how we interact with a node to share and call complex paradata (e.g. Dynamic Learning Maps type stuff).
• We need to start defining the structure of paradata for various use cases. E.g. we need to look at the concept of ‘actor’ as currently specified for paradata.
• Note that running a node is a cost, and the JLeRN node will only run for the life of the project (until July 31 2012); need to think about business model and business case for node services; folk can build their own tools and services on top of nodes. People will not feel motivated to start building on something that is still experimental and has an uncertain future.
• Might be an idea for JISC to take a similar approach to developing SWORD: a series of simple tools to put and get data into JLeRN.
• Running a node on Amazon Web services (i.e. on a cloud service) has unpredictable costs; this is not generally liked by UK university finance departments!

Data sources for JLeRN

A final note to ourselves: some excellent suggestions from the floor, and thanks to Lorna for taking these notes!

• Jorum
• Xpert
• OU
• NHS eLearning Repository
• DLM NBBS programme data
• FE Data sources like NLN? XTLearn
• Open Spires podcasts
• Delicious / Diigo
• Merlot
• NDLR

Next Steps

JLeRN are about to attend the Learning Registry session at the CETIS Conference 2012, like, tomorrow. And we are still calling for entries to our Dev8D JLeRN Paradata Challenge (due Friday midday).

After that, we have five months to go until the end of JLeRN. What should we be focusing on? Discussions are ongoing, we’ll report back here, let us know your thoughts!

Alpha node

We installed the JLeRN “alpha” node on our new Ubuntu server on the weekend (Jan 21-22) before the Hackday.  But there was a bug which affected the indexes and thus document retrieval.

The LR developers in the U.S. resolved the bug promptly and we applied the fix on Jan 28th.

The node is here: http://alpha.mimas.ac.uk

The node supports all publish and retrieval services although we haven’t had a chance to test all of these yet.

The node is now open to the world except you need a username and password to publish documents.  The credentials you need to publish are:

Username: fred
Password: flintstone

Give it a go when you have a minute or two.

Examples:
http://alpha.mimas.ac.uk/status
http://alpha.mimas.ac.uk/description
http://alpha.mimas.ac.uk/obtain  [all documents in node, 100 at a time]
http://alpha.mimas.ac.uk/obtain?request_ID=http://dspace.jorum.ac.uk/xmlui/handle/123456789/1000
http://alpha.mimas.ac.uk/slice?any_tags=curve
http://alpha.mimas.ac.uk/slice?any_tags=magnetism

N.B.: The examples above fetch JSON documents.  Install an extension to your favourite browser so you can display the documents in a readable format; e.g., JSONview extension for Firefox.

Curl examples:
$ curl  -v http://alpha.mimas.ac.uk/obtain?request_ID=”http://alpha.mimas.ac.uk/obtain?request_ID=http://dspace.jorum.ac.uk/xmlui/handle/123456789/1000″
$ curl -Xv POST -H “Content-Type:application/json” “http://alpha.mimas.ac.uk/publish” -d @test_data.json -u fred

The Learning Registry Quick Reference Guide has more examples.

Communities, Networks, Nodes: Where to next for the JLeRN Experiment?

NB: I’ve prepared a simplified handout version of this post for the JLeRN / UK Learning Registry Contributors’ Hackday, available on Googledocs to print out or download here.

So what’s this all about again?

Are you feeling a bit baffled by the Learning Registry concept? By the JLeRN Experiment? But excited by some of the possibilities that trickle through the confusion as you start to get a handle on what we’re doing? Join the club.

The Learning Registry project worldwide is starting from a very techie place, and we are only beginning to imagine how that might eventually impact on services for teachers and learners, and the support staff who help them with using resources.

We’ve learned from the mis-steps of years past where we fumbled through if-we-build-it-they-will-come and if-only-someone-would-create-one-uber-repository/portal. We’re focussing on what we’ve been told over and over by educators for years: that recording and analysing and understanding and disseminating and using data about use of learning resources should be at the centre of resource provision and management. We’re calling that data ‘paradata’.

So, how will we, the UK-based JLeRN Experiment, take forward our investigations? We need your feedback. Please read on for options and questions.

The building blocks

The Learning Registry folks have produced some well-written and well-conceived specification documents, which outline clearly the kinds of decisions that different participants (not just JISC) could make at a policy level here in the UK. I will summarise below (a) what we’re doing right now, and (b) what some of the wider options are for implementing Learning Registry nodes, networks and communities.

NOTE: nodes, networks and communities are the three levels of togetherness available to educational communities wanting to share resource data and paradata. We can:

(1) share our data with others via a single node;
(2) widen our sharing to a network of nodes that share the same policies about access etc.; and
(3) widen our sharing even further within communities of networks.

More below!

If you really like to read full specs, check out this openly available Googledoc; it’s the main specification document this post quotes from (it’s very readable as specs go): The Resource Distribution Network Model: Learning Registry Technical Specification.

From that document, here is a visual representation of how Learning Registry nodes, networks and communities relate to each other and to external producers and consumers of data. You may need to refer back to it as you read on.

The Learning Registry Resource Distribution Model Diagram

The JLeRN Experiment at Mimas

So, Mimas was asked by JISC to set up a Learning Registry node and play with it, with help from JISC CETIS and an informal task group of interested folks in UK education, to see what we could learn. That was about all any of us understood about what was needed at that time.

We’ve had a working node at Mimas for some weeks now, which has led to acquisition of skills and understanding for our devs Nick and Bharti, and we are busy getting our node set up on a dedicated server to allow anyone to experiment with getting their data in and out.

We’ve since discovered that there are a number of options for nodes, and there are also possibilities for networks of nodes, and network communities. These are described in more detail further on in this post. We have implemented a common node, without requiring signatures to push and pull data out of the node (in other words without the basic security restriction available). A common node is defined thusly:

“Common Node: A common node MAY provide any of the node service classes listed. If provided, the distribution services of a common node SHALL be limited to connecting to other nodes in the same network (the distribution service MAY connect to multiple destination nodes).”

There’s only one other kind of node: a gateway node.

I bet all that just raised a bunch of questions for you, right? Read on!

Where to from here?

Let’s talk about nodes

Nodes are the building blocks of the Learning Registry. They enable decentralised networks for sharing data about learning resources and their use. Anyone can set up a node wherever they like by installing the node code and making it available to whomever they like*. They can also restrict access if they choose. Those who share data via that node can publish their data to the node, or extract anyone’s data from the node. A completely open node allows literally anyone to publish or access data.

NOTE: There are two kinds of node: common nodes and gateway nodes. Each kind of node supports distinct activities. Basically, a common node can support all the different specific services you need to push, pull, distribute and process resource data with any number of external sources, and within a given network of nodes. A gateway node allows different networks to connect with each other to share data. (Might be an idea to scroll back up and look at that diagram again!).

A common node is defined further up the page, and its possible services in the next section. A gateway node simply provides a data distribution connection between one network and another, because nodes cannot belong to more than one network, and a clearly defined pipeline is needed, for security and other policy reasons.

Until the JLeRN Experiment has some pressing use case for testing a gateway node, we’re working with a common node for now.

What can a common node do?

Common nodes can offer five kinds of service:

• Publish Services allow data to be published to the node from external sources. We can choose which publishing APIs we will support (e.g. SWORD), but we have to (and we do) support the Basic Publish Service. NOTE: we’re talking about how we might get data into JLeRN’s Node at Mimas from a Jorum OAI-PMH feed, which will likely involve some scripting as it’s not provided as part of the core node set-up.
• Access Services allow data to be pulled, or accessed from the node or the distribution network the node is part of. Again, different APIs (e.g. OAI-PMH) can be, but don’t have to be, supported.
• Distribution Services allow data to be replicated and transferred between nodes.
• Broker Services allow us to “augment, transform or process resource data held at that node to produce new or updated resource data for access or distribution”. Interesting!
• Administrative Services, which “are used to query a node to obtain its status or to trigger node administrative actions.”

So: what kinds of services would you like to trial with the JLeRN Experiment? What do you think should be trialled?

Discuss!

Resource distribution networks

You’ll have noted already that common nodes can be part of networks, and that networks can be connected via gateway nodes. When networks are connected, this is called a network community. Here’s what a network (or resource distribution network) is:

“A resource distribution network is a group of one or more connected nodes, with each node providing node services. All nodes in a resource distribution network operate under the same policies. Multiple resource distribution networks MAY be established.”

Important things about networks are:

• Any given node can only be part of one network; the node is subject to the policies of that network. A gateway node is necessary for a common node to connect to a different network.
• Network policies include such things as security requirements for sharing data via nodes in the network, e.g. whether signatures are required, data deletion policies, and so on.
• A network can be part of only one community (so if you want your node to interface with other communities, you’ll need to set up and connect via a gateway node. Again, scroll back up to the diagram!).

So, what about network communities?

Network communities

OK, if you’ve managed to read this far, you can read the specification document definition! It doesn’t really require paraphrasing:

“A network community is a collection of interconnected resource distribution networks. A community MAY contain one or more resource distribution networks. A resource network SHALL be a member of only one community. Gateway nodes provide the connectivity between resources networks within a network community and MAY provide connectivity between networks in different communities. NB: A gateway node that provides an intra-community network gateway is undifferentiated from one that provides an inter-community network gateway.”

The important thing to note about communities is that open communities, known as social communities, and closed communities are both supported.

These are fairly self-explanatory: social communities can connect to each other via gateway nodes to share data. Closed communities only allow sharing between nodes and networks within their own borders. At the moment, the Learning Registry project itself has both kinds. The Learning Registry is a social community, and The Learning Registry Testbed is a closed community for developers to work on the code and the specs.

NOTE: At the moment, we are thinking about setting up a node to be part of the Learning Registry Testbed closed community, but we are, as previously noted, currently only running a node that is not yet part of any network or community, and that we are making available for anyone to test publishing and accessing data with.

So that’s where we’re at! What next?

We’re taking advantage of our proximity to the Jorum repository of open educational resources at Mimas to start exploring data and paradata around Jorum’s stuff, and how these might interact with the Learning Registry to the eventual benefit of Jorum’s users. There will be a blog post soon on the Jorum team blog saying a bit more about that.

We’re hosting a hackday in collaboration with JISC CETIS on Monday 23 January 2012, here at Mimas in Manchester. We’ve got ca 10 people coming from the UK education community, and we’re going to let them at our node to test out whatever folk want to test. We’ll also be brainstorming ideas for the future, use cases, and what the UK HE community wants from the JLeRN Experiment over the next few months. We’ll try to get a few folk tweeting from the event: follow and ask questions via hashtags #learningreg and #jlern  And there will be a blog post or two reporting back.

Then we’re participating in another session with JISC CETIS at their conference in February where we hope to do a bit more talking about ideas and a bit more hacking and some finalising of requirements on the JLeRN Experiment. This session will include a broader view on the entire Learning Registry project as well. I think there are still places on this so book up if you want to come!

Watch this space, and please comment here on the blog if you have any questions, inputs, or indeed corrections to any misunderstandings on my part in the text above!

* NB: The Learning Registry specifications and software are all still very much experimental and under development. The JLeRN Experiment is running concurrently with Learning Registry developments worldwide. So everything is subject to change, improvement, and undiscovered bugs and issues at the moment.