Metadata Matters

Category: BibFrame

  • Whither CC:DA?

    Back in the old days (Feb. 2014, to be exact), I published a blog post entitled: “Wake Up Call for CC:DA”, written during an excruciating conversation at the tail end of a CC:DA meeting at Midwinter 2014. As part of that I recommended that CC:DA change its focus:

    “What we need here is to change the conversation, and no group is more qualified to do that than CC:DA. To do that it’s absolutely necessary that its membership become more knowledgeable about what is now possible in automating metadata creation. Without that kind of awareness, it’s impossible to start thinking and discussing how to focus less of CC:DA’s efforts on that part of the cataloging process which should be done by machines, and more on what still needs humans to accomplish. There are several ways to do this. One is by dedicating some of CC:DA’s conference time to bringing in those folks who understand the technology issues to demonstrate, discuss, and collaborate.”

    There were no comments to that post (not much of a surprise), but in the years since, change has been forced on CC:DA as a result of the RSC’s push to change RDA from the Anglo-American focus of the past to one more international and multilingual. This has changed CC:DA’s status from the 800 lb. gorilla whose discussions went directly into the ears of the RSC (then the JSC) to a cranky corner of the RDA peanut gallery. The Europeans, many of whom are actually using RDA, have taken center stage, leaving the Americans to cope (or not) with BibFrame (characterized by some across the pond as just another remnant of America’s colonial aspirations).

    Like most change, that’s the bad news and the good news, depending on your point of view. Mine (again no surprise) is that this shift is the good news, or will be when the CC:DA community decides to make it so. IMO, the usual CC:DA conversation, most often focused on the ‘rules’, has resulted in keeping back the American discussions of what the future looks like for the metadata community. Europe is far ahead of us, having been relatively powerless to change the guidelines, and has instead been focused on learning more about the data models they need to know about to evaluate what they do now and how that needs to change. There has been far more experimentation and implementation in Europe than we’ve managed in the U.S. (the BF distraction is part of that) and as they have developed much more sophistication in their thinking.

    So what should we do to change that? Some possibilities:

    1. Start talking about what metadata should or could be for our present and future, whether creation, evaluation, distribution or improvement. Figure out what we know and don’t know and how we can learn what’s going on in the metadata world outside libraries and how we can apply that knowledge in libraries.

    2. Set up a working group or committee to take that discussion and develop a curriculum for CC:DA with the intention of building up skills and understanding to spread around, within and beyond CC:DA, as well as throughout the cataloging community (which desperately needs leadership in this area).

    3.Determine who within ALA and allied organizations can participate and assist, by preparing reading lists, developing and/or linking to existing materials, and leading discussions (both f2f and online). Eventually we’ll need to set up a variety of strategies for supporting and expanding these opportunities.

    This is clearly not part of the current remit of CC:DA, and the budget does not yet exist for this kind of effort. Clearly there will need to be partnerships and allies for an effort like this, but we’re already behind, so let’s get started.

    [I plan to make a proposal to CC:DA to start talking about this, so watch this space.]

  • Hey BibFramers, what’s it all about?

    One of the ongoing myths about RDA is that it’s just a set of instructions and rules for the creation and maintenance of bibliographic metadata, regardless of data model. This has never been entirely accurate, since the RDA instructions explicitly reference RDA’s FRBR-based metadata model, which was significantly modified by BibFrame. But the notion of RDA-as-rules divorced from its data and infrastructure seems still to be part of the promotion of Bibframe. This is not helpful, and when the misinformation is stated over and over it begins to look like an Alternative Fact.

    For example, as part of the Bibframe Update presentations at ALA in Chicago, it was stated that the Bibframe editor will have the “RDA rules hot linked to element labels” (presumably from the Toolkit) to assist catalogers using BF to create bib data. I find this difficult to get my head around — BF and RDA use different reference models, name things differently, etc. And the RDA 3R project to reorganize and rewrite the instructions to align RDA with the IFLA LRM (which is both more extensive than, and less aligned with the Bibframe model) is well underway, and will likely confuse the issue even more.

    The contention that RDA guidance can be used to build BF data is certainly not new. What is new was the momentum of change in process with RDA, from the R3 project, to the internationalization of RDA governance, to the growing list of translations. When the 3R Project is complete (early next year), the RDA instructions in the Toolkit and the data in the RDA Registry will be far more integrated than AACR and MARC ever were. Whether that integration will leave room for BibFrame to use the new instructions is unclear.

    There was an impressive list of RDA information sessions at Annual, and an increasing numbers of folks attending them. This suggests that the RDA message seems to be gaining momentum, and there’s mounting evidence that this is so. A few presentations from the “RDA towards Linked Data sessions, held in conjunction with the European RDA Interest Group (EURIG) annual meeting in Fiesole, Italy this May illustrate that point:

    In his presentation, Philip Schreur pointed out that RDA “is a natural representation of our data on the Web” because of its extensible and flexible framework, its rich treatment of relationships, and its focus on resource discovery.

    Gordon Dunsire’s presentation showed how the wider implementation of the “4-fold path” in RDA for data capture and storage is intended to support a full range of data representation from catalogue cards, flat file schema, and RDBMS, to linked data.

    Most people who attended the RDA sessions in Chicago seemed to be very interested in RDA’s approach, in particular how the data is handled, the growth of translations, and the strong desire to extend RDA to meet the needs of specialized cataloging communities. A meeting to explore the needs of those communities was exceptionally well attended, with lots of good suggestions. And the RDA Linked Data Forum (where people actually got a chance to ask questions!!) was standing room only. (My slides are here).

    There are definite challenges for the North American cataloging community moving forward if they want to avoid isolating themselves from the rest of the bibliographic world, by and large unenthusiastic about BibFrame. The Anglo-American cataloging rules are fading into the distance as the rest of the world embraces the reality of a truly multinational, multilingual, multicultural metadata environment, exemplified by the RDA/LRM bibliographic model. The North American bibliographic community has never been explicitly “America First” and now is not the time to start.

    Stay tuned.

  • Denying the Non-English Speaking World

    Not long ago I encountered the analysis of BibFrame published by Rob Sanderson with contributions by a group of well-known librarians. It’s a pretty impressive document–well organized and clearly referenced. But in fact there’s also a significant amount of personal opinion in it, the nature of which is somewhat masked by the references to others holding the same opinion.

    I have a real concern about some of those points where an assertion of ‘best practices’ are particularly arguable. The one that sticks in my craw particularly shows up in section 2.2.5:

    2.2.5 Use Natural Keys in URIs
    References: [manning], [ldbook], [gld-bp], [cooluris]

    Although the client must treat URIs as opaque strings, it is good practice to construct URIs in a systematic and human readable fashion for both instances and ontology terms. A natural key is one that appears in the information about the resource, such as some unique identifier for the resource, or the label of the property for ontology terms. While the machine does not care about structure, memorability or readability of URIs, the developers that write the code do. Completely random URIs introduce difficult to detect semantic and algorithmic errors in both publication and consumption of the data.

    Analysis:

    The use of natural keys is a strength of BIBFRAME, compared to similarly scoped efforts in similar communities such as the RDA and CIDOC-CRM vocabularies which use completely opaque numbers such as P10001 (hasRespondent) or E33 (Linguistic Entity). RDA further misses the target in this area by going on to define multiple URIs for each term with language tagged labels in the URI, such as rda:hasRespondent.en mapping to P10001. This is a different predicate from the numerical version, and using owl:sameAs to connect the two just makes everyone’s lives more difficult unnecessarily. In general, labels for the predicates and classes should be provided in the ontology document, along with thorough and understandable descriptions in multiple languages, not in the URI structure.

    This sounds fine so long as you accept the idea that ‘natural’ means English, because, of course, all developers, no matter their first language, must be fluent enough in English to work with English-only standards and applications. This mis-use of ‘natural’ reminds me of other problematic usages, such as the former practice in the adoption community (of which I have been a part for 40 years) where ‘natural’ was routinely used to refer to birth parents, thus relegating adoptive parents to the ‘un-natural’ realm. So in this case, if ‘natural’ means English, are all other languages inherently un-natural in the world of development? The library world has been dominated by the ‘Anglo-American’ notions of standard practice for a very long time, and happily, RDA is leading away from that, both in governance and in development of vocabularies and tools.

    The Multilingual strategy adopted by RDA is based on the following points:

    1. More than a decade of managing vocabularies has convinced us that opaque identifiers are extremely valuable for managing URIs, because they need not be changed as labels change (only as definitions change). The kinds of ‘churn’ we saw in the original version of RDA (2008-2013) convinced us that label-based URIs were a significant problem (and cost) that became worse as the vocabularies grew over time.
    2. We get the argument that opaque URIs are often difficult for humans to use–but the tools we’re building (the RDA Registry as case in point) are intended to give human developers what they want for their tasks (human readable URIs, in a variety of languages) but ensure that the URIs for properties and values are set up based on what machines need. In this way, changes in the lexical URIs (human-readable) can be maintained properly without costly change in the canonical URIs that travel with the data content itself.
    3. The multiple language translations (and distributed translation management by language communities) also enable humans to build discovery and display mechanisms for users that are speakers of a variety of languages. This has been a particularly important value for national libraries outside the US, but also potentially for libraries in the US meeting the needs of non-English language communities closer to home.

    It’s too easy for the English-first library development community to insist that URIs be readable in English and to turn a blind eye to the degree that this imposes understanding of the English language and Anglo-American library culture on the rest of the world. This is not automatically the intellectual gift that the distributors of that culture assume it to be. It shouldn’t be necessary for non-Anglo-American catalogers to learn and understand Anglo-American language and culture in order to express metadata for a non-Anglo audience. This is the rough equivalent of the Philadelphia cheese steak vendor who put up a sign reading “This is America. When ordering speak in English”.

    We understand that for English-speaking developers http://bibframe.org/vocab/title is initially easier to use than http://rdaregistry.info/Elements/w/P10088 or even (heaven forefend!) “130_0#$a” (in RDF: http://marc21rdf.info/elements/1XX/M1300_a). That’s why RDA provides http://rdaregistry.info/Elements/w/titleOfTheWork.en but also, eventually, http://rdaregistry.info/Elements/w/拥有该作品的标题.ch and http://rdaregistry.info/Elements/w/tieneTítuloDeLaObra.es, et al (you do understand Latin of course). These ‘unnatural’ Lexical Aliases will be provided by the ‘native’ language speakers of their respective national library communities.

    As one of the many thousands of librarians who ‘speak’ MARC to one another–despite our language differences–I am loathe to give up that international language to an English-only world. That seems like a step backwards.

  • Fresh From ALA, What’s New?

    In the old days, when I was on MARBI as liaison for AALL, I used to write a fairly detailed report, and after that wrote it up for my Cornell colleagues. The gist of those reports was to describe what happened, and if there might be implications to consider from the decisions. I don’t propose to do that here, but it does feel as if I’m acting in a familiar ‘reporting’ mode.

    In an early Saturday presentation sponsored by the Linked Library Data IG, we heard about BibFrame and VIVO. I was very interested to see how VIVO has grown (having seen it as an infant), but was puzzled by the suggestion that it or FOAF could substitute for the functionality embedded in authority records. For one thing, auth records are about disambiguating names, and not describing people–much as some believe that’s where authority control should be going. Even when we stop using text strings as identifiers, we’ll still need that function and should be thinking carefully whether adding other functions makes good sense.

    Later on Saturday, at the Cataloging Norms IG meeting, Nancy Fallgren spoke on the NLM collaboration with Zepheira, GW, (and others) on BibFrame Lite. They’re now testing the Kuali OLE cataloging module for use with BF Lite, which will include a triple store. An important quote from Nancy: “Legacy data should not drive development.” So true, but neither should we be starting over, or discarding data, just to simplify data creation, thus losing the ability to respond to the more complex needs in cataloging, which aren’t going away, (a point demonstrated usefully in the recent Jane-athons).

    I was the last speaker on that program, and spoke on the topic of “What Can We Do About Our Legacy Data?” I was primarily asking questions and discussing options, not providing answers. The one thing I am adamant about is that nobody should be throwing away their MARC records. I even came up with a simple rule: “Park the MARC”. After all, storage is cheap, and nobody really knows how the current situation will settle out. Data is easy to dumb down, but not so easy to smarten up, and there may be do-overs in store for some down the road, after the experimentation is done and the tradeoffs clearer.

    I also attended the BibFrame Update, and noted that there’s still no open discussion about the ‘classic’ (as in ‘Classic Coke’) BibFrame version used by LC, and the ‘new’ (as in ‘New Coke’) BibFrame Lite version being developed by Zepheira, which is apparently the vocabulary they’re using in their projects and training. It seems like it could be a useful discussion, but somebody’s got to start it. It’s not gonna be me.

    The most interesting part of that update from my point of view was hearing Sally McCallum talk about the testing of BibFrame by LC’s catalogers. The tool they’re planning on using (in development, I believe) will use RDA labels and include rule numbers from the RDA Toolkit. Now, there’s a test I really want to hear about at Midwinter! But of course all of that RDA ‘testing’ they insisted on several years ago to determine if the RDA rules could be applied to MARC21 doesn’t (can’t) apply to BibFrame Classic so … Will there be a new round of much publicized and eagerly anticipated shared institutional testing of this new tool and its assumptions? Just askin’.

  • The Revolution Is On The Way, Televised or Not

    Many of you have heard me say “Time flies, whether you’re having fun or not”–and that has certainly been the case since I got back from the NISO Roadmap meeting a few weeks ago. Somehow, with my head down, I missed part 1 of Roy Tennant’s post “The Post-MARC Era, Part 1: “If It’s Televised, It Can’t Be the Revolution”. I’m old enough to remember the 60’s and the call to revolution that Gil Scott-Heron referred to, and in fact had a small part in it–but since it WAS live, I’ve no evidence to present about my participation, you’ll just have to believe me.

    On the other hand, I’ve been very involved in the revolution under discussion in the remainder of his post, and there’s quite a bit of video to confirm that, including at the beginning of the NISO Roadmap meeting, where Gordon Dunsire and I tossed a few thought-bombs out before the conversation got going. I think it validates Roy’s point about participation to say that the points we made came up frequently in the subsequent small group sessions, which were not, I believe, on the video feed. What I observed as a participant was that more than a few folks left with some new information and (I hope) some expanded thinking about what the revolution was about; more than they came in with.

    Despite the fact that I’ve acquired an undeserved reputation for being a MARC hater, I actually think that we should continue to use the semantics of MARC, and get rid of the ancient encoding standard. It’s in some ways a Dr. Jekyll and Mr. Hyde problem we have here, and we’re about to kill the ‘wrong MARC’ in our exasperated search for something simpler, because we can’t seem to get clear about what MARC is and isn’t. The reality is that the MARC semantics represent the accumulated experience in library description from the days of the 3 x 5 card with the hole in the bottom (see Gordon Dunsire’s presentation on that evolution). We’ll clearly need to map the semantics of our legacy data forward, but that doesn’t require that we carry along the ‘classic’ MARC encoding. Consider the old days of the telegraph, where messages were encoded using dots and dashes. Those messages were translated into written English for end users, who didn’t need to know Morse Code to read them. Now we use telephone messaging and email for those kinds of communications, and Morse Code doesn’t figure in there anywhere.

    In addition, we need to look past all those rarely used MARC fields, and recognize that they are only irrelevant in an environment that looks very much like our current one, with artisanal catalog records records and top-down standards development. That’s not really what we’re hoping for, as we wrap our minds around what an environment based on linked open data might free us to do differently. When systems were built to process MARC-encoded records, those systems needed to be updated at regular frequencies and all the sharing partners moved in lockstep. It was very expensive to manage the code that was the plumbing of those systems and the specialized fields didn’t add much value. But remember that each of the proposals for change were extensively discussed and formally accepted. I was there for many of those discussions, and recognize that not all of them were accepted, but a considerable number were, and then not always (or often) used after they were included in MARC. Before we label all that effort wasted, and attempt to re-litigate all those decisions, let’s take a closer look at the real costs of moving those forward, in the very different environment we’re envisioning, where the costs are differently distributed and everyone need not move in lockstep. It’s entirely possible that some new communities will find these specialized fields very relevant, even though libraries have not.

    Roy quotes from the BibFrame announcement, which states:

    “A major focus of the initiative will be to determine a transition path for the MARC 21 exchange format in order to reap the benefits of newer technology while preserving a robust data exchange that has supported resource sharing and cataloging cost savings in recent decades.”

    It’s still unclear to me (and I’m not alone here), that we really needed a ‘transition path for the MARC 21 exchange format’. Why can’t we join the rest of the world, which is tootling along quite nicely, thank you, without a bespoke exchange format? We have several useful sets of semantics, built collaboratively over the past half century–why would we need to start over? I generally read the BibFrame discussions, but rarely participate, mostly because it all seems like a reinvention of something that doesn’t need reinventing, and I have no time for that. Whatever the BibFrame people come up with will be mappable to and from the other ongoing bibliographic standards, and whoever wants to use it for exchange can certainly do that, but it will never have the penetration in the library market that MARC has.

    It’s also a bit mysterious what ‘preserving a robust data exchange’ actually means. Are we talking about maintaining the current exchange of records using OCLC as the centralized node through which everything passes? What part of that ‘preservation’ is about preserving the income streams inherent in the current distribution model? What is it about linked open data, without a central node, that isn’t robust enough?

    Roy ends his post with something that I didn’t expect, but definitely applaud:

    “Watching the NISO event over the last two days crystallized for me that I had fallen into the trap of thinking that the Library of Congress or NISO or OCLC (my employer) would come along and save us all. I forgot that for a revolution to occur it can’t come from the seats of the existing power structure. True change only happens when everyone is involved. Those organizations may implement and support what the changes that the revolution produces, but anything dictated from on high will not be a revolution. The revolution will not be piped into our cubicles, ready for easy consumption. The revolution will be live.”

    We could start by no longer waiting for LC to deliver an RDF version of MARC 21, unencumbered by 50 year old encoding standards. We already have that, at http://marc21rdf.info. Yeah, it needs some work, but it’ll get done a lot faster if we can get some help from the 99% of the library world. Give us a holler if you’re interested.

    Clearly the revolution is not happening on the BibFrame discussion list, it is happening elsewhere.