Such data is a form of Activity Data, which can be defined as “the record of any user action that can be logged on a computer”. Meaning can be derived from Activity Data by querying it to reveal patterns and context, this is often referred to as Analytics. Activity Data can be shared as an Activity Stream, a list of recent activities performed by an individual. Activity Streams are often specific to a particular platform or application, e.g. facebook, however initiatives such as OpenSocial, ActivityStreams and Tin Can API have produced specifications and APIs to share Activity Data across platforms and applications.

While Activity Streams record the actions of individual users and their interactions with multiple resources and services, other specifications have been developed to record the actions of multiple users on individual resources. This data about how and in what context resources are used is often referred to as Paradata. Paradata complements formal metadata by providing an additional layer of contextual information about how resources are being used. A specification for recording and exchanging paradata has been developed by the Learning Registry, an open source content-distribution network for storing and sharing information about learning resources.

The briefing paper provides an overview of each of these approaches and specifications along with examples of implementations and links to further information.

The Cetis Activity Data and Paradata briefing paper written by Lorna M. Campbell and Phil Barker can be downloaded from the Cetis website here: http://publications.cetis.org.uk/2013/808

“Education technology and data need to work better together to fulfill their potential for students and teachers. Until now, tackling this problem has often been too expensive for states and districts, but inBloom is easing that burden and ushering in a new era of personalized learning.”

This initiative first came to my attention when Sheila circulated a TechCruch article earlier in the week. Normally any article that quotes both Jeb Bush and Rupert Murdoch would have me running for the hills but Sheila is made of sterner stuff and dug a bit deeper to find the inBloom Learning Standards Alignment whitepaper. And this is where things get interesting, because inBloom incorporates two core technologies that CETIS has had considerable involvement with over the last while, the Learning Registry and the Learning Resource Metadata Initiative, which Phil Barker has contributed to as co-author and Technical Working Group member.

I’m not going to attempt to summaries the entire technical architecture of inBloom, however the core components are:

• Data Store: Secure data management service that allows states and districts to bring together and manage student and school data and connect it to learning tools used in classrooms.
• APIs: Provide authorized applications and school data systems with access to the Data Store.
• Sandbox: A publicly-available testing version of the inBloom service where developers can test new applications with dummy data.
• inBloom Index: Provides valuable data about learning resources and learning objectives to inBloom-compatible applications.
• Optional Starter Apps: A handful of apps to get educators, content developers and system administrators started with inBloom, including a basic dashboard and data and content management tools.

Of the above components, it’s the inBloom index that is of most interest to me, as it appears to be a service built on top of a dedicated inBloom Learning Registry node, which in turn connects to the Learning Registry more widely as illustrated below.

inBloom Learning Resource Advertisement and Discovery

According to the Standards Alignment whitepaper, the inBloom index will work as follows (Apologies for long techy quote, it’s interesting, I promise you!):

The inBloom Index establishes a link between applications and learning resources by storing and cataloging resource descriptions, allowing the described resources to be located quickly by the users who seek them, based in part on the resources’ alignment with learning standards. (Note, in this context, learning standards refers to curriculum standards such as the Common Core.)

inBloom’s Learning Registry participant node listens to assertions published to the Learning Registry network, consolidating them in the inBloom Index for easy access by applications. The usefulness of the information collected depends upon content publishers, who must populate the Learning Registry with properly formatted and accurately “tagged” descriptions of their available resources. This information enables applications to discover the content most relevant to their users.

Content descriptions are introduced into the Learning Registry via “announcement” messages sent through a publishing node. Learning Registry nodes, including inBloom’s Learning Registry participant node, may keep the published learning resource descriptions in local data stores, for later recall. The registry will include metadata such as resource locations, LRMI-specified classification tags, and activity-related tags, as described in Section 3.1.

The inBloom Index has an API, called the Learning Object Dereferencing Service, which is used by inBloom technology-compatible applications to search for and retrieve learning object descriptions (of both objectives and resources). This interface provides a powerful vocabulary that supports expression of either precise or broad search parameters. It allows applications, and therefore users, to find resources that are most appropriate within a given context or expected usage.

