*updated* Most of the guts of the public draft of the spec aren't entirely new, but it does draw together parts from a number of existing IMS specs, and shows how they can be used to contruct a variety of different kinds of ePortfolio that can be exchanged between different systems.

The last few years have seen a surge of interest in the use of ePortfolios- i.e. collections of evidence of a person's learning and achievement, to be used in activities like personal development, assessment or job application, amongst many more things.

The trick with any of these activities is that the portfolio, or a particular view on the portfolio, will have to move between systems. In this sphere, no interoperability means "a part of your life for a while record" rather than the genuine "lifelong learning record" that an ePortfolio ought to be.

IMS ePortfolio is designed to make that interoperability possible, but has to take into account the kinds of things people do with ePortfolios to get there. After all, using a portfolio to plan your learning is rather different from presenting a part of your portfolio for professional advancement, or maintaining the learning portfolio of a whole team.

To accommodate all these different uses, the spec brings a model of categories and relations between these categories to bear on the two broad types of information you might want to collect in a portfolio: artefacts that were created by whoever the portfolio is about (i.e. its 'subject'), and formal records of achievement about the subject. There's no real limit on what form these types of information can take: anything from notes, to pictures of sculptures to certified lists of marks can be included.

Naming of parts

The categories in which these bits of data can be classified, and the vocabulary of relations in which they can be linked, are not new: most come from the existing IMS Learner Information Profile (LIP) specification.

That spec already has the elements to define things such as goals, interests, qualifications, activities, products and competencies. What's new here is the addition of assertions and reflections. These last two come out of the work on the British Standard 8788, "UK Lifelong Learner Information Profile", where it was determined that the two additions were essential in enabling the use of ePortfolios as a tool in the process of Personal Development Planning (PDP).

The reflection elements does that by providing a place for people to record their reflections about other parts of the portfolio. It's not a description of such a part, but more of the outcome of thinking about how, for example, parts of a course helped them achieve a personal goal. The assertion element is a place for other people, such as tutors, to attest to the competency of the subject in a certain area.

The BS 8788 standard is still a work in progress, and, through an agreement between IMS and British Standards International, the outcome of that process will be harmonised with both the IMS ePortfolio and LIP specifications.

Another bit that has been thrown in the ePortfolio pot is the existing IMS Reuseable Definition of Competency or Eductional Objective (RDCEO) spec. The long title hides a comparatively simple spec that serves as a kind of coathanger for communities to hang their definitions of competencies or educational objectives on.

Most modularised courses in British universities and colleges, for example, will contain some statement about what a student is expected to be able to do or know after taking that module. Usually, such objectives are composed of smaller skills or topics. RDCEO provides a generic way in which to get identifiers on such things, so that a machine can get a handle on them.

In the new ePortfolio spec, that is used for a genuinely new addition: rubrics. These are essentially the kinds of tables many educators use to mark assignments, and to give students an idea of what they should be aiming for. In the case of essays, for example, there's likely to be a column about a major subject matter topic, as well as a column about punctuation and style. Rows in such tables will indicate the different level of attainment or competency a student can reach in the particular column, with the cells describing what the criteria for attaining that level in that column are.

ePortfolio rubrics, again, make such tables machine processable, which means that particular assessed works can point to not just marks, but also how they were determined. People looking at a piece of work that points to a rubric can thereby have a better idea of the quality of that work.

Yet more bits of the ePortfolio spec are taken from the IMS Accessibility for LIP (AccLIP) and Enterprise Services specs. The AccLIP spec provides a means for recording people's preferences with regard to accessing any kind of material: with audio captions, or in braille, for example. The Enterprise Services spec provides a simple means for referring to groups of people.

Ifs and buts

The inclusion of the Enterprise Services spec, and the general policy of IMS to release new specs with behaviours, might suggest that ePortfolio would define a little more than just data structures. As with older IMS specs, that is not the case with ePortfolio, however. Though the new spec has lot to say about what the data should look like, it does not provide a standard set of commands with which machines could get particular pieces of an ePortfolio via, for example, webservices.

The public release of the spec also mentions that there is a patent claim on the spec by the BSI. What's more, the patent is to be licenced under a so-called Reasonable And Non-Discriminatory (RAND) licencing structure. That means it shouldn't be too expensive to acquire the right to implement those parts of the spec, and the price is the same for everyone. That could still pose problems for open source projects, though.

There are several indications, however, that the paragraph rests on a misunderstanding in the editing process of the public draft document. There appears to be no patent claim from the BSI, much less a RAND one. It's just that the copyright on parts of the IMS spec is owned by BSI. The final release will have a clearer statement on the issue.

Resources

The documents can be viewed on, but not directly printed from, the IMS website.