The Place of FRBR in Search and Findability

As Christine Schwartz observed in the Cataloging Futures blog, I don’t believe that MARC is the problem with the OPAC or issues with findability.

Functional Requirements for Bibliographic Records—or FRBR—is an important part of organizing bibliographic records using the entity relationship model. An entity is an object that can be uniquely identified. The Marc record itself is an entity—a specific bibliographic edition. Within that entity are other entities (aka access points)—author and subject, for example. RDA is the FRBR inspired code that adds other uniquely identified entities—the aspects of work, expression, and manifestation. An entity can contain other entities. These entitles should be stored outside of the bibliographic entity each in their own table, and only referenced from the Marc bibliographic record.

Functional Requirements for Bibliographic Records—or FRBR—is not Marc, nor is FRBR changing Marc. RDA is the FRBR inspired code that adds the aspects of work, expression, and manifestation to the Marc record.

Doreva Belfiore tweeted:

@dorevabelfiore Doreva Belfiore
#FRBR is a model, not a code. #RDA is the cataloging code that defines attributes to record.

Every entity must be unique in order to prevent the duplication of data. In library science, the basis for an entity should be authority files. Normalization can be improved by utilizing authority files for certain fields of the Marc records. A FRBR entity-relationship database can be queried more accurately; making data more findable. This is especially important as our databases become more and more massive.

“Being able to do this accurately – split the MARC record into work, expression, manifestation and item records, then link multiple expressions to the correct work record – is essential… for transforming a MARC flat file database into a FRBR entitity-relationship database.” (Maxwell, R. FRBR: a guide for the perplexed, p. 135).

Some ILS utilize authority tables within its database design. Some, however, do not. ILS database design is the problem I see with how we store bibliographic information, not Marc itself. One example of the benefits of authority files in ILS database design is the change of the subject heading “cookery” to “cooking.” A normalized database with the subject headings in an authority table would only necessitate one change – in the subject table. The new heading would automatically be reflected in the edition entity, since in this model only a reference to the subject table would actually be contained within the edition entity.

In conclusion, normalizing our databases in which we store our bibliographic records is of critical importance as we seek to serve the library patron, who is not the least bit concerned with how the data is stored. He just wants to find the information for which he seeks. If the library makes it too difficult for him, he will be just as happy with Google—but not necessarily successful in his quest.