inBloom’s Learning Registry participant node is peered with other Learning Registry nodes so that it can receive resource description publications, and filters out announcements received from the network that are not relevant.

In addition, it is expected that some inBloom technology-compatible applications, depending on their intended functionality, will contribute information to the Learning Registry network as a whole, and therefore indirectly feed useful data back into the inBloom Index. In this capacity, such applications would require the use of the Learning Registry participant node.

One reason that this is so interesting is that this is exactly the way that the Learning Registry was designed to work. It was always intended that the Learning Registry would provide a layer of “plumbing” to allow the data to flow, education providers would push any kind of data into the Learning Registry network and developers would create services built on top of it to process and expose the data in ways that are meaningful to their stakeholders. Phil and I have both written a number of blog posts on the potential of this approach for dealing with messy educational content data, but one of our reservations has been that this approach has never been tested at scale. If inBloom succeeds in implementing their proposed technical architecture it should address these reservations, however I can’t help noticing that, to some extent, this model is predicated on there being an existing network of Learning Registry nodes populated with a considerable volume of educational content data, and as far as I’m aware, that isn’t yet the case.

I’m also rather curious about the whitepaper’s assertion that:

“The usefulness of the information collected depends upon content publishers, who must populate the Learning Registry with properly formatted and accurately “tagged” descriptions of their available resources.”

While this is certainly true, it’s also rather contrary to one of the original goals of the Learning Registry, which was to be able to ingest data in any format, regardless of schema. Of course the result of this “anything goes” approach to data aggregation is that the bulk of the processing is pushed up to the services and applications layer. So any service built on top of the Learning Registry will have to do the bulk of the data processing to spit out meaningful information. The JLeRN Experiment at Mimas highlighted this as one of their concerns about the Learning Registry approach, so it’s interesting to note that inBloom appears to be pushing some of that processing, not down to the node level, but out to the data providers. I can understand why they are doing this, but it potentially means that they will loose some of the flexibility that the Learning Registry was designed to accommodate.

Another interesting aspect of the inBloom implementation is that the more detailed technical architecture in the voluminous Developer Documentation indicates that at least one component of the Data Store, the Persistent Database, will be running on MongoDB, as opposed to CouchDB which is used by the Learning Registry. Both are schema free databases but tbh I don’t know how their functionality varies.

inBloom Technical Architecture

In terms of the metadata, inBloom appears to be mandating the adoption of LRMI as their primary metadata schema.

When scaling up teams and tools to tag or re-tag content for alignment to the Common Core, state and local education agencies should require that LRMI-compatible tagging tools and structures be used, to ensure compatibility with the data and applications made available through the inBloom technology.

A profile of the Learning Registry paradata specification will also be adopted but as far as I can make out this has not yet been developed.

It is important to note that while the Paradata Specification provides a framework for expressing usage information, it may not specify a standardized set of actors or verbs, or inBloom.org may produce a set that falls short of enabling inBloom’s most compelling use cases. inBloom will produce guidelines for expression of additional properties, or tags, which fulfill its users’ needs, and will specify how such metadata and paradata will conform to the LRMI and Learning Registry standards, as well as to other relevant or necessary content description standards.

All very interesting. I suspect with the volume of Gates and Carnegie funding backing inBloom, we’ll be hearing a lot more about this development and, although it may have no direct impact to the UK F//HE sector, it is going to be very interesting to see whether the technologies inBloom adopts, and the Learning Registry in particular, can really work at scale.

PS I haven’t had a look at the parts of the inBloom spec that cover assessment but Wilbert has noted that it seems to be “a straight competitor to the Assessment Interoperability Framework that the Obama administration Race To The Top projects are supposed to be building now…”

