Also, the talk I gave at SWIB2015 is now viewable on youtube: Mistakes Have Been Made. That is a much shorter (30 minutes) and less subdued explanation of what I see as the problems with FRBR. If that grabs you, some chapters of the book will give you more detail, and the bibliography should keep anyone busy for a good long time.
Let me be clear that I am not criticizing FRBR as a conceptual model of the bibliographic universe. If this view helps catalogers clarify their approach to cataloging problems, then I'm all for it. If it helps delineate areas that the cataloging rules must cover, then I'm all for it. What I object to is that implication that this mental model = a data format. Oddly, both the original FRBR document and the recent IFLA model bringing all of the FR's together, are very ambiguous on this. I've been told, in no uncertain terms, by one of the authors of the latter document that it is not data model, it's a conceptual model. Yet the document itself says:
The intention is to produce a model definition document that presents the model concisely and clearly, principally with formatted tables and diagrams, so that the definitions can be readily transferred to the IFLA FRBR namespace for use with linked open data applications.And we have the statement by Barbara Tillett (one of the developers of FRBR) that FRBR is a conceptual model only:
"FRBR is not a data model. FRBR is not a metadata scheme. FRBR is not a system design structure. It is a conceptual model of the bibliographic universe." Barbara Tillett. FRBR and Cataloging for theFuture. 2005This feels like a variation on the old Saturday Night Live routine: "It's a floor wax. No! It's a dessert topping!" The joke being that it cannot be both. And that's how I feel about FRBR -- it's either a conceptual model, or a data model. And if it's a data model, it's an entity-relation model suitable for, say, relational databases. Or, as David C. Hay says in his 2006 book "Data Model Patterns: A Metadata Map":
Suppose you are one of those old-fashioned people who still models with entity classes and relationships.It's not that entities and relations are useless, it's just that this particular style of data modeling, and the technology that it feeds into, has been superseded at least twice since the FRBR task group was formed: by object-oriented design, and by semantic web design. If FRBR is a conceptual model, this doesn't matter. If it's a data model -- if it is intended to be made actionable in some 21st century technology -- then a whole new analysis is going to be needed. Step one, though, is getting clear which it is: floor wax, or dessert topping.