Un-uniform titles

The Open Library will soon be revealing its first attempt to bring together all of the many published books that represent the same work. It's been a fascinating exercise; sometimes very satisfying and other times terribly frustrating. If I hadn't already been convinced that we will need to change our data practices if we want to implement FRBR, this experience would have convinced me.

One of the problems that we ran into was one that Thom Hickey at OCLC had already reported in his blog post: that uniform titles (MARC 240) are both necessary for the identification of works, and a hindrance. The uniform title, which is being called the 'work title' in RDA (see Chapter 6) actually serves two (possibly three) different functions, and unfortunately this is not being fixed in RDA.

The first function of the work title is to bring together the different expressions of a work. This is mostly obvious for works that have been issued with different titles (the various Hamlets over time) and for works that have been translated (which also includes Hamlet). In this case, the work gets a 'work title' that is unifying, and this work title helps create work views in bibliographic databases.

Shakespeare, William, 1564-1616
Hamlet.
The tragedy of Hamlet Prince of Denmark, as is now acted by Her majesties Servants.

Shakespeare, William, 1564-1616
Hamlet.
The tragicall historie of Hamlet, Prince of Denmarke.

Shakespeare, William, 1564-1616
Hamlet.
William Shakespeare's Hamlet, Prince of Denmark.

The second function performed by the uniform title field is to give works a collective title. These are titles like 'Essays' or 'Works.' This is a title given to a grouping of works, not a single work. It's kind of a superset of works, and the same work title can be given to a different selection of an author's works. This uniform title does not help gather and display the FRBR work level, and in particular it isn't useful for user displays because the grouping title is so broad and vague. It probably would be useful as a genre for retrieval, but it's not great as an organization for works. In particular, you wouldn't want to present these to users as the same work:

Bacon, Francis, 1561-1626.
Essays
The essayes or counsels, ciuill and morall, of Francis Lo. Verulam, Viscount St. Alban

Bacon, Francis, 1561-1626.
Essays
The essaies of Sr Francis Bacon knight, the Kings Atturney Generall. His Religious meditations. Places of perswasion and disswasion. Seene and allowed

These are of the genre essays, and a genre data element is commonly used as a facet in systems that have that functionality. But the genre should not be confused with the work title, as it is here.

The function that may or may not be a third function relates to the additions to the uniform title, which really should be handled elsewhere in the record. Thus:

Hamlet. French
Hamlet. German
Hamlet. Italian

Languages and dates get all mixed in with the title of the work when the title is a 'heading' in the bibliographic record. Like the use of the uniform title for genre, systems today can provide this kind of organization, if it is desired, from data in the record, and can use it for a variety of purposes such as selection or grouping. There is absolutely no need to tack this data onto the work title now that records are no longer being placed in linear catalogs.

Note that I'm aware that I haven't expounded on the uses of uniform titles in music cataloging. The uniform titles in music cataloging are fascinating constructs for the arrangement of musical pieces, but they are not work titles. I haven't had any experience trying to create work views of music, however I'm sure that's a very interesting problem; one that I hope someone else will solve and share with the rest of us.

We need a work title if we are to follow the bibliographic concepts in FRBR. One of the big problems with the data we create today is that so many data elements are performing multiple functions that may be clear to humans but aren't coded in such a way to be clear for machine processing. That this same mistake is being made in RDA, which is supposed to be based on FRBR, shows that we still aren't designing our data for machine processing. In this day and age, that is pretty sad.