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.