JLeRN project manager Sarah Currier and developer Nick Syrotiuk opened the meeting by recapping the project’s progress and some of the issues they encountered. Nick explained that setting up a Learning Registry node had been relatively straightforward and that publishing data to the node was quite easy. The project had been unable to experiment with setting up a node in the cloud due to limitations within the university’s funding and procurement structures (Amber Thomas noted that this was a common finding of other JISC funded cloud service projects), however all the JLeRN node data is synchronised with iriscouch.com, a free CouchDB service in the cloud. Although getting data into the node is simple, there was no easy way to see what was in the node so Nick built a Node Explorer tool based on the LR slice API which is now available on Github.

Sarah also explained that the project had been unable to explore moving data between nodes and exploiting node networks and communities as there are currently very few Learning Registry nodes in existence. Sarah noted that while there had been considerable initial interest in both the Learning Registry and JLeRN, and quite a few projects and institutions had expressed an interest in getting involved, very few had actually engaged, apart from the JISC funded OER Rapid Innovation projects. Sarah attributed this lack of engagement to limited capacity and resources across the sector and also to the steep learning curve required to get involved. There had also been relatively little interest from the development community, beyond one or two enthusiastic and innovative individuals, such as Pat Lockley, and again Sarah attributed this to lack of skills and capacity. However she noted that although the Learning Registry is still relatively immature and remains to be tried and tested, there is still considerable interest in the technology and approaches adopted by the project to solve the problems of educational resource description and discovery.

“If we are to close the gap between the strategic enthusiasm for the potential wins of the Learning Registry, and the small-scale use case and prototype testing phase we are in, we will need a big push backed by a clear understanding that we will be walking into some of the same minefields we’ve trodden in, cyclically, for the past however many decades. And it is by no means clear yet that the will is there, in the community or at the strategic level.”

In order to gauge the appetite for further work in this area, JLeRN have commissioned a short report from David Kay of Sero Consulting to explore the potential affordances of JLeRN and the Learning Registry architecture and conceptual approach, within the broader information environment.

Following Sarah and Nick’s introduction Phil Barker presented an update on the status and future of the Learning Registry initiative in the US, which I’ll leave him to blog about The rest of the meeting was taken up with presentations from a range of projects and individuals that had engaged with JLeRN and the Learning Registry. I’m not even going to attempt to summarise the afternoon’s discussions which were lively and wide ranging and covered everything from triple stores to Tin Can API to chocolate coloured mini dresses and back again! You can read about some of these projects on the JLeRN blog here:

• ENGrich Learning Registry Case Study for JLeRN some ideas for a use case on paradata and accessibility opportunities
• Ideas for a use case on paradata and accessibility opportunities
• Understanding and using the Learning Registry: Pgogy tools for searching and submitting
• How widely useful is the Learning Registry?
• Sharing Paradata Across Widget Stores
• Rapid Innovation Dynamic Learning Maps-Learning Registry (RIDLR)

It’s worth highlighting a few points though…

Pat Lockley’s Pgogy tools gave a glimpse of the kind of innovative Learning Registry tools that can be built by a creative developer with a commitment to openness. Pat also gave a thought provoking presentation on how the nature of the learning registry offers a greater role for developers that most current repository ecosystems as the scope of the services that can be built is considerably richer. In his own blog post on the meeting Pat suggested:

“Also, perhaps, it is a developer’s repository as it is more “open”, and sharing and openness are now a more explicit part of developer culture than they are with repositories?”

Reflecting on the experience of the Sharing Paradata Across Widget Stores (SPAWS) project Scott Wilson reported that using the LR node had worked well for them. SPAWS had a fairly straightforward remit – build a system for syndicating data between widget stores. In this particular usecase the data in question was relatively simple and standardised. The project team liked that fact that the node was designed for high volume use, though they did foresee longer term issues with up scaling and download size, the APIs were fairly good, and the Activity Streams approach was a good fit for the project. Scott acknowledged that there were other solutions that the project could have adopted but that they would have been more time consuming and costly, after all “What’s not to like about a free archival database?!” Scott also added that the Learning Registry could have potential application to sharing data between software forges.

