Reservations About Reservations About FRBR
Back in April I mentioned a short piece by Jeffrey Beall called “Some Reservations About FRBR” (Library Hi Tech News 23: 2 (2006)). I finally got my hands on a copy. It’s quite short, under two pages. I’ll pick out the key arguments and offer some comments. (Others can give far better responses to some of his points and I hope they’ll speak up.) This is the first published anti-FRBR article I’ve seen, and it’s worth reading; it’s too bad it’s not on the open web.
- Beall compares FRBR to the Cooperative Online Resource Catalog, “a new way to share metadata for digital objects,” which failed because it was “decided by committees and organizations and then thrust on the field without sufficient testing and proof” that it was useful.. This is the first I’ve ever heard of CORC so I won’t comment on the comparison, but as for testing and proof, see below.
- Groupthink: “our field discourages dissent.” I’m not a cataloguer, but I haven’t noticed this as a problem. From the outside it looks like a fairly conservative field (which is good, when the job is long-term preservation of information) but not closed to dissent.
- Unwarranted enthusiasm. Beall says that Dublin Core was “largely accepted before being proven” and “has largely failed.” FRBR could prove the same. Is DC a failure? That’s the first I’ve heard of it, but I don’t use it a lot. Beall also says that though FRBR “has not been proven successful, the literature treats it as a smashing success.” I haven’t seen that. It’s a topic of great interest, so it gets attention, but the papers show curiosity, questions, plans, testing, implementations, research, and analysis. Lots have people have raised questions and points that need clarification, but that no-one has rubbished it probably just means it’s a good idea.
- FRBR wasn’t developed in North America. “[A]fter a new standard is proposed, employees in well off organizations organize development meetings in far flung, exotic locales about once a year. It takes at least five years to develop a standard, so participants get at least five, company-paid vacations during that time…. [FRBR's] development occurred in a vacuum, largely devoid of input from practitioners.” Beall objects to where it was developed (by which he means where IFLA’s annual meetings were held), and who could go (people from large institutions who have a good travel budget). All that work was done about a decade ago, so let’s set that aside and look at how things are now. The are four working groups in action right now, and the people on them don’t need to go to IFLA conferences and can do most of their work by e-mail. The list of people on the Working Group on Aggregates can be examined to see if it’s “largely devoid of practitioners.” Pat Riva, the chair of the FRBR Review Group, is a working cataloguer, as is Patrick Le Boeuf, the former chair. I asked Pat Riva about how people can get involved and she said they could e-mail her, or start with their national or specialist associations, which probably have some sort of FRBR group set up and I bet are eager to have interested people join them. The FRBR-influenced Resource Description and Access revisions are being done in an open way (I’ve noted some here) and there’s a fair bit of discussion about it on AUTOCAT and the FRBR mailing list. If you’re interested in FRBR (pro or con), you can speak up as an individual or work through an organization, and your ideas will be considered. (People can post comments here, too!)
- Work, expression, and manifestation aren’t always clearly defined. Serials are hard to handle. True. People are working on this. Implementations will need to have good rules to follow.
- FRBR is chiefly for large libraries. For smaller ones it will just mean more work. I’d object to this on two points: first, that there’s just One Big Library, and sharing between all its various branches will only increase, so it should be made easier to navigate that enormous union collection (and bookstores and music stores); second, that copy cataloguing and good library system implementations will make it easy to manage FRBRized records. Granted, that’s just hand-waving from someone who isn’t a cataloguer.
- MARC records can’t handle FRBR, so sharing records will be harder. Some people think so, others (like Martha Yee) would disagree. How all this will work when widely implemented is uncertain, but yes, it’ll take work and special attention for sharing records.
- “The justification for FRBR is insufficient. It has never been adequately explained why this new model is needed. The current model of bibliographic records is more than adequate at representing library holdings at the work, expression, and item level.” (Beall agrees manifestations aren’t done well enough, I assume.) I wrote a paper in library school (FRBR and Fundamental Cataloguing Rules) showing how FRBR embodies fundamental laws and objectives of cataloguing and librarianship. It’s the next step in the process of making things easier to find and use. Here’s an example of the inadequacy of the current model, at least as displayed by a Dynix system: search my public library’s system for Harry Potter books. Horrible. Any objection to FRBR on the grounds that our catalogues are easy enough to use gets a puzzled look from me.
- Conclusion: “When objective research and extensive beta testing have shown FRBR to be successful, then it should be adopted widely. But not before.”
One problem with the piece is that Beall seems to mix up the FRBR model, as finished in 1997, with current work on implementing it, hence the repeated comments about testing and proof. The people that wrote the original report (Olivia Madison, Nancy Williamson, et al.) put forward a model based on research and experience. If the model is useless, people are free to ignore it. They aren’t. They’re doing research and writing papers about it. They’re starting to implement it, but slowly, because, as Beall points out, to do so is hard work and the rules aren’t completely clear. There aren’t many big implementations to point at right now, and each new one that’s done turns up more questions and problems. That’s a lot of the research and beta testing: not done in labs and written up for journals, but done out in the open, for all to see, by people who want to make their systems better. They think FRBR will do that, and so far it has. OCLC’s xISBN service, for example, is a building block, and it helps LibraryThing group manifestations into works. That’s successful. We can all look at it, try it out, and adapt it if we like it. The new North Carolina State catalogue is run by people who’ve said they think FRBR will make it even better to use. They’re paying salaries for people to do the work, and they’ll test FRBR and drop it if it’s no good.
I haven’t seen wild, unquestioning acceptance of FRBR. Interest in it spread slowly for years, but lately it’s picked up. People who hear about it say, “Hey, that sounds like a pretty sensible way of organizing things … but won’t it be a lot of work? Is it ever going to get anywhere?” Some organizations that can work on it are working on it; others are waiting for better rules and easier tools. FRAR and FRSAR are part of the big plan too, and they should all be considered together. Of course, they’re just new, and all this stuff moves rather slowly, and I can’t point at anything showing how great it’ll all be in five years.
Beall raises some points in his article that I agree with, and he should be happy to hear FRBR people are trying to fix them. On other points, like unwarranted enthusiasm and the lack of testing, I think he’s wrong.
If you have a comment about this, please leave one here. I get swamped by comment spam but I’ll keep a close eye out for real people.
Minor correction: LibraryThing does not use xISBN at all. It would probably help, but we decided to keep the experiment “clean.” In fact, we’re going to release our own xISBN-like service. It makes more errors, but includes more paperbacks.
Comment by Tim — 6 June 2006 @ 9:09 amThe one thing that got my attention from the article was the “DC is a failure” claim. DC is emphatically not a failure. The DC initiative continues to pick up steam, work continues to be done, and DC is in fact being used by all sorts of communities. Everyone involved in DC believes that DC has been a smashing success, has clearly gone over the ‘tipping point’, and it’s future is not in question.
I’m not sure why Beall thinks that DC is a failure. Perhaps someone gave him the idea that library cataloging would be done with DC? This was never really the intention of DC. I’m not really sure what he was talking about. It confuses me.
Your review of the review is good overall.
I do personally think that FRBR needs a lot more work–the model hasn’t been changed in the 15 years since it originated, has it? I’m not just talking about the idea of the four bibliographic entities—FRBR is more than that, and THAT idea needs to be better propagandized—along with further thought on the justification for FRBR. Really, I don’t just mean further justification of FRBR, I mean further thought on what the library catalog of the future should look like. Fantasy mockups of how a user should be able to interact with the catalog, for instance. I think more thought in this direction will make it easier to explain why a _systematic and shared conceptual/data model_ is neccesary. FRBR is the first attempt to create one. FRBR is not done, but a systematic conceptual model that can be shared between catalogers and system designers and everyone else involved is so so crucial, and FRBR is an attempt at that. This does need to be explained better, to people like Beall. If Beall doesn’t realize that current library catalogs are badly broken—well, that’s a battle that’s got to be fought too.
Comment by Jonathan — 6 June 2006 @ 4:10 pm[Rather than end with it, let me start by saying this is largely based on the arguments--and sometimes even the phraseology--of David Weinberger and to a lesser extent Clay Shirky. I'm not kidding; this would be plagarism if I didn't shout it from the rooftops! I'm going to blog about Weinberger soon, and will put up some links. Let me also note that I am not a FRBR expert. I've read the spec. I've never done anything with it. I look very much forward to being educated if I made errors.]
So here are two possible criticisms, both from “left field.” I offer not because I insist upon them, but because they’re both “out there,” and they’re stimulating to think about. They are that FRBR is, like most library systems, unnaturally binary and unduly authoritative.
FRBR is completely binary. An expression either IS or is NOT an instance of a work. “Relationships” allow you to finesse some tricky issues, but the binary choice is essential to system. Someone has to decide what the relationships are between Pyramus and Thisbe, Romeo and Juliet and West Side Story. And that relationship must be binary.
There are, of course, situations that call out for binary answers. Our legal system, despite concepts like “mitigation,” requires a binary determination of guilt. It wouldn’t do to have people serving 2 months time because they were “almost certainly not guilty” of murder. We didn’t let Al Gore and George Bush be president on alternate days. (Roman consuls in the field acted like this, but never mind.)
Are books binary? Surely not. The relationship between works, editions and so forth involve–at least sometimes–irresolvable issues of judgment, taste and perspective. The “reality” of literary connections is both complex and irresolvable. Kenneth Branagh’s Hamlet is a very complete adaptation of Shakespeare’s text, his screenplay a virtual photocopy. Clueless is a rather loose adaptation of Jane Austen’s Emma. And so on forever.
By its very nature cataloging reduces complexity, all the way down to the binary level. Something does or does not fall under the LCSH “Married people–drama.” (In this case, the barrier is set very high, since most plays involve married people, but few get the subject. Macbeth? No. Medea? No. Winter’s Tale? Yes.) There’s power in this binary choice–what simplifies can also clarify. But in large part the binary conventions of cataloging arose from the physicality of book cataloging. Books have a single Dewey because books can only fit one place on a shelf. Books have a limited number of LCSHs because cards have limited room, and card catalogs decline in usefulness as they get larger. Having “Married people–drama” take up two rooms worth of cards, and including 90% of the plays ever written, would be worse than useless. The physical both requires and reinforces. Once a book has its cataloging information printed, people don’t change it. As much as we’d all like to change “cookery” to “cooking,” doing so would be more work than remembering the alias.
The digital world has no such constraints. A book can have as many subjects as you like. Subtleties like being “about marriage, but only obliquely” or a “loose adaptation” can be accommodated, and indeed can suggest a relevancy order. Interested in plays about married people? Here’s a long list, but start here–this stuff is really apposite. (The sort of fuzzy, statistical conceptualization is the best argument for tags.)
The objection about FRBR being unduly “authoritative” is similar. There’s a lot of power in authority. Once authority has decided something, it can be considered settled. Authority prevents “debate” from mucking things up. I imagine some of this goes on anyway, that libraries in Greece have a subject for “Famous Greeks–Alexander the Great” and Macedonian librarians “Famous Macedonians–Alexander the Great.” But nobody’s catalog has “Famous [link to debate]–Alexander the Great.” The system accommodates differences in voice and opinion by “forking,” not by integration.
There are various political and deconstructionist arguments against authority here, none of which I have any sympathy with. But the point remains. Cataloging, FRBR, included assumes one right answer. If there is potential value in differences of opinion, perspective and such not, the value is lost.
Both the binary and authority objections do not require libraries to be wishy-washy or open their records up to the untrained mob. I certainly am not saying that. But, in a digital world, with no physical constraints, you don’t need to make these decisions at the level of the *system* and at the outset. The system could remain flexible–incorporating fuzzy relationships and differences in voice–for whatever value that might provide.
[I might end up posting this, or a modified this on thingology.)
Comment by Tim — 7 June 2006 @ 5:31 pmI believe it’s important to note that the CCQ issue (simultaneously published as a monograph) Beall refers to when claiming the literature refers to FRBR as a “smashing success” is actually titled “FRBR: Hype or Cure-All?” A large volume of discussion on an issue hardly by itself qualifies the issue as a “smashing success.”
Comment by Jenn Riley — 8 June 2006 @ 1:32 pmIn and of itself, FRBR doesn’t do anything; it isn’t a
system. Its a way to think about how to cluster
like things, which also serves to disambiguate them at the
same time. Humans recognize similar things and tend to
shun the unfamiliar. The more bits of data out there, the
more things will naturally coalesce around recognizable
or at least familiar entities (whatever those may turn out
to be).
Boundaries are important for entity description, since
Comment by Mia Massicotte — 8 June 2006 @ 5:03 pmwithout them, retrieval is peculiar to say the least.
The novelty of browsing through exabytes wears off pretty
quickly when you’re trying to find something. As is setting up
elaborate filters to improve precision. Every mouse click is
a binary choice. How can the data clustering approach
be increasingly “intuitive”, is the question. FRBR tries to
advance that, in my estimation.
Once something is fortunate enough to have been found,
it still needs to be examined in order to determine its
usefulness.
The persistent myth that being on working groups (national or
international) allows fun all-expenses paid vacations being trotted
out again. The reality is that going to a conference like IFLA when
you are on committees means the priviledge of working 12 hour days for
10 days straight after very long flights, and going back to the office
first thing the day you get back. You don’t get to see much of the host
city (unless you arrange for additional vacation time), and often you
will have had to either consider the conference itself vacation time
(in addition to having worked those weekends), and you may very well have
had to pay most of the costs yourself, as prestigious universities are
generally long on prestige and short on funds.
So why does anyone do it? Mainly we enjoy the opportunity to engage with
Comment by Pat — 8 June 2006 @ 7:41 pminteresting colleagues who are also serious about doing the best they
can for the library community world-wide.
Tim: I’m not sure I follow you, about FRBR being neccesarily ‘binary’ and the implications.
On your own librarything at the moment: Either an edition (essentially a FRBR ‘manifestation’) _is_ in a work set (a member of a work), or it _isn’t_. My particular copy of Hamlet either is a copy of the work ‘Hamlet’ according to librarything, or it isn’t. It’s binary, right? Why have you coded it that way, if you think these things shouldn’t be binary? Do you think there is utility in, instead of providing the user with “All the people who have copies of Hamlet”, you instead provided the user with, like, this guy has a 75% chance of having a copy of Hamlet; or, 60% of users think the thing this guy has is a copy of Hamlet, 40% think it isn’t. Would this be useful to anyone?
I don’t know, I guess it’s possible something like that could actually be useful in some ways, although I think that, generally, deciding that either it is or isn’t a copy of that work would suffice.
But. I don’t see how the FRBR model constrains us in any way there either. The FRBR model, especially since at this stage it’s really just a skeleton, just a starting point, just a discussion document toward developing a common systematic understanding of the bibliographic universe—the FRBR model would certainly not require anyone to assume “one right answer”. I’m not sure if you’re right about ‘cataloging in general’ (as it’s done now? As it could be done?) assuming that. But nothing about the FRBR model locks us in there. If you can figure out a useful way to assume there are many valid answers to whether a manifestation belongs to a work; or what the title of a work is; or whether two works are related—-the FRBR model won’t prevent you from doing so. Instead, the FRBR model gives us the vocabulary to even discuss these things from a common ground, to use words like ‘manifestation’ and ‘work’ and ‘title’, and ‘relationship’, and have a common understanding of what they are.
Comment by Jonathan — 12 June 2006 @ 2:57 pmTim, as to your point about FRBR being binary, it doesn’t need to be. It all depends on who’s making the decisions (an authority question!) about where to draw the line between X and Y and when X_1 is the same as X_2 or when it’s a Y. Different people, making different systems and applications, can decide the rules differently, depending on their users. In the Family of Works diagram by Barbara Tillett (see What is FRBR?) you can follow those guidelines or not, and no-one will be ashamed of you.
Libraries can put their books wherever they want on the shelves, in order to suit local needs and what works best for the users. Any cataloguing system can do the same, and applications of FRBR for public libraries, for people analyzing pre-Gutenberg biblical texts, for online bookstores, for a Tolkien geek who wants to browse his collection of LOTR books, for AustLit expanding their listings to including everything Australian ever written at all, can all be different but still all be FRBRish. How to make it so that all that great cataloguing and description work can be easily moved from one place to another and loaded right into the system, well, I don’t know. If you think Y is a new work based on X and I think it’s a new expression, maybe our rules could be encoded somehow and when we swap data it’d all be taken care of.
One implementation’s FRBR relationships aren’t fuzzy, but they can be across many different implementations. Not everyone has to agree about when to move from one level of the hierarchy to another.
Comment by wtd — 12 June 2006 @ 8:20 pm