Scott's Workblog

scott.bradley.wilson@gmail.com


attention!
This blog has moved! Go to my new blog!


July 18, 2005

Introducing IMS ePortfolio, Part 1: Introduction

This is the first part of an article about the IMS ePortfolio specification, in which I'll be looking at what the specification does, how you might use it, how you might want to not use it, and where it may be going in the future.

How the work began

IMS ePortfolio has quite a long history, and is in fact being released about a year later than originally planned. It emerged as a result of discussions amongst a number of organisations within the IMS consortium, including Educause, OSPI, Blackboard, JISC (CETIS), and EPICC, all of whom had an interest in ePortfolios and the possibilities of interoperability between ePortfolio-capable systems.

The original starting points were the existing IMS specifications. This seems a bit limiting, and I think if this work were starting now it would have been sensible to look more broadly, but it is fairly typical of specification bodies to work primarily within their own "portfolio" of standards. So, in this case the starting points are the IMS Learner Information Package (LIP) specification, and the IMS Content Packaging (CP) specification.

On the surface this looks pretty obvious; an ePortfolio is a sort of conglomeration of content and identity ("this is me, and these are the things I've made"), so joining up standards for person information and content into one sharing model would seem logical.

I've written elsewhere about the use of FOAF and Atom, and this again is a model of linking identity and content within a sharing model (REST-style aggregation in this case).

Of course, the specific way in which you merge different specifications is important, as they often have different underlying models or theories of operation, and may use very different technical approaches to solving similar problems.

For example, Atom uses XML, while FOAF uses RDF, so the way to join them up has to be quite loosely coupled and not rely too much on the specific features of XML vs. RDF. Likewise, the IMS CP and LIP specifications, while both use an XML representation, have considerable functional overlaps using very different methods. I'll talk more about this in Part 3 of the series, when I discuss the bindings.

How IMS specifications work

Before you can make use of IMS ePortfolio, you really need to understand some of the ways in which IMS goes about writing and publishing specifications; it will soon become clear why this is the case.

Each specification body has its own ways of defining how "mature" a specification is. For example, IETF are quite strict about what a "draft" is and what "final" is, with requirements for evidence of interoperating implementations. W3C are a little more easygoing with their "drafts" and "recommendations". However, compared to both IETF and W3C, IMS is quite liberal when it comes to labelling specifications "final".

Let me explain that a bit more.

An IMS specification begins life as a charter, which is a document that a group of IMS members write that sets out the case for a new specification and collects together various requirements. The IMS membership vote on this document, and if successful, a Project Group is set up to actually write the specification.

The next phase is a Base Document, which is circulated privately, and sets out the main parts of the finished work. Members comment on the base document, and this informs how the next phase, the Public Draft is created.

The Public Draft is the first real public showing of the specification, and is intended to gather feed back from the implementation community. This lasts maybe six months, then its onto the Final Specification.

The Final Specification incorporates comments received during the Public Draft period, and represents the "finished" specification, which is again approved (or not) by a vote of IMS members.

Note that the whole process, from charter to final specification, can take place with (a) No actual implementations to test whether the spec works and (b) No initial submissions of existing implementations to start things off. IMS is quite "R&D-like" compared to a lot of other bodies.

So how on earth does the Project Group know that the "final" specification is actually going to work? Well, the short answer to that is, "they don't". IMS uses incremental specification versioning - if there is something wrong, it gets fixed in a later release.

So, an IMS v1.0 Final Specification is sort of like a beta version of a piece of software. By around v1.1.2 you usually have something you might be willing to trust as being fairly "bug-free" and implementable, although that varies a lot between specifications.

The structure of the documents

All IMS specifications are in (at least) three major parts:

  1. Information model
  2. Best practice and implementation guide
  3. Binding

The Information Model document sets out the underlying model used for the specification, such as the names and definitions (semantics) of the data items, and the operation signatures for any behaviours.

The Best Practice document provides additional information about implementation, such as deployment patterns, how to deal with various aspects of deployment and security, and also suggestions for extensibility and recommended vocabulary values. As an IMS spec of the "v1.0" variety probably doesn't have any practice, never mind "best practice", this sometimes gets waggishly referred to as "Best Guess Practice" in IMS circles.

The Binding is where the nitty gritty of the technology is described, usually with reference to one or more XML schemas.

If you adopt an IMS specification, to be able to say you are "IMS compliant" means you have to have implemented the Binding - not just the Information Model. This is the opposite way around from a lot of standards, such as IEEE, where the model has primacy rather than the binding.

(Note also that "compliance" and "conformance" do not in themselves guarantee interoperability; you can quite easily create "compliant" data instances that are meaningless to anyone else in a practical sense.)

The ePortfolio specification

OK, so we now know how the specification is structured in terms of documents. But what of the ePortfolio specification itself?

IMS ePortfolio defines an ePortfolio by referring to the Educause NLII definition:

a collection of authentic and diverse evidence, drawn from a larger archive, that represents what a person or organization has learned over time, on which the person or organization has reflected, designed for presentation to one or more audiences for a particular rhetorical purpose.

IMS expands this definition, stating that:

This collection usually takes the form of a set of pieces of evidence of learning and performance, reflections, or interpretations on that evidence, and representations of relationships between and among the evidence, interpretations, and evaluation criteria. Broadening out from just learning, an ePortfolio could also evidence personal qualities and attributes, or any 'competencies' that are relevant to the particular audience, who could be potential employees or colleagues interested in performance at work, as well as academics interested in the outcomes of learning.

So from this you can (correctly) infer that the IMS ePortfolio is looking the representation and exchange of these "collections", the "pieces" and the relationships between them.

The next part of the definition is also interesting:

The subject of the ePortfolio may also be the same person as the audience, and the purpose may be reflection. In this case, there are no particular bounds to what is relevant, and the whole of the archive can be considered to be the ePortfolio. While the subject of an ePortfolio is always the overall owner of the portfolio, some evidence, reflections, relationships, and criteria may have been created and may be owned by another individual or group. The authenticity and integrity of these parts may need to be verifiable with some third-party authority.(my emphasis)

So as far as the specification is concerned, an ePortfolio is owned by its subject. However, this is an assumption rather than a conformance requirement - there isn't any way that the specification can enforce this.

The general data model that emerges from this is that an Owner has zero or more Portfolios. Each Portfolio consists of a set of Parts, and also has zero or more Presentations (stylesheets). A View, which represents a subset or particular aspect drawn from a collection of pieces, is also a Portfolio. Finally, a Portfolio is, at the binding level, a kind of IMS Content Package.

Reinforcing the earlier definition, the owner of each portfolio is assumed to be the same as the subject (the person whom the portfolio describes).

The bulk of the specification is therefore concerned with:

  1. the vocabulary of portfolio parts
  2. the vocabulary of portfolio relationships
  3. portfolio metadata representation
  4. portfolio packaging and transfer

The vocabulary of portfolio parts is found in the Information Model; the vocabulary of relationships is in the Best Practice Guide; the last two are in the Binding.

Its entirely up to you which pieces of the spec you decide to adopt, but remember our caveat earlier about what "IMS-Compliant" means: you must adopt the binding to make a claim of compliance. Of course, you may have no intention of making such a claim for your system, in which case you can ignore the binding entirely if you wish.

Thats the end of our introduction to IMS ePortfolio - in the next part we'll dig into the content of the specification itself, the vocabularies.

main archive