Wednesday, November 01, 2006


I was taken to task in the FRBR Blog for saying that FRBR is not about catalogs.
I don’t understand the statement that FRBR isn’t about catalogues. It’s Functional Requirements for Bibliographic Records, and when bibliographic records are shown to users, that’s called a catalogue.
I realized from this comment that I am using the wrong term when I say catalog. A catalog is defined as a list of items, coming from word roots that mean "list, to count up." Examples are a library catalog, a list of items offered for sale, or the catalog of a museum exhibit that lists the items in the exhibit. In the library, the catalog is an inventory of items owned or held by the library. The library catalog is an inventory of items held in the library, and it was once equal to what users could access in the library. From the early or mid-1800's, the physical library catalog also served the purpose of the user interface to the library's holdings. (Prior to that time, catalogs were mainly used by librarians, and not members of the library's public.)

The as-yet-unnamed thing that I wish to define (and which I mistakenly called a catalog) serves these functions (please add on what I have forgotten):
  1. A list of items owned by the library. This list is at a macro level (e.g. serial titles but not the articles in the serial). Often that level is determined by the purchase unit, since this list interacts with the library's acquisitions function.
  2. Serial issues received. This is usually found in a separate module called a serials check-in system (which replaced the old Kardex)
  3. Licenced resources. These may be listed in the catalog, but they may either/also be found in a database used by an OpenURL resolver or in an ERM system (which is not accessible to users). In some cases, these are listed on a web site managed by the library.
  4. Journal article indexes. These used to be hard-copy reference books. They are now often electronic databases. User interface to these varies.
  5. Items available via ILL. This could be a union catalog of libraries in a borrowing unit. It also is a function that interacts with OCLC's ILL system. This latter usually isn't visible in the user view of the library.
  6. Links and connections from information systems not hosted by the library, such as the ability to link from an article in a licensed database to the full text of the article from another source; or a link from an Internet search engine to library-managed resources through a browser plug-in or a web service.
  7. Location and circulation status information, plus the ability for users to place holds on items or to request delivery of items.
  8. Interaction with institutional services such as courseware.
  9. One or more user interfaces. Many of these services above will have a separate interface just for that service, but there are also meta-interfaces that will combine services.
This is a first stab. I'll post this on the futurelib wiki where it can be easily modified.


Scott said...

Related to point 7 - the ability of library users to check their own accounts (status on waiting lists, items out, fines, etc.) Might be a separate item....

Karen Coyle said...

Right -- maybe the whole user interaction should be a module of its own. It could include writing reviews and other social tagging. Actually, what I really want to see is a set of user tools for managing the personal info-verse, kind of an updated version of V. Bush's Memex. It would be part personal bibliography, part search engine, part mark-up and tagging tool. It would warn you about overdue books, let you know when new books by a favorite author come out. Oh, I could take this fantasy far! Thanks.