LOMand Dublin Core

> Can someone explain to this simple, country editor why we need both LOM and Dublin Core?

I think I look at this question a bit differently, asking instead, "Why do we need one?"

A characteristic of LOM (and increasingly of Dublin Core) is that it is trying to do everything itself. Inside LOM is bibliographic information, categoization and taxonomic information, authorship and publication information, technical information, rights information, and only incidentally, it seems, educational (or learning-related) information.

By creating 'one-size-fits-all' versions of such metadata, in my view, the result is that these different types of metadata are done badly. Consider Rights, for example, characterized by a couple yes-no questions and a text string. Surely there are better ways of doing this. Certainly, there are alternative (ODRL and MPEG-REL) ways of doing this.

Similarly for technical metadata. Ill-conceived (by requiring the definition of a player, rather than a media format) the technical metadata can and should be very precise - and most importantly, different - for different types of media.

To me, the metaphor of 'metadata as document' or 'metadata as catalogue card' - with a primary emphasis on things like search - unnecessarily limits how we can talk about learning objects and learning resources in general. We ought to have, for example, evaluative metadata, including (as appropriate) commentary, links to review, and more. We ought to have usage metadata. We ought to be able to, over time, assemble from many different sources, different metadata 'views' of the same resource, depending on our needs and perspective.

Certainly, the 'core' approach (as instantiated by the Dublin ilk, or RSS, or Atom, or a few others) ought, in my mind, to be favoured, creating a minimally defined set of elements that may, as need and custom demand, be extended.

Why do I feel the need to comment on this? because there still exists the tendency to belief that some specialized need ought, by the fact of its possibility, constrain or even become a part of the specification.

I agree with Mikael: "The way forward that I see as most promising is not merging standards but rather to disassemble standards."

If there is a way forward for LTSC, I think that it would be in articulating how we think about this and how we use disassembled standards in concert to realize semantically useful results (not just searches - there is way too much emphasis on searches, in my view - not everything is a library).

My own views on this (a bit dated now, but still possibly fresh enough): http://www.downes.ca/files/resource_profiles.htm