The guts of a standards compliant repository…

Perusing the newly-released LOM/CanCore-based Open-Source Software Components was a humbling experience for me. The page promised that the code being offered included “interfaces, APIs (Application Program Interfaces), or schemas for working with LOM (Learning Object Metadata) or LOR (Learning Object Repository) data and functions.”

Hmm, well… I kind of know what all those things are… Then there’s the stated rationale for these components, “to greatly simplify the challenging task of developing learning object repositories –all without adding in any way to development costs.” Well, I can get down with that. But what do I do with them? How do these components fit in to what I or other LO projects at UBC are trying to do?

And if I wanted to be an educational technologist, why did I get a Master’s Degree in English?

As I hoped he would, Wilbert Kraan of CETIS steps in with a nice overview of the release, and its utility:

At first flush, it probably seems much more satisfying to deliver one complete, turnkey tool. Just plonk it on a machine, and after a nice splashscreen with your own logo, that is it: it works. Except that the people in institution Y need another doohickey that your app doesn’t have. And the people in institution Z want your app to talk to some system you’ve never heard of. And the users in your own institution would like another user interface, etc. and so on.

Some tools are built flexibly to accommodate such modification (e.g. Reload), many more are essentially monolithic and would require a close-to-make-no-difference re-write to do anything other than what it was originally intended for.

This effect is particularly strongly felt in educational open source software, which is typically built by one team on a project grant, and then left to its own devices. The idea is that others will pick up the project, and further refine it. In practice, however, the work involved in adapting an existing monolithic application is so large that you might as well start again.

The answer, then, is to build a component or service based architecture, which is exactly what the CanCore people did. The three components they just released — a programmatic handle (API) on metadata records, a metadata repository API and an LDAP based LOM repository — are essentially building blocks for whatever digital library you want. Though the team did built basic ready-to-use implementations of all these components, the idea is that other developers can save weeks, or even months, of development time by dropping the components into the programs that they are building.

It will be fun to watch if this release takes hold with upcoming developments. Will this get to the techies? Will they like it? Will the resulting implementations satisy users? Does this component release herald a new approach to developing tools and systems?

Will I keep asking open-ended questions I have no way of answering?

About Brian

I am a Strategist and Discoordinator with UBC's Centre for Teaching, Learning and Technology. My main blogging space is Abject Learning, and I sporadically update a short bio with publications and presentations over there as well...
This entry was posted in tech/tools/standards. Bookmark the permalink.

1 Response to The guts of a standards compliant repository…

Comments are closed.