Web Magazine for Information Professionals

IMS Workshop

Tracy Gardner reports on a meeting held in March in the Francis Hotel, Bath.

“IMS is a global coalition of academic, commercial and government organizations, working together to define the Internet architecture for learning.” Excerpt from the IMS project website [1].

IMS was originally a US-based organisation but now wishes to be seen as an international effort. In the UK, the JISC is an investment partner and a UK IMS centre has been set up [2]. Recently, I attended two UK IMS events: the IMS Developer Workshop (March 23 - 24 1999, Bath) and the IMS/eLib Concertation Day (May 4 1999, London).

This article provides an overview of these events from a technical perspective. I went along to the events wanting to find out what action developers of (learning/library) information systems should be taking at the moment and what plans we should be making for the future. The IMS Metadata specification is discussed in more detail since it is currently one of the most complete specifications and a public draft is available.

What is IMS?

IMS is a set of specifications which will allow learning management systems to interoperate both with each other and with external support systems such as administrative databases. A discussion of learning management systems and their relationship with IMS can be found in a previous Ariadne article [3].

IMS is not an application in itself, it is a set of specifications (which will undergo standardisation) to which applications can conform. It does not make sense to say that a system is simply IMS compliant. But it would make sense to state that a search engine robot IMS Metadata v1.0 compliant.

IMS currently contains a number of specifications including:

The specifications are intended to feed into open standards through appropriate standardisation committees.

Is IMS a good thing?

It may seem that building systems to standards which may be overly complex for your local requirements is an unnecessary burden. This may be true if your systems are relatively simple and self contained. If however, you wish to start sharing content, user information or system components with external systems then the benefits of standards become apparent. Additionally, systems often develop beyond their original complexity, if you have implemented your system to support a thoroughly considered standard then incorporating new user requirements should turn out to be much less painful.

As the IMS standards develop and are (hopefully) supported by free and commercial software it should become possible to take an existing tools and combine them with components developed to suit local needs. This will allow developers to focus on the interesting aspects of a system without having to reinvent all the basic parts. Standards like IMS promote such scenarios and prevent the proliferation of multiple incompatible approaches or the domination of the proprietary approach of a single company which has no desire to support interoperability.

Can I start implementing the specifications?

The final IMS version 1.0 specifications should have started to appear in April this year (packaging and metadata) with further specifications following throughout 1999. Unfortunately there has been some slippage on these dates. Only a draft version of the IMS Metadata specification has been made public to date. Public versions of specifications will be made available from the specifications area of the IMS website [4].

That’s the bad news. The good news is that if you are a developer or investment member of IMS then you can access draft versions of the specifications before they are released. The JISC is an investment member of the IMS and this entitles all UK HE and FE institutions to have access to the IMS Technical Development Site [5] which contains, amongst other things, internal documents such as current versions of specifications. Lisa Rowlands at Bangor (l.rowlands@bangor.ac.uk) is the UK contact for getting access to the private areas of the IMS website.

Should I start implementing the specifications?

If you have an existing system for which some of the IMS specifications would be applicable and the system is currently stable and in service then you probably don’t need to be in a hurry to rewrite it to comform to IMS specifications. In this case it is probably better to wait until the IMS specifications have been publicly released and have stabilised. Even then you will need to consider which aspects of your system need to be IMS compliant.

If you have a system that is currently undergoing further development then the advice is slightly different. You will probably want to concentrate on IMS compliance at the boundaries of your system. For example, if you need to export metadata to another system then you may wish to do this using the IMS metadata specification.

If on the other hand you are about to start a new project then the IMS specifications may provide a useful starting point. If, for example, you need a way of packaging up learning resources into deployment units then you should probably make use of the IMS Packaging specification . Even if interoperability is not a current requirement - after all there is currently very little that you could be (IMS) interoperable with - you will save yourself the effort of coming up with a home-grown solution. Most of the IMS specifications have not yet stabilised. This has both negative and positive aspects, the specification may change and you may need to update your application to remain compliant but on the other hand you may be able to feed into the specification development process to ensure that your requirements are met.

The UK IMS Centre is keen for UK developers to start implementing the IMS specifications in their applications - if you have an interest in doing this you should get in touch with them (initially via Lisa Rowlands who will be able to put you in touch with an appropriate person).

Which specifications should I focus on initially?

