skip to main page content CETIS: Click here to return to the homepage
the centre for educational technology interoperability standards

skip over the long navigation bar
Home
News
Features
Events
Forums
Reference
Briefings
Press centre

Inside Cetis
what is Cetis?
Contact us
Cetis staff
Jobs at CETIS


 




Syndication
XML: Click here to get the news as an RSS XML file XML: Click here to get the news as an Atom XML file iCAL: Click here to get the events as an iCalendar file

Background
what are learning technology standards?
who's involved?
who's doing what?

CETIS Groups
what are cetis groups?
what difference can they make?
Assessment SIG
Educational Content SIG
Enterprise SIG
Metadata SIG
Life Long Learning Group
Portfolio SIG
Accessibility Group
Pedagogy Forum
Developer's forum

Subjects
Accessibility (310)
Assessment (74)
Content (283)
Metadata (195)
Pedagogy (34)
Profile (138)
Tools (197)
For Developers (569)
For Educators (344)
For Managers (339)
For Members (584)
SCORM (118)
AICC (18)
CEN (34)
DCMI (36)
EML (47)
IEEE (79)
IMS (302)
ISO (21)
OAI (24)
OKI (20)
PROMETEUS (12)
W3C (37)

print this article (opens in new window) 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.

Resources

The public draft of Resource List Interoperability is available on the IMS website.

Related items:

Comments:

No responses have been posted

copyright cetis.ac.uk
Creative Commons License This work is licensed under a Creative Commons License.

syndication |publisher's statement |contact us |privacy policy

 go to start of page content