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?
Hi. I am the programmer of the components in question.
Will this get to the techies?
That is why I have been working with Norm and CanCore, to help get publicity for them, so I dearly hope so, as techies are the target of these packages.
Will they like it?
If you are writing software that works with metadata, you need some way to represent that data inside your software. If you are programming in Java, my packages provide you that representation.
But it goes far beyond saving the programmer time creating custom containers for LOM data, the real benefit is in the growing set of programmer tools for manipulating LOM data as well. A good example would be the equality function I provide – it will compare any two LOM metadata record instances for logical equality, that is to say, not just comparing them textually as strings, but taking into account ordered/unordered fields, lang string values and their defaults, etc. This function can be used, for example, when uploading or harvesting metadata to see if the record has in fact changed or not – allowing the programmer to avoid, say, republishing the same metadata record in an RSS feed repeatedly. The library of functions is what saves the programmer time. Now, without my packages, each programmer must create a different internal representation (API) of their own, and then none of us can share the tools we each build to work with our custom representation. But, if we can all share the programming interface for this data, I am hoping the common pool of programmer utilities for working with LOM will grow far beyond what I currently provide.
The API and library are all written in clean object oriented extensible Java code. I have many years experience creating tools such as this. I am confident any programmer, upon examining these packages design and functionality, would look upon them very favorably. That is to say, I hope they will jump for joy at all the work I save them 🙂
Will the resulting implementations satisy users?
What you build using these components is up to you. These libaries are to aid construction of the internals of the software, but the programmer still needs to build the application around them. There is no end user aspect to any of these packages.
The lack of user interface is actually part of my problem though. The community seems to have many visible high level participants who technically “kind of know what all those things are”, but it is extremely hard for me to get this out to the geeks actually building the software – the real target of these components.
Does this component release herald a new approach to developing tools and systems?
No. Programmers in any field draw upon common code libraries for building their software. I am, however, trying to create one of the first such libraries for working specifically with learning objects and their metadata.
I hope this helps clarify this release somewhat. I have tried to not be overly technical. I encourage people to please bring these components to the attention of any programmers building a repository or working with LOM data – they will understand what it is.
And if you or anyone has any additional questions, please feel free to email me.
Thanks.