view printer-friendly version (opens in new window)
IMS Abstract Framework names parts
Though it may look like a kind of architecture, IMS' newly released Abstract Framework is more of a reference work. Designed to map out what has already been done and could be done in the eLearning specification world, it provides a guide to the kinds of things that make up eLearning practice. We talk to the principal author, Colin Smythe.
At the moment, the Abstract Framework is really three documents: a list of parts, a glossary, and a whitepaper that outlines how the parts hang together from a multitude of perspectives. Still to come is a companion Learning Activity Model (LAM).
Though abstract, and not intended to be anything that you could actually implement, the Abstract Framework does provide some interesting pointers to what a good many members of IMS and assorted eLearning experts think is the state of the art in the field.
Most immediately noticeable are the services and components that make up much of the substance. Though the division is not meant to preclude building humongous VLEs or MLEs that comply with various IMS specs, the documents themselves present a system whereby any number of applications get data and functionality from an application services layer, that in turn relies on a common services layer. The common services layer, in turn, relies on a basic infrastructure layer. Each of these layers are made up of components that are designed to do just one thing, and do it well. In short, the Abstract Framework is focussed on component and service architectures, though carefully crafted to be relevant to Other Ways of Doing It.
Of that little lot of components and services, IMS envisages that it will be mostly specifying the bits in the application services layer, simply because that is the one specific to eLearning while still some distance from vendor specific implementations. Common services tend to be things like authentication and authorisation, which is well served by specs like Internet2's Shibboleth, and infrastructure services are largely composed of general internet specifications like those from the World Wide Web Consortium (W3) and the Organization for the Advancement of Structured Information Standards (OASIS).
With regard to the missing bit, the IMS Learning Activity Model, we asked IMS' Colin Smythe what the plans were.
That's going to be an abstract representation of the commonalities between the different IMS content specs. A bit like IMS Learning Design in the abstract- the pedagogy behind what we do. That includes learners- and an abstract representation of them. The Learning Activity Model was meant to develop in parallel with the Abstract Framework, but it turned out to be much more difficult to do; it's much vaguer than the technology. We'll be trying to get people like Rob Koper and Bill Olivier (driving forces behind the Learning Design specification, WK) together to just get a first cut to kick of the debate.
The Abstract Framework took a lot of changing and brainstorming, and I expect the Learning Abract Model is going to be a similar process.
Back in the present Abstract Framework, the "Applications, Services, and Components" document lists many overlapping application services- the things that IMS has already specificied, and will continue to specify. Many of these share components and some application services even depend on other application services, but quite a few seem to overlap. Why, for example, have Enterprise Services (management of course enrolments and learning activities), when there's Group Management, Party Management (the management of parties- people or organizations), Class Administration and Membership Management (the management of memberships in groups)?
You could throw all that overlap together and simplify it. Its mostly a result of legacy specifications. Take 'group': that's not turned out to be the best concept- it gets interpreted semantically differently by different people. What some understand by a class, as expressed in an IMS Enterprise 'group', is not the same as others, and that poses problems for interoperability. But it's there, and it can't just be dropped.
Also, the list of application services is not exhaustive, it was never meant to be exhaustive, sorted or normative. These are just lists of the most obvious things that people might want.
The more interesting aspect of the Framework is that it maps the breadth and depth of eLearning specifications, and the holes that are in there now: the Learning Activity Model, for example.
The Abstract Framework's main point is about building consensus across the different spec bodies. Who is doing what already, and what still needs to be done. It facilitates the 'filching' of stuff that has already been done by others than IMS- and that means efficiency. We should never re-invent wheels.
The main way of facilitating that exchange is simply via the glossary document- even if you don't agree with a term, or its definition, it will at least enable people to have a common terminology. Too much time and effort is wasted on semantic holy wars.
The framework is not meant for ever, though. I wouldn't be surprised if the whole thing would be thrown out in two or three years. The whole field moves too fast: there's things like grid technology and the semantic web just over the horizon.
Some components in the abstract framework (e.g. LOM and Manifests) list the patent and license encumbered MPEG 7 meta data description specification and the MPEG 21 Digital Item content packaging specification. Does that mean that these are going to be profiled? What does that mean for the free-to-use policy on IMS specs?
Both the MPEG and the IMS specs have useful aspects, and neither will have the whole world for itself, so we need to interoperate. e.g. MPEG 7 has quality of service meta data. We don't have it, and we may need it for streaming media. Again, it's about not re-inventing the wheel.
IMS don't want to go down the route of having to pay for specs. So no patents. The integration with MPEG would depend on the members: the alternative would be to try reverse engineering. That may be too expensive, and still violate rights.
The standards bodies (e.g. IEEE LTSC and ISO SC36, WK) may be a better place to sort out how to combine IMS specs with MPEG specs.
The first principle for the AF listed is Interoperability, yet the bindings (the particular technology used to express the agreed concepts or datamodel) are still left unspecified. It seems the a big potential stumbling block to interoperability, and it doesn't appear to offer required flexibility to particular domains or sectors. Why leave that ambiguity?
We are edging closer to a single binding. At the moment it is not politically feasible, though that might change. Maybe we will find in a year's time that no-one uses anything other than the stack of binding technologies that we focus on. The whole Abstract Framework is designed around webservices, even if all the "web" and "SOAP" words have been taken out.
In that sense, you could say that the IEEE LTSC is datamodel centric, OKI does interfaces and IMS is binding centric; even if it is our information models, not the bindings, that are formally normative. People tend to look at IMS bindings, and implement that.
Just looking through the documents, it is clear that the Abstract Framework has a lot of use beyond informing spec wonks or even those who want to design eLearning architectures or implement Managed Learning Environments (MLEs). Some of it is inevitably techy, but that's exactly where the excellent glossary comes into its own; it's worth a look just for that. Now let's see the Learning Activity Model, IMS.
All of the documents can be viewed and downloaded (for free...) on the IMS Abstract Framework page.