view printer-friendly version (opens in new window)
Transferring resourcelists from a VLE to a library (and back again)
Resource lists as a general concept can cover most anything between a list of URLs and a pile of exhaustive metadata records. In that space, the new RLI spec covers the middle ground; the sort of area that a personal bibliography management package such as Papyrus or Endnote cover. Like those, it offers a means of listing materials with enough metadata for citation and retrieval purposes. How the retrieval exactly takes place depends on the local system and the nature of the resource, but there is a place to stick resolvable locators such as the popular OpenURL.
The difference with a bibliographic management package's format and IMS RLI is threefold: RLI is designed for use in bigger network applications, it has a behavioural model and web service binding and, crucially, it is an open XML specification.
The first means that it is optimised for such uses as a lecturer authoring a reading list for a course using a function of a library system, and then have it uploaded to a VLE. The VLE can then just display it, or even present a student with a collated list for all courses in a particular semester. The lists themselves can be stored after the course has run, and re-assigned and updated the next academic year.
The behavioural model makes this even more interesting by exposing various operations on a resource list to a services based Managed Learning Environment (MLE), such as those derived from the E-Learning Framework (ELF). If the system that holds and manages the resource lists implements such a service interface, it becomes comparatively easy for a wide range of other tools to read, write and collate the lists. A list could be created as part of a collaborative learning activity, for example. Better still, if personal bibliographic management packages incorporate a service interface, people could manage them from there, and make them instantly available to whichever tool could use it.
Technically, such an update operation would require uploading a complete new list, unfortunately. Editing operations are being planned for future releases, though. Fortunately, there is already a conventional webservices WSDL and SOAP binding that conforms to the abstract behaviour model. It is the latter that is normative, though, and heavy hints are dropped that other bindings can/will be developed. RSS is the prime candidate, because it is already in such widespread use on the web for similarish functions.
The datamodel itself bears witness to RLI's position between the e-learning and library worlds. Most of it maps to a subset of the venerable IEEE Learning Object Metadata (LOM) standard, but the authors felt that it couldn't handle citation formats very well, so that is mapped to a subset of the ISO 690-2 bibliographic citation standard. There are bits of Dublin Core in there as well.
For the physical interchange of the lists, IMS Content Packaging is recommended. Though Content Packaging is largely a list of resources in its own right, RLI couldn't be bound straight to CP. An RLI list will, therefore, be just another blob of data inside an IMS Content Package. Also, there is a desire to keep the alternative of using the library world's Metadata Encoding and Transmission Standard (METS) open.
In short, it's a compromise between both worlds, and implementations will have to demonstrate whether the right balance has been struck.
The public draft of Resource List Interoperability is available on the IMS website.
No responses have been posted