I had occasion yesterday to download and look at the IEEE LOM for the fist time. The last time I’d looked at a metadata spec was in ’01, the IMS 1.2.1 final. At that time, I’d been teaching the course that would become tOFP for a few years, and was working with two other writing instructors to create other distance learning writing courses. I was of course also interested in getting the maximum benefit out of the materials we were creating, and so started looking around for ways of doing so. It was about this time I began experimenting with metadata, and reading David Wiley’s writing on the subject (which was a tremendous help).
I have a background in relational database design and implementation (mostly using FileMaker–and I’ll ignore for purposes here the question of whether it’s a “real” relational database), and so with my commute time (always amazing to me what can be accomplished in twenty minutes a day if you do it every day), I set about creating a system to organize metadata about the classes we were developing (and other resources). It was clear from the beginning that creating metadata would be an enormous amount of work, the more so the more granularly we wanted to track the information. The tool also tracked licensing fees, because we were asking the instructors to create the materials on their own time and license use of them to us when and if courses actually ran, so it had to figure out how to calculate fees at multiple granularities.
It was also clear from early on that some of the most important data, and the most difficult to capture, was in Element 7.1, which tracks the kind of relationship the resource has to other learning resources. 7.1 was a problem an order of magnitude beyond the multiplying records caused by granularity. Relationships exploded exponentially as you broke the courses down into their elements, and tracking all of the relationships seemed both impossible and vital. Beyond that, it seemed equally vital to track relationships generated by reuse (in large part to track the license fees associated. I came up with an ER model for the database that leveraged FileMaker’s ability to look up data from one record in creating another, which cut the effort required to enter the metadata, provided you started at the highest granularity and worked your way down to the lowest. It also allowed for tracking of these parent-child relationships, thus automating the capture of a lot of element 7.1 data.
It was about this time that a number of things occurred. FileMaker came out with a new version, I moved from Emerson to MIT, and I realized that on top of tracking original and reuse relationships, the system would need to track derivations as well. I started from scratch and rebuilt the system in the new FileMaker version, incorporating a number of new ideas (including tracking of Creative Commons licenses). Ultimately, I shelved the project because I didn’t have a test use for it, and there were a few FileMaker tricks I needed to learn to get some of the functionality to work. But what has stuck with me from the project is the importance of element 7.1 data–the circumstances under which resources are created, reused and modified. I still feel like this data is the heart of metadata’s usefulness. Of course it’s great to know the “how big?”s and “what format?”s, but if you can locate a resource of any format and usefully understand its relationships to a range of other fields and uses, you’re 90% there. A little tweaking and hacking can usually get you the rest of the way.