Metadata Matters

Category: RDA

  • We don’t need no stinking Access Points

    …in the RDA Ontologies. Do we? After all, they’re a big part of the ‘Access’ in Resource Description and Access (RDA). But they’re not particularly semantically meaningful, especially if you have the component parts available. An Access Point is just a structured string. For instance a ‘Publication Statement’ Access Point for “The Daytona daily news” might look like:

    “Daytona Beach, Florida : Geo. F. Crouch, 1903-1926”

    It has a formal syntactic structure, and semantics derived from adherence to that structure when the string is created:

    “Place of Publication” : “Publisher’s Name”, “Date of Publication”

    Note that the punctuation is part of the formal grammar that helps parse a grammatically correct statement into its semantically meaningful constituent parts.

    And this is the way we’ve been doing things forever (well it seems like forever) — semantics is derived from proper use of a syntax that everybody who is creating and using shared data has agreed upon in advance. And as long as everybody uses precisely the same syntax this works great. It works really, really well with structured syntaxes like MARC21:

    260 $a Daytona Beach, Florida
260 $b Geo. F. Crouch
260 $c 1903-1926

    …and hierarchical syntaxes like XML:

    <publicationStatement>
  <placeOfPublication>Daytona Beach, Florida</placeOfPublication>
  <publisherName>Geo. F. Crouch</publisherNam>
  <dateOfPublication>1903-1926</dateOfPublication>
</publicationStatementt>

    The RDA documents go so far as to call an Access Point an Element and its constituent parts Sub-Elements, again clearly thinking of this nice syntacticly-defined semantics.

    But what if your data says, semantically, that “Place of Publication” isn’t the Name of the place or the Label for the place, but a URI that identifies the Place itself; a resource rather than a string. The Access Point rules don’t let you stick a URI in the Publication Statement where a string is supposed to be.

    What about “Publisher’s Name”? That’s clearly going to be a string no matter what — names tend not to be resources. But there’s probably a Publisher resource out there, somewhere, with a URI that identifies the Publisher and probably has a Name or a Label property that provides a string that you can stick in the Publication Statement.

    We’ll just ignore “Publication Date” for the now, since that’s a very different can of worms: slimy, smelly worms.

    At the moment, RDA doesn’t acknowledge the existence of the resources supplying the strings for an Access Point, and it lets substantial ambiguity sneak in with property names like “Place of Publication” rather than “Place of Publication Name” like they resolved with “Publisher’s Name”. But that ambiguity didn’t exist when all the data was strings — strings you used for indexing, and displayed to the user, and didn’t have to go fetch from somewhere because they were right there in that 260 field.

    I listened to a radio program that referred to all of the money that everyone in the world has available to invest as “The Global Pool of Money” and I think that applies quite nicely to the Linked-Data notion of the Semantic Web — “The Global Pool of Data”.

    The open world model of the Semantic Web assumes that you will never have all of the available data that describes a resource, and the RDF data model supports this. Resources often exist, outside of traditional library data, available from the Global Pool of Data, that can supply the necessary labels.

    But of course we usually just have the labels. This is library data made for cards that need to be put in the correct order and read by a person. And the Global Pool of Data usually just has a bunch of resources. This is linked data, in no particular order at all, meant to be read by a machine.

    So, specifying Access Points as pre-coordinated strings actually provides us with a major opportunity when defining the ontologies; several opportunities actually:

    • We can formalize each Access Point specification into what Dublin Core calls a Syntax Encoding Scheme (SES) and say that each Access Point has a datatype.
    • We can clarify the semantics of using a label rather than a resource for properties (sub-elements) like “Publisher’s Name”
    • We can clarify the semantics of using a resource for “Place of Publication” and say that the label used in an Access Point must be the Name of the Place and this is distinctly different.

    So, refined to use properties that are a bit more semantically clear, we have a slightly modified Publication Statement:

    “Place of Publication Name” : “Publisher’s Name”, “Date of Publication”

    …we tie these properties specifically to a FRBR Manifestation that RDA says must be what they describe, and in RDF the supporting ontology looks like:

    rda:placeOfPublicationManifestation a owl:ObjectProperty
