There's nothing like inter-continental travel to provide you with those sleepless nights that are ideal for a re-reading of the FRBR document. I am not a cataloger, so I assume that I am missing some or much of the importance of the FRBR analysis in relation to how catalogers view their activity. My reading of FRBR is that it is a rather unrevolutionary macro analysis of what cataloging already is. As a theoretical framework, it gives the cataloging community a new way to talk about what they do and why they do it. From what I've understood of the RDA work, FRBR has brought clarity to that discussion, and that's a Good Thing.
Then I hear about people FRBR-izing their catalogs, and I have to say that I can find nothing in the FRBR analysis that would support or encourage that activity. FRBR is not about catalogs, it's not even about creating cataloging records, and it definitely does not advocate the clustering of works for user displays. I'm not sure where FRBR-izing came from, but it definitely didn't come from FRBR. FRBR defines something called the Work, but does not tell you what to do with it. In addition, the Work is not a new idea (see section 25.2 of AACR2 where it describes the use of Uniform Titles).
I think that those of us in the systems design arena have confused FRBR, or perhaps co-opted it, to solve two pressing problems of our own: 1) the need to provide a better user interface to the minority of prolific works, that is, the Shakespeare's and the oft-translated works; 2) and the need to manage works that appear in many physical formats, such as a printed journal and the microform copy of that journal, or an article that is available in both HTML and PDF. We can find elements of FRBR that help us communicate about these issues; we can talk about Works (in the FRBR sense) and Manifestations. But solving these problems is not a FRBR-ization of the catalog.
The first problem, that of prolific works, had at least a partial a solution in the card catalog: the Uniform Title. It was that title that brought together all of the Hamlets, or all of the tranlsations of Mann's "Zauberberg." While RDA may in the future define work somewhat differently from AACR2 and may expand the breadth of the groupings of bibliographic records, this isn't a new concept. Interestingly, I find that Uniform Titles are often not assigned in catalog records, which limits their usefulness. So here we are hailing FRBR when we aren't making use of a mechanism (UTs) we already have. In any case, we are finally trying to cluster works in a way that should have already been part of our online catalog. Although the definition of Work may have changed, the idea of grouping by work is not new.
The next problem is one I hoped would be addressed in RDA but it appears that it isn't (well, I can't find it in the drafts): should we catalog different physical formats as separate items, or could we have a hierarchical view of our catalog entry that would allow different physical formats to be listed as a single item? Physical formats are important because the format can determine the user's ability to make use of the item. This is conceptually a cataloging question, but it's also a systems design issue, which is one of the reasons why I would like to see some work between the RDA committees and a group of systems designers. From this latter point of view, my preference would be to create a multi-level record that allows for manifestation and copy-level information to be carried with (or linked to) the bibliographic data. The MARC21 Holdings Format gives us one model for a solution, but in my experience it needs a make-over (and another level of hierarchy) in order to play this role.
I'd like to see discussion of both of these issues and their possible solutions. It is clear to me that post-processing of current catalog records is not sufficient to create the kind of user services that we want to provide. We are going to have to talk about what we want our data to look like in order to serve users of our catalogs.
10 comments:
I agree that “FRBRizing” a catalog usually comes down to making better use of MARC/AACR2 uniform title data; but I think there’s more in the FRBR report than that. FRBR defines work and expression as entities, which is a step beyond seeing them as aspects of access to a manifestation entity. Entities can have their own records. The closest approach I’ve seen to a practical use of FRBR was Sally McCallum’s MARBI discussion paper (http://www.loc.gov/marc/marbi/2005/2005-report02.pdf) proposing that either the MARC bib or the MARC authority record could be used to represent works and expressions, but that both would need some significant new elements.
As for the multiple versions issue, I’d prefer to see a modular solution linking records together rather than an integrated hierarchical record. Serials and monographic sets have a logical integrity that warrants describing them as wholes, but the array of versions in which a given title may appear do not—they will vary with every collection, and the absence of one version would not be considered evidence of “incompleteness” in a library’s holdings. So, one record to describe the characteristics of a title common to all versions, others to describe the version specific characteristics, and links and display solutions represent the information about and relationships between the title and the versions held clearly and succinctly.
Stephen
For the introductory master class I'm helping to teach this semester, I took the students to OCLC's FictionFinder and had them do a title search on Alice in Wonderland, and then explain to me why Grapes of Wrath was appearing as a result. One of them was actually able to locate the audio recording that contained both Grapes of Wrath and Alice in Wonderland in WorldCat (one of those 'great works' audio recording series). I then asked them if they thought users would be happy or hopelessly confused seeing Grapes of Wrath pop up for that search. There was fairly unanimous consent that this was not a good thing.
Splitting work level records from manifestation level records sounds interesting but I think it ignores the fact that 99.44% of library users just want to get at an item, don't care about our hierarchies, and will not be happy if we tell them they have to recursively search down various paths in a tree to find the item they want because that keeps our data model clean and shiny.
Yes, this is one of the things that worries me about modifying the catalog design around the Work concept. While we might want to group some items because they represent the same work, we don't want to make users go through the Work/Expression/Manifestation/ hierarchy for all of those items that are unique. The Relvyl display that was recently announced seems to handle this pretty well (although in most cases it is clustering duplicate copies not versions of works, but I think that's due to other problems of their test design).
As for sound recordings, I have to say that I think of albums with multiple works as a kind of "bound with" situation. I don't know how music librarians view it, but at least for classical music the packaging of works together just doesn't seem to me to constitute a new work. I suspect it's all about filling a disc, much like collections of short stories are about filling a certain amount of pages. No, I know it isn't random, but as we go digital I think the need for such packaging will be lessened. This may give us a catalog unit that is more like the item the user is seeking.
I think there is so much misconception about FRBR. [To begin with, it's confusing that the FRBR report kind of pretends to be about something other than a model, but is actually mostly a model. So when people say 'FRBR' they really mean 'The FRBR Report Model'. But that's not actually confusing, becuase everyone usually means that.]
There is more to the FRBR model than work sets. There is more to FRBR than even the Group 1 entities. The FRBR model is an explicit model of the bibliographic universe, including entities, relationships, and attributes.
We could talk about why having such an explicit shared model is important, or what problems the lack of such an important shared model has caused, or what benefit it can give us. I'm not sure if we're all already on the same page with that or not (It depends on who 'we' are, of course---there certainly isn't as much consensual understanding of this in the library world as a whole as I would like).
Then we could talk about if the FRBR model is the _right_ one or not---understanding that there is no absolute truth here, we're talking about in what ways the FRBR model might be useful, or not, in what ways it could be improved.
Now, I think you're right that the FRBR model does not determine what your interface will look like OR how your cataloging is done. But, making these decisions based on the FRBR model as a shared understanding, the FRBR model WOULD influence them.
It's true that the FRBR model kind of assumes that the Type 1 entities are a more or less accurate representation of the Things Users Care about. Do you agree or disagree? This assumption hasn't neccesarily been empirically verified, but I personally buy it anyway--at least in terms of Work, which as you note way pre-dates the FRBR report as a concept ("Expression" is a little bit sketchier). If we agree, then it does follow that it is important that:
1) Our bibliographic record corpus be structured such that The Work Set CAN be extracted from it ---this has implications for the bib record, but there are still many ways this could be accomplished. Some of which would be more feasible than others, some of which would be more succesful than others if implemented. FRBR does not pre-determine which should be used.
2) That our public interfaces allow people access to the work set somehow. Again, there are many ways this could be accomplished. So I agree that it doesn't neccesarily make sense to talk about "FRBRization" of the catalog--what does that mean? If we're talking about making work sets available, let's just say that---becuase on teh one hand there is MORE to FRBR then that, and on the other hand, there are DIVERSE ways this could be accomplished, none of which are prescribed by FRBR.
There are diverse ways to make work sets available. Making work sets available---and making our bibliographic records capable of providing them---does NOT neccesarily mean making users go through a work-expression-manifestation hierarchy for single manifestation items. Certainly. It doesn't even _neccesarily_ mean grouping items by work on the main results page (although I personally think this is very very probably of value).
I think FRBR is both much more and much less than most people think. It's more than the concept of 'work', or even of 'work/expression/manifestation/item.
' It's a complete explicit model--and that's very very important. But it also doesn't answer the question for us, it provides a shared language, a way to to get all of our devices (codes, formats, systems, practices) on the same page (which right now they woefully aren't)---and it suggests _what_ this same page should look like to serve the serve the users---but it doesn't make any actual decisions. And as far as user interfaces--its' a shared page that should support multiple different decisions in different contexts--FRBR does not mean all public discovery interfaces need to look alike.
FRBR is also not finished. It's just an initial sketch of a shared model, in fact.
Jonathan Rochkind
PS:
"While RDA may in the future define work somewhat differently from AACR2 and may expand the breadth of the groupings of bibliographic records, this isn't a new concept. Interestingly, I find that Uniform Titles are often not assigned in catalog records, which limits their usefulness. So here we are hailing FRBR when we aren't making use of a mechanism (UTs) we already have."
Yes, exactly, but I think you are wrong about the contradiction between "hailing FRBR but not making use of a mechanism we already have." FRBR is _not_ a mechanism. FRBR is a model. If we're talking about how to make our bib records match the FRBR model---you are absolutely positively right that one way to do this is to make more use of Uniform Titles, and tie the use of Uniform Titles to the FRBR model, make it clear that UTs are the way that we identify work sets. (Current cataloging codes are not clear on this; thanks to my professor Allyson Carlyle for making this point, that it should be explicitly said that the point of UTs is for work-set-collocation).
You are absolutely right, but this is not to the detraction of FRBR---we can hail FRBR, and use that hailing of FRBR to suggest that UTs should be used more! These are not at cross purposes, they are one and the same! We can also decide that UTs are not sufficient mechanism, and we need a new mechanism (and then we can argue about whether that is feasible). None of this is predetermined by FRBR. FRBR is not a mechanism, and FRBR does not say anything about current mechanisms. It is a misconception that it does.
Jonathan Rochkind
[phew, I need my own blog. Sorry, but these (in my opinion) widespread misconceptions about FRBR are a big peeve of mine.]
> It's true that the FRBR model
> kind of assumes that the Type 1
> entities are a more or less
> accurate representation of the
> Things Users Care about. Do
> you agree or disagree?
I think it is more or less accurate, but I'm more concerned with FRBR's adequacy than its accuracy at this point, and I see at least one area where I think FRBR is deficient, the result of a methodological error generating an inadequate data model.
To highlight the methodological error, let me put forth two quotes from the FRBR Final Report:
"The study makes no a priori assumptions about the bibliographic record itself, either in terms of content or structure. It takes a user-focused approach to analyzing data requirements insofar as it endeavours to define in a systematic way what it is that the user expects to find information about in a bibliographic record and how that information is used."
"The basic elements of the model developed for the study--the entities, attributes, and relationships--were derived from a logical analysis of the data that are typically reflected in bibliographic records. The principal sources used in the analysis included the International Standard Bibliographic Descriptions (ISBDs), the Guidelines for Authority and Reference Entries (GARE), the Guidelines for Subject Authority and Reference Entries (GSARE), and the UNIMARC Manual."
I don't think you can claim that you are making "no a priori assumptions" about records' content or structure if you're model is based on an analysis of existing record content and structure. In my opinion, a data model of this kind should be based solely on an in-depth investigation of user needs, and should have ignored existing methods and practices to the extent possible. That was not done.
As a result, while I think the FRBR data model actually improves some aspects of our thinking with respect to cataloging, I think it fell short of its promise to try to develop a model which would support a broad spectrum of uses or users. Traditionally, cataloging has placed on a far greater emphasis on patron's needs than librarian's needs, and FRBR continues in that vein.
As an example of both how FRBR is an improvement and how it fell short, look at the treatment of manifestation level attributes with an eye towards the work of audio/visual preservationists. The manifestation-level attributes contain several valuable bits of information for a preservationist with respect to sound recordings, but nothing resembling the same level of detail for moving image formats. It also omits information that would have been useful for both audio and visual preservation, such as tape brand.
I suspect this is because that the analysis of the appropriate attributes *was* based on examining existing records and practices, rather than going and talking to preservationists about what they really need. So, while I think FRBR is a step forward in actually doing a better job of recognizing the need to support users other than the patron than we have traditionally done, the study group's approach prevented them from developing a complete model. Their approach was one too biased towards reproducing existing practice, in my opinion.
A perfectly reasonable objection could be raised at this point that there is no way the FRBR study group could have engaged in field research of sufficient breadth and depth to adequately examine all users' needs, and I think that is true, but I think that simply highlights a problem in our efforts to rethink cataloging within the community. We can't hand things over to a single panel of experts and expect them to come up with a comprehensive model at this point. The issues and needs are too broad. We need to instead develop a model which allows for integration of input from experts in different realms. I don't blame the FRBR study group for not knowing everything there is to know about A/V preservation; I certainly don't know everything there is to know about A/V preservation. But I do think the effort can be faulted for not adequately recognizing that fact, and for failing to adopt a methodology which was more focused on gathering information from different communities of practice regarding their needs, rather than recapitulating existing practice.
A bit off the topic of how FRBR should be represented to patrons, I suppose. But the fact is that while it is correct to say that FRBR is a model and not a mechanism, I think it ignores the fact that there already *was* a model, if not an explicitly stated one, and that in either case, the model has to be implemented, and the focus on reproducing the hierarchical model of FRBR in new implementations ignores the fact that we had a hierarchical model before, and found that an effective implementation of that model for our users didn't require them to recurse hierarchies to find information.
Jerome McDonough
"and found that an effective implementation of that model for our users didn't require them to recurse hierarchies to find information."
I don't think we found that at all! I think we found that we had trouble effectively implementing that (implicit) model, and had trouble creating user displays that worked out of the cataloging copy created from it.
If we have perfectly effective implementations now, then indeed none of this stuff is neccessary. I don't think we do.
Jonathan
This is a great thread and I hope people are actually reading it. With that hope, a couple of comments:
I remember distinctly, Karen, being on the opposite side of the mulver question from you during one of our common tenures on MARBI. Now, here I am citing you as the one who was right then, and you've changed direction! Someone in this thread pointed out that the real issue is how the information for the different entities are related, and I think that's exactly right. Continuing to discuss this issue within the boundaries of historic cataloging practice is missing the point. Modularity is what will allow us to do what we need to do for users, and, not inconsequently, for ourselves.
I also think that it's a mistake to look towards uniform titles for a solution. Yes, they've been used as a method for collocating materials together, but they've also been used to distinguish things from one another (in serials and legal cataloging, for instance). I really do think that uniform titles are pretty broken at this point, and we should look at the modularity ideas as the best bets.
At the risk of rolling eyeballs, I'll just mention that the Dublin Core Abstract Model has a notion of "description sets" that might have some traction in this arena. It's at: http://dublincore.org/documents/abstract-model/ and though not a fun read, extends some fundamentally bibliographic ideas past the straightjacket of our past practices.
Diane Hillmann
Karen,
I've been hoping for co-option by the interface developers all along. Whether something is a work or expression or manifestation is chasing windmill blades. What we need is an interface that can make your work collocate with my expression and somebody else's mixed record, helped along by more helpful cataloging rules. Perhaps we could dedicate the co-option to Crystal Graham, particularly your option 2 to pull together versions of a journal run. Do you think we can train the interfaces to compress holdings over different records?
Sherman
Sherman, I think the answer to your question is that we need to decide what we want our systems to do BEFORE we decide what our records will look like and what they will contain. The problem today is that we have a record format standard that preceded any concept of library systems design. It's much harder to implement today's system design with yesterday's record. For example, Martha Yee and I had some long discussions about her FRBRization paper. Martha's desires are all legitimate, but creation of the catalog she wants is very difficult with the records we have today. This is the reason why I've been encouraging MARBI (and others) to organize a group of systems designers to work in parallel with the RDA and FRBR work. If we want to implement the ideas, we have to do some heavy design work to make it possible.
Post a Comment