The metadata and packaging specifications are currently the most complete. These specifications are a good place to start if you intend to begin implementing the IMS specifications and metadata and packaging are relevant to your application.

IMS Metadata specification

Since a draft version of the IMS Metadata specification is publicly available it’s possible to describe to provide an overview here to give an idea of what it would take to make an application IMS Metadata compliant.

The scope of the IMS Metadata specification is (from developer workshop):

The basic idea behind the IMS metadata specification is that all applications should support a stable base schema for metadata which contains a number of mandatory and optional elements, applications should be able to specialise and extend this schema for their own purposes, such extensions need not be supported by other applications but where there is agreement shared extensions can be facilitated by registries. IMS metadata is based on the IEEE Learning Object Metadata (LOM) v2.2 standard [6] which was developed by IMS and ARIADNE.

The IMS master metadata schema corresponds to the IEEE LOM and is organised into a hierarchy with the following metadata categories at the top level: general, characteristics, life cycle, metametadata, educational, technical, rights, relation and annotation. The IMS metadata specification defines four levels of obligation for metadata elements: mandatory, optional, conditional (must appear if another element is included) and not allowed (used when specialising an optional element in a local schema). In addition metadata elements may be non-repeatable, or may have an ordered or unordered list as a value. The mandatory elements form the IMS Base Metadata Schema which all IMS metadata compliant systems must support.

Mandatory metadata elements include: General.Identifier; General.Title; Characteristics.Language; Characteristics.Description; Lifecycle.Version; Lifecycle.Create.Date; Lifecycle.Publish.Organisation; Meta-metadata.Create.Person; Technical.Format; Technical.OSRequirements.OperatingSystem.

Extensions of the base schema for describing items, modules and tools are also provided, these draw on the master schema.

The role of the Dublin Core [7] element set for resource discovery has been considered in the development of the IMS metadata element set. IMS metadata subsumes the Dublin Core in its descriptive power but, unfortunately, there is no direct inclusion of the 15 Dublin Core elements. The IEEE LOM includes a mapping from the Dublin Core element set to the LOM/IMS element set, all Dublin Core elements can be mapped onto LOM/IMS elements but the correspondance is not 1-1. An IMS metadata record does not point to a Dublin Core record for the same resource, instead it includes the information that would have been entered into a Dublin Core record. If for example, you wish to embed both IMS metadata and Dublin Core metadata into the same resource then there will be duplication of information. The IEEE LOM includes a mapping from the Dublin Core element set to the LOM/IMS element set - all Dublin Core elements can be mapped onto LOM/IMS elements but the correspondance is not 1-1.

An XML representation of IMS metadata is used throughout the IMS metadata specification but it is not the only way that IMS metadata could be interchanged. Other representations including alternate XML representations (e.g. using RDF) might be used in practice. Appendix D, the non-normative implementation guide, is currently empty. For early adopters of IMS metadata the focus should be following the IMS schema rather than exchanging IMS metadata in a standard way. ‘Hard-coding’ of metadata in a particular XML representation is not the best approach. It is better to generate XML from a database so that it can be exported in a variety of formats if necessary.

Conclusion

The IMS specifications are at a stage where proof-of-concept implementations are required. It’s not the right time to rewrite all of your applications to be compliant to the appropriate IMS specifications but if you are reimplementing them for other reasons or you are developing new software then you should consider the IMS specifications both for your own short term gain (no need to reinvent existing specifications) and for the long term (interoperability). If IMS takes off - and it has the backing of many major players who could make that possible - then you’ll be ahead of the game if you have already considered the relevance of IMS to your systems.

References

[1] - The IMS Project website - http://www.imsproject.org
[2] - The UK IMS Centre - http://www.imsproject.bangor.ac.uk
[3] - SELLIC: Learning Management and the Library - http://www.ariadne.ac.uk/issue19/ims/
[4] - IMS Specifications - http://www.imsproject.org/specifications.html
[5] - IMS Technical Development Site - http://www.imsproject.org/dn/techdev/
[6] - IEEE P1484.12 Learning Objects Metadata Working Group - http://www.manta.ieee.org/p1484/wg-12.htm
[7] - The Dublin Core - http://purl.oclc.org/dc/

Acknowledgements

Thanks to Ian Upton from the BUILDER eLib project for useful comments on an earlier draft of this article.

Author Details

Tracy Gardner
Technical Development and Research, UKOLN
E-mail: t.a.gardner@ukoln.ac.uk