rda:PlaceOfPublicationName a owl:DatatypeProperty
rda:publisherManifestation a owl:ObjectProperty
rda:PublisherName a owl:DatatypeProperty

    Here’s our sample instance again (by the way, this data is from a real linked data resource):

    “Daytona Beach, Florida : Geo. F. Crouch, 1903-1926”

    <http://chroniclingamerica.loc.gov/lccn/sn93063916>
  rda:publisherManifestation <http://???> (blank, but we know one must exist)
    rda:PublisherName "Geo. F. Crouch"
  rda:placeOfPublicationManifestation <http://dbpedia.org/resource/Daytona_Beach%2C_Florida>
    rda:PlaceOfPublicationName "Daytona Beach, Florida"
    rdfs:label "Daytona Beach, Florida"

    This tiny chunk of data was gathered by hand and mapped (by me) from the existing resources and the labels supplied by those resources.

    Someday there will be services that comb through linked data looking for missing data like that Publisher resource, and will perform a search on the Global Pool of Data looking for resources with labels matching that library data, expressed in RDA/RDF, fill in the missing pieces and present the lucky cataloger, and ultimately the user, with all that rich linked data.

    The eXtensible Catalog project is working on services that do just that kind of thing, so someday may not be too far off.


  • Linked Data at ALA Annual

    One of the most interesting programs at ALA Annual that I was involved with was the Linked Data grassroots program. Here’s the blurb:

    From Legacy Data to Linked Data: Preparing Libraries for Web 3.0. “How can library cataloging data be transformed to function within ‘Web 3.0’ and be understood by non-library web applications? Speakers from both the library and Semantic Web communities will explore the situation in a non-technical manner and describe current work underway to transform legacy library data into linked data.“

    The speakers were: Eric Miller (President, Zepheira, Inc.), me, Jennifer Bowen (Co-Principal Investigator, eXtensible Catalog Project, University of Rochester), Rebecca Guenther (Senior Networking and Standards Specialist, Network Development & MARC Standards Office, Library of Congress). Corey Harper of NYU introduced the speakers and fielded questions at the end. Because this was a Grassroots program, attempting to make a place for emerging trends in what is often a program consisting primarily of the hot issues of a year or two ago, all the approved programs got small rooms. The one we ended up in seated about 75, and we filled the floors, the aisles and much of the hallway outside the room. The room was in the Hilton, not easy to find, so it was gratifying how many people made the effort.

    American Libraries reported on the program, and from the comments I’ve received it was a successful session and has generated interest in further programming on the subject for next year (and we are actually talking about doing that). In my presentation, I made the case for the readiness of libraries for the challenges of linked data, citing the work done with the RDA vocabularies as foundational to that claim. I admit that although there was a part of that claim that was, if not actually wishful thinking, at least a rhetorical device, clearly we are at some kind of tipping point (or approaching it pretty quickly). Every six months when I talk to people at ALA extensively about this stuff, or when I’m out “on the road” talking to colleagues, there is more excitement and more interest on the part of librarians, who are definitely “getting it.”

    Presentations are available on the ALA Wiki.

  • FRBR vs. FRBR-ization

    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.

  • Testing! Testing?

    Today I got a very disappointing note in my inbox, from the US National Libraries RDA Test Project. I guess I’d call it a “ding” letter, and I have to say it was more than a bit surprising. I had volunteered to help with the testing, not by creating records, mind you, but in analyzing the records other people create. Given the fact that I’ve been the co-chair of the DCMI/RDA Task Group, done the major part of the work in registering the RDA schemas and vocabularies, and have been involved in building the XML schemas that will be the basis of much of the data creation for many early RDA implementations, I figured my experience might come in handy. But apparently not …

    Dear Diane: Thank you for your interest in the US National Libraries RDA Test project. The RDA Test Steering Committee regrets that you could not be selected as a formal test participant. Interest in the project was much greater than the Steering Committee originally anticipated, and it was necessary to select test partners from more than 90 applications. Every applicant had a great deal to offer to the project, and each was carefully considered. The Steering Committee based its final selections on the goal of ensuring that the RDA Test will reflect a cross-section of US cataloging agencies balanced by size, type of organization, OPAC and cataloging systems used, and areas of specialization in cataloging and collection development.

    The Steering Committee will share the methodology for the test on its Website at URL . If you are interested in conducting your own test of RDA, we encourage you to produce records following this methodology and to share the results with the Steering Committee during the test period.

    Thank you again for your interest in the RDA Test.

    So, exactly what are they testing that makes my knowledge and experience useless? Darned if I know. But I can’t get beyond the notion that the testing regime I see described on the website is pretty limited, and it’s hard to imagine what the results can really tell us, aside from the obvious difficulties people will encounter in attempting to cram a FRBR-based structure into any one of our current flat MARC-based library systems.

    Much more interesting, to me anyway, is the idea of what RDA records might look like in straight XML or RDF, without the necessity of the contortions involved in making it all “fit” into a MARC system. Without the layer of MARC contortion we might really be able to figure out whether catalogers could adjust to RDA and create FRBR-based records. It would be nice to think that some of the open source systems would find a way to play with these records and test some more forward-looking, rather than backward-looking implementation issues.

    Any volunteers for an alternate testing regime?

  • On the Road at NJLA and the Five Colleges

    This week I’ve been on the road, doing presentations at the New Jersey Library Association meetings on Wednesday, and Five Colleges in Western MA Friday morning. I’ve been doing all this travel in the faithful MetadataMobile, increasingly an object of interest, amusement and (almost) veneration by those who have heard about her. It’s been a great trip, with wonderful audiences, and as always, I learn a lot about what’s on the minds of those in the trenches.

    I arrived later than I’d expected at NJLA, due to missing the exit I was supposed to use on the Garden State Parkway. I was very busy looking for a coffee and a rest stop, and it probably whizzed right by me. By the time I realized I was way too far down the Parkway, I decided to get off and use my newly acquired New Jersey Official Map to get me to my destination. I know, it’s very retro as a strategy, but maybe I was feeling that a little self-punishment was in order, or maybe I just needed to get off the big roads for a while.

    As a child of the fifties, my first stop was a gas station as I needed to gas up and figured I’d confirm my location on my handy-dandy map and get some advice on my route. I had forgotten that New Jersey doesn’t do self-service gas pumping, and I’d also forgotten that virtually all the NJ gas stations I’ve visited in the past decade are staffed by (and possibly owned by) persons from somewhere else. When shown a map and asked for directions, they invariably act like people who have been lately dropped into their current location from the sky with no idea how to locate themselves in the world they inhabit (pretty close to reality, probably). I knew pretty much where I was, but wanted to figure out how to get to a big secondary East/West road that would take me to where I needed to be. It was hopeless—these guys (they’re always guys) couldn’t even locate the town they were in on my map so I thanked them for their trouble and got back on the road. I ended up following my nose (and the MM’s internal compass, which tells me whether I’m going N, S, E, W or any rational combination thereof). Thankfully, in NJ if you go east you find the Atlantic eventually.

    It was a gorgeous day to be taking the long way, and I passed by what remains of the agricultural areas in NJ, including a whole bunch of horse farms (one was called “Due Process Stables” and you could pretty much guess how that was funded). I got to the conference venue in Long Branch (right on the beach) in time to take a nice walk on the boardwalk and decompress from those long hours behind the wheel.

    The program was about FRBR and RDA for real people, and Rhonda Marker from Rutgers presented first. Rhonda and I have presented together before, and generally have fun with it, since we sometimes disagree and are very open about it, to the general amusement (or maybe consternation) of the audience. We only had two hours, which wasn’t enough, but the audience was very receptive and had some good questions. The slides for this presentation are available here.

    From Long Branch, NJ, I pointed the MetadataMobile north, through the horror of Big Apple driving (BIG trucks!), though Connecticut and up to Amherst, Mass., for a confab with a group from the Five Colleges. This had been in the planning works for some months, but was made more interesting by the announcement a few weeks ago of some pending reorganization of technical services operations in the colleges in response to the same kinds of financial pressures being experienced everywhere. I’d been forewarned about this by the organizers of this session, and included some of the issues most relevant to the group in my presentation (though the slides, available here don’t always reflect this directly). My underlying point was that they were not, in fact, dealing with only one crisis—the financial meltdown—but two, if you include (as I do) the pending changes in how we do business as data creators and managers, changes that are absolutely necessary to avoid the continuing marginalization of our efforts to provide information to our users.

    One thing that impressed me about this group was that it included a number of the library chiefs, systems folks and others not part of the cataloging cohort that normally predominates in my audiences. This is good—very good, in fact—because it signals to me that the issues I talk about are being seen as crucial to the discussions around a change in mission and strategy essential to creating positive change over the longer term, not just arguing against cuts in budgets for the short term. But, like President Obama points out, the one-crisis-at-a-time approach doesn’t work in a context of multiple crises related to one another in fundamental ways. Attempting the financially necessary reorganization without a refocus on mission, in the face of the huge challenges we face in remaining relevant in the current information environment, is self-defeating at best, suicidal at worst. I spoke to one of the chiefs after the presentation, and he said that he wished his public services folks had been there, too, and I agreed. Certainly the demise of the library catalog as we know it will affect their work hugely, and it behooves us all to break down those barriers of specialization as we face issues of our own survival as information providers.

    What this also suggests is that the focus of the testing being done by the US national libraries cannot be limited to cost benefit analysis. If we fail to look at the issues of most importance to libraries, as the LC Working Group on the Future of Bibliographic Control certainly did, we risk our future entirely. Of course, in the current environment particularly, we need to pay attention to costs and efficiency as we move forward, but they cannot be our sole criteria for decision making.

    For those of you knitters among my readers, I also made a pilgrimage to Webs and spent a goodly portion of my speaker’s fees to support the local economy. It was a great, though at this point I’m going to have to do a “real” retirement sooner than anticipated to use up all the accumulated yarn and patterns I’ve amassed. Either that or recruit a chauffeur on these trips so I can knit on the way.

  • Humble Pie

    There’s nothing quite so humbling as reading something one wrote some time ago, particularly if the ideas expressed are, if not quite so old as oneself, at least betray an expired shelf life. This is particularly a problem when the item in question “looks” new, e.g., is recently “published.” These uncomfortable thoughts arose this week because the long-planned festschrift for my late colleague, Tom Turner, was released last week.

    Metadata and Digital Collections: a Festschrift in honor of Tom Turner. Edited by Elaine Westbrooks, Associate Dean of University Libraries at the University of Nebraska at Lincoln, and Keith Jenkins, GIS/Geospatial Applications Librarian at Cornell University’s Albert R. Mann Library. Ithaca, New York, USA: Cornell University Library, 2009.

    And my contribution, “Looking back—looking forward: reflections of a transitional librarian” is the last one on the table of contents.

    Tom has been gone for about six years now, and in fact “Metadata in Practice,” published in 2004 (and still selling pretty well, thank you very much!) was dedicated to Tom, who was something of a missing link between me and my co-editor, Elaine Westbrooks. To explain that odd notion: for a time during my tenure at Cornell—at the beginning of the Age of Metadata—Tom was the only other person who understood what I was talking about when I tried to discuss metadata. Then Elaine came along, to take over Tom’s responsibilities when he became ill. When Tom unfortunately left us, I decided to become something of a mentor to Elaine, as Tom had been. I never asked her whether she wanted one, mind you, just noticed that she was smart and understood deadlines, and asked her to be co-editor of the book. It certainly worked out for me, especially when I broke my right arm while we were still setting up the book and the contract … but that’s another story. I’m not sure all the reasons why the release of the festschrift took so long, but the result was that something I wrote eons ago (in Internet time) is now “just out.” I’m not assigning blame, mind you—I’m hardly one to cast the first stone—but it seemed like a good idea to point out where my thinking has moved on beyond that article and where the issues I brought up then still have legs.

    The issue that still speaks loudest (at least to me) is the one about standards maintenance. The bald fact is, in 2005, when I wrote most of the article that appears in the festschrift, I wasn’t yet convinced that MARC was dead, and I was looking at the issue of how standards were maintained primarily in the context of Dublin Core. Most of my experience with “process” in that context had been on MARBI, and in fact MARBI was a direct progenitor to the Dublin Core Usage Board, on which body I served until last fall. In the festschrift article, I take a few potshots at MODS (as is my usual habit) primarily because, at the time, the maintenance process for MODS consisted of one mailing list dominated by XML geeks. The MODS squad has wised up since then, and has set up a maintenance group with some credibility, but some of the damage has been done and can’t easily be undone. (And if you think I’m picking unfairly on MODS, ask me about DC Source).

    Process is not an insignificant issue in the life of a would-be standard, and it is indeed staring us in the face yet again, in the guise of RDA. There has been a bit of conversation on the RDA-L list recently, precipitated by the announcement that Tom Delsey will be stepping down as Editor once RDA is officially released. So the question was, “what’s the plan for maintenance?,” and the answer given by Marg Stewart was just the sort of answer that was intended to reassure, but certainly didn’t reassure me: “The JSC will revert to its process of handling updates to RDA as it had for AACR2. Namely, the update process will be handled by the JSC itself.”

    Why am I not reassured? I can’t help looking back at the process of creating RDA in the first place. In the beginning, there was the closed room with the JSC working under the cone of silence. Then, after rumblings from the field, drafts were released only to specific people in selected organizations who then became gatekeepers for their communities. Then when that didn’t work very well, drafts were released publicly. But still, the same small group made the decisions, managed the discussion, and held their meetings essentially behind closed doors, with decisions handed down from on high in a process that seemed anachronistic at best and elitist at worst. As another un-reassured commentator noted:

    “And the report of the last JSC meeting shows us, that we have created a process which is so huge, that we couldn’t manage it: only a third part of the suggestions could be discussed. In spite of modern means of communication, it’s not sure, that we are able to handle a world wide process for developing a cataloging code.”

    I think we need to look at the process of updating and maintaining RDA anew, recognizing that the process that created the text was problematic at many levels, certainly overly expensive, and in this age of social networking and virtual communities, unnecessarily limited in its reach. There’s also the issue that the work done to create the vocabularies and schemas is now essential to RDA, and there needs to be a process that updates those vocabularies, and provides for their rational expansion (into full vocabularies, not just term lists) as well as their extension (with new terms and more appropriate participation). What the community can ill afford is a continuation of JSC as the Marie Antoinette of organizations, perfecting their embroidery skills while the revolution continues on outside the gates of their artificial world. The current process is ponderous, exclusionary, and ensures that the “quality control” measures operate primarily as a bottleneck, without meeting the overall goals of providing consistency and utility.

    What might we like to see in an RDA update process going forward? To start that conversation, let me suggest the following requirements:

    1. The process must include explicit ways for a broader array of libraries to participate, not just the Anglo-American national libraries and library societies. Including these libraries only in the review process is insufficient and condescending.

    2. The process must be more nimble and lightweight, using the community based tools that enable all of us to operate as a virtual community, instead of relying on expensive face-to-face meetings in closed rooms and decision-making based only on formal proposals. The NSDL Registry will be adding capability that will allow simple threaded discussions at a granular level (by property or term), which, with appropriate management, could provide a much better way to flesh out and expand the current vocabularies. This sort of capability is essential at all levels of a newly envisioned maintenance process.

    3. The process must not be based primarily on the elevation of “control” as the first principle. The assumption that seems to be behind the assertions by JSC that they must be the center of the process is that this is the only one way to assure that the textual guidance and the vocabularies grow intelligently. This assumes the re-creation of the AACR2 update process with the same cumbersome, centralized methods, and the multi-year time lines for change. To my mind, this is the most Marie Antoinette-ish notion of all, an absolute denial of reality.

    Can we finally look at what worked and didn’t with the RDA development process, at what the tools available to us provide to meet our needs for broad participation and quality control, and design something that makes more sense? We cannot just keep maintaining the powdered wigs and the formal dancing in the face of the revolution happening outside our gates.

  • Denver Midwinter: All RDA, all the time …

    Yes, it was laughable to imagine that I might blog from Midwinter—silly me. My schedule was insanely full and I didn’t even get to peek into the exhibit hall, much less visit and pick up some swag for the grandchildren. As things move along with RDA, and as I become even more convinced that despite its flaws we need to have it out and used, my conference program became even more ridiculously focused on anything RDA. So there I was at both CC:DA meetings, the RDA Testing meeting, the RDA Implementation meeting, and on, and on.

    I posted briefly before I left for Denver on the work Metadata Management Associates (me and Jon) will be doing with ALA Publishing in relation to the RDA Online product. Some of this will involve integrating the RDAVocab registered elements, roles, relationships and value vocabularies, with the online product, thus ensuring that catalogers using the online product and applications using the Registry output will be linking to and/or referencing the same information (no synchronization issues!) Other tasks involve building XML schemas so that those seeking to build data—whether in the tool or in another application—have somewhere to start. We’ll be working on other bits and pieces to enable support for those trying to see their way forward from where they are to a world where RDA with a FRBR foundation is the way we do description. This is a tremendously exciting project for us and it was nice to see that when I explained it to others they thought so too!

    The RDA Testing meeting, led by Beacher Wiggins, was an interesting one—more so than I had anticipated. The idea is that the effort will be led by LC, NLM and NAL, but it will be open and participants from a variety of venues (including library students and recent graduates) are encouraged to sign up. Beacher emphasized that testers will use the environments they have available, which for most means MARC systems, but if RDA Online can produce records as well, that’s an added opportunity, particularly for systems eager to figure out how these records might behave in newer systems. Testing will last about six months and include a training phase, an active record creation phase, and an assessment phase. After that, the three national libraries will make individual “go” or “no go” decisions. There will be a website at some point, most likely a subset of the website of the LC Working Group on the Future of Bibliographic Control.

    There were a lot of questions about this testing effort, only some of which were asked or answered at the meeting. One of my concerns (which was too fuzzy and formless to ask at the meeting) has to do with the usefulness of testing how much time it takes to create a record under the old regime (AACR2 and MARC21) vs. the new regime (RDA and MARC21? or RDA and the RDA schemas and tools?)—you see part of the problem here. The deck seems pretty stacked towards the old and familiar, despite some attempts to create more balance by ensuring that some of the anticipated participants—the library students and recent grads primarily—will have as little experience with the old regime as they do with the new one. In all cases there will be “subjective” assessment solicited from participants as well as the “objective” results (the time invested in record creation). Part of the plan is that there will be a 20-30 item list of resources to be cataloged, and most participants will do one regime or the other (not both) for a particular resource, with hopes that aggregation of a large-ish number of results will provide a more reliable measure. I’m not sure the “timing test” is going to be particularly useful, given the number of uncontrollable variables likely to be introduced along the way—particularly in whatever technical environment is used—but I’m sympathetic with the notion that looking for a useful objective test in this situation is extremely challenging. It’s obvious to me that we’ll learn something from the objective and subjective portions of the testing, but whether what we learn is going to be clear enough to support either option with sufficient clarity for those who prefer evidence-based reality is quite another story.

    Given the fact that the testing results are likely to be subject to various interpretations and caveats, it’s hard to imagine how any of the national libraries could justify a “no go” decision, and what that would actually entail, if one or more might be inclined in that direction. One hears rumors, which naturally can’t be attributed, that one or two are so inclined but it’s something I’m really curious about. Would a “no go” decision be something like “no go until 2011” or “we’re sticking with AACR2 and MARC21 until Hell freezes over,” and how long would that be supportable? Two years, five years, maybe? It all depends on how long and how messy one thinks the transition would be, and how many would be inclined to lag far behind the early adopters waiting for some undefined
    tipping point. I tend to think that there will be enough of the early adopters, particularly in the open source development community, that by the time the “go”/”no go” decisions are made, the “go” decision would be almost inevitable. But I’m an optimist on this, as I’m told fairly frequently.

    Of course, the timeline for testing is dependent on RDA Online being released on time (3rd quarter, 2009) complete with vocabularies. I’m an optimist on that, too, which is a good thing, since some of it depends on me continuing to work relentlessly on some of my task list. More on that topic in other posts …