Another area where the Learning Registry approach is likely to be of particular benefit is the medicine, dentistry and veterinary medicine domains where curricula and learning outcomes are clearly mapped. Susanne Hardy and James Outterside from the University of Newcastle presented a comprehensive use case from the RIDLR project which built on the work of the Dynamic Learning Maps and FavOERites projects. Suzanne noted that there is huge appetite in the medical education sector for the idea of JLeRN type services.

Owen Stephens made a valuable contribution to discussions throughout the day by asking particularly insightful and incisive question about what projects had really gained by working with the Learning Registry rather than adopting other approaches such as those employed in the wider information management sector. I’m not sure how effectively we managed to answer Owen’s questions but there was a general feeling that the Learning Registry’s open approach to dealing with messy educational data somehow fitted better with the ethos of the teaching and learning sector.

One issue that surfaced repeatedly throughout the day was the fact that Learning Registry nodes are still rather thin on the ground, although there are several development nodes in existence, of which JLeRN is one, there is still only one single production node maintained by the Learning Registry development team in the US. As a result it has not been possible to test the capabilities and affordance of networked nodes and the potential network scale benefits of the Learning Registry approach remain unproven.

Regardless of these reservations, it was clear from the breadth and depth of the discussions at the meeting that there is indeed a will in some sectors of the HE community to continue exploring the Learning Registry and the technical approaches it has adopted. Personally, while I can see the real benefit of the Learning Registry to the US schools sector, I am unsure how much traction it is likely to gain in the UK F/HE domain at this point in time. Having said that, I think the technical approaches developed by the Learning Registry will have considerable impact on our thinking and approach to the messy problem of learning resource description and management.

For further thinky thoughts on the Learning Registry and the JLeRN experiment, I can highly recommend Amber Thomas blog post: Applying a new approach to an old problem.

Although it’s a bit early to start identifying specific technology trends across the programme, a few themes are already starting to emerge.

Unsurprisingly several projects mentioned that they were interested in using HTML5. Martin Hawksey who has been doing PROD calls with the OER RI projects to discuss and record their technical choices, noted that four out of eight projects already interviewed listed HTML5 among the technologies they plan to use; Bebop, Developing Linked Data Infrastructures for OER, SPINDLE, and Xenith. Synote Mobile also intend to use HTML5. It’ll be interesting to see if these intentions translate into implementation or whether any of these project go on to use alternative technologies.

Another broad theme that emerged was accessibility and widening access to open educational resources. Improving Accessibility to Mathematical Teaching resources is focused on making mathematics OERs fully accessible to visually impaired students, while two projects are aiming to make audio resources more accessible to a range of users. SPINDLE aims to increase OER discoverability by using linguistic analysis to generate keywords for enriching metadata, and the project also plans to investigate semi-automated generation of full-text transcripts. While Synote Mobile will make accessible, searchable, annotated recordings available on mobile devices.

There is also some interest across the programme in the Learning Registry development and the use of paradata. The SPAWS project plans to share paradata or usage data, such as reviews, ratings, and download stats, between widget stores and are currently developing recipes for paradata verbs which they hope to contribute to the Learning Registry Paradata Cookbook. And RIDLR will test the release and harvest of contextually rich paradata via the JLeRN Experiment to the Learning Registry.

I don’t know if this really counts as a theme, but it was also interesting to note that although the Rapid Innovation programme is very much focused on short term technical development, several of the projects discussed “soft” issues relating to the use of open technology. For example the aim of the Bebop project is to develop a WordPress plugin that can be used with BuddyPress to extend an individual’s profile to re-present resources that are held on other websites such as Slideshare, Jorum, etc. However Bebop’s Joss Winn added that by focusing on individual staff profiles they hope to encourage teachers to engage with using WordPress.

It’ll be interesting to see how these themes develop as the programme progresses and which other trends will emerge.

The recording of the OER RI catch up can be found here and Martin Hawksey’s aggregation of OER RI project feeds is here.

