On 22/02/2012 17:36, Kevin M Randall wrote:
<snip>This would be all well and good, to claim that FRBR is only an abstraction such as a Venn diagram, but the fact is, one of the major points for the acceptance of RDA with all of its attendant costs and hassle, is that it is the first step on the road to FRBR (which will undoubtedly have many more costs in the future). RDA on its own without the goal of FRBR loses much of its sense, as was mentioned in the Report from LC, NAL and NLM. Therefore, it is not just an abstraction. Plus, FRBR is based on tasks that supposedly are important to the users.
In reading FRBR, it is very important to understand that the figures used are entity-relationship (ER) diagrams, not examples for OPAC displays. The figures illustrate the relationships between the FRBR entities, for the purpose of helping the information professional understand those relationships. (And by information professional, I don't mean the person at the desk involved in a reference interview; I mean people like those who are designing metadata schema and cataloging rules and search engines and OPAC displays.) A particular work will appear one time only in the figure because that is all that is needed to explain its relationship to the dependent expressions. This is part of the standard language of ER diagrams.
I may be able to use a butter knife as a screwdriver in some limited circumstances. But that does not make it a screwdriver, and in most circumstances it would serve poorly as one. It would be very strange for me to complain to the manufacturer of the butter knife that they made a faulty screwdriver.
Likewise, the FRBR diagrams do not serve well as designs for OPAC display, precisely because that is not what they are intended to do, any more than Venn diagrams in an explanation of Boolean searching imply that search results should show up to the user in interlocking circles. The diagrams serve a particular purpose, and that purpose is *not* OPAC display. It is very easy to maintain that FRBR is a conceptual model intended only for librarians (and other information professionals), because that's what it says it is, and it uses language only appropriate for that audience.
Let's try using some other terminology. When a human interacts with this hypothetical FRBR tool that we are aiming for, and comes across the WEMI structure, somehow, somewhere, something has to be displayed that has meaning to the human and that he or she can understand. At first blush, it would seem as if there should be an incredibly wide choice in how to achieve this but in reality, there is much less freedom. Specifically, while the the fonts, colors, placement of information in a left or right navigation bar, and so on and so on, can change in myriads of ways, yet the more basic decision of: do I display each entity in the WEMI once or many times? does not allow that many options. Deciding to display a specific number of times, e.g. two times, ten times, one-half the time, a random number of times, although it could probably be done, becomes very strange.
On the other hand, if we want to state that FRBR has no real relationship to users, that would be fine. Let's just call them "librarian tasks". Of course, the problem with that is, our catalogs fulfill those tasks for us right now and do not need to be changed. But if we did rename them to "librarian tasks," we could at least begin to build something that might make a difference to the people who pay our wages and keep our doors open: the users.