I’m not your typical cataloger working deep within the belly basement of a library pounding away at MARC records on OCLC Connexion. Like many recent MLIS graduates, I’ve found work outside the library- I work for a software firm.Â It’s not entirely out of scope, this firm designs the open source collection management software, CollectiveAccess. I won’t turn this into an advertisement for our system, but I will say that the most exciting feature is that you are never locked into a rigid metadata schema. When you download the software you can choose from a myriad of cataloging interfaces, like collection-specific OR standards-based, and even from there you can customize it further to meet your collection or institution specific needs.
For the past 6 months, I have developed all the standards-based interfaces and have become intimately familiar with these schemas. Now I have a bone to pick with what I would like to call the “Core.”
When you think of the core of something you visualize the essence, its center, the most basic elements of a thing. “Core” metadata schemas were developed to supposedly capture the most necessary information within a given subject area. Really? Let’s take a closer look:
The first and probably the most widely recognized “Core” metadata schema. With only 15 simple elements and a easily understandable qualifiers, DC makes for one flexible structure standard. What I like the most about DC is its rules: no elements are required, and repeat elements as necessary.
Some opponents say that it is too simple, then I say it’s not the schema for them. Dublin Core doesn’t have to solve the world’s metadata problems, but it is a great starting point to begin any form of description. Of all the “Cores.” DC really is a Core. Simple and to the point. Descriptive access at it’s most basic level.
VRA Core is the structure standard for the cultural heritage (primarily visual culture) community. With 18 elements at its simplest and 53 at its most complex, VRA Core 4.0 can be either basic or complex. It follows DC’s 1:1principle, while allowing for the historically interconnected structures of cultural heritage collections. However it confusingly prescribes the Collection / Work / Image relationship. How can these complex relationships be expressed through a 1:1 ratio?
PBCore was developed for the Public Broadcasting community to describe motion picture works. (It’s currently in Version 1.2; however the only way to view the update is through a graphic mapping available for download through the website. boo.) Version 1.1 has 53 elements arranged in 15 containers and 3 sub-containers, all organized under 4 content classes. Regardless of the differences between 1.1 and 1.2 – it contains over 50 elements! This hardly seems “core.” PBCore controlled vocabularies, called “pick-lists,” are ridiculously long and confusing. This schema could be really useful outside the public broadcasting community, but it needs to be edited and trimmed down to the most “core” information required to access these kinds of assets.
And finally we get to DarwinCore the Biodiversity “core” metadata schema. I don’t know what to say about this schema. It has so many elements in what seem to be a relational structure; however that structure isn’t clearly defined. How many identifiers can be packed into a schema? According to Darwin Core – 22. While I completely agree that biodiversity data requires a metadata schema, I think Darwin Core requires more testing. Its complexity is debilitating.
I could write pages about these schemas, and certainly many people have. But for now I just wanted to rant and rave for a few paragraphs and bring these “cores” to the center of our conversation for this week. Just remember as Prof. Block says, “Standards are like toothbrushes, everyone agrees theyâ€™re a good thing but nobody wants to use anyone elseâ€™s.â€
Until next time…