On 24/07/2012 21:01, Marc Truitt wrote:
Umm, with due respect to Jim, I’m not so certain that I agree with the implications of this statement. All new/enhanced functionality has to start *somewhere*, and unless we accept that it may be incomplete or imperfect, we will never implement it. As I understand Jim’s view, one could easily argue that we should never have begun adding contents notes or TOCs to bibliographic records either, unless we intended to go back and do all the millions of legacy records we’d created before that lacked such information. Or, to take another (perhaps extreme) example, it might be argued that we should never have used MARC for anything at all except card production, lest we otherwise be forced to rely on split files, one online and the other representing the huge pile of paper-based cataloguing.
But of course, that’s *precisely* what many of us did, for many, many years. Yes, there were recon projects in many places — believe it or not, I’m working in an institution that is only now nearing the end of that tunnel! — but we accepted the fact that automating would result in split files for years or even decades. And some of us continue to accept this situation, cumbersome though it may be.
In my mind’s eye, I can imagine an implementation of FRBR that someday might allow me to ask the catalogue — whatever catalogue — to show me all the manifestations of all the expressions in a collection that could be said to be traceable back through the Western literary tradition that begins with the work _Romeo and Juliette_. It’s pie-in-the-sky right now, but you might call it my proof-of-the-pudding FRBR fantasy. But in order to have even a remote hope of getting there, I have to accept that we start drawing relationship links at some point. We worry about the unlinked previous objects sometime after that point.
We regularly implement new features and functionalities in our systems, knowing full well that they will not apply to work we’ve already done for a long time, if ever. It’s a part of life, and we all simply deal with it.
It seems to me that it is much better, especially given the powers of modern systems, to focus on what we can provide–right now, today, instead of aiming toward possibilities that may or may not give semi-decent results after 15 or 20 years or so, but we know that we will have to undertake huge retrospective projects before decent results are even possible. If new capabilities such as gender are needed so badly, we should discover what other tools exist (e.g. even books!) that may give even better information to the public right now. The catalog was always primarily a pointing device and to expect it to do fundamentally different tasks such as to “find all female authors writing on spiritual matters” is asking the catalog to do more than it was originally designed to do. It seems much the same as someone saying, “Let’s add barcodes to the books so that it makes circulation easier. I just made a new field for the barcodes” and walking away. When adding new books, it’s easy, so for the catalogers, who focus on adding the new items, it’s easy, but for the rest of the library and its patrons, when you are looking at tens or hundreds of thousands of books already in a collection, or more, and they are currently being used, it creates huge problems for everybody else that people will have to solve somehow. Therefore, it will take significant resources for a long time to make the barcodes really useful. It may be decided that adding barcodes may, or may not, be worth the costs and efforts because there are definite benefits, but adding gender is of a completely different nature.
As I said before, if somebody finds the cash to add the gender field or even if the work is crowdsourced it may be worthwhile, but it seems to me that not putting practical considerations front and center means promising more than we could ever furnish and setting ourselves up to fail. Today, there are new possibilities: are there ways of hooking into other systems that may have this information? If so, is it enough to just point to those resources (i.e. catalog them), or do they have to be incorporated into the mechanisms of the catalog? If they are to be incorporated, what does that entail? Is this the best way to use the library’s resources? These are logical questions and yes–it means making a business case.
I confess that in many ways, I am incredibly conservative as a cataloger. (Not so much in other ways) I fear that if we are not very careful, we could easily make our database obsolete, or spend time filling it up with lots of information that cannot and will not be used, and thereby promise far too much that can never be fulfilled–at least not without scads of manual updates. That would be setting ourselves up for failure. And our field cannot afford that right now. Saying that something might come in handy someday runs into the same arguments that has provoked the cataloging simplification of the last several decades, where so many notes and other practices were eliminated. We shouldn’t start that process again. After all, Seymour Lubetzky himself came up with the question: “Is this rule necessary?” Still wise words today.
At the same time, there is a great deal of data in our records that goes unused right now. We should be concentrating our efforts on that.
In my mind’s eye, I can foresee a time when 95% of everything is digitized and OCR’d, so that contents notes and TOCs will be searched in the items themselves, and that same information in the catalog will become more or less obsolete. There will still be cleanup but it will be correcting the OCR–something that many, many people, including myself want. At the same time, with improved OCR all kinds of additional computer manipulation could be done, much like a Google Ngram Viewer, but much improved. http://books.google.com/ngrams. For an idea of what the current directions are in these fields, see John Unsworth’s talk at MIT http://video.mit.edu/watch/building-and-using-big-digital-libraries-john-unsworth-11546/ where he discusses some of these new capabilities.