view printer-friendly version (opens in new window)
Splashing in Ponds and Pools
There's an awful lot going on in the general area of learning resource discovery and management at the moment. Most especialy about finding the right place to store resources, while still making sure that they can be discovered by other people. The Splash peer-to-peer (P2P) personal repository has been around longer than most in this area, and has been connected to nodes at institutional and regional/national level. We look at some of the lessons the developers learned.
Splash is a freely available desktop program that allows educators to store their own learning objects, and author metadata for them. Splash makes the collection available and allows searches through other people's collections. It was developed by Griff Richards and Marek Hatala and their team at Simon Fraser University in Canada as part of the wider Portals for On-line Objects in Education (POOL) consortium- hence the watery name.
Splash is built on pure peer to peer technology, which means that Splash programs can talk directly to each other over the network, without the need to bother a server or its human minder. The beauty and pragmatism behind it, though, is that it has been conceived to talk to a serverish 'head' Splash in a group of Splashes (i.e. a Pond) and to gateways at major internet backbones (Pools). Not only does this set up make sure that objects can still be found on Ponds -even if the machine a Splash is installed on is off the network- it also speeds things up.
Even better; existing, conventional repositories can be elevated to Pond status by either making it talk Splash by the addition of an interface on the repository, or, since very recently, by having Splashes talk to a Gateway that speaks eduSource Communication Layer (ECL- a national implementation of the IMS Digital Repository Interoperability specification) to other grown-up repositories on the other end. 'Talk to the sock' in the best possible way, in other words.
An inate talent to talk to lots of other kinds of repositories doesn't explain why you wouldn't want to upload learning objects to a grown-up repository in the first place, though.
Why peer to peer
The reasons include a desire to put objects close to where they are both used and produced- on educators' desktops. This gives educators the most direct control over who sees what and when. But there's more: because a Splash is also a convenient store for your own learning objects, content that isn't quite finished, or doesn't meet stringent repository standards yet can still be exposed and found by someone. Because of this informality, it may well be that more resources are available more quickly, expecially since there is no gap between edits on a learning object and its availability.
Perhaps most important of all, though, is the lesson from other P2P networks such as the original Napster and Kazaa: whatever their failings in the area of digital rights management, they were and are some of the biggest and richest publicly accessible collections of digital objects in the world. They did it simply by exposing stuff that people had on their machines, and were willing to share. Doing the same with learning objects just has to be worth pursuing.
Lessons learnedPerhaps the most important lesson is that it is quite feasible to let informal P2P networks interoperate with more centralised and professionaly administered repositories, without all parts of the network having to talk the same protocol at all times for all purposes. As long as big repositories can either easily add a P2P interface, or people can easily set up a gateway, each node on a repository network can do its own thing, without shutting out the rest of the world.
Users don't need to be bothered by the technicalities of this linking-up, even if they can restrict searches to known collections. Such collections need not be run on conventional repositories; Splash's ability to be ramped up in terms of availability and resource and metadata policy shows that it is desirable that communities can easily start their own resource hubs.
On the technical side, Splash seems to have made an interesting journey from something closely based on the JXTA P2P protocol (like the similar Edutella P2P educational network), via its own Splash protocol to a combination of Splash for the P2P bit, and ECL for connectivity beyond.
Marek Hatala, technical lead for Splash development, points to a few peculiarities of sharing learning objects for the reason why the team had to develop their own protocol: there are typically just one or two copies of an object on the network, and some can be quite large. This presented a bit of a challenge to the JXTA protocols' ability to set up virtual P2P networks across institutional network boundaries, more particularly their mechanisms to overcome firewalls.
Trouble is, the mechanism relied on a JXTA peer outside a firewall relaying messages to those inside. Fine if it's shuttling relatively small files from multiple sources, such as what you'd find on the music oriented networks. Not so good if you're trying to shuttle an 80 Mb video file of a lecture from just the one place: the connection has to be totally reliable. If not, the relay peer is liable to choke, and the download fails.
Added to this were issues with JXTA's reliance on a specific hole in a firewall (port 80- the one were most web traffic flows) being open both ways, where most university and college networks are open outwards, but not inwards. Solving all of these problems meant the Splash team having to roll their own protocol.
The final reason for developing a separate Splash protocol was more social than technical, though: JXTA doesn't have the notion of a Pond. It is, therefore, much less flexible in setting up a network node that can serve as the resource hub of a community, or any number of other specialised functions for groups.
The biggest lesson of the project as a whole, though, concerns that old bugbear: metadata quality. Like most other projects in this field, it found that good educators are neither trained nor motivated to meta tag the resources they create in a way that facilitates precise search results. Or, conversely, that the Learning Object Metadata (LOM) standard is just too onerous and too inflexible to make the investment in time and effort of creating good metadata records worth it. Proposed solutions include focussing on a small core of the LOM (such as the CanCore profile), and enabling communities of practice to develop schemas that make sense to them, and that complement the core.
ResourcesThere's a wealth of information on Splash, Pond and Pools on the EduSplash website. More information on ECL is available on a separate ECL page.
No responses have been posted