Wednesday, February 21, 2007

FRBR User Tasks

I have long had a hard time with the FRBR user tasks, but haven't been able to quite articulate it. This is an attempt to do so.

The steps defined by FRBR are: find, identify, select, obtain. To me this describes the actions of a user approaching a library catalog with a known item in mind, and the way the tasks are defined confirms this to me.
  • to find entities that correspond to the user's search criteria
All actions begin with a search, and the search is initiated by a user. This eliminates a number of ways that catalogs can be used to link to other resources, or to analyze relationships, and a host of other functions that don't involve a user (including FRBR-zing, ironically enough). It also doesn't seem to take into account browsing, serendipity, or other ways that users encounter resources. All of the steps prior to "find" are ignored, as if the catalog doesn't intend to address them.

  • to identify an entity (i.e., to confirm that the entity described corresponds to the entity sought, or to distinguish between two or more entities with similar characteristics)
The trouble I have with this one is that there is an "entity sought." This assumes that the user has some idea of what they will find when they do the search. I don't think that's always the case. The classic user task as defined by Cutter is: "What does my library have on this topic?" To me, that general question doesn't necessary have a "sought entity" as its goal.

This also seems to skip a step, which is the evaluation of the search results. For someone who is exploring a topic rather than looking for a specific item, the retrieved set itself needs analysis. It could have items that are incongruous as a set (Java the country and Java the programming language). It could have both highly popular and totally obscure works. It could have items suitable for the user (a current edition of Mark Twain's Huckleberry Finn) or quite unsuitable (a translation of Huckleberry Finn into Latvian). The user may need to see the set analyzed into facets (geography, programming languages), or may need a ranked display showing which items have been selected most often by other users, or which are most commonly held in similar libraries. For some users, there will not be an entity to identify, and the retrieved set will often be too large for the user to look at each one individually.

  • to select an entity that is appropriate to the user's needs (i.e., to choose an entity that meets the user's requirements with respect to content, physical format, etc....)
This is the librarian's dream user -- one who knows what he needs and can interpret the entry in the catalog to that end. In fact, I suspect that most selection has an element of randomness, with the except, perhaps, of the selection on format or availability. The user may be looking for a movie, or may specifically NOT be looking for a sound recording, but I wouldn't want my salary based on how many times a user has made a selection from the catalog based on a note saying "Includes bibliographical references (p. [403]-449) and index." Also, in an environment where many items are available electronically, selection may follow "obtain," as it does in bookstores or in the open shelves of libraries. It is interesting that the FRBR user tasks ignore the interaction between the catalog and the shelves (analog or virtual). We know that users may look in the catalog under subjects to find a general shelf area to browse in; they may browse the shelf and then turn to the catalog. In fact, the FRBR user tasks have no iteration at all, whereas many of us can attest based on our own experience that many searches may be performed before the user begins to look at specific items in retrieved sets.

  • to acquire or obtain access to the entity described (i.e. to acquire an entity through purchase, loan, etc., or to access an entity electronically...)
I suppose we can ignore the person who is compiling a bibliography and will return at some point to actually access some works, or the one who was looking up a book to answer a question in a crossword puzzle (one of my main uses of catalogs, I admit). What is interesting here is the implication ("through purchase, loan, etc.") that the library catalog leads users to a wide variety of resources beyond the library itself. Yet, where library catalogs show their weakness is in limiting themselves to the works held (or licensed) by the library. There was a time when that was sufficient, since books and other works were scarce. That time ended around 1900, however, with a robust publishing industry. Now, with a highly networked electronic environment, scarcity is definitely in the past. A catalog of what is held by the library is useful to the person in the library who wants to go to the shelf and pick something up right now, but it is no more an information system than the inventory database at the local Barnes & Noble store. Users may discover that something is available through interlibrary loan precisely because it is NOT in the library's catalog, but only if they have gone to the library with a specific citation in hand. In fact, this entire FRBR task set ignores that the library catalog is but one information source in a huge sea of information sources. A catalog that represents the information resources in a single library is an anachronism in today's global information society. Looking for a particular book on a particular shelf is the very tail end of a complex process, a process that libraries seem to have stepped away from.

What it all comes down to is that the FRBR user tasks are limited in scope, and as such they limit how we think about users and catalogs. I'm thinking about an expanded set of user tasks (and even non-user tasks), and invite suggestions, both here and at http://futurelib.pbwiki.com.

4 comments:

Irvin Flack said...

Karen

Thank you for your stimulating blog.

As a use case for 'identify' I've always pictured a cataloguer with a new book in hand, wanting to find out if the catalogue already has a record for the item or if they need to create a new record.

Elaine Svenonius suggested some changes to the original FRBR objectives which I believe RDA has taken up: http://www.collectionscanada.ca/jsc/prin.html

She adds a fifth objective, 'To navigate a bibliographic database (that is, to find works related to a given work by generalization, association, or aggregation; to find attributes related by equivalence, association, and hierarchy)'. That might partly cover your point about browsing and serendipity.

She also changes the first objective to 'locate' and splits it into two parts: 'find' and 'collocate" to roughly reproduce Cutter's first two objectives.

Irvin Flack
Metadata Librarian
Centre for Learning Innovation

Anonymous said...

I think Svenonius's changes are a big improvement, and I think things can be improved further just by taking out unneccesary limitations.

Svenonius's "find" vs. "collocate" essentially corresponds to a known-item search (find), vs. a search on some characteristic (collocate--assemble all the records sharing some characteristic). That search on some characteristic doesn't necessarily, I agree, need to be explicitly defined by a user--in general, I agree with Karen that we shouldn't neccesarily think of the user's explicitly formulating their objectives in these terms. But nonetheless, I think these are the things that the _system_ needs to do to meet user needs.

This stuff gets confusing and abstract quickly. But I do think there's a lot of value in those basic 'user tasks'. Now, these are called 'user tasks' so maybe it's odd for me to be saying they aren't neccesarily the way the user actually should be expected to think about things---maybe they shouldn't be. Maybe they're really 'system functions that must be supported by metadata.' Maybe we need some user tasks (or needs?) on top of that that are different---and the system functions are what the system must be able to do perform in order to meet those needs?

It does get awfully confusing fast for me, when I try to think about it. This is tricky stuff.

Jonathan Rochkind

irvin flack said...

Yes! I'm all for concrete examples.

Also, I feel both FRBR and Svenonius' book are describing a different information universe to the one we are now in. Both are brilliant syntheses of 150 years of cataloguing experience but they don't take into account the changes brought about by the web and digital publishing--not that they could be expected to at the time they were written. So it would be surprising if the FRBR user tasks--and the entities--didn't need reviewing in the light of such major changes.

-Irvin

Mia said...

FRBR user tasks are those which, in addition to searching, are otherwise "making use" (FRBR Final, p.8) of the data exposed.

In my view, FRBR attempts to provide a framework in which THIS berry can be recognized by a human to be in a state of "pickable-ness"; as opposed to THAT berry which is not. (cf Bates and many others on the iterative nature of browsing/finding/identifying, etc.)

We "make use" of the aggregated data bits exposed: by pursuing, by casting aside, by changing direction, by backtracking, by zeroing in, by using any and all cues available at the moment. It never stops.

There are an infinite number of possibilities existing in users' minds which may satisfy the "pickable-ness" of a berry at any given time.

FRBR is attempting to provide a framework establishing the key components, including relationships among components, which allow something to be recognized by as a desirable berry for picking. Once picked, one probably wants to do something further with it, and is completely free to do so.

Perhaps my view is too expansive, but nonetheless there it is.

Mia Massicotte