view printer-friendly version (opens in new window)
Sticking a layer of CORDRA on top
The Carnegie Mellon Learning Systems Architecture Lab (LSAL) published a new paper on ADL's new Content Object Repository Discovery and Registration/Resolution Architecture (CORDRA) initiative. It comes with a major health warning to the effect that it represents nothing but the authors' opinion, but it certainly clarifies what CORDRA is meant to do, and how it could go about doing it.
According to the LSAL team, the problem CORDRA is meant to address goes something like this: content and metadata interoperability specifications such as those referenced in ADL's SCORM have solved the problem of moving learning objects from one content management and delivery system to another. The remaining problem is about discovering and retrieving interesting learning objects that you don't know about yet, and that reside in repositories somewhere else.
Straight through or over the top
Within the wider field of digital repositories, the federated search and discovery problem is the subject of some fevered research and development at the moment. Initiatives such as Canada's eduSource Communication Layer (ECL), the US's LionShare and Europe's Simple Query Interface (SQI) are all intended to provide at least part of the answer.
The difference between those initiatives and CORDRA is that most of the others aim to stitch together repositories more or less directly. Their aim is to be able to have a search for material go out to herds of different kinds of repositories all at once, and get some coherent results back, and offer a way of retrieving the objects at the same time.
This approach has already been demonstrated to work, but it isn't easy. The metadata on all objects in all repositories in such a federation needs to be reasonably similar, for example. Ways of talking between a search tool and repository also needs to be coordinated, as do ways of running queries on such a repository. Last but not least, participants in such a federation need to agree on some basic rules about who can access what material under which conditions. Not straightforward if the federation consists of anything from a lecturer's desktop repository to a humongous national library.
CORDRA attempts to sidestep all those issues, by, essentially, adding a whole content management system on top of such herds of repositories.
What CORDRA does
In functional terms, CORDRA enables a community to specify a means of registering the contents of (part of) a repository, and exposing those contents for searching, querying and harvesting via a centralised system. Note that the system will not do storage, even if it can potentially do almost everything else.
Leaving just storage to the original repositories is really the secret sauce here: rather than try to homogenise diversity when a user submits a query to a federation of repositories, it homogenises at the point at which resources of any description get added to the system. Users searching and discovering will therefore interact with an almost completely homogeneous environment until it comes to delivery.
How this is done is where it gets a bit complex but intriguing. A CORDRA implementation is a Service Oriented Architecture (SOA) at a sector or community wide level that, in LSAL's view anyway, is completely componentised. It's functionality, therefore, can be integrated into any number of applications, helped by the fact that it is broken down in a large number of standardised bits that can be handled in the same way. As the LSAL people put it: "everything is an object". Not just the content, but also whole repositories, and even things like DRM or usage policies, metadata records and the links between a metadata record and the learning object itself are all objects.
The upshot of all that is that almost any aspect of the underlying diversity can be, and almost any aspect of the homogeneous layer on top can be captured or specified in a neat and flexible way.
The curse of recursion
But it also raises a fairly important question: if communities can customise their CORDRAs six ways to Sunday, how do you search and discover stuff across multiple CORDRAs? In other words, has the interoperability problem not simply been chucked one level higher?
The immediate answer of the LSAL authors is that there is no reason why CORDRAs couldn't be federated in an overarching CORDRA. Because of its object oriented nature, it technically doesn't matter whether what's underneath a particular CORDRA is a herd of actual repositories or CORDRAs.
Politically or socially, on the other hand, it does matter. It's not clear that every community would want their collective content store to be subsumed by an über-CORDRA owned and run by somebody else. Even if the actual access and management rights of that über-CORDRA could be specified to a very fine degree, some harmonisation of the specs within the linked CORDRAs would have to take place.
That would also mean that there probably is a natural limit to how many times the extra-layer-on-top trick can be repeated. That is, it is expected that you probably can't stack more than two layers of CORDRA on top of each other.
You've found it, but can you use it?
Other questions that may need some more thought concern the link between content objects and their representation at the CORDRA level. As EduSplash and LionShare demonstrate, the actual producers and consumers of learning objects (i.e. teachers) like to have direct control over the content they use. That CORDRA does not touch storage is therefore a good idea. But it does mean that people will have to be quite disciplined in registering and updating their stuff at the CORDRA level. Harvesting may help, but only if the content objects' metadata records are up to scratch- which is a problem for any kind of collection of content, not just CORDRA.
Another question in the storage area is that of retrieval or delivery of content. Though CORDRA can specify exactly how a repository is to make its content available, and how exactly a consuming system is to get the stuff out of a particular repository, the two may simply have to be tweaked before they meet these requirements. You could argue that actual tweaking isn't CORDRAs job —it only makes the job more manageable—, but it's clear that there aren't any magic bullets here. Much the same goes for content formats: if the receiving system can't handle the format of the remote content object, some tweakery or clever transformation will have to take place somewhere.
In the end, though, that may turn out to be CORDRAs strength rather than weakness. By offering standardised handles on such incompatibilities, it could provide both an incentive for people to implement deeper standards compliance, as well as make the standards implementation process more manageable. You don't have to chuck out all the legacy stuff in one go.
The CORDRA: Technical Introduction and Overview paper is available on the Carnegie Mellon LSAL site.
No responses have been posted