1. Reaffirmation
The IEEE have now reaffirmed the LOM data schema (1484.12.1), which means that it continues as a standard for another 5 years.

2. Corriegenda
We discussed Draft 5 of the corriegenda (which fixes some known issues in the LOM without making substantive changes to the standard). A couple of new mistakes in the documentation have been identified and rectified, see the draft document for details. Those on the call believe that we identified all changes that are necessary to turn this draft into the final version. This will be circulated on the LTSC LOM mailling list soon. (Many thanks to Javier Godoy who has been leading this work.)

3. Expressing LOM in the Dublin Core Abstract Model
Unfortunately this wasn’t discussed. The DCMI IEEE LTSC Taskforce section of my last update on Dublin Core represents pretty much the latest I’ve heard on this.

Like my son said when we were stuck behind some agricultural vehicles the other week: “things with big wheels and big engines move more slowly than smaller things”.

1. Reaffirmation

The IEEE standard process mandates that standards have a lifetime of five years after which they must be reaffirmed (i.e. they stay on the books as-is), updated or deprecated. The LOM base schema (IEEE Std 1484.12.1) will be reaffirmed (assuming the ballot results are rubber stamped), so there will be no substantive changes to it for another five years.

2. Corrigendum

The IEEE have agreed that some long standing but relatively minor errors in the LOM documentation should be fixed through a corrigendum. The issues, which were first raised some time ago, are discussed listed along with their proposed resolution on the LOM wiki (temporary home). The next step is for the formal text of the corrigendum to be drawn up and submitted to ballot.

3. Convergence

The IEEE LTSC have authorized two related projects arising from the Joint DCMI/IEEE LTSC Taskforce: one that will recommend practice for expressing LOM instance using the Dublin Core abstract model, and a second that will produce a standard RDF vocabulary for LOM data elements. I’m sure the approved project descriptions will go onto the IEEE website sometime, but for now you can read submitted version on the taskforce JISCMail archive.

4. The next version

The LOM was designed around the turn of the century, it is fixed now until 2013: what should the next version look like? That, broadly speaking, was the subject of a meeting hosted a few weeks ago by Erik Duval’s group in Leuven and available online, and will continue to be a theme of discussion in the LOM working group. You can see the Flashmeeting recording of the last meeting; the next meeting is on April 23rd.

LOM Corrigendum Review

This is perhaps the least interesting of the developments, but it’s important and there’s more interesting stuff to come so bear with me. Five years since it was published, the IEEE Standard for Learning Object Metadata (IEEE Std 1484.12.1 – 2002) was due for review to iron out any wrinkles that had been reported by implementers. This work was lead by Eric Duval, and completed in remarkably efficient manner in three calls. The sort of detail being addressed was whether the ordering of elements which given in the standard as “unspecified” should instead be specified more precisely as “unordered”, and making sure that the example vCards in the Standard documentation are valid. Eric has kept a record of all the issues discussed and the decisions made during the calls; formal documentation is in preparation. More substantial changes to the LOM are the subject of the next item…

LOM Next; LOM-DC; Harmony

I don’t have a great deal to say about this work (yet) but I wouldn’t want to give the impression that minor corrigenda to the LOM are all that are being addressed. For some time now, there has been a joint DCMI-IEEELTSC group looking at how each metadata standard might complement the other. Similar people have been involved in a separate initiative, lead again by Eric Duval, looking at harmonizing metadata, i.e. achieving interoperability between metadata standards. The intention is that once the corrigenda work is completed these ideas may be taken forward to create the next generation of, or successor to the LOM: LOMNext.

Dublin Core

This summer, the Dublin Core Abstract Model (DCAM) recommendation was updated. Presentations about the model, and a concrete example of how it has been applied as the Scholarly Works Application Profile are available from April SIG meeting. A quick look at either of these should convince you that there’s more to Dublin Core than a vocabulary of 15 elements: this is a framework which could be used to express the same detail of information about the educational properties of a resource as is conveyed by the LOM. And that is essentially the problem space that the DC Education community is looking at. Their approach is to glean useful terms from the LOM, so that these can be expressed in conformance with the DCAM and used in application profiles for the description of educational materials. So they are not aiming to produce a complete application profile along the lines of SWAP, but rather a “partial profile” or profile module that can be used along with other DC terms to create a complete description of a resource. The wiki for this work is open, and it was discussed on the DC-Ed mail list in August. This approach has something to recommend it: it allows education metadata specialists to focus in on the questions around how best to describe the educationally relevant properties of resources; other people are looking at metadata for other domains (e.g. accessibility, preservation, properties specific to certain media-types such as images and so on). Two things, I think, will be key to the success of this approach. Firstly, making sure that modules fit nicely together, which will in part depend on the second, which is being clear about what is being described (the resource, the context it might be used in, the person who might use it … as Andy Powell said, you need an entity-relationship model). It will be interesting to see how the DC community addresses these.