Like most of my classmates, my experience with metadata standards comes through coursework—MARC, which I regard to be the metadata standard in the lowest circle of hell; MODS, which I can barely remember from 551 two years ago; Schema.org, a microdata standard; and of course, our new friend, the Dublin Core.
I recognize the need for standards. Back when I used to work for YALSA, one of my duties was to manage the YALSA Blog, and we had a big problem with posters inventing their own tags and categories. So, for example, if we had a series of posts about Annual Conference 2009, we had tags for Annual, Annual Conference, Annual 2009, AC2009, and Annual Conference 2009. The end result of this open tagging problem was that none of our information was tagged the same, and so blog readers interested in seeing all of our posts would have to a) know the individual tags and b) surf around to find them. The problem with not having standards (and I recognize that tags are not necessarily a metadata standard) is that you get chaos. Not only can you not organize chaos, but it creates a less than pleasant user experience.
Cory Doctorow’s amusingly argued “Metacrap” identifies a number of issues that metadata standards raise, but to me, the biggest problem is that metadata standards try to apply 20th-century thinking to 21st-Century technology. Information on the web evolves constantly—sometimes even hourly. Metadata standards aren’t built to change that often. They assume that categories will always make sense. They assume that basics are enough. They’re created by committees and seemingly written by computers. I can’t be the only person who cocked her head awkwardly at the directions for DC.Source: “Recommended best practice is to identify the related resource by means of a string conforming to a formal identification system.”
As I worked on my project this week (my collection is concert ticket stubs), I found myself confounded by what to add to some of the DC areas. DC.Type calls for definition of the material, whereas DC.Format gets into specifics, but why not condense them together, since they’re basically offering similar information at different levels of specificity? I might want to know where the seats were, or how much they cost (which could theoretically go in DC.Description) because that might be more useful to a collector than a collection of URLs or ID numbers. It’s awkward to apply the same standards and information to collectibles that you would to, say, a book.
So, in summary, I read Librariems’ post and I want to go to there.