LEAP 2.0

I had an interesting call with Simon Grant earlier about the developing LEAP 2.0 specification for representation of ePortfolio data. An ePortfolio is an electronic portfolio of evidence and reflections that collectively represents your skills, accomplishments, and sometimes learning process. Elgg, when coupled with its presentation tool, is a kind of ePortfolio.

UKLeaP, the first version of the specification, was tied to IMS LIP: a standard so complicated that a “plugfest” was arranged before every annual ePortfolio conference, where software vendors demonstrated that their products could read and write it. When you have to organise an event to prove that you can read and write a file format, it’s probably safe to say that it’s not going to receive widespread adoption. As a result, we gave it a wide birth, and stand by that decision.

For a standard to actually be adopted, it needs to be:

• Simple
• Flexible / extensible
• Easy for end users to deal with
• Easy for developers to write for

Those last two points are key: end users and developers are the people who count the most, in that order. If users refuse to use your standard, you might as well pack up and go home now; you’ve got to write simple tools with easy interfaces. Meanwhile, if developers don’t embrace your standard, the users aren’t going to have any meaningful tools to use it with; that means it has to be painless or extremely compelling for them to include it in their software.

What LEAP 2.0 gets right, so far, is that it’s based on three classes – entries, proxies to external content, and tags. That’s all you need! Competencies are subclasses of tags; reflections and goals are subclasses of entries; evidence is all supported by the proxy class. Although all the traditional elements of ePortfolios are supported, importantly they’re all optional. You can just represent an object as entry and leave it at that.

These are the promising beginnings of a simple standard which is both flexible and extensible. So what next?

Once the technical details are pinned down and documented for both decision-makers and programmers, I’d argue that one of the biggest tasks will be to create a set of stub classes in different languages for programmers to pick up. Elgg is written in PHP; other ePortfolio tools are likely to be written in C, Java, .NET, and so on. It would be a very smart gateway to adoption to have interfaces written in each of these that would handle the meat of reading and writing. JanRain did this with their base OpenID classes, which dramatically sped up the adoption of the identity standard.

Even if these stubs aren’t made available, I am hopeful that this will be the beginnings of a genuinely useful standard that starts in education and makes its way to the outside world. As we begin to represent more and more of ourselves electronically, and in more sophisticated ways, it makes sense to be able to transfer and process our digital identities more flexibly. Let’s see what happens.