July 22, 2005
Introducing IMS ePortfolio, Part 3: Binding
LIP and CP: A difficult legacy
As mentioned in Part 1, the IMS ePortfolio specification took as its starting points the LIP and Content Packaging specifications. These are the two sources of the IMS ePortfolio binding. These specifications are used for the portfolio metadata representation, and for portfolio packaging and transfer.
LIP is a very early IMS specification (about the same vintage as what we now call LOM). It provides a mechanism for describing and packaging learner information, including both metadata-like structures for things like goals and activities, and content representations for various supporting media.
Its sort of an ePortfolio specification already, although one that seems like something that has emerged from the world official records and transcripts.
Content Packaging provides a mechanism for describing and packaging a set of resources for transmission between systems.
So, both specifications have ways of packaging up a set of metadata and some files so they can be batch transferred between systems. And herein lies a bit of a problem.
LIP has both a hierarchical and a graph-based structural model, and a set of data models for individual parts, both resources and metadata, such as identifiers, titles, and so on.
CP has a hierarchical structural model, and a set of data models for individual content objects and their metadata, such as identifiers, titles, and so on.
The trouble is, they look very different in implementation, and merging them requires that a lot of assumptions have to be made clear.
For example, a Content Package can contain a reference to an item, the item can have a reference to LIP metadata and to a file, the LIP metadata can have references to other LIP metadata, and to the file too.
If you're not careful, the whole thing turns to spaghetti.
So, for better or worse, one structure had to go, and the approach taken has been to effectively deprecate the whole CP structuring mechanism, replacing it with a small number of rules that map particular CP "Items" to ePortfolio constructs: so, for example, one node contains all the "parts", while another contains all the "relationships" and so on. So you have to follow these rules if you're to have any chance of someone else being able to interpret your portfolio correctly.
This means that to adopt this binding, you cannot really re-use much existing IMS Content Packaging code; you have to use a particular algorithm to interpret what IMS CP is being used for in this particular case. In a sense its a very "dumb" content package, because all the "intelligence" is now in the LIP metadata, which is all referenced as if it were a set of resources.
LIP may also surprise some developers with its extreme verbosity. It was designed with lots of flexibility, and is also quite old, predating things like xml:id, XLink and XPath, so there are a lot of elements that look a bit odd and redundant from an XML developers' perspective.
For example, this is how you represent a date in LIP:
<lip:date> <lip:typename> <lip:tysource sourcetype = "imsdefault"/> <lip:tyvalue>Created</lip:tyvalue> </lip:typename> <lip:datetime>2004-05-31T13:00:00-05:00</lip:datetime> </lip:date>
As opposed to, say:
This pattern is pretty much repeated for representing any piece of information in LIP, so you can imagine some of these metadata files are going to get quite large.
On the positive side, LIP has had a thorough overhaul as part of the BSI UKLEAP standardisation process, so there aren't that many bugs in the specificaton. Although some features, such as proper internationalisation support, are still missing.
When to use the IMS binding, and why
I imagine I haven't done a terribly good job at selling this binding mechanism to you. Well, to be honest it isn't something I'm all that happy with, it seems to make something that could be quite simple into a bit of a baffling ordeal.
However, if your requirement is to bulk transfer a complete archive of very detailed ePortfolio data between two large systems, then this could meet your needs. Especially if wearing the "IMS compliant" badge is important to you or your customers.
On the other hand, if you want to use an aggregation-style approach with various types of feeds of ePortfolio data and resources being consumed and provided, then the processing overhead and large file sizes count against this binding, and you're better off basing your implementation on something like Atom and/or FOAF, but making use of the IMS ePortfolio vocabularies where they're useful (see Part 2 for more information).
Marks out of ten?
In an earlier post I set out some ideas of values that a successful standard should rank highly on. How does IMS ePortfolio perform against them? (One caveat - I was one of the contributors to the specification, although not a primary author as such, so I'm not entirely a dispassionate reviewer!)
Utility: Can IMS ePortfolio fulfil the requirement for which it was intended? Well, I think the vocabularies are 80% there, and there is a binding. I've got some niggles with the vocabularies (like the absence of Plans, and the ambiguity of how Participation actually gets used) but overall I think its a good start. I'm not sure if the binding is usable; time will tell as developers take a crack at it.
Precision: Is the specification unambiguous? Well, I think the definitions are quite well done, although given the topic of summarizing very broad categories of information, its clear that some terms are always going to be a bit ambiguous, such as "activity" or "goal", but within its own terms of reference I think its reasonably precise.
Free: Is there a licensing cost? Not as far as I'm aware. No companies posted patent disclosures during the development of the specification.
Open: Is the specification part of an open process? Yes, IMS is an open process, although one that requires paid membership for voting rights. I think overall more openness would have been helpful, as some organisations that I would have liked to have made an input didn't know that the specification was being developed until it was too late for them to have substantial input.
Clarity: Is the specification clearly explained? Well, yes and no. I think overall the information model is very clearly written, and mercifully brief. However I found the binding a bit confusing. Overall, though, I think its quite an easy read compared with other IMS specifications, mostly because its quite short!
Popularity: Is anyone using this? Well, OSPI have it on their roadmap. Other developers (ELGG, DotFolio) seem to be taking a more cautious approach, starting with the vocabularies but using simpler bindings to start with. Its really too early to tell.
Simplicity: The big one - is the specification as simple as possible (but no simpler, as the man said). Well, I think the vocabularies are quite simple, and could be modelled quite elegantly using a range of technologies; there are some bits (like Rubric and RubricCell, and Participation) which may need a bit of rethinking, and I'm not convinced yet of the utility of the "transcript" and "security key" parts, but overall I think the number and definition of parts and relationships seem about right. However, the binding seems too complicated for widespread use, adding together as it does two quite tricky to implement IMS schemas in an untested configuration.
This is the v1.0 of IMS ePortfolio, which, as discussed in Part 1 of this series, is really the first rather than the last phase of its development. IMS are looking for feedback, especially on the binding method, so make sure you go and fill in their feedback forms if you want to have a say in how it develops.
I hope you've found this exploration useful; if you have any questions, feel free to email me at firstname.lastname@example.org