The CWA is interesting in terms of general education metadata for a couple of reasons:

1. it is an education-related metadata standard that uses some DC elements (more specifically some of the ISO 15836 “simple DC” element set — it’s not a profile of DC), and
2. it models things like Learning Opportunity Specification, Provider and Instance, which may have some relationship to the objects relating to educational context and setting which have been identified as important in discussions relating to the Learning Material Application Profile and the DC-Ed Application Profile

Just in case you’re wondering, MLO is not related to ISO MLR or the LOM despite any similarity in the initials, they have a different scope.

DC-Ed application profile

On Tuesday afternoon, Sarah Currier led a DC education application profile task group meeting. You may know that this task group is drafting an “application profile module” for describing educational properties in Dublin Core resource descriptions. And the key thing here is that it is only the educational properties that are in scope for this profile, not everything that you need to know about a resource to use it in teaching and learning, not things like license details, accessibility details, title or location, just the education-specific properties. The aim is that the application profile module will specify how to describe these properties in such a way that can be “plugged into” DC descriptions built from terms that are generic or that are specific to other domains, to give you a full description of everything you need to know.

The group is basing its methodology on the Singapore Framework for DC application profiles, which calls for (among other things) functional requirements, a domain model, and a description set profile. Sarah presented a summary of the requirements that have been extracted from the use cases and scenarios that have been collected, and related these to a domain model. (Lorna and I have been discussing this with Sarah to make sure that she gets to benefit from the LMAP work we’ve been doing–more on that soon). It turns out that the educational properties that need to be described are frequently not properties of the resource per se but rather of the audience it is put before and the topic being studied.

Help needed

That’s all good progress, but there’s loads more work to do in agreeing the details of what property goes with which entity in the model to best fulfill the requirements, and then there’ll be some work on the description set profile. And there weren’t that many people in the room, none of them with much time to spend on this work. So there’s a real need for more people to help. It’s an open group, if you have resources to put into metadata for education you could do a lot worse than putting them into this work. The contact details for Sarah and her co-moderator, Diane Hillman, are on the DC Education Community page.

DCMI IEEE LTSC Taskforce

On the Wednesday there was a working group meeting lead by Mikael Nilsson about the work of the joint DCMI and IEEE LTSC taskforce which aims to recast elements from the IEEE LOM in a form that is consistent with the Dublin Core Abstract Model. This work has been on hold pending the drafting and approval of formal project authorization requests for the IEEE and some updates to the DC abstract model. Those pieces are now in place, and Mikael and Pete Johnston have been making progress on the actual work of recasting the LOM elements into a flat entity-relation model, dealling with issues such as how many namespaces the LOM element set and vocabularies require, what should be the URI convention and so on. The work covered by the IEEE PARs will be to create a standard for an RDF vocabulary for LOM elements and recommended practice for expressing LOM instances as Dublin Core descriptions. Extra outputs of the task group, not quite covered by these PARs but closely related could include a DC Application Profile for the LOM, i.e. a DC description set profile relating to the second PAR, and a GRDDL transform from LOM in XML to DC LOM application profile in RDF.

FYI: DCMI = Dublin Core Metadata Initiative; IEEE LTSC = Institute of Electrical and Electronics Engineers Learning Technology Standards Committee; IEEE LOM = IEEE 1484.12.1 – 2002 Standard for Learning Object Metadata.

Bringing it together

There is obvious overlap between the DC-Ed application profile and the DCMI/IEEE LTSC LOM work, the differences are that the former is looking anew at what is needed to describe educational resources, the latter is a straight translation of what exists outside of the DC sphere. Another initiative outside of the DC sphere which got some discussion time in the task force meeting is the work at ISO/IEC SC36 on Metadata for Learning Resources (MLR). The hope expressed in the meeting was that the framework for ISO MLR would be defined in such a way as to maximize its compatibility with current efforts in Dublin Core: the current draft of ISO MLR doesn’t do that, it remains to be seen how much effort will be required to re-align it.

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.