Oh and one last thing, great to hear that projects found the technical calls with Martin to be very useful, if you haven’t made a date to talk to him yet, drop him a mail now!

Working with the Learning Registry: Project Developers’ Workshop
Tuesday 13.30 – 14.30
Led by: Sarah Currier and Nick Syrotiuk

Sarah Currier and Nick Syrotiuk of Mimas’ JLeRN Experiment will be running a workshop which will share technical issues, requirements and solutions, and will help JLeRN and CETIS learn how to support projects with an interest in experimenting with the Learning Registry. As well as giving an update on Learning Registry specs, code and tools, Nick and Sarah will also provide an update on JLeRN’s latest technical developments, including the new Node Explorer. Projects will also have a chance to share plans and ideas for using the Learning Registry and paradata.

This workshop will be followed up on Wednesday by a hands-on hack session with JLeRN’s developer Nick Syrotiuk.

Target Audience: Developers and other technical folks working on projects (including OER3 and OER RI) interested in using the Learning Registry and/or working with the JLeRN Experiment. Other project staff also welcome!

Tags: #dev8ed, #jlern, #learningreg

Booktype
Tuesday 13.30 – 14.30
Led by: Adam Hyde

Booktype is an online book production software application developed by non-profit organization Sourcefabric. Booktype is 100% open source and is gathering a lot of interest, use, and following in the OER sector since its launch in February. Adam Hyde, Booktype’s project leader will be facilitating a workshop that will look at how this new software works for the user, trainer and developer. Booktype outputs to book formatted PDF, epub, mobi, PDF, .odt, templated HTML, print on demand services and ebook distribution channels. Booktype is federated and supports bi-directional text and equations, making it perfect for multi-language collaborative online textbook creation.

Target Audience: content creators and publishers of eBooks; OER projects with an interest in disseminating content as eBooks.

PublishOER: new business models for incorporating commercially published content into OER
Tuesday 14.30 – 15.30
Led by: James Outterside, Dan Plummer, Suzanne Hardy, Graham Isaacs, Raul Balesco

PublishOER is a JISC funded OER 3 project at Newcastle University, which is working with publishers to find new business models for enabling risk free incorporation of published materials into OER. The project is undertaking development work for centralising a business process for dealing with permissions requests to publishers, publishing to multiple publication formats from a single source, dealing with multiple licences, etc. Additional technical development work (SupOERGlue & RIDLR OERRI projects) is underway on Newcastle University’s novel Dynamic Learning Maps system, enabling the creation of resource mashups using OER bookmarking and OER Glue from within the learning environment and sharing of contextually rich curriculum related meta and paradata about learning resources via API/JLeRN to other users including publishers and HEIs.

The Newcastle team are interested in working with others including:

• Booktype: working with multiple publication formats
• University of Edinburgh: congruence between DLM (Newcastle) and COM:MAND (Edinburgh): curriculum mapping systems.
• Sharing resource meta/para/activity stream data.
• JLeRN /Learning Registry harvesting/syndication.
• Anyone interested in permissions management systems.
• Publishers and new publication business models. Solutions to dealing with multiple licences within ePub2 & 3 and other publication formats.

The team develops with Django and Python but are happy to work with developers using other languages.

Target audience: Administrators and developers from both HEIs and publishers.

Tags: #dev8ed, #publishoer

In addition to these workshops JLeRN, Booktype and PublishOEr will also be giving lightning talks on Tuesday morning at 10.30 when Dev8eD kicks off.

Well, not quite. Phil and I do have one or two thoughts and reflections on the session. There still seems to be growing interest and enthusiasm in the UK ed tech community (if such a thing exists) for both the Learning Registry development in the US and the JLeRN Experiment at Mimas. However in some instances the interest and expectations are a little way head of the actual projects themselves. So it perhaps bears repeating at this stage that the Learning Registry is still very much under development. As a result the technical documentation may be a little raw, and although tools are starting to be developed, it may not be immediately obvious where to find them or figure out how they fit together. Having said that, there is a small but growing pool of keen developers working and experimenting with the Learning Registry so expertise growing.

