Posting to RDA-L
Thanks for your comments. My replies are included:
The practical consideration is not FRBR but is linked data, which FRBR (or something like it) facilitates. And yes, it is being investigated in a number of instances, some being the XC project, Open Library, Freebase. It is also the topic of the World Wide Web Consortium’s Incubator Group on Library Linked Data.
I understand linked data and have great hopes for it. Certainly, it is very important for libraries, but I do not see that in order to institute linked data, we must first embark on FRBR and RDA. If the experiments were focused on using linked data for what we already have, which would be the least disruptive, and find out what parts of the record (sorry for using that term) are not conducive to it, we could change those parts as necessary.
So much of this has to do with changing MARC in the sense of “behind the scenes” MARC. As I keep mentioning, so long as libraries use ISO2709 as their primary format for record exchange, we remain trapped inside its limitations. So long as the main XML version of our catalog records must remain “round-trippable” with ISO2709, we still remain trapped. Once we get rid of this baggage which is definitely, without-a-doubt holding us back, then we can focus on other areas.
And RDA itself is being tested (albeit using MARC) by dozens of libraries in the US.
This is hardly the “untested” vision that you allege. True, libraries are not yet cataloging in this environment, but I would be greatly surprised if we DON’T end up creating linked data in the future. This is a change that is on the way, that has real practical applications, and that is a benefit to libraries. The reason for making this change is NOT about cataloging, but about serving the users; serving the users where they live and work, on the Web.
I’m afraid we have a serious disagreement here. I cannot believe the changes proposed by RDA will serve the users in any way at all and this has yet to be demonstrated. RDA and FRBR are *not* about serving the users, they are about maintaining the traditional library catalog structure into the future of the web.
And it does remain untested in many ways. Perhaps in theory it’s been “proven” and many of our current records can be shoehorned into the RDA/FRBR world, but what remains to be tested are the practical consequences: what advantages will we achieve? will these changes improve matters for catalogers? Will they raise standards or quality? Will they raise their productivity? Will they give other metadata creators incentives to cooperate? Will they provide our users with anything that they want? I have seen no tests or studies in any of these areas. The most important of course, is “customer testing”, or, are we giving people what they want or are we building typewriters in the age of word processors and laser printers? In other words, will this be an advance, a lateral move, or a step backward?
My own experience working with patrons says definitely that today, we are not giving people what they want. People simply do not understand the catalog and pretty much refuse to learn. Therefore, we must change, and that’s OK. But we must change by giving our users something that they will want to use. I cannot see that RDA does this, but if it is demonstrated that by implementing RDA users will find our catalogs more comprehensible, easier to use, etc. I am willing to change my mind. I have not seen any such tests because I think they would show just the opposite result, and they wouldn’t be published. In fact, when I have shown users the FRBR displays, they find them even more confusing than what we have now. Our users have changed. We must find out in what ways they have changed and provide them with what they want, but that will take time and research.
In the meantime, I agree that linked data should be the goal, and can probably be achieved gradually, e.g. it could be done now with the headings, I still do not see why this would demand RDA. Why can’t we try to do it now? So, for me, linked data and RDA/FRBR are not joined at all. You could do one without the other.
Finally, enough with theory. We’ve had plenty of theory for a long time. What are the practical consequences of these tremendous changes?
Jim, your vision of FRBR as “extra records” is a false impression, probably based on the diagrams in the FRBR document. FRBR is a conceptual model, not a data model. In fact, it has nothing to do with records and linked data doesn’t really make use of the concept of records. Exactly how library data will be structured as we create it and exchange it is yet to be seen, but I think we can assume that there will be entities and relationships between those entities.
RDA attempts to bring the FRBR conceptual model into the world of the web. So, the goal of RDA is to achieve the realization of FRBR.
Concerning the idea of “records”, we can use another word if you like, but there will still be agglomerations of text, or referential links that will eventually lead to some kind of text (at least I hope so. The buck will finally have to stop somewhere). Some of these links may go into id.loc.gov, others may go to dbpedia or VIAF, or wherever, but the final product will still be this agglomeration e.g. for a personal name, that will have certain attributes. This “agglomeration” will sooner or later be human-readable in some way. This is what I am calling a “record.” When we say that there will be an “expression” that can be used through linked data somehow, that means that there will be an agglomeration of links leading to text, and possibly immediate text, that can be linked to. I call that an expression record, but we can call it something else.
It works just like what we call a webpage and I have made thousands of them. (I am still a coder, by the way, and use tools like Notepad to build my catalog, so I understand including files and do it every day) The page that we are looking at right now is most probably made up of dozens of files, or even more, that are linked together. Many pages I have made have header and footer files, a left-hand navigation area, images, and scripts, and the browser imports all these files, puts them together on the fly and the result is the page that you see. Some of these files that are imported may in turn import other files, and many times, these files can be on servers from all over the place, resulting in mashups. Yet, we still have no problem calling the result we see a “page” because that is the part we experience.
Much the same will happen with linked data, creating “pages” “records” or whatever from information located in all kinds of places, except it will be semantic. (The Semantic Web) From the strictly technical point of view, this is what has been going on for years now, but from the intellectual point of view, it’s something new.
You can create another model to guide you if FRBR isn’t what you need, but the key thing is that *first* you need a model, *then* you need cataloging rules. So if you prefer not to use FRBR as the model for your cataloging rules, you need to substitute another model, and then make sure that the rules fit the model.
I find I must disagree again. First, we need to know what is needed: what catalogers need and what our users need. The user tasks in FRBR are certainly not what I have seen people doing; they are not what I do–at least, not any longer. If we can show that users really do require the FRBR user tasks, then we are probably on the right course, but I am unaware of any studies that have demonstrated this is what they want and do. I very rarely do those things myself. The error in FRBR is to take what the catalog has always provided, and conclude that this is what people want. It was also pre-web, and we must admit that much has changed since then. If we don’t start from what users want to do with information (and I will continue, what librarians need), then the model has absolutely no relation to anything that anyone wants.
I want catalogers to build something that people will want to use–not just serve some experimental model.