Maybe it’s just me, but I like to be able to look at data “in the raw,” without some developer deciding for me what I’m allowed to see, and how I’m allowed to see it. There was an old story I used to tell about visiting a vendor booth at ALA Exhibits some years ago, where a marketing guy got me extremely irritated by not getting why I wanted to see a naked MARC version of some record he was using to illustrate a point he was trying to make. The punch line of the story was that I would characterize his reaction to the request as making me feel like I’d asked to see child pornography. The line always got a laugh, particularly in highly geeky librarian circles (which meant something quite different 10 or 15 years ago, but never mind).

The point was, of course, that in order to evaluate what a system was doing with your data, you had to be able to look at the underlying data, and follow it through whatever process was in place to manipulate or use it in some way. Of course, “naked MARC data” really meant “scantily clad MARC data,” because few of us really spent much time with unformatted MARC, in whatever flavor our system used, though I remember on many occasions being shown marked up printouts of NOTIS EBCDIC, and working with a programmer to figure out what was wrong and how to fix it.

I was reminded of this when hearing a developer (who shall remain nameless) say recently that “of course you’d never show anyone the FRBR structure” in an RDA based system. “Why the hell not?,” I responded (though perhaps the response was in my head and I was actually more polite—reports vary). There was a condescension in that comment that made me bristle, and I remembered the stories of why the early BALLOTS system (which I used for a mercifully short time) didn’t use MARC tags. The icky mnemonics that BALLOTS substituted were there because some genius decided that librarians (mostly women, of course) would never be comfortable with numeric tags. I don’t know whether the story is true, but it sure fits with the sexist attitudes of the time.

It’s a bit depressing that this sort of thing keeps coming up. Now that I’m older and even crankier than I was when I first encountered this attitude, I have even less patience with the idea that I might want to be protected from angle brackets, namespaces and whatever it is that is the is the special purview of the people who program. Show me the data—I can handle it.

[Disclaimer–this isn’t about you Jon!]

By Diane Hillmann, December 13, 2008, 10:44 am (UTC-5)

Add your own comment or set a trackback

Currently 6 comments

  1. Comment by Owen Stephens

    I don’t think that data structures should be deliberately withheld from those who are interested. However, I have some sympathy with the programmer in question.

    As you say, very few people would work with actual MARC records in their raw format – and I can really see no reason why you would want to unless you really were debugging at that level.

    My impression (completely anecdotal I admit) is that many librarians (and I probably really mean cataloguers) feel that the data structures currently being discussed to realise FRBR are ‘to complex’, and that this makes them reluctant to support a move to FRBRized data structures. In this context saying that you wouldn’t expose librarians to this complexity makes sense to me – as the complexity of the data won’t go away just because people don’t want to engage with it.

    I’d reiterate, I don’t think the data structures should be ‘secret’ or deliberately hidden from someone who wants to see them – but it isn’t necessarily important for most (not all) to engage with this level of detail.

  2. Comment by Diane Hillmann


    Learning programming is one way, but I’d argue that it’s not the only way. I’ve never learned programming, but one of my former programmer colleagues complimented me once by saying that I “think like a programmer.” What does that mean, and where did I learn that? I have no idea, but it wasn’t by learning programming. I suspect I picked it up by hanging out with programmers and asking questions; also by listening to their questions–often more revealing.

    I’d rather spend time learning to play my hammered dulcimer, to be honest. I’ll leave the programmers to do the programming and happily continue to work with them to make things happen!

  3. Comment by Chris Schwartz

    This is why it behooves aspiring metadata librarians to learn some computer programming. It really makes a world of difference toward understanding how the metadata we’re creating is being used by the computer. And trying to tell the computer to do something, i.e., programming, is a great way to acquire the geeky sensibility that we need!

  4. Comment by Jenny

    Argh. I apologize for that last post; I must have hit the “link” button or have forgotten to close a link tab.

    The title of the book is “Taming HAL,” and the author is Asaf Degani.

  5. Comment by Jenny

    Oh, good. I thought it was just me.

    This is also reminding me of a book that I just finished reading– by Asaf Degani. Degani’s thesis is that interfaces to machines or programs that give no indication of the structure of the machine (or system!) or its processes will inevitably lead to disaster. If people can’t see how information is organized, they won’t be able to find it. And if librarians can’t figure out how their libraries are structured, how can they expect to help their patrons?

  6. Comment by carol

    I agree! Knowing what the pretty, pretty display is drawing from helps me know what I need to know to construct the data. In a library I used to work at, the previous librarian had disabled the “title” search from the keyword search – meaning if you knew the title but searched it in keyword, you would not find the item. Others on staff had been puzzling on why the catalog never seemed to bring the results back properly because all the MARC seemed right … I got into the algorithms and found out why. Once fixed, life was fab. Ya gotta know WHERE it is coming from and HOW it is arriving at that search.

Add your own comment

Follow comments according to this article through a RSS 2.0 feed