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)

IMS releases public draft version 1.0 of the Digital Repositories Interoperability specification.

The Digital Repositories Interoperability (DRI) spec allows Managed Learning System (MLE) users to search, gather and expose various learning objects that are stored in repositories. It also allows people to submit, store and request them, and the resources delivered. And all of this from a spec that doesn't actually specify very much.

DRI is an IMS spec, but not as we know it. The main reason for that, is that not many new practices are actually codified in the draft per se. The spec has the customary Information Model, Best Practice Guide and XML Binding parts, but the XML Binding in particular "...utilizes schemas already defined elsewhere". The consequence is that the whole spec reads like a Best Practice Guide, if a potentially rather effective one.

What the DRI does specify is which existing specifications to use for the core functions of the DRI. Search and expose, for example, can be done with either the Z39.50 spec that is widely used by libraries, or else via XQuery; a newish XML based spec from the W3C that is designed to take advantage of the explicit information structure of XML documents. Z39.50, then, is most useful when querying existing libraries, while XQuery is ideal for dedicated learning object repositories. For both methods, a mapping is provided to IMS meta data and IEEE LTSC Learning Object Model (LOM).

The gather and expose functionality, by contrast, piggybacks on the work of the Open Archives Initiative (OAI). This involves users querying not just one repository, but many. The results of such a query can be aggregated and stored in a metadata repository, that can then be queried much like any other repository.

Having found all these resources, a user still has to request them, and have them delivered. In the case of fully IMS compliant systems, this is done by either making use of the element of the IMS metadata spec or a variety of location independent URL alternatives like OpenURL. Basic transportation is to take place over the traditional http and ftp internet protocols, with everything wrapped up in IMS content packaging. Ideally.

That still leaves the issue of messaging: the business of passing requests and other signals from one system to another. A basic commitment is made to the SOAP-with-attachments standard that is being developed at the W3C. Simple Object Accessing Protocol (SOAP) is a messaging technique that is likely to become quite universal, but it doesn't by itself provide the specifics necessary for a task like DRI. Some sample mappings of XQuery to SOAP are therefore provided by IMS DRI, but any other kind of messaging is left pretty much open. Some samples of what looks like a prototype IMS messaging schema are given, but not further elaborated. The model is there, but quite a bit of the implementation is for the future. Nor is this the only issue left open: alerting users to new resources in a repository is deemed a core function, but not implemented in this version of the spec. Message security, failure notices and incomplete queries and the like share a similar fate.

The compromised, work in progress, feel of the spec is hardly surprising: digital repository architecture is both important as well as comparatively periferal to IMS's remit. Repositories are largely the preserve of established specifications and practices from bodies outside of the e-learning domain. So while a decent infrastructure for shuttling learning objects around is crucial, trying to carve brand new IMS specs for the purpose is neither practical nor desirable. Given this context, the present draft looks like a solid and workable architecture, even if a lot of devilish detail still depends on others.

The Digital Repositories Interoperability specification, public draft version 1.0, is available from 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