07.04.2011 08:03, Trickey, Keith:
Just a gentle aside - if members of the bibliogrpahic engine room struggle with this - how is the wider community supposed to make sense of it?
At the end of the day, what matters is if and how catalog users can make sense of it, if not even become attracted to it. The language of FRBR is, at least in important parts, the one of the database engine room, not the bibliographic engine room, which means one room further away from the end user. The two engine rooms must, however, be better able to communicate, so both sides need to have some understanding of the other. Not a new topic at all. The entity-relationship model (don't mix that up with the relational database model!) provides the foundation for FRBR. FRBR was written so as to make database engineers better understand what they are supposed to think and to do. Google's database engineers will have a language of their own, too. But nothing of it seeps through into their user interface, and this is what must be achieved with FRBR as well. The very acronym FRBR must not show up there, and not <shudder> "FRBRized" either, nor "entity" or "expression" or "manifestation" and so on. Coming to think of it, "Functional Requirements of Bibliographic Records" does not really reveal much of what it is talking about. From todays view of database theory, something like "Bibliographically Structured Object Model" (BiStrOM) would be much more plausible, and this could trickle through into the user room as "Bistro Catalog". And get rid of the dry and dreadful "RDA" as well! I mean, how unimaginative can we allow ourselves to get... B.Eversberg
