ALA Annual in Chicago has been a blur—I did three presentations (which I hope to talk about and link to slides as time permits). But one issue has been rolling over in my mind ever since I blurted something about it at my first presentation on Friday of Annual, when I was last up on a panel about “The Future of MARC.” Rebecca Guenther of LC spoke about the efforts to keep MARC relevant and Ted Fons of OCLC covered similar topics from the viewpoint of “The Big O” (thanks to Karen Schneider for that wonderful appellation!) A feature of both talks was the idea that reorganizing MARC records into “FRBR-ized” views was really all that was needed to take advantage of FRBR. I argued at that time that this was not the case, and as I think more about it I’m more convinced it’s true: FRBR-ization is not the same as using FRBR in native RDA.

Part of my view is based on the differences between RDA and MARC semantics (not syntax, which is where the conversation usually goes). One of the most overlooked aspects of RDA in general is the rich vocabulary of relationships that it brings to the table for use in bibliographic description. Most people who’ve focused on RDA as a textual guidance or set of rules have overlooked this, because the relationship vocabulary appears in appendices, and most of us don’t consider appendices the most important part of anything. But consider this: in the RDA Vocabularies, each of these relationships has an identifier, is part of a hierarchy that allows expression of bibliographic relationships at several levels, and gives us the ability to use these relationships to navigate the bibliographic landscape without having to delve into records and interpret the text notes we’ve used for the same purpose in MARC. For instance, using RDA you can say that ‘Resource X’ is an abridgment of ‘Resource Y’ (and that ‘Resource Y’ has an abridged version in ‘Resource X’) in a way that a system can expose to the user with no muss or fuss. The relationship is specific, identified and explicitly defined if anybody needs that to apply or interpret it.

In contrast, FRBR-ization only exposes what we can assert based on a mapping from MARC to FRBR (or RDA), which is at best the relationships between the FRBR Group 1 entities: the Work, Expression, Manifestation and Item. With the RDA array of identified relationships, we have a whole lot more. I suppose one could say that these are not necessarily part of the FRBR panoply, but if you consider them the “horizontal” relationships that fill in between the “vertical” relationships that Work, Expression, Manifestation and Item provide, then it’s possible to see how these relationships are enabled by the way the FRBR model has allowed us to rethink our world.

This is one of the issues that makes my head hurt when I think about the RDA “testing” regime that we keep hearing about. Are we wedded to the notion that if it can’t be crammed into MARC we aren’t going to use it? Can’t we start to think about MARC as a fairly lossy output format and move on to something that expresses the relationships we know will help us maintain some important functionality and credibility in the broader data world? As Jennifer Bowen and the eXtensible Catalog folks have discovered as they build the services to transform MARC into RDA (see my post on Jennifer’s paper for more about that) transforming MARC to RDA represents a fundamentally different set of problems and trade-offs than going the other way. [By the way, the XC Project was everywhere at Annual--go Jennifer!]

And as more vendors step up to the RDA plate and begin to build applications that start with RDA rather than try and transform MARC into something that could be mistaken for RDA only in dim light, we’re going to have to accept the fact that like any other metadata mapping, there is no such thing as a free lunch or a round trip.

The Registry has some of these relationships registered already (see “RDA Roles” for the relationships between FRBR Group 1 and Group 2 and “RDA Relationships for Works, Expressions, Manifestations, Items” for the relationships between Group 1 entities), but be aware that these are not yet the final versions. I haven’t gotten the information yet about the final changes to allow me to make those updates, but when I do I’ll make an announcement to that effect.

Be Sociable, Share!
By Diane Hillmann, July 18, 2009, 11:35 am (UTC-5)

Add your own comment or set a trackback

Currently 4 comments

  1. Comment by Jonathan Rochkind

    I actually think of the FRBR model itself as a work in progress. The FRBR report, especially when it comes to relationships, frequently actually says things along the lines of “these are just examples, more work is needed.”

    So I think of RDA as continuing that work in progress, of fleshing out and formalizing things further. So I’m not sure it’s quite right/useful to say “those things aren’t FRBR, but RDA” — I think FRBR, at least as contained in the report, is more of an _approach_ than a formal model. And RDA is an attempt to make it into a bit more of a formal model. Which is a good thing.

    But it’s worth pointing that out, as you do, that RDA does indeed have more specifics than the model in the FRBR report alone.

  2. Comment by Heidi Hoerman

    I do think that we are going about this all wrong. Because we haven’t yet figured out the framework to replace MARC bibliographic records we are going to try to force RDA into compatibility with MARC format bibliographic records. We need to look at things the other way around.

    First and foremost, FRBR does not rely on the stand alone bibliographic record as we know it. MARC relies on the concept of bibliographic records just like cards. FRBR relies on clustering related data.

    Until we fully understand what this change in the shape of the data means I think the effort that will be spend training folks to shoehorn RDA data into standard MARC records is not going to result in what FRBR promises.

    Anyway, in my trying-to-twist-my-head-around-this way, I’m agreeing with you … I think.

  3. Comment by Diane Hillmann


    Thanks for the pointer to the Schneider/Denton Code4Lib presentation–it does make one of my points much better than I did! The other point, though, is that there are a plethora of relationships between the FRBR entities that aren’t FRBR, but RDA, and you don’t get those either with a FRBR-ization strategy. It’s those relationships that are largely overlooked when people think about RDA and what it buys us.

  4. Comment by Jonathan Rochkind

    This point is similar to the thesis of Bill Denton and Jodi Schneider’s presentation at the last Code4Lib:

    What We Talk About When We Talk About FRBR

Add your own comment

Follow comments according to this article through a RSS 2.0 feed