That cautionary note aside one of the really interesting things about the Learning Registry is that people are already coming up with a wide range of potential use cases. As Sarah’s conference summary shows we had Terry McAndrew of TechDis suggesting that Learning Registry nodes could be used for capturing accessibility data about resources, Scott Wilson of CETIS and the University of Bolton thought the LR would be useful for sharing user ratings between distributed widget stores, a group from the Open University of Catalunya were interested in the possibility of using the LR as a decentralised way of sharing LTI information and Suzanne Hardy of the University of Newcastle was keen to see what might happen if Dynamic Learning Maps data was fed into an LR node.

Paradata is a topic that also appears to get people rather over excitable. Some people, me included, are enthusiastic about the potential ability to capture all kinds of activity data about how teachers and learners use and interact with resources. Others seem inclined to write paradata off as unnecessary coinage. “Why bother to develop yet another metadata standard?” is a question I’ve already heard a couple of times. Bearing this in mind it was very useful to have Learning Registry developer Walt Grata over from the US to remind us that although there is indeed a Learning Registry paradata specification, it is not mandated, and that users can express their data any way they want, as long as it’s a string and as long as it’s JSON.

We’re aware that the JLeRN Experiment were hoping to get a strong steer from the conference session as to where they should go next and I had hoped to round off this post with a few ideas that Phil and I had prioritised out of the many discussed. However Phil and I have completely failed to come to any kind of agreement on this so that will have to be another blog post for another day!

Finally we’d like to thank all those who contributed to a the Learning Registry Session at CETIS12 and in particular our speakers; Stephen Cook, Sarah Currier, Walt Grata, Bharti Gupta, Pat Lockley, Terry McAndrew, Nick Syrotiuk and Scott Wilson. Many thanks also to Dan Rehak for providing his slides and for allowing Phil to impersonate him!

The Learning Registry

The Learning Registry – main web page.

Learning Registry Collaborate Google Group – “If you are interested in integrating, developing applications, working with Paradata… using the Learning Registry to make awesome things happen, then this is the Google Group for you. This list is suited to projects we’re working now, for Plugfest and any collaborative effort involving the Learning Registry.”

Learning Registry General Google Group – for general discussion and announcements.

Learning Registry Developer Google Group – the core technical developers list.

The Learning Registry Technical Guides – page linking to all the technical documentation.

Learning Registry Quick Reference Guide – “The purpose of this document is to provide a brief reference to the principal data structures and services that typical users of the Learning Registry will most frequently interact with.”

Learning Registry in 20 Minutes or Less – “This document will get you rolling with creating, uploading, downloading, and verifying envelopes in and out of Learning Registry server.”

Paradata in 20 MInutes or Less – “The goal of this document is to get you booted up using paradata in 20 minutes or less.”

Learning Registry Technical Specification V.0.5x.x – the top level of the Learning Registry Technical Specification.

Paradata Specification V1.0 – the formal Learning Registry paradata specifiction

Learning Registry Github Code Repository

Learning Registry Browser – demonstration term explorer.

Blog Posts

The Learning Registry: “Social Networking for Metadata” – an introduction to the Learning Registry by ADL Senior Technical Advisor Dan Rehak.

The Learning registry Plugfest: Report and Developments – does what it says on the tin! A report from the June 2011 plugfest by the University of Oxford’s Pat Lockley.

The Learning Registry: Rough Guide for Contributors – by CETIS’ R. John robertson.

Open Educational Resources Timeline – a post by Lou McGill looking at JISC and CETIS involvement in educational resource initiatives over time.

The JLeRN Experiment

JLeRN Experiment – main project blog.

JISC Learning Registry Node Experiment – CETIS blog post introducing JLeRN project.

JLeRN Alpha Node – LR test node running on Ubuntu.

JLeRN Hackday – issues identified at the January 2012 project hackday.

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).