Kevin M. Randall wrote:
The elements are required to BE there, but there is no requirement at all that all entities related to a resource display ever and always whenever the record for the resource is being displayed. They just need to exist, able to be displayed when needed and appropriate. The DISPLAY of all of these things all together is not the purpose of FRBR. The FUNCTIONALITY of the elements and their relationships is the underlying purpose (thus the title, "Functional Requirements for Bibliographic Records"). With those relationships coded into the records (or data linkages), the resource can be found whether the route to it happens to be through this attribute, that attribute, or yet some other attribute. What elements display to the user are totally dependent upon the context (type of catalog, type of search, user settings, etc.). Sometimes a display of the "complete bibliographic history" might be necessary to help the user find what they need; in most cases, I'd say it would not.
FRBR is not about display; it doesn't even talk about display. FRBR is an analysis of the specific data elements required to reflect logical attributes and relationships. How those data elements are displayed to the user are entirely outside the scope of FRBR.I have seen this mentioned a lot that FRBR does not discuss display, but therein lies a problem: if we say that FRBR is *only* about functions, and nothing else, then there is no reason to change anything at all since the catalog today fulfills all the FRBR user tasks, just as it did in the 19th century. We create, and have created from that time, records that can be found/identified/selected/obtained by their works/expressions/manifestation/items using authors/titles/subjects. It was just more complex to do that in the card catalog (and the virtual card catalogs we have today) than in the printed catalog, as I tried to illustrate earlier.
The only difference FRBR introduces from what we have today is getting rid of the "unit record". It does this by creating entity-level records where there will be a *single* record for each work (importing names, subjects, and other information), a *single* record for each expression (with parts of the uniform title, perhaps editors, translators, etc.), a *single* record for each manifestation (as we supposedly(!) have today, but it will import related work and expression information), while items can do whatever. There are various relationships among everything. The function is the same as today.
What is the purpose to change, retrain everyone and retool everything, to create these single records? To continue doing what we do today and have everything display over and over in separate unit record displays? That could be done, but it would be senseless to retool and retrain everyone to wind up doing exactly what we do today. And what about those examples we see in FRBR that have those FRBR displays? The single entity records are there to display a single time, otherwise there is little sense in it; or perhaps it deals with strictly internal database maintenance, but this has nothing to do with "function". Of course today, modern formats and methods can display repeated information only one time through automated means, and there is no need to have single records for each entity.
The other point, which I keep bringing up, is that there are relatively few users out there--and I think their numbers are decreasing all the time--who would agree that by following FRBR, we will create records that are indeed "functional", at least for their needs, since many find the current catalog not functional but dysfunctional.