Two stumbling blocks

Recently, while I was browsing Twitter, this tweet “It’s not true that #marcmustdie; it’s the silly cataloguing rules that dictate incomplete & irrelevant metadata that need the chop” triggered a few thoughts that I’m sure have been brought up before, but I couldn’t help myself, so here goes.

We create silos in two ways: through content and carrier. Neither are sustainable the way they are now. Both require radical (maybe even heretical) rethinking with regard to our patrons and the larger world of (bibliographic) information on the web.

Because the cataloging rules that govern the library metadata content are so byzantine and in many cases unnecessarily complicated, we make it too hard and time-consuming to provide adequate metadata. It’s not that the rules exactly “dictate incomplete & irrelevant metadata”, but their application is often just too complex. After all, rules are not an end in themselves, but should enhance findability. And the fact that the carrier format (MARC) is so restricted to the library domain is another reason why we cut ourselves off from the larger technology / web community. Other players in the bibliographic universe (Google Books, LibraryThing et al.) have such a hard time understanding our data because both content (rules) and carrier (data format) are mostly incomprehensible for people other than catalogers.

There are two possibilities to make our metadata more accessible: by conceiving rules that are easier to apply and by using a carrier that is understood outside the library community. At one point I had hoped that RDA radically simplifies and weeds through the rules, that it would be a kind of act of liberation. But it doesn’t appear to make a bold enough cut. What good are those most laudable efforts of creating RDA metadata vocabularies for 21st century technology when the rules are still difficult to grasp and follow?

If we remove these two stumbling blocks (which, as I’m well aware, constitute much of the identity of cataloging and catalogers) we’ll have made big steps towards opening up our bibliographic metadata and letting go of models that epitomize the past. Of course I realize that the paradigm shift and change in mentality and mindset seem unachievable, but a cataloger can dream, no?

Rules vs. format

To make library data more accessible for others to work with, we not only need to split our records up into atomic bits that can be mapped and modeled and identified, we also have to rethink the relationship between the rules and the format. In his article for Code4Lib, “Interpreting MARC“, Jason Thomale cogently talks about explicit vs. implicit structure as one of the reasons for his struggle with extracting the bibliographic data proper. The implicit structure is a result of the cataloging rules and *not* the data structure – you have to know the rules in order to interpret the 245 field correctly. It’s not enough to simply know what the field stands for. The explicit structure is made up of fields, subfields, indicators, or generally refers to a formal model of a data structure, a schema.

The fact that in MARC the explicit and implicit structures are so intertwined as to be almost inseparable is at the heart of the difficulty of non-catalogers to interpret our data and use it for machine-processing. The rules creeping into the format make it hard for programmers or others willing to reuse our data to make sense of it even if it’s encoded in XML.

… [T]he more structured a data record is, the more explicit the semantics tend to be. Meaning is clear and encapsulated—the overall context in which data appears within a record is irrelevant because, apart from what might be specified in the data model, context carries no semantic meaning. (Jason Thomale, “Interpreting MARC”)

We shouldn’t let the rules interfere with the definition of metadata elements, and we have to get the semantics of these elements across as unambiguously as possible. This is only achievable by keeping content (i.e. rules; AACR, RDA…) and structure (i.e. format; MARC, RDA vocabularies, Dublin Core…) apart. As soon as the former obscures the latter, we’re headed for trouble.

Interpreting MARC – article

The current issue of the Code4Lib Journal features an excellent article by Jason Thomale, “Interpreting MARC: Where’s the Bibliographic Data?”. The abstract:

The MARC data format was created early in the history of digital computers. In this article, the author entertains the notion that viewing MARC from a modern technological perspective leads to interpretive problems such as a confusion of “bibliographic data” with “catalog records.” He explores this idea through examining a specific MARC interpretation task that he undertook early in his career and then revisited nearly four years later. Revising the code that performed the task confronted him with his own misconceptions about MARC that were rooted in his worldview about what he thought “structured data” should be and helped him to place MARC in a more appropriate context.

I have to say that the project he writes about (ditigal music collection) is very complex, because music cataloging has special rules on top of the regular ones. This doesn’t change the assessment of the MARC data structure, though, which has “as much in common with a textual markup language (such as SGML or HTML) as it does with what we might consider to be ‘structured data.’”

It’s a worthwhile read for both catalogers and programmers: it illustrates the programmer’s perspective looking at and working with MARC data and it provides insights into what made MARC the way it is and into possibilities of dealing effectively with the quirks that exist.