Re: [RDA-L] Conference names : use of annual, etc.
Amanda Xu wrote: snip Adopting and implementing RDA standards and technologies is different from fixing a broken motorcycle or automobile. In the later case, you have to replace parts that are not working or need to be modernized. The pipes or wires that connect to the parts may not be durable any longer. In an ideal RDA implementation scenario, we will extract what is working out of the old engine, transform and load them into the new platform or simply add a plug-in or appliance between the old and new interface if we can't afford the new platform. If we did right, the end users shouldn't even be aware that such transformation had occurred except some nice UI features. It happened just like when we migrate from Windows XP to Windows Vista or later version. The new arrival collections will mount directly into the new platform under the new standards and technologies governed by RDA as the universal content model for the discovery of library resources, and the support of user tasks as defined in FRBR/FRAD. That is why we are learning from each other and the RDA toolkit right now. Backward compatible tools, e.g. from RDA to AACR2 are needed as well. For those libraries who can not afford the upgrade. This should be surprised at all for those of us who have years of experience with the info ecology systems. Technically speaking, the implementation of RDA is not about fixing. It is about extracting, transforming, loading (a.k.a. ETL), etc. Of course, to do it right, doctor-like diagnosis and analysis of the library's resources, workflows, etc. is critical. /snip The question being discussed was: what is the purpose of adding the frequency to a conference name? This does not involve extracting, transforming, or loading. I mentioned that I could not see any reason for adding the frequency that would be useful either for patrons or librarians, and I asked: what is broken that this proposal attempts to fix? I pointed out, in fact, that such a rule would very possibly make it more complicated for end users to find conference names and some sort of way would need to be found to bring the variant names of the same conference together. This would be getting really complicated and somebody, somewhere should have to say why we need to add the frequency. Where is the evidence that end users or librarians are having problems that this would fix? If there is no evidence, there is no problem and therefore, nothing to fix. We should not assume that just because there is a proposed rule change in RDA, or in any cataloging rules, that it is either useful or needed. Evidence should be given. Many of the changes with RDA seem similar in their utility to the end users and to the librarians, at least that's how they seem to me. I have nothing against extracting, transforming and loading, but this is not what I see the changes of RDA doing. Those would be tasks mainly for systems librarians. Such tasks will demand changes in our formats and to establish some levels of interoperability with other systems out there, while questions of abbreviations, eliminating O.T. and N.T., changes in conference names, and others, have nothing whatsoever to do with ETL. And I must repeat that if the end users don't even notice these changes except for some UI features (that can be debated whether those features will be nice or awful), the usefulness of the final product will be highly questionable. I won't mention again my doubts about the validity of the FRBR user tasks. There needs to be some major user research and a business plan that makes sense. James L. Weinheimer j.weinhei...@aur.edu First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Conference names : use of annual, etc.
Hal Cain wrote: snip Yebbut-- the hardest problems of achieving consistency usually arise from the inconsistencies found in the resources themselves. Regularizing such inconsistencies will infringe on the principle of representation: there should be a clear match between the resource and how it is described (and, I add, consistency in how we provide access) -- and what searchers bring to the catalogue often starts with a citation, formal or informal, created by someone looking at the resource. You can't get away from the thing in hand (or on screen, etc.) and suppress those inconsistencies. /snip Some of the wisest advice was given me a long time ago by an unforgettable fellow, who was a member of a one of those motorcycle gangs that gets violent occasionally. This fellow was pretty nice though and very colorful. His advice is certainly nothing new to anyone, but it was to me at the time, and it comes back to me occasionally. He said, with a lot of feeling: If it ain't broke, DON'T FIX IT! But he did mention that figuring out exactly what is broken on a motorcycle or automobile can be very difficult and can turn out to be completely different from what you thought at first. You fix what is broken, otherwise you may be taking everything apart, changing parts that don't need it and perhaps wind up making the engine run worse than before. So, I look at the rule changes of RDA, such as this one for conferences and immediately wonder: What is broken? I confess that this one is a mystery to me. While I readily agree that members of the public experience problems finding conference names, I can't imagine that adding the frequency to the conference name could be any kind of a solution. So, the public doesn't need it; I don't think librarians have problems with conferences that would be solved by such a rule. I think most of the problems people have with finding these names (and other authorized forms) have far more to do with the inability of library catalogs (or at least most of them?) to search authority files and bibliographic files at the same time using *keywords*, which is how everybody searches today. James L. Weinheimer j.weinhei...@aur.edu First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Conference names : use of annual, etc.
Danskin, Alan wrote: snip Treating events consistently is a simplification of the instructions. The decision to include frequency in the name of the event is justified by the principle of representation if the event represents itself as an Annual Conference or the Biennial Festival. /snip I have been following this discussion with some interest. While I fully agree that this may be a simplification of the instructions, it does seem possible that the final product, i.e. the work of the catalogers and of the researchers who need to find these conferences, could very probably be made more complex. In fact, it could wind up becoming very complex as conference names change from one to another based on frequency. It occurs to me that perhaps the concept of the superwork, aimed primarily at serials, will also be suggested for conferences, so that people who are interested can find the various forms of the potentially multiplying conference names. James L. Weinheimer j.weinhei...@aur.edu First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Conference names : use of annual, etc.
On 18/04/2011 19:34, Adam L. Schiff wrote: snip I think you are right, but then our patrons will demand that somehow, these separate conferences all come together. People have plenty of problems already with conferences--one of the worst is the idea that it is a conference *name* and not a conference *title*. I don't know how many hours of my life I have argued this with people, where I have to show what is a corporate body, etc. Anyway, that's why I mentioned the superwork idea, but in this case, it would be a superconference. It's hard to decide how all of this superstuff will turn out though. In my own opinion, it is evidence that something, somewhere is wrong. /snip James L. Weinheimer j.weinhei...@aur.edu First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] FRBR
Myers, John F. wrote: snip One could argue interminably the pros and cons of abbreviating or not. I can see merits to both sides, as well as to native language representation of missing date issue. (That is, the replacement of [s.l.] with [place of publication not identified], where [s.l.] replaces the earlier [n.p.] for no place.) I am however adequately convinced by the machine processing crowd to hold my reservations in abeyance. The Bible heading changes would happen regardless of RDA -- they were the last proposal to change AACR2 and were rolled into RDA rather than causing a new update to AACR2 in the middle of the RDA development process. If by lack of $b in titles you mean that the Other title information element is not part of the core elements of RDA, I would point out, insofar as AACR2 had core elements which I will equate with the first level of description articulated at 1.0D1, it is neither a core element of AACR2. The equivalence of the RDA core element set as a Full level record is an undesirable possibility, but is a consequence of policy implementation not of RDA itself. /snip What I am asking is do we honestly and truly think that these tiny, insignificant changes are going to make any difference at all to our patrons? These changes certainly won't help anybody find anything--they are just changes in display: the elimination of O.T. and N.T., spelling out abbreviations, the subfield b. The only possibility of added access is getting rid of the rule of three, but that could just as easily reduce access since the only mandated access point is the first author. (Oh yes! Plus translators and illustrators of children's books!) Will the public suddenly like our records and find them useful after these changes? Why? We need to look at matters from *their* viewpoint, not ours. Look what they can do using other tools. Some are saying that search is going away altogether. http://www.huffingtonpost.com/2011/04/04/bing-director-stefan-weit_n_844004.html. While I don't necessarily agree (and I hope not, as people can hear my views on search from my last podcast), these people, e.g. from Bing, have a *far bigger* voice in the information universe than any library cataloger, or group of library catalogers. We must do something, and something big. Kevin Randall wrote: snip The questions above indicate that the questioner is missing the point of RDA entirely. Abbreviations could be limited or eliminated entirely by a very simple amendment to AACR2. /snip I don't think I am missing the point of RDA, and the abbreviations are a great example. Do we really believe that a simple rule change will solve whatever problems the public supposedly has with abbreviations in the catalog? Sorry, but I find that very naive. To be fair, I was guilty of exactly the same thing back when the Soviet Union and Eastern Europe fell apart. I and my team at Princeton struggled mightily to fix all of the--who knows how many subject and corporate name headings in the catalog, but we did it. It was one of the tasks I took special pride in and the heading browses looked great! But then came the retrospective conversion project of the cards, and the beautiful displays of the headings were utterly spoiled by being inundated with zillions of obsolete headings! I was so mad until... I realized that what I was looking at was only the reality that confronted our patrons every day. When the patrons used both the cards and the OPAC (which they did constantly of course), everything had always been split, but for me as a cataloger, I was concentrating only on the OPAC and the cards were somehow outside. I had been ignoring the complete reality of the situation. Suddenly, I was confronted with what the users saw every day. I didn't like it, but it was a humbling moment. Abbreviations are precisely the same thing: while new records will have their abbreviations spelled out, the old records will not. Our patrons will still have to work with those abbreviations, that is, unless some retrospective project is created, but what a waste of resources that would be! In any case, thinking that making a new rule is going to solve a problem, when millions of records that will not be fixed will still be in people's faces every day, in every search result, shows one of the reason why technical services librarians are often held in such low regard by other library divisions. So many times, technical services people see only what they want to see, just like I did with the Soviet Union/Eastern European headings. We shouldn't delude ourselves that these insignificant changes (for our users, but not insignificant for us) will make any difference in the scheme of things. As Mac said, it is not the problem of the rules, but the problems we are facing are in other areas. James L. Weinheimer j.weinhei...@aur.edu First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] FRBR
Kevin M. Randall wrote: snip James Weinheimer wrote: I don't think I am missing the point of RDA, and the abbreviations are a great example. Do we really believe that a simple rule change will solve whatever problems the public supposedly has with abbreviations in the catalog? Sorry, but I find that very naive. Did you read the rest of my post? This response shows that you still do not understand at all. The simple rule changes are *NOT* the changes that are significant in RDA. What is significant and has great potential is the entire concept behind RDA, creating a framework that brings metadata into the current age of information technology /snip Well, if you insist so strongly that I don't understand, it certainly must be true! :-) But please bear with me and let me insist that I do understand. The underlying structure of RDA, which tries to envision the FRBR structure, is still something that is highly debatable. First, there is still no evidence that this structure is wanted or needed by our patrons. Every FRBR-type project I have seen is of limited use for our patrons, in my professional opinion, since our patrons are moving away from such things into the world of search. Certainly people will look at and play with the displays, but there is still no evidence that it provides what they need, especially WEMI. And WEMI is one of the main products we will be making. I think very, very few people need that. The second point, and of course the most important, is the business case that demonstrates that all this is actually worthwhile in the business and financial sense. Both of these points have been advanced over and over throughout the years and certainly didn't start with me. In any case, I think the library world has to demonstrate some kind of substantive advances, and I think we have to demonstrate them soon since the information world is moving away from us faster and faster, and along with that world goes a lot of the funding. Instead of swallowing the promises of a future Eldorado, the powers that be are starting to ask: what can you do now? This is why I mentioned the abbreviations problem and the changes to the Russian headings. We can change everything in our new records but there is still a massive amount of legacy data out there that our patrons will be seeing and working with every day just as much, or probably far more, than with the newer records we create. So, whether it's some completely insignificant rule change about abbreviations, or something bigger with new frameworks and structures, it all comes down to the same thing: our patrons will be working with both every day in every single search they do. This is why I say we have to look at it through their eyes, and not ours. From that point of view, things look much less revolutionary. Now, we can either convert the older records, or we could place those older records into a separate database, in essence, archive it all. This would be one idea that I may go along with, and then start fresh with a brand-new format, rules, and so on and the task would be to get the two databases to interoperate as closely as possible. Of course, all this assumes that RDA and FRBR is useful and needed by our patrons AND that it's worth the costs. I am certainly not saying that I know what people want when they search for information. That can only be discovered after research, especially in times as dynamic as our own. To begin creating an FRBR/RDA structure on the assumption that it provides people with what they need (otherwise why would you create it?), without any evidence for it, is unwarranted. So, the FRBR/RDA structure may be revolutionary and great, or it may just be a continuation of the 19th century structures, placed into the 21st century, which is my own opinion. James L. Weinheimer j.weinhei...@aur.edu First Thus: http://catalogingmatters.blogspot.com/
[RDA-L] Cataloging Matters Podcast no. 9: Standards, Perfection, and Good Enough
All, For those who are interested, I have just placed another of my podcasts on my blog: this one a discussion of good enough means in relation to library cataloging. http://catalogingmatters.blogspot.com/2011/04/cataloging-matters-podcast-no-9.html Please forward this to any others who may be interested. https://mail.aur.edu/owa/?ae=Itemt=IPM.Notea=New# James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] FRBR
Harden, Jean wrote: snip My experience leads me to the opposite conclusion. For people who don’t already know how to catalog, much of RDA *is* simpler, more transparent, and so forth than AACR2. It’s only those of us who have been using AACR2 for years that have so much trouble grasping the new rules. In my job I teach a steady stream of young catalogers, and I was also in the RDA test. Teaching AACR2 while testing RDA gave me a daily side-by-side comparison. I have found that new catalogers very often stumble into doing descriptive cataloging “right” according to RDA when they come to the end of their AACR2 knowledge. In formal classes, I have taught FRBR for at least a couple of years now. I find that people without previous cataloging experience understand the basics of FRBR within about half an hour. Then we do a couple more hours of exercises to cement the concepts (take books, scores, recordings, videos, etc. from the collection and make cards for the work, expression, manifestation, item, related works, responsible persons, and whatever else suits the particular group of students, putting these cards on the relevant spot on a labeled table or even floor). I haven’t yet had a student fail to get a firm grasp on these basic ideas within one graduate-length class session. /snip I have no doubt that experienced catalogers can learn RDA. After all, the final product is not all that different from what we do now. The problem for experienced catalogers is to master a new set of tools that are very expensive in comparison to what we had before. Catalogers can learn to deal with all of this, of course. The question is: are the (so-called) advantages worth the disadvantages? Is the final product worth the cost, especially in these exceedingly difficult economic times? We can each have our own opinions (I haven't made my own much of a secret) but when it comes down to it, there is going to have to be an answer: is it worth the cost? And the answer will be very simple: either Yes or No. How many of our CFOs will say yes? No matter what some may think, RDA is not unstoppable and can be checked at many points along the way, as I am sure it will be. As a result, one of the unavoidable consequences of RDA, whether people like it or not, will be a split in the library metadata community. We have seen promises and presentations with incredible graphics that have made me gasp for breath, but I have found it all very short on specifics. For example: where is the money supposed to come from for this training? What are libraries supposed to give up? Or, are libraries expected to get additional funding for all of it? (Ha!) Also, more than anything else, I think it's clear that catalogers need help: substantial help, Is there any hard evidence (other than anecdotal) that anybody outside of libraries (and especially Anglo-American libraries) are going to switch over to RDA when they never did with AACR2? James L. Weinheimer j.weinhei...@aur.edu First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] FRBR
Megan Curran wrote: snip I just feel like if our catalogs are on the web, and most of what we catalog is in the web environment, then the rules should be made for that environment. Using coding tricks and discovery layers to force paper-based cataloging rules into a web environment amounts to putting lipstick on a pig. The data display can only be as good as the data underneath, and the data should be relevant to the environment in which it's processed. I understand the reticence of veteran catalogers. Unlike other areas of librarianship, the rules have stayed relatively static and continued working for a long time. I think the RDA skepticism is good, because the discussion will result in a better set of standards in the long run. But I think RDA has a lot of potential, I'm looking forward to seeing how it pans out in the day to day. /snip As one of those veteran catalogers, I honestly do not see how the changes in RDA have a lot of potential. Which changes do you have in mind? The abbreviations? The changes in the headings of the Bible? The lack of the $b in titles? While the potential changes with FRBR would be noticeable to the public because of different displays, I truly do not see how the changes with RDA will even be noticed by our public. What will they notice first? It seems to me that if people really do not like our catalogs as they are today, it is RDA that will be the equivalent of putting lipstick on a pig. There are many, many problems with our library catalogs and they should not be ignored. Very few of those problems are with the rules--it's how the catalog works in an environment that is not a card catalog. This should have been discussed a *long* time ago, but it wasn't. Now, it's coming back to haunt us. Our rules have always been made for non-changing, physical items: books, serials, scores, recordings, maps, etc. but in the online environment, any record a catalog creates may not describe the remote resource just 5 minutes after it was created. Remote-accessed, dynamic resources are substantially different from printed items and special rules should be made for those resources. So far as I know, the book as we know it may become far less important in our society fairly soon (lots of people are saying that!), and other physical items may follow fairly quickly. Are librarians only interested in physical items that are arranged on shelves? I hope not! There is a place for librarians and people who describe and organize all of these resources, I am sure. But where is that place? How do they (we) remain relevant in such a society? James L. Weinheimer j.weinhei...@aur.edu First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] FRBR
Hal Cain wrote: snip Jim, I think you're over-thinking it. Confronted with a new book, don't we examine it and check our favorite database(s) to verify whether it's a new work or a version of an existing work? If new, we just treat it at the manifestation level. Under the currently-anticipated regime for implementing RDA (until we are engaged in a different scenario, for which systems and services don't yet exist on any significant global scale) we'll do the same. Having accounted for the manifestation and its content, then it's done. /snip You're right Hal. For the moment with the few changes that RDA actually implements, we will be doing essentially the same thing as we are doing today: cataloging manifestations and dealing with works and expressions only when we need to. The changes of RDA, as I have mentioned so many times before, are such that our patrons most probably won't even notice any changes at all. (This is why I say that RDA changes are only faux-changes, i.e. it changes only cataloger's work, is not worth the effort, blah, blah blah, when what we *sorely need* are changes in other areas of the catalog and cataloging, but those are different topics) However, when (not if) linked data is implemented there will be a need for the cataloger to determine these issues. RDA is almost finalized, and it strikes me that there is such difficulty on determining something as basic as: what is a work! (I'm having trouble too, by the way!) And this while everybody seems to agree that it is vital to determine WEMI now. Somehow, things are not adding up. The only consolation is that with MARC format, especially in its bizarre ISO2709 version, none of it matters for the moment. But that is quite an odd sort of consolation! James L. Weinheimer j.weinhei...@aur.edu First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] FRBR
On 08/04/2011 16:37, Brenndorfer, Thomas wrote: snip RDA would call those Derivative Works under the Related Work element. LibraryThing calls them Related Movies. Neither RDA nor LibraryThing calls them the same work. /snip So, what is this record? http://www.librarything.com/work/2264 Is it a superwork? And when I click on the Related Movies http://www.librarything.com/commonknowledge/search.php?q=The+Scarlet+Letterf=37exact=1, all of the information seems to be only in the record for the Work (or superwork) and I get nothing when I click on the movies, except I see that record for the Norton critical edition as a different work. That's why I don't understand what the work is here. James Weinheimer j.weinhei...@aur.edu First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] FRBR
On 08/04/2011 22:19, Stephen Early wrote: snip Which reminds me of Marcel Duchamp's L.H.O.O.Q. (Mona Lisa with a mustache) and the Andy Warhol silk screen prints of Mona Lisa. How would these fit into the FRBR model? (enjoying this very interesting discussion) /snip I agree that this is an interesting discussion, but how about something a bit more realistic in this new universe of information? I have taken a position as consultant to FAO of the UN and we are discussing online statistical databases. What is the WEMI of something like Google Public Data, e.g. here is a database, *held at Eurostat* but accessed (in real time) through the incredible Google statistical tools, that allows the user to see the relative minimum wages in Greece, Netherlands, and Great Britain (I selected these countries myself). http://tinyurl.com/3bbqrh3. Here is another interesting dataset: unemployment in the US since 1990 http://tinyurl.com/3uom8fs, the database held at the US Dept. of Labor Statistics. Click on the arrow and watch the movie. Individuals can now add their own statistical tables, too. Or, here are Craiglist apartment listings on Google Maps. http://www.housingmaps.com/. You can use Google Earth to map archaeological findings; Google maps again, to plot the protests in the Middle East http://tinyurl.com/4crzdzg These are just some of the tools that are genuinely new, i.e. they have never existed before, that people are finding very useful, and I am sure there are far more complex tools than these. What is the value of WEMI to our users or even to librarians, in these cases? Do we ignore the resources that don't fit, or are we forced to shoehorn everything into a WEMI structure, which I personally believe is based on printed materials? Catalogers also can't spend all day on one record, as many people think we do. WEMI is based on a physical view of the information universe and the world is moving away from the limitations of the physical. -- James Weinheimer j.weinhei...@aur.edu First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] RDA draft
What I mean about making the business case for RDA would be to take, e.g. Mac's sheet at http://www.slc.bc.ca/cheats/aacr22rda.htm and make a business case for these changes, e.g. what is the business case that makes the *change in the procedure for treaties sensible? What is the problem this change is supposed to address and how would the change solve that problem? Or for Works. Selections? Spelling out all of the abbreviations? And on and on. Every library will be expected to answer such natural questions coming from their administrators. If the only answer is: it's what everybody is supposed to do but otherwise, I don't have the faintest idea concerning why, then that puts librarians in a very tough situation. At least with AACR2, the business case was clear enough: if the Anglo-American libraries followed the same rules, the amount of copy cataloging could rise substantially. Some people thought it still wasn't worth it, but at least it was correct and clear: the amount of copy did increase tremendously. Whether it was worth it is a different question but AACR2 did achieve what it set out to do. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/ From: Resource Description and Access / Resource Description and Access [RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Brenndorfer, Thomas [tbrenndor...@library.guelph.on.ca] Sent: Thursday, March 17, 2011 7:54 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] RDA draft -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Weinheimer Jim Sent: March 17, 2011 7:19 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] RDA draft . Compare this with the ONIX Best Practices at http://www.bisg.org/docs/Best_Practices_Document.pdf and you will see that *each field* has an associated business case in its favor. Although I don't think this level is necessary for library cataloging rules, at some point something will have to be done, because otherwise the changes RDA offers seem completely random and strange with no overall purpose--at least this is how they seem to me and I am sure how they seem to many others. I still see *no tangible advantages* whatsoever and I cannot imagine that a non-library administrator would see any more than I do. The RDA Element Set View (as opposed to the main RDA text) already closely resembles this ONIX document. In the long term I would prefer the Element Set approach because it brings all relevant details about an element together, which I view as a very practical approach, with tangible benefits in improving training and enhancing the record creation process. For example, the sources of information are listed in detail with each element (instead of in the preamble), along with the recording guidelines, and with related elements like Source Consulted. Newly added (I don't recall seeing these the last time I looked) are links to the MARC21 encoding fields for these elements (and the main RDA text doesn't have these direct links to MARC21). Each element should include the method of inputting, which the ONIX document has. Right now we're stuck with the various MARC conventions, as opposed to the simpler element approach in ONIX and RDA. For example, for Title of Person, ONIX has TitlesBeforeNames and TitlesAfterNames and RDA has Title of the Person. The MARC21 encoding points to web pages for all the bibliographic (100, 700, 800) and authority (100, 400, 500) fields, through which was one has to sift to find the delimiter ($c) and associated punctuation, then refer back to the content standard for the choices that are made for the element. The status quo with AACR2-MARC is the strange standard, and the most random and time-consuming way of cataloging. The Element Set View in ONIX and RDA is quite rational, streamlined and systematic in comparison. Adding the business case for each element is an excellent idea in an Element Set View. In looking at the ONIX entries for each element, the business cases often focus on sales and inventory control, but mostly they just restate the user task objectives in RDA in different words. For example, the ONIX business case for recording large print is Visually-impaired consumers need accurate information on large print, which is basically the Select user task objective in RDA for this element (select a resource that is appropriate to the user's requirements with respect to the physical characteristics of the carrier). Thomas Brenndorfer Guelph Public Library
Re: [RDA-L] RDA draft
Mike Tribby wrote: snip Should cost of access and the possibility of universal access have been concerns? I think they should have been-- but they were not. To perhaps put it crassly: theoretical purity was a higher concern than access. It's hard to blame the co-publishers very much since none of them are exactly rolling in extra money, and this process has been expensive, but some of us have been complaining about the assumed cost of subscriptions to RDA for some time now. /snip The current metadata universe could not have been foreseen when FRBR and RDA were being created. I can't find fault with anyone on this. FRBR first came out in 1998 (which meant several years of development before that). It turned out to be the model for later work, which didn't begin until 2005 or so. While this may be considered the fast track in traditional library experience, the revolutionary changes in information searching and retrieval brought about by Google and continued by many other very powerful companies, didn't really begin until afterwards, about 2000 or so. In fact, Google didn't go public until 2004. Most of the really new possibilities of search have taken place only in the last few years and I think we all expect these changes to increase at a huge rate. People really like these new capabilities a lot and in fact, are considered the standard by many who compare our tools to the full-text ones. Nobody could really have expected that in the mid-1990s. Things often don't turn out as we wish. Those poor people in northern Japan could tell us a lot about that. But stuff happens and you have no choice except to deal with them. If the Google-type algorithms had not been discovered (created?), and the global economic meltdown hadn't happened and everybody were still swimming in money like before :-) , matters would be quite different for librarians and catalogers now. But libraries have lost whatever primacy they had in metadata, the black box has been opened (as I mentioned in my last podcast) and there is no telling what will happen. But if RDA is implemented, it must split the library metadata world; that is clear. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/
[RDA-L] Standards (Was: Subjective Judgements in RDA 300s????)
Diane I. Hillmann wrote: snip I think what this discussion points out is a gap in how we think about who contributes to data and how it is created. In libraries we have this fantasy that catalogers are 'objective' and that's what we're trying to do when catalogers create data--provide one-size-fits-all, all-purpose objective data. The problem is that isn't necessarily what our users want, we just think that's it and go on serving it out (no matter that it's not objectivity we were aiming for, but consistency). And the issue of costs keeps coming up to justify why we can't do anything different from what we've always done. /snip I believe the matter is actually a matter of adhering to *standards* and considering whether adhering to genuine standards is important for libraries or not. The idea of standards is one that the business world understands far better than the library world. Every single day in the business world, they work within real, genuine standards that everybody *absolutely must* follow, whether they happen to agree with them or not, because if you decide not to follow those standards, you may wind up in jail, sued, and the company closed down. Just imagine the number of standards followed when you do something supposedly so simple as buying a can of peas: there are standards for fertilizers, for storage, for grading, for canning, for labeling, and many other standards I do not know about. Everybody assumes much of this when you pick up that can of peas, e.g. do you care about how these peas that you are about to eat have been stored? (Yes) Do you want to know the details? (No) Do you want to be able to go about your business after you eat these peas and not wind up in an emergency room? (Yes) All this is assumed, but we do not consciously think about them since we figure that the experts behind the scenes can be trusted. None of this has much to do with objectivity. Even if the standards are not effected though legal means that still doesn't let you off the hook in the business world since there are other methods of enforcement, and your products could still easily wind up effectively boycotted by every other legitimate business on the planet, and bankruptcy is inevitable. Of course, in the library cataloging world, not following bibliographic standards can be done more or less with impunity. I personally do not think this laissez-faire aspect of our traditional library practice can be transferred into the larger world of metadata, which includes the business world. Business is starting to understand the importance of metadata (of the many recent articles, these are interesting, http://radar.oreilly.com/2010/07/metadata-not-e-books-can-save.html, http://www.digitalbookworld.com/2010/metadata-more-important-than-ever/, http://tinyurl.com/32ders5) Somehow, sooner or later, real standards will be introduced that people will be forced to follow, or suffer negative consequences, just as in the regular business world. I believe this concern is what underlies Diane's mention of *consistency*, which is correct but has tremendous consequences the moment we take the matter of consistency seriously. What does consistency mean, and what does it entail? So, it is not so much a matter of objectivity since there may be hundreds or thousands of ways of doing a single task in a competent manner. The task of standards is to find a limited number of those competent manners and create a system that allows for *reliability*, i.e. guarantees that the item you receive fulfills these specified standards. For example, there is no single, objective, best way of counting the pages of a book. There are more or less accurate ways, but no objectively best way. What is far more important is to follow a standard, whether I happen to agree with that standard, or think it is completely wrong. An associated concern of standards is that people must take a serious attitude toward the standards. So, do we want someone really *playing* with the quality of the water that comes out of our pipes, and laughing and laughing? Do we want an airplane mechanic examining a vital part of the airplane we are about to board, and he sighs, Who cares? In these cases, they had better take the standards seriously because people could die from bad water or a plane crashing. In those cases, standards are not a joke. Maintaining standards in the wider world is more complicated today than before. For example, here in Italy, there are not only the Italian standards for food, but the more recent European standards must be merged somehow. This has been controversial, to put it mildly, but I think libraries could learn a lot from this since I believe we will experience something similar as our library standards must somehow be merged into the larger universe of metadata standards. In my opinion, adhering to *real* standards that are enforceable, no joking, no excuses, is the only way
Re: [RDA-L] Standards (Was: Subjective Judgements in RDA 300s????)
Karen Coyle wrote: snip Standards are only enforceable if they are measurable. There is no way to enforce a standard on transcribed data elements. The more that our data allows for free text input, the less we can do to ensure that standards are followed. /snip What people are calling free text does not necessarily mean that you are free to enter the text you want. It is *text*, certainly, but anything but *free*. For example, the ISBD rules of exact transcription of the title page has the result that the information in the 245 is *not* free at all, although as with every rule or standard, there is naturally a little bit of wiggle-room, and the more experience you have, the more wiggle-room you can find. Still there are limits, so there is no way that any standard could e.g. allow for the preliminary title the author chose when first writing a book, and by the time the book was finished, the author had changed the title into something quite different, to then say that the preliminary title should be accepted as the final title of the book makes no sense. This would be like putting the title Trimalchio on West Egg on Fitzgerald's The Great Gatsby http://www.guardian.co.uk/books/2009/jan/19/1000-novels-top-10-trivia-rejected-titles-mullan. Sure, the title may be of interest and someone may want to record it, but it is *not* the title of the book. All of this can certainly be measured, and has been a lot, as any cataloger (including myself) can testify who has undergone the (often humiliating) scrutiny of strict revisers. Those revisers would have kicked me out of the places I have worked if I had given them a record like this: http://chopac.org/cgi-bin/tools/az2marc.pl?ct=comkw=0521348358 For this item: http://tinyurl.com/4s2rlke (and you can even compare the scan! http://www.amazon.com/Cicero-Cambridge-History-Political-Thought/dp/0521348358) Practically every field needs updating. There are far worse records than this one. Still, such things *can* be measured and are, every day. I also don't see that even in the 260$b it's all that free. The terms and abbreviations used there have been strictly controlled over such a long period of time, and I have a suspicion that a good perl programmer could probably work out a routine to display ill. or illus. as illustrations or in whatever language you would want. Doing this should be child's play. There are just not that many abbreviations, even historically. So, it wouldn't surprise me if it turned out that those abbreviations could perform essentially the same function as computer codes, maybe not quite so perfectly, but it would be far more flexible (different languages) and in any case, a better use of the cataloger's time than the tiresome-Sisyphean task of typing out all of those abbreviations in full (and would only make the programmer's job more complicated), or wishing that the creators of MARC had made special codes and click boxes for everything. The headings are not free-text, by definition. The only place where there is true free text is in the note fields (I know--there are probably some others I've forgotten), but not all the note fields. There is nothing wrong with some free-text fields, and they are vital for a cataloger to do the job properly. And Google Translate has demonstrated in amazing fashion how much you can do with transforming true free-text. It would be so much more fruitful to concentrate on the powers that the computer systems give us and to work with what has been given to us in new and powerful ways. We need to work with what we have. Our traditional controlled terminology should be exploited for all it is worth. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Subjective Judgements in RDA 300s????
Jonathan Rochkind wrote: snip Because like I said, I suspect that whether illustrations are present in color or not is not of much concern to 99% of patrons 99% of the time. In fact, if you think about it too hard it's a bit frustrating that expensive cataloger time is being spent marking down whether illustrations are colored or not (let alone correcting or changing someone elses spelling of colored!), when our actual real world records generally can't manage to specify things the user DOES care about a lot -- like if there is full text version of the item on the web and what it's URL is. (Anyone that has tried to figure this out from our actual real world shared records knows what I'm talking about; it's pretty much a roll of the dice whether an 856 represents full text or something else, it can't be determined reliably from indicators or subfields.) /snip Hal Cain wrote: snip I don't agree -- maybe so in an academic environment, but for other kinds of libraries (school and public, and maybe specials too) the presence of illustrations can be a significant element in making a choice of the possibilities. The LCRI for AACR2 which enjoins just illus. for all kinds of illustrative material doesn't help! /snip I think Jonathan is absolutely right. Cataloger time is valuable, and at least I *very much* hope cataloger time will become increasingly valuable in the future (since the opposite is a terrifying possibility!). It has always been the case that creating bibliographic records/metadata involves a tradeoff of including some information at the expense of other information. For example, the rule as it states now is that a cataloger needs only to add the first of a number of authors, and use cataloger's judgment concerning adding any others. Why should there be such flexibility on rule as important as this one (and which I personally believe is unwarranted), but then worry so much over whether the illustrations are colored (or coloured)? And Jonathan is completely correct about the problems with the 856 field, which I see miscoded much of the time anyway. Yet, it is always interesting to compare matters with the rest of the metadata universe out there, since we should be trying to interoperate with them. If you look at the ONIX Best Practices http://www.bisg.org/docs/Best_Practices_Document.pdf look at p. 85 for 30. Illustration details description and see their guidelines. Frighteningly detailed, e.g. 500 illustrations, 210 in full color but we see it can also be: halftones, line drawings, figures, charts, etc. So, how are we supposed to handle this? If we get an ONIX record with 500 illustrations, 210 in full color, 35 figures, 26 line drawings, 8 charts, do we devote the labor to edit it down to AACR2/RDA thereby eliminating some very nice information? But if we just accept it, what do we do then with the materials we catalog originally? illustrations (some coloured) looks pretty lame in comparison and can certainly lead to confusion. Finally, we should ask: how important is this issue compared to the many others facing the cataloging world today, and how much time should we spend on this issue when, as Jonathan points out, one thing people really want to know is that there is a free copy of Byron's poems online for download in Google Books, the Internet Archive, plus lots of other places, and here are some links. While you're at it, you may be interested in these other links to related resources that deal with Byron's poetry in different ways. My own opinion is: people are confused in general by library catalogs and their records, while the illustrations section is one of the least important areas of confusion. Considering all of this, maybe illustrations (some coloured, a few beautiful, several less than aesthetically pleasing, and a couple downright nasty) isn't so bad after all! James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Subjective Judgements in RDA 300s????
Hal Cain wrote: snip My point is that what we provide in cataloguing should be accurate as far as it goes, and it should go as far as is reasonably foreseeable to be useful. /snip Absolutely agreed, but my point is: in the environment we are entering willy-nilly, where everyone and everything is supposed to interoperate, the definition of the word accurate must be reconsidered. This is why I added the ONIX example: 500 illustrations, 210 in full color, 35 figures, 26 line drawings, 8 charts vs. illustrations (some colo*u*red) as possible descriptions of the same item depending on who made it. How does accuracy figure into this? Are we to consider them equally accurate? How does looking at everything in the aggregate affect matters, i.e. multiple records displaying multiple methods and the user sees differing practices more or less randomly? Will this trouble the users, or will they not even notice? How does the librarian figure into this? Does trying to maintain consistency in this bibliographic area not matter? Also, in the huge metadata universe beyond RDA/AACR2/ONIX, there are even more practices. Personally, I don't think maintaining consistency is worthwhile in this case, but I am sure others would have different opinions. I grant that illustrations are less critical, but counting the pages (extent) is far more important to decide that we are--or are not--looking at the same resource. There are lots (and lots and LOTS) of ways to count the number of pages. I discussed this at some length in that book Conversations with Catalogers in the 21st Century. (I need to put my chapter up on the web) This is an area that certainly requires consistency. snip A great deal of the detail provided in cataloguing has been irrelevant to the majority of users -- but vital to the people who manage the collections and make decisions about selection and discard, and significant to a fraction of end-users. /snip This is a key point that needs to be kept in mind. Libraries have their own needs and purposes (collection management) and this is reflected in their metadata. For the ONIX community, illustration information is added for their purposes, and represents an important *advertising* point, as they say in the Best Practices document under Business Case (these sections are absolutely vital to understanding ONIX): For many illustrated books the details on the illustrations are a critical selling point. Customers purchasing art books, for example, want to know the number of color plates included in a book. Customers purchasing atlases want to know the number of maps included in the book. This information can only aid in the sales of illustrated books to both trading partners and end consumers. Of course, this is quite different from the collection management purpose within the library catalog since there it is not a matter of getting people to open up their wallets and actually purchase a book, but rather simply to help them decide whether to consult it. (ILL is another matter) I keep going back to the talk Michael Gorman gave at the RDA@yourlibrary conference. It still strikes me as the best way to move forward in the current environment. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Abbreviations in RDA
Hal Cain wrote: snip The dictum that context imparts meaning is, I think, relevant here. In the context of an ISBD bibliographic record, printed or in a screen display, standard abbreviations have a context; nowadays, even so, possibly not all who see them in that context will understand them. In contemporary bibliographic displays, the context is often fractured. Therefore the meaning may be obscured. When we prepare to dismantle bibliographic data and mash elements into hitherto unseen combinations, we can assume no particular context, Therefore it seems to me that abbreviations no longer have a place in our workflows. /snip This is a very important point, but I have a different take on it. In the future, I think it is safe to assume that the catalog records we make will be mashed up with other things out there to create entirely new resources. (At least, I hope they will be because otherwise, our records will be ignored and not used at all) At this point in time, it is practically impossible to predict how our records will be used and changed, but one thing that I think we can assume: the traditional context will be lost, as Hal mentioned. This means that a bibliographic record will be seen *outside* the catalog, in isolation from the rest of the records it relates to, by way of headings and descriptive treatments. It will be just like looking at a few catalog cards taken out of a catalog. There are so many relationships that the headings and descriptions make little or no sense. (To explain this, someone can ask of a single record: Why did you use the form International Business Machines Corporation and not IBM, which is the way everybody thinks of it? Because the other records in the catalog use that same form. etc.) In the future, a record will also be seen from within different cultural/linguistic contexts. So, when a patron sees a record imported into a future mashup, it may be coming from--who knows where, e.g. (I hope these links work) http://tinyurl.com/68jaybd from the Deutsche National Bibliothek, where the abbreviation for pages is S. or from the Russian State Library, where the abbreviation is http://tinyurl.com/6ccpjwq c. but there are all kinds of other abbreviations, too in all of these records. So, while the Russian abbreviations may be incomprehensible to English speakers, the reverse is true as well. This is what our patrons will see and will be experiencing in the near future--I am sure that many are experiencing this right now--and we must respond. All of these library/catalog records will--sooner or later--be mashed up. Of that I have no doubt because people want it so desperately. [Concerning this, I suggest the recent report from CIBER Social Media and Research Workflow. http://www.ucl.ac.uk/infostudies/research/ciber/social-media-report.pdf, p. 29 where it is clear that above all, *everybody* wants from libraries a single search for all electronically licensed resources. I think we need to do more than that and include non-licensed resources, and that is what I have attempted to do with my Extend Search in my catalog at AUR] For our patrons, the universe of information has gone *far outside* the boundaries of our catalogs, and we must continually look at the information universe through the eyes *of our patrons*, and focus less on the information universe *of library catalogs*, which sadly, is having less and less meaning and importance to the world. This involves a total change in the intellectual orientation of catalogers, it's true, but it is vital that we do it. It has been compared by others to the intellectual changes people went through when the Earth ceased to be the center of the universe, and the Sun became the center of one small solar system inside an average galaxy within an immense, almost unlimited universe. How do/will our records fit in to such a universe? Does typing out abbreviations even play a role in it? How can we fix the situation for our patrons when they can see so many types of records created under so many rules and many times--if not most of the time, no rules at all? These are some of the genuine, and serious, issues that our patrons are facing, and by extension, we should face as well. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] rdacontent terms - dataset
Bernhard Eversberg wrote: snip 15.02.2011 20:48, Weinheimer Jim: In my opinion (and not only mine), this is the world we must enter, whether we want to or not. How do you enter this world? By creating Web Services. In order just to start to do this, you must use XML, since this is the language. It is not ISO2709. Now that is of course right. Only you must use XML does precisely *not* mean use XML as your internal syntax! It just means be able to use XML in the production and use of services. That, in fact, is posible on systems that use MARC internally, and even ISO-MARC. The misunderstanding here is the same that led to the internal use of MARC in ILSs in the first place. That was never really necessary, nor intended by the creators of MARC, for MARC was meant to be a communication format. In modern parlance, a service format, only that it was offline bulk services (magnetic tapes) at that time. Again, to make it clear: Internally, in the black box that is your system from the viewpoint of the world, you can do whatever you want to structure your data. You can even (although you should think twice) use ISO-MARC - only just let nobody see it. As long as you are able to answer requests in XML *and in other syntaxes that may be asked for*, in services that the world can use. XML is not a be-all or cure-all, and in 10 years' time it may be obsolete - we have no control over that. May we now put that matter of ISO to rest? I've never liked it myself, and it *ought* to be gotten rid of, but that's actually off-topic in this forum. /snip This is correct. I never mentioned ISO2709 being used internally. The internal format also probably won't be MARC, but some kind of relational structure, or an XML structure (as in Lucene), or a mixture of both (as in Koha). Each system internally can and probably will be, quite different, just as they are today. That is beside the point. The only catalog I know of that stores records internally in ISO2709 is CDS-ISIS, but there are probably others. All that matters ultimately however, is that the final product transfers its data according to a specified format. That aside, the matter of ISO2709 *is* of incredible importance for the transfer of our records, because so long as we use it for transferring records, we remain locked into all its deficiencies, no matter how great our internal systems may become. It's like having a dam within a drought-suffering populace that needs water. Your dam may be able to deliver 200,000 gallons of water a second, but if the pipes are old and can only deliver 100 gallons a second, the fact is, you can only deliver 100 gallons a second, and this remains the case even if you do more work and you can deliver 400,000 gallons. Although everyone wants your water, and you want to deliver it, the pipes must be upgraded if you are to help. And if we don't upgrade those pipes, we cannot blame the populace for looking elsewhere for what they need. So, perhaps we create these wonderful sites that internally have, e.g. 100 subfields in a field. Maybe we want fields beyond the 999 that we have now. None of this can be transferred using ISO2709. *If* we wanted to get rid of the single main entry, by making the 100 repeatable and everything associated with it, it would be a huge undertaking in ISO2709, if it could be done at all, but fairly simple in XML. There are lots of problems. I don't know if XML is the ultimate solution, but that doesn't matter. It would certainly be a step forward; a step we could take now; the developers could start working with our records now and the public--perhaps--might even begin to appreciate them; and it wouldn't cost nearly as much as instituting RDA (to bring the topic back). But you are right. I really do not like saying bad things about RDA on this list. The reason I harp on this is to provide a concrete example how we could adopt changes that are much less disruptive to us than the adoption of RDA, far less expensive, and that would (or at least could) have far more profound effects on the world out there. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Cataloguing non print materials
J. McRee Elrod wrote: snip I've had not one suggestion on or off list with any provision in RDA which makes it easier to catalogue electronic resources than using AACR2, which might have been added to AACR2. /snip That is very interesting and it certainly mirrors my experience. Cataloging electronic resources that you do not control, e.g. a digital copy of a book on the web, is not more difficult than cataloging a regular book. You just handle it differently, and decide if it is, in FRBR terms, a new item or a new manifestation. Keeping a valid URL is the major difficulty. Working with the real web materials is completely different, but this does not mean that they are any more difficult to catalog. In my experience, the problems fundamentally stem from the nature of the materials: 1) it's difficult to examine the item. With a book or map or recording, etc. it is pretty easy to examine the entire item before you begin cataloging. With web sites, you don't know where it starts or finishes, when you have left the site or not, etc.; 2) the information on the item changes constantly and unpredictably, so you can never be sure whether the record you made last week--or even five minutes ago--has anything to do with what the resource looks like now. But none of this is really new, since these are essentially the same problems we face when cataloging serials and looseleaf publications. That's why I think that the real problem is: 3) web resources change with no notice. With physical resources, the mail arrives, is sorted out, and the relevant materials eventually get sent to someone who updates the record. With web materials, this no longer applies since the web master can change the title of the resource, the site can even be hijacked, or whatever and the record does not change because we have not been notified. The note we provide that gives the date the title was viewed on: Title from home page (viewed April 22, 2002) is just pathetic and is similar to: Don't blame me, I'm only the cataloger. None of this has anything to do with cataloging *rules* and much more to do with procedures and using technology to deal with a different kind of material. I still believe my ideas from an article I wrote in Vine Magazine from 1999 could point toward a solution. The article was much too long (my normal problem, I know) but in essence suggested that using embedded metadata within the resource could be checked by a web spider periodically and if certain information were updated, the catalog record would be updated as well. I saw the workflow as: a selector decides a site is worthwhile and provides some instructions to the cataloger (e.g. analyse certain subsections of the site). This goes to a cataloger who creates the record(s). The web master is notified that the site has been selected as especially worthwhile and given a copy of the metadata record(s) to be placed on specific page(s). Then, if the web master changed the title of the site or other information such as the dates or basic description, he or she would be required to change the dc:title or dc:date in the embedded metadata record. (This is simple for the web master) A spider would check it periodically, and if any changes are found, they are added in the catalog record automatically, and messages sent both to catalogers and the web master to notify everyone of the changes. I saw it as an interactive CIP and apportioning the labor where it best belongs. But I have never seen how changing cataloging *rules* have much to do with the matter. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] rdacontent terms - dataset
Bernhard Eversberg wrote: snip Another reason why I think that not MARC is any of our troubles but the glacial reluctance against using MARC intelligently or at least in more reasonable and elegant ways. This would include abolishment of ISO2709, without which MARC wouldn't lose any of its potential. Although Jim Weinheimer seems to believe MARC can't live without it. At least, it is very safe to say that XML is not an antidote to ISO2709, nor even a viable way to escape it. But overkill it is, for the actual ecosystem we have to cope with. /snip I guess I am being completely unclear. MARC *definitely can* live outside of ISO2709. The first step is to overcome the limitations of ISO2709. ISO2709 is the language of the traditional library. XML is the language of the web. Switching just to MARCXML would be a tremendous step forward for libraries into the web, if for nothing else, so that we could have an infinite number of subfield codes. We just have to get rid of the roundtripability feature of MARCXML, which is actually not a feature but a prison cell. Of course, MARCXML doesn't solve all the problems, but one big one will be out of the way. Plus, it could be done in such a way that catalogers probably wouldn't even notice a difference. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] rdacontent terms - dataset
Bernhard Eversberg wrote: snip Am 15.02.2011 15:27, schrieb Weinheimer Jim: Of course, MARCXML doesn't solve all the problems, but one big one will be out of the way. Oh get real, Jim! The plain text format of MarcEdit can do the same, with an absolute minimum of effort when compared to MARCXML. Don't overlook the constraints of our actual ecosystem. Where ISO can't be avoided, for some updating or transfer purposes, MarcEdit can still be converted both ways with existing tools. Where MARCXML is desired, it can be produced from both ISO-MARC and MarcEdit. MARCXML must be looked upon as an add-on, not a requirement or necessity to escape the present, unsplendid ISOlation. /snip I am being real. The plain text format of MarcEdit *absolutely cannot* do the same as MARCXML. I'll prove this right now. Browsers are built to work with XML, so right now, this second, any webmaster can work on the fly with XML using nothing more than a browser. They need no other tools. This is the importance of XML. Here is an example of how it works and you can change it yourself where you can add in variables and values as you want: http://www.w3schools.com/xml/tryxslt.asp?xmlfile=simplexsltfile=simple For example, in the XML part (left side) add a value under food thingThing/thing In the XSLT (right side) under xsl:value-of select=description/ copy and paste this: span style=font-weight:bold;font-size:5em;color:red;xsl:value-of select=thing//span Then, click the button and see what happens underneath. This particular example is done using a server, but it can be done in a browser, or both. There are a thousand variations on using XSL Transformations, some very impressive. I always assume that when you have an XML file, you can do *anything* with the information within it. Anything at all. There are also a lot more ways of using XML records than only XSLTs. You cannot do this with a plain text format. Even though I use MarcEdit every day, nobody in the world uses (or will use) it except for libraries and librarians. MARC in its ISO2709 form is used today *only* for transferring records from one *library catalog* to another *library catalog*. It has no other function. This is why I say that so long as we use ISO2709, we are stuck on Library Island because nobody else can transfer our records. Why? Because you can't do anything at all with them until you have parsed them out and transformed them into a format you can deal with. Therefore, if a webmaster wants to work with our records now, they first have to parse them using a separate tool (like MarcEdit) to transform them into XML (or some kind of format that works with a web browser), and this they will not do because they *cannot* work with the records on the fly, as they can easily with the XML above. If we supply people with XML--even DC simple--they can at least work with it to an extent. Again, if somebody were to include an ISO2709 parser into every browser, matters may be different (maybe?) but there is no chance of that when it is we who should change and not everyone else. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] rdacontent terms - dataset
Jonathan Rochkind wrote: snip On 2/15/2011 10:34 AM, Weinheimer Jim wrote: I am being real. The plain text format of MarcEdit *absolutely cannot* do the same as MARCXML. I'll prove this right now. Browsers are built to work with XML, so right now, this second, any webmaster can work on the fly with XML using nothing more than a browser. They need no other tools. That's not really true. Most browsers don't give you any tools for 'working with' XML, although some (but not all) of them will display it with nice syntax-aware coloring. /snip Sorry to contradict you, but I have done this myself multiple times. Here is a discussion of it: http://www.herongyang.com/XML/Browser-XML-File-Browser.html. Anybody can work with XML and XSLTs with a browser, and in fact I have had to do it because I did not have access to the expensive XMLSpy, which verifies your XML. But I think I finally understand where the disagreement lies. For example, you mentioned: snip Nonetheless, I see no reason to think getting either MarcEdit text format OR MarcXML to be processed natively by our ILSs would be an improvement for us at all. If that's what's being suggested? I'm not sure what IS being suggested. /snip No, I am not suggesting ILSs. If everything were based on everyone searching separate library ILSs, everything would be fine but that is no longer the case. The internet is growing through means of mashups and apis. This is an absolute fact. This is a wonderful development and extremely powerful. But what does this mean exactly? I think the best explanation is this short video from ZDNet that I suggest everyone watch. http://www.youtube.com/watch?v=ZRcP2CZ8DS8. In my opinion (and not only mine), this is the world we must enter, whether we want to or not. How do you enter this world? By creating Web Services. In order just to start to do this, you must use XML, since this is the language. It is not ISO2709. What are some examples? Let us imagine that a scholarly group wants to build a site about baroque architecture (this is true since I know some of them). One thing they should be able to do is to make automatic queries behind the scenes (i.e. web services) to bring together all kinds of information to create some new tool of use to their community. They can--right now, today--use Google Maps, Google Books, Amazon, Yahoo, dbpedia, the Internet Archive ... Here are just a few of them available now: http://www.programmableweb.com/apis/directory. In here, we can see that there is a system called BookBump http://www.bookbump.com/ that uses a number of apis, including the LC SRU API http://www.loc.gov/standards/sru/, which is based on providing records in XML. Unfortunately, there still doesn't seem to be a Google Scholar API, which could be one of the most important apis for our community. If we do not enter this world based on APIs and web services, I fear that we will be left behind completely. The general public will never even know about our records. We must let our data enter and interoperate with other apis in ways we cannot foresee right now. We also cannot expect that everyone will consciously click on the links to our catalogs and search them, because they just won't. Besides, people want to use our information in genuinely unique ways they never could have before. This is why I feel so strongly that sticking with ISO2709 for transferring records hurts us terribly. The longer we remain in that ISO2709 straight jacket, the less we can enter the world where everything is happening. There are other reasons, too, but in the world of mashups, we cannot assume that people will come to our ILSs, especially when they will be able to use the Google Books api or the LibraryThing api or the Internet Archive api. There must be some kind(s) of Library api. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] RDA and MARC
Karen Coyle wrote: snip I'm not sure how you calculate this. There are only 9 single-digit numbers (0-8, since 9 is for local use only), and most of them have already been used: 0, 2, 3, 4, 5, 6, 7, 8. A decision was made early on that the number subfields, to the extent possible, would retain the same meaning in each field in which they were used. Perhaps you were thinking about using upper case letters, which would indeed give us 26 more options. That has been suggested many times at MARBI and never accepted even for discussion. The MARC record structure would allow the use of more than one character for the subfield code, e.g. aa instead of just a. (Up to 9, BTW, since it's a one byte numeric field). That would give us scads more possibilities, but would require a lot of coding changes for software that processes MARC records. The number of characters in the subfield code is encoded in the leader, so we could actually mix 1-char and 2-char records in a single dataset, but most code that reads and writes MARC doesn't use that Leader byte to control the number of characters -- we tend to assume 1. /snip Of course, this all assumes continuing the completely 100% obsolete ISO2709 format from the 1960s. For example, is the Unicode set valid for subfield codes? If not, why? Why can't we have a subfield lambda or rho? Why not a Chinese character or Church Slavic? If these were allowed, then we would have 1,114,112 possibilities, according to the high authority of Wikipedia http://en.wikipedia.org/wiki/Mapping_of_Unicode_characters. That should be enough. The answer is, such a suggestion is ridiculous since not everybody understand Chinese or Church Slavic. I agree, so the obvious question is: why do we have to be stuck with ISO2709 and single subfield codes? The instant we switch to an XML structure, even MARCXML, we can begin to add subfield codes that are 2, 3, 4, 5 or as many characters as we would like. It's time to get rid of the leader, the directory and the entire structure of the ISO2709 record. It served its time but has long been detrimental to the further development and sharing of library metadata. I still don't understand. Here we are discussing changing cataloging rules (well, not so much the procedures, but the numbering and structure of the rules) spending money so that every cataloger will have to be retrained and catalogs will have to be retooled; yet this lousy ISO2709 format seems to be sacrosanct. Why? It absolutely must be dumped overboard, and the sooner the better. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] RDA and MARC (was Linked data)
Kelley McGrath wrote: snip There was a discussion a while ago now about the problems (or not) with MARC. I gave a presentation at ALA Midwinter called Will RDA Kill MARC? I was sort of waiting for the official version to be posted, but, although the person organizing the presentation has tried to post it on the ALA/ALCTS site, apparently the site down a lot. So in order to belatedly get my two cents in, I've put the presentation up at http://pages.uoregon.edu/kelleym/KM_MWpresentation.pptx for anyone who might be interested. I guess my point is that we could make MARC do at least most of the things we need it to do to support RDA, but that's probably not the best use of our limited resources. Interestingly, one of the audience members asked rather if MARC will kill RDA... /snip Thank you so much for sharing this presentation. It's no secret what I think about RDA, FRBR, and MARC but I agree with a lot of what you point out. Yet, I do have a question. On slide #15, you use an example MARC record to show how the current coding of our data is inadequate by referring to a record (which I discovered to be Flume by Martin Boykan) and at first, I could not understand how the coding you presented there was inadequate. But I realized that the problem (if it turns out to be one) is that the information for e.g. Cyrus Stevens, only pertains to the first work (Sonata for violin and piano), which was performed at the Sonic Temple, etc. and that the other pieces of music there had other performers and performance information. As a result, information for the separate pieces is spread around all over the place and as you point out, it cannot be brought together. [As an aside, for the entire record, you can see the one at Princeton http://catalog.princeton.edu/cgi-bin/Pwebrecon.cgi?Search_Arg=A-200+CD+897Search_Code=CALLCNT=1HIST=1 (You need to click into the record. It's the closest I can get), and it is also interesting to compare this with the version from Amazon, using that wonderful conversion tool: http://amazon.libcat.org/cgi-bin/az2marc.pl?kw=B6IZMR. By the way, the library record seems superior in every way, allowing controlled access to every name and title.] But I wonder if what you point out is a genuine problem, especially in an RDA/FRBR universe. The user tasks are to find, identify, yadda -- works, expressions, manifestations, and *items*. Not sub-items. This record seems to allow everything that FRBR requires, plus it allows even more because if I am looking for Boykan's First string quartet, there is a beautiful controlled analytic. This level of analysis is rarely followed in regular cataloging of other materials. So, as far as finding goes, there is absolutely no problem. It is just that in order to *see* the metadata associated with this particular piece (remember, I can still *find* it!), I have to look at the description for the entire item. Nevertheless, it can be found--and in a controlled way as well since the cataloger did a good job--and this information is available for the later user tasks of identifying, selecting and obtaining. This seems to fall squarely within the FRBR requirements. Of course, breaking it all down could be achieved today in MARC through doing separate constituent entry/host entry records, so that the information that is scattered around within the single record would actually come together in the separate records. With a more flexible format than MARC, the information could be grouped within the same record, e.g.: record metadata for host entry title/title author/author publication/publication ... metadata for 1st constituent title/title author/author details of the performance /details of the performance ... /metadata for 1st constituent metadata for 2nd constituent ... /metadata for 2nd constituent /metadata for host entry /record None of this would allow for more *access* than what we have right now however, since people would still be able to find exactly what they can today. I am sure that it would be just about as much work for the cataloger as doing constituent/host entries. The actual difference would be with display, since the constituents would display within the host entry, if it were desired. (Although they wouldn't have to) While this *may* be more flexible than what we have today, I still believe that with XML and XSL Transformations, we could probably have almost the same displays available using our current constituent/host entry cataloging. (By the way, I am *NOT* at all advocating we institute host/constituent cataloging!) A difference could be if we added controlled access for, e.g. place and date of a performance, perhaps similar to a conference heading, but I am also *NOT* advocating that, either! I can imagine that a problem could arise with interoperability with another catalog/database that coded these matters separately, e.g. a music recordings database where you could search for
Re: [RDA-L] general interest in RDA
Barbara, I agree with what you say almost completely. Libraries must update their world views to include what the general public actually uses by adapting to the new information environment, or as I described it in my talk at the RDA@yourlibrary conference, these are matters of Darwinian survival. Where I disagree is that I believe the changes of RDA really are just little tweaks to AACR2 and the LCRIs; they are not indicative of any real change either for the sharing or production of our records, and will not help or hinder the new directions you outline. But catalogers themselves will be hindered since everyone will have to learn to use new tools and new terminology to produce what is the same product as today, except for a few cosmetic changes. I have yet to see how RDA will improve the situation for our patrons, while being incredibly disruptive--and expensive--for us. We need CHANGE--not typing out abbreviations and adding a few extra fields. Those are not the problems we face. But I am repeating myself, and I hate to say bad things about RDA on this list. The more I think about it, I think Michael Gorman's talk at the conference really makes the most sense in the current environment. Still, I think we all agree about where we want to end up; we just disagree on how to get there. Jim James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/ -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Tillett, Barbara Sent: Friday, February 11, 2011 2:37 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] general interest in RDA James - If we just keep business as usual, I am convinced libraries will go the way of the dinosaurs, and very soon (as we've seen academic and public libraries shutting down branches and closing catalog depts to rely on vendors or technicians to do copy cataloging only). The metadata we provide has tremendous potential for re-use in the internet environment in ways that will make libraries even more relevant to users everywhere, and that is what we are preparing for with RDA - when we can move to creating well-formed metadata following RDA's elements and relationships, away from the AACR2 mentality of creating only linear citation listings with main entries and authorized headings (it can be done other ways, given labeling the data for machine re-use). We must break with that kind of 19th and 20th century thinking. It's not just a matter of little tweaks to AACR2 and LCRIs. We definitely need our vendors on board to make all this much easier for catalogers, and we can build a shared vision of where we are going with all this. Why not a shared datafile of the world's bibliographic and authority data, freely accessible for all to use - not behind OCLC's WorldCat with its costs and restrictions and the costly repetition of the same data in local OPACs around the world - why not replace OPACs with much better resource discovery systems? Ex Libris is moving that direction as is III. Those resource discovery systems of tomorrow will be able to answer all sorts of user questions, not just the author/title/subject index choices we give them now, and not just be proprietary to libraries but open to the entire information community. We could be doing so much more for so much less cost by sharing globally and using a structure of well-formed metadata, packaged in an RDA-based XML schema. I would much rather be energized by such a prospect than wallow in the gloom and doom of today's economic woes. Let's make it less expensive and better than ever. - Barbara Tillett (these are my own personal views, not speaking as Library of Congress) -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Weinheimer Jim Sent: Thursday, February 10, 2011 10:58 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] general interest in RDA Diane Krall wrote: snip Sent: Thursday, February 10, 2011 4:22 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] general interest in RDA Mike Tribby said: At this point any librarian interested in cataloging or the functioning of their catalog *should* at least know about RDA, but so far many don't seem to have that knowledge or any interest. I have to agree, based on 2 personal experiences. The head of Tech Services at my library has been asking what our ILS vendor's plans are for RDA, but they seem to be totally unaware of it. Also, in speaking with MLS students from Indiana Univ. as part of a cataloging assignment, I
Re: [RDA-L] general interest in RDA
Kevin M. Randall wrote: snip Jim, it sounds from this comment that you really are not grasping what RDA is all about. If you look at it just in terms of the guidelines themselves, or the resulting MARC records currently being created, certainly it would seem that it's just a little tweaking here and there. But the underlying philosophy and structure of RDA are nothing short of revolutionary when compared with AACR2. You are asking for change; and a huge change is what RDA is actually helping to bring about. AACR2 is based on the eight areas of ISBD, and guides the cataloger through the process of putting together a description for ISBD display. RDA is based on discrete bits of data (the RDA elements), each uniquely identified (that's a VERY important part), and guides the cataloger in supplying those bits of data, regardless of what kind of display is going to be used. /snip ISBD/AACR2 guide the cataloger to put together a description for ISBD *display*?! I confess that this is a very strange idea to me. I personally don't think about display when I am cataloging anything. Very few online catalogs use an ISBD display for the unit record, so Worldcat, Voyager, Dynix, etc. each have all kinds of displays for their records. (OK, I confess I'm a throwback and I have used a modifed ISBD display in my catalog, but I don't have to). ISBD mandates standards for the *creation* of the single record (or unit record) such that the description can be shared internationally. Currently, the ISBD standard separates the elements using punctuation, but it could just as easily (and should) be linked to UNIMARC, much as the LCRIs now show the MARC format; but UNIMARC is based much more closely on ISBD than is MARC21. AACR2 continues ISBD (with a minimum of differences, we hope?) to stipulate how these separate records should link together, defining strings of text that imply some kind of physical arrangement (primarily alphabetical, or dictionary), and this method of alphabetical browsing is continued into subjects as well. Now, if we are talking about the displays of *multiple records*, that is another matter, since FRBR discusses e.g. what a user *needs to be able to do* with a work or expression. While the RDA elements are very important, and they are uniquely identified, and I don't want to be mistaken that they are not important because they are; nevertheless, this is not something all that new, since a coding such as 260$c and http://RDVocab.info/Elements/placeOfPublication are equivalent. So, we could just as easily have http://RDVocab.info/Elements/260c but we want things to work with *English* language terms, something that was not possible back in the 1960s when MARC and ISO2709 were created. With the rise of the FRBR framework, other possibilities became possible which, we must admit, were always there, but went beyond the purposes of the catalog (as it was at that time) e.g. the place where a work was created as opposed to the place where it was published, or you can have the extent not only of a manifestation, but of an expression. Again, I posit that this is not really new; a cataloger could always have done the extra work to find out where Stephen King wrote The Shining, but it wasn't seen as worth the effort so there were no guidelines for establishing or encoding it. For some cases of manuscripts and early printed books, the extent of the actual expression inside the physical items was seen as absolutely important, and has been described in far more detail than regular, mass produced books. It remains to be seen if our predecessors were correct in considering that adding this information to be not worth the effort or perhaps some kind of crowdsourcing or interoperating with other databases will provide a solution, if indeed, it is determined that there is a problem. But ISBD is primarily a standard for *description* and not display, i.e. how to describe an item for maximum clarity and interoperability in the greater world. There are just a few pages of rules for punctuation, while the vast majority discuss how to determine which information to input and how to do it. The rules for description are incomparably more important than those for punctuation. Anyway, the display that ISBD mandates is followed by almost no one now and is pretty much ignored since other methods have overshadowed them. Whether this is wise or not is a matter of debate. FRBR continues ISBD in a theoretical sense, and attempts to create a framework for how the aggregate of records are supposed to function with one another, but once again, I suggest that FRBR does nothing more than describe how our catalogs have always worked--and does not discuss whether these are the tasks that users themselves really want and need to do. For only one instance, the dictionary catalog is *dead*--dead and, it should be, buried. These are a few of the challenges we face of *genuine change*
Re: [RDA-L] general interest in RDA
Nerissa Lindsey wrote: snip It is interesting to hear that RDA isn't being taught yet at many of these programs. I personally think that this is unfortunate, because even if RDA is not adopted I think all cataloging students should at least be learning the fundamentals so they know why it is even being considered as a replacement for AACR2. I can understand why people who have worked in the field for many years are 'tired' as Mr. Weinheimer has mentioned. However, graduates from MLS/MLIS programs are going to be shaping the futures of cataloging/metadata departments of all kinds, and I think that educating them in RDA is just as important as teaching AACR2. I just finished my MLIS in June '10 from the University of Washington, and last spring they offered a course called RDA and Metadata taught by Diane Hillman. I gained a lot of insight from auditing this course that I wouldn't have otherwise if I stuck with just the regular cataloging courses. I see a trend across libraries at least in the US where cataloging departments are changing their names to things like cataloging and metadata department or just metadata services. I even applied for a position with the title: Resource Description and Access manager after I had graduated. I have heard stories about libraries who are hiring metadata librarians and not planning on replacing their catalogers when they retire. I do not feel qualified to state whether I think RDA is the best option or not, but I do know that any student hoping to make it in this field after they graduate better have at least a solid educational foundation about RDA. /snip Thanks for your input. I very rarely get to hear the voice of the younger generation, so I really appreciate it. But let me mention, as one of those old codgers, that the world of metadata is a huge one with practices you (and I) cannot imagine, much less agree with. The voice of experience suggests that underestimating the complexity of the task facing us will lead straight to failure and ignominy. The people who come after us (and I hope, many of us who are still around--including myself!) absolutely *must* find some kind of ways to bring these disparate methods into something approaching harmony. The old methods are shot--I completely agree. The workflows, the methods, the *almost* everything, must change radically. (OK, some things can stay!) One thing I am certain about: if librarians/catalogers don't do it, somebody else will, perhaps Google or Yahoo (both for-profit corporations), perhaps an agency from some government (US, UK, Italian, German, Chinese, Russian?), perhaps an international organization, perhaps some 12 year old kid in his basement. I don't know which one, but I do know that sooner or later everybody's work will interoperate in some way, even if that means that it is all mashed together semi-mindlessly, on the order of the Google Book metadata that we have now. The assumption that the 19th century conceptual framework of RDA/FRBR encompasses this huge, changing universe is rather bewildering, and completely unwarranted, in my opinion. RDA/FRBR are representative of the old methods (again, in my opinion!). While I will admit that there is a remote possibility that this rather ancient world view of FRBR may actually describe what we are facing today, I remain *extremely skeptical*. In fact, it is my belief that if Panizzi, Jewett, Cutter, etc. were alive today, they would be the first to throw out the old ways to find what people *really* need and what our capabilities really are. I prefer not to say bad things about RDA and FRBR on this list, so I apologize. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] RDA provisions
Brenndorfer, Thomas snip The entries are organized by his role in each film: actor, director, producer, soundtrack, composer, miscellaneous crew, camera and electrical equipment. This is a very user-friendly organization. The whole point to RDA is to allow properly differentiated and interconnected elements to thrive in these kinds of displays. Burying data in text descriptions is just that-- burying. It's wasted effort, and the data is of limited utility, happily living in flat file card-like environments, but not much use elsewhere. It's true that making full use of RDA elements in MARC is a problem, but it would be wise to assert that it is MARC that has the problem, not RDA. /snip It may not be so much a MARC problem, but a conscious decision among catalogers quite some time back that continuing this sort of access was unwarranted. Adding relator codes have always been possible http://www.loc.gov/marc/relators/relaterm.html but, while I cannot point to a decision from where I am currently, it was obviously decided that it was not worth the effort. At this point, I can point to some cards http://1.bp.blogspot.com/_gU8TOkockqs/TKO77DZVvSI/Ai4/_WHr-zMo_ac/s1600/loc-card-catalog-entries-sep-2010.jpg, that show earlier practices of joint author, and comp. The original LC AACR2 Rule Interpretation on relators apparently was issued in 1982, p. 29-30, when they decided not to apply the option, except for ill. for illustrators of added entries. http://www.loc.gov/cds/PDFdownloads/csb/CSB_018.pdf. In addition, certain communities went their own ways, e.g. the art cataloging community for access for artists such as Albrecht Durer, who fulfilled many roles. There is a lot of metadata that could be added to records that is considered not worth the effort. It's important to distinguish between a complete lack of access (i.e. when a name is not recorded at all) as opposed to more specific access, such as being able to limit a search to someone as an editor, a publisher, a producer, a joint author, and so on, although the person's heading can still be found. Of course, any information at all can be added, but the unavoidable question is: is it worth the effort to distinguish blurb writer from licensor? A practice that can be achieved only by 1% or 5% of the cataloging community cannot be considered practicable for the entire cataloging community. Perhaps in highly specific databases, it is worth the effort but for a general cataloger, practical matters must enter into it somewhere. And *especially so* today since the cataloging community is facing highly restricted budgets for a long time to come. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/
[RDA-L] Cataloging Matters Podcast #8. RDA: the wrong solution for the wrong problem
All, Please share this message with anyone you think may be interested. I would like to announce that the next podcast of Cataloging Matters is available. This one is a little different. It is the paper that I delivered at the online RDA@yourlibrary conference last Friday (Feb. 4) http://rda.amigos.org/. The title is: RDA: the wrong solution for the wrong problem. The Amigos consortium very kindly shared the recording with me. In this one however, the embedded file didn't work for some reason, so to listen to the podcast, I placed a simple link to the file, now in the Internet Archive. As always, the transcript, with links, is on my blog. Apologies for no music on this one! The next one will have music, I assure you. James Weinheimer j.weinhei...@aur.edumailto:j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Linked data
Hal Cain wrote: snip I think we could devise efficient ways to encode the necessary data in MARC 21, and in a way that will enable older systems (not designed for such extended provisions) to use the data no worse than they do now (supposing the data is actually there). Some may be better carried in the authority data, perhaps. And we record the data with all the essential information in sufficient granularity and consistently, surely it should be possible to extract it in other forms for other applications. /snip I agree that doing this (in my idea, this means having more than a single main entry or in other words, multiple 1xx fields) could be done so that the records work as well as they ever did. Still, I have considered this, and I don't know if it could work with the current MARC structure, or, if it could, is it worthwhile to change it? It can certainly be done in MARCXML, although major changes would have to be made, especially the prerequisite of roundtripability with ISO2709 format. It is only a moment's work to make the 1xx field repeatable, thus making it into the equivalent of dc:creator, while making the 7xx equivalent of dc:contributor, but the problem comes with analytics and name/title headings. So, a 600 for Gilbert and Sullivan must somehow allow for Sullivan as well. Plus, the 7xx and 8xx fields. I don't know how this could be done in the current MARC format, although in a variant format, such as: subjects subject authors author 100aGilbert, W. S./100a 100q(William Schwenck)/100q 100d1836-1911/100d /author author 100Sullivan, Arthur/100 100d1842-1900/100d /author /authors titles title 245aH.M.S. Pinafore/245a /title /titles [would we need this wrapper?] subdivisions standard Discography /standard /subdivisions /subject /subjects (You see I'm improvising here) Delineating each author seems to be necessary to ensure that Gilbert does not get the dates 1842-1900. In any case, this is what we would have to solve if we were to make the 1xx field repeatable and thereby get rid of the problems of a single main entry. In an FRBR world, with a work record, a lot of this could be imported, but the ultimate structure would remain similar. Can this be achieved in our current MARC structures? Perhaps. But since there are much more powerful and flexible formats out there, maybe it's time to salvage what we can and just move on. Or maybe there is a MARC solution (non-ISO2709!). I don't know. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Linked data
My own opinion is that the term access point should be relegated to the same oblivion as we have placed the terms library hand and librarian's knot. With keyword capability, each word in each field is now effectively a point of access. The idea of access point is based on the limitations of physical catalogs from the distant past (distant past at least in Internet terms). The traditional access point has evolved into controlled vocabulary which functions differently from free text, but both are equally accessible. This has been the case for at least 20 years or so? And if we add to the concept of controlled vocabulary certain types of standard numbers, matters simplify (or at least I think they do). There are different kinds of these standard numbers however. There is a standardized number that is assigned by outside agencies, and then there are numbers that relate only to internal database structures, such as 773$w. So theoretically, if a single (let's say) physical item is analysed into 10 separate articles, the number that could bring all the analytics together could be either the 773$w or a 020 if it existed. So long as the 020 would be unique (which is not always the case, but let's assume for the moment that they are) the 020 would be universally applicable--and therefore sharable--while the 773$w could not. I feel like an anachronism! It's time we had some new vocabulary. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] Linked data
Bernhard Eversberg wrote: snip This tells us something about LC, but about MARC? LC might, in fact should and certainly could, add MARCXML to the options instead of providing merely ISO there. They might add EndNote and BibTeX as well, and more. /snip I hate to keep repeating myself, but I feel it is important that I make sure my point is clear, whether or not others believe I am correct. When I mention MARC, I am not talking about the codings and subfields, but the ISO2709 instantiation of it, which is useful *only* to librarians. This is because that for all practical purposes, only librarians have the tools to deal with ISO2709 records. Excellent as it is (I use it every single day!) nobody but a librarian will use MarcEdit, and we shouldn't expect them to. This is why I say that so long as we rely for transfer of library records using the ISO2709 protocol, we remain marooned on Library Island because nobody else can use them. By making our records available in MARCXML, we make library records available to everyone in the world, in a format that allows people to do with them as they wish. If we make BibTex and EndNote available, while that's OK, this is only partial information. If you make the entire MARCXML available, people could create their own style sheets for MARCXML and create their own EndNote, BibTex or any other format(s) they want. Or, they could do much more. The downside is: to work with MARCXML, developers need to know the MARC codings and subcodings. While this is quite I bit, I think that if people want it badly enough, they can deal with it. These developers are pretty clever folks and libraries should give them a chance, plus a bit of help since they would be helping us too. As we see how this works out, we can begin to think how to change MARC in the best ways for the public and for ourselves. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Linked data
I guess I didn't make myself clear. When there are different titles listed in the 245, there is *absolutely no reason whatsoever* why a computer would have to extract those titles automatically since the cataloging rules make very clear that they are supposed to be traced in separate 240, 246, 7xx$a$t and 740 fields (off the top of my head, probably not an exhaustive list). The parsing has already been done and the computer work is superfluous. A cataloger knows this, while a non-cataloger does not. There is no algorithm needed since the cataloger has done all the work manually. In the example in the article, I found the record the author mentioned and showed how the cataloger had parsed it all manually. Where is the problem with this? Why parse something that doesn't need it? Why not use the power of the entirety of the records? It seems that from your post, you are maintaining that a title in a 740 or 246 field, or in a 700$a$t field is not usable? James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/ From: Jonathan Rochkind [rochk...@jhu.edu] Sent: Wednesday, January 19, 2011 7:03 PM To: Resource Description and Access / Resource Description and Access Cc: Weinheimer Jim Subject: Re: [RDA-L] Linked data Again, as someone who knows cataloing rules, if there's an algorithm you can give me that will let me extract the individual elements (actual transcribed title vs analytical titles vs parallel titles vs statement of responsibility) reliably from correct AACR2 MARC, please let me know what it is. I am fairly certain there is no such algorithm that is reliable. I guess you could say that there's no reason to _expect_ that you should be able to get those elements out of a data record. But most developers, library or not, will consider bibliographic data that you can't reliably extract the title of the item (a pretty basic attribute, just about the most basic attribute there is) from to be pretty low-value data. They won't change their opinion if you show them the record serialized in MarcXML instead of ISO Marc21. All that you get by being an expert in the data is the knowledge that you _can't_ really reliably algorithmically extract the transcribed title alone from any arbitrary 245 of Marc/AACR2. It'll work for the basic cases, but once you start putting in parallel titles, analytics, and parallel titles of analytical titles, it's a big mess -- and such complicated cases (which are rare in general but common in some domains like music records) are also the ones where the cataloger is most likely to have gotten the punctuation not EXACTLY right, making it even more hopeless, even if the programmer did want to write an incredibly complicated algorithm that tried to take into account the combination of ISBD punctuation with marc subfields. Yes, many of these issues have been known from the beginning and dealt with in various ways. That doesn't make the data easily useable by developers, whether you put in MarcXML or not. Those various ways, if we're talking about software trying to extract elements from bib records, are expensive (in developer time) and fragile (they still won't work all the time) hacks. On 1/19/2011 12:52 PM, Weinheimer Jim wrote: Jonathan Rochkind wrote: Concerning: One example of this can be found reported in this article: http://journal.code4lib.org/articles/3832; snip Okay, what would someone who knows library metadata do to get a displayable title out of records in an arbitrary corpus of MARC data? There's an easy answer that only those who know library metadata (apparently unlike people like Thomale or me who have been working with it for years) can provide? I have my doubts. /snip I agree that this is an excellent article that everyone should read, but I wrote a comment myself there (no. 7) discussing how this article illustrates how important it is to know cataloging rules and/or to work closely with experienced catalogers when building something like this. It also shows how many programmers concentrate on certain parts of a record and tend to ignore the overall view, while catalogers concentrate on whole records. In this case, the parsing is *always* done manually by the cataloger, who is directed to make title added entries, along with uniform titles, including the authors--that is, so long as the cataloger is competent and following the rules. So, it is always a mistake to concentrate only on a single field since a record must be must be considered in its entirety. It would be unrealistic for systems people to know these intricacies, but it just shows how important it is that they work closely with catalogers. Therefore, it's not *necessarily* arbitrary. Many of these issues have been known since the very beginnings and have been dealt
Re: [RDA-L] Linked data
Bernhard Eversberg wrote: snip They could use the MARCXML records right away? You're sure about that? Has this assumption been tested with users who know nothing about MARC? Of course, they cannot use ISO-wrapped records. But even to use MARCXML records, you still have to have quite a lot of MARC insight the records do not carry with them. /snip. You already supplied the same answer I would have: with MARCXML people *can*, i.e. it is possible, while with ISO2709, they *cannot*, i.e. it is impossible (practically). But yes, you have to know a lot about MARC. Still, I don't see why the general populace would want an entire record, and they could take what they want, e.g. the ISBD information (simple enough to take), the headings, especially if the links were there, ISBN, etc. Librarians could supply those types of style sheets and people could play with them for their own purposes. Perhaps someone could make an XSLT-generator that would let people choose what information they wanted, and they could choose titles, authors, Dewey, etc. Although this would be difficult for me, creating something like this would probably be child's play for someone out there. Once you have XML, there are possibilities. Without it, there are none at all. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Linked data
Bernhard Eversberg wrote: snip So, please forget about ISO2709. For all the flaws that MARC is ridden with, and I can give you a long list, this is not among them. It has nothing to do with the *content* of MARC records, and about nothing else do we need to worry, and we can easily give that content to anyone without any trace of ISO. /snip I wish I could forget it, but it's in our faces and we have to deal with it every single day for every single record. This is my entire point. Today, right now, if *anybody* wants to work with library records from any library catalog, e.g. LC's catalog, their *only choice* is ISO2709, except for the non-delimited formats of Text-Brief and Text-Full. OCLC allows citation-type exports, e.g. see Cite/Export on any record in Worldcat http://www.worldcat.org/title/metadata/oclc/225088362referer=brief_results At least through the Worldcat API, OCLC supplies citations using partial XML (not MARCXML) using the RSS protocol. Using that XML, I am now able to take that information, reformat it *on the fly*, and automatically display it as I want to in my catalog. My patrons really appreciate that. If my only option were to get the ISO2709 record, I would have to devise some system that would download it, parse it, then create the XML before I could begin to do anything at all. If I received an entire MARCXML record instead of the abbreviated RSS one for citations, I could do even more than I do now using the tools that can work with XML on the fly. I could apply my own style sheet to display what I want how I want, and more importantly, operate as I want, once again, *on the fly* with the browser doing all the work, just as it does now with the citations from Worldcat. If I could get groups of records, well... now that would be interesting. Since this cannot happen with an ISO2709 record, the result is that the only people in the entire world who can work with library records are other *librarians* because they are the only ones with the special tools such as MarcEdit. As a result, we cannot share our records with *anybody* except other libraries today. If all we care about is sharing with other libraries for placing records in their catalogs, I agree that there is no problem since it has worked for a long time and everybody has special tools, but our world views absolutely must change from this. Since the web browsers can work on the fly with XML, we must use those tools. This means switching to XML. Easiest and quickest is MARCXML. Today, so long as we stay with ISO2709 for record transfer, it leaves us marooned on Library Island, completely separated from the rest of the information world. We must share outside our traditional boundaries, and it is 100% impossible to do that today. Switching to MARCXML would make all of this 100% *possible* from the *technical standpoint*, but I admit, still 98% *impossible* because the general populace does not know what 300$b means. Still, that is only 98% impossible instead of the 100% impossible we have today. That must be seen as some kind of advance in comparison with today. I agree: forget the ISO2709 format. Then let's get rid of it by stop using it for record transfer. And good riddance. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Linked data
Bernhard Eversberg wrote: snip Where and how do you receive ISO records from LC, as a non-librarian? ... Jim, this gets us nowhere, your preoccupation with ISO! Rest assured, it is a non-issue for as much as our dealings with the populace are concerned. Where it still exists, it can be nicely circumvented. /snip Obviously, I am not making myself clear somehow. Why I am preoccupied is because I have succeeded with this myself so I know how it works. First though, how do you get ISO records from LC? From inside the database: http://tinyurl.com/4p2vgxz At the bottom, you'll see Select Download Format where you can save as text or as an Iso2709 record. Lots of catalogs allow that and in fact, if they didn't, non-OCLC libraries would have trouble getting records. But remember: this is to transfer a single record from one library catalog into another library catalog using supplementary methods such as MarcEdit. Libraries must do much more than this however, and this is why XML is so important. Let me show you how the XML can work. OCLC has created a web service for citation formats. See the sample in XML at: http://oclc.org/developer/documentation/worldcat-basic-api/rss-xml-sample. I have used this web service by having my catalog search for that RSS feed when someone clicks a specific record in my catalog. Then on the fly, when they look at a record such as http://www.galileo.aur.it/cgi-bin/koha/opac-detail.pl?bib=26319 and click Get a citation in the right-hand column, the web service has *already searched* Worldcat and returned the citation, my machine has reformatted it and displayed it in this way. I could display this directly without a click, but have chosen to do it this way to keep from cluttering up the display. This cannot be done with ISO2709 records. This is not all that special and anybody in the world who knows how can do the same thing right now. This is how mashups are created: by automatically searching different sites in the background bringing in information into a page that is reformatted in various ways. The tool to do this is XML. Amazon does exactly the same thing with its reviews and ratings, Librarything does the same thing. Blackwell does something similar. Mashups are one of the main ways people are personalizing the web. To do it you must use XML. It is my opinion that libraries and their records must enter that kind of mashup world, and the sooner the better. So, what I am saying is *if* the web service from OCLC were not just citations in XML, but the entire MARC record in XML, then right now--today--I, myself, could create something with it that I cannot now using the power of the headings (if not more). I have no doubt that I could create something of great use to my patrons. If queries could return multiple records somehow, I can't imagine anything precisely at this point, but I am sure something great could be built. Even more important: *anyone else in the world* could do the same thing, just as all kinds of developers are doing now with the citations or from Amazon, from Librarything, or even most open archives allow this sort of power. This is what it would mean to enter that universe. I have worked with XML rather extensively, so I have seen what it can do. Browsers work with XML, not with ISO2709. If browsers did work with ISO2709, then that format would probably be fine. But I cannot believe anybody would make an ISO2709 parser as part of the browsers because that format is obsolete. This is why switching from ISO2709 is so important: it will be the first step into the greater world where *others* can begin to work with our data. Librarians can work with our data now, and if that was all that mattered, there would be little reason to change much at all. We need to stop thinking in terms of: here is a record I want. How do I get that record into my catalog? There are ways of doing that, and we must deal with new demands. Is this really so difficult? I must not be explaining it right. It is crystal-clear to me. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] Linked data
Karen Coyle wrote snip Actually, an OpenURL requires a program and a database to resolve it. It doesn't link directly to the resource. In fact, that's the point of the OpenURL: it goes through a resolver database in order to provide the best source for the resource to the user. /snip Then how do you explain the fact that the specification for URIs includes a possibility for a query, http://tools.ietf.org/html/rfc3986#section-5.1 and the link to http://tools.ietf.org/html/rfc3986#section-3? snip No, MARCXML does not move us toward dbpedia. At least, not the MARCXML that is the LC standard. That is, as Jonathan has pointed out, just a different format of the same old MARC record with all of the same constraints. Also, linked data and XML are VERY different approaches to data modeling, and many feel that XML actually gets in the way. The direction that I am trying out (and not sure yet how it will all work out) is to break MARC up into its logical component parts -- it's actual data elements. You can follow this as I develop it at: http://futurelib.pbworks.com/w/page/29114548/MARC-elements /snip I have major differences with this. When compared with today's ISO2709 records, the ability to add a little suffix to a link that says format=MARCXML would present developers with a wealth of possibilities, for a single record, and even more for multiple hits. Even I, with my limited knowledge, could do quite a bit with that. And if those MARCXML records had links to the authority records in the headings, instead of just text, wow! It's not the end, but a start. I think we agree in a lot of ways, but I suspect the actual disagreement involves something more expansive: what are these things called linked data and the Semantic Web? And even more important: what constitutes a real step toward them? Linked data and the Semantic Web are both rather vague ideas that people still disagree over, but they sound like something that would be great. This reminds me of stories that circulated in the West about Peking: how beautiful and rich it was, the amazing things to see, and so on. So, people wanted to go there, but they weren't sure how to get there, except Go east. Of course, east is a very indirect direction, so if you don't know where something is, it's hard to find it. Maybe it's NE and you go ESE and you will never run into it. At the same time, you honestly don't know if Peking is a beautiful place, if it's really a dump, if it has been sacked and destroyed, or if it is even a real place at all, like the seven cities of gold, the fountain of youth, or the empire of Prester John. Still, in order to begin to find out the answers to any of these questions, you must begin your journey, otherwise you will never know. This is where I think we are now: we want to get to the Semantic Web or linked data, but we aren't quite sure where they are, or at this point, if they are something we really want, or if they can even exist at all. Some may have more confidence than others, but yet, there is only one way to find out and that is to set out on the journey. That means you have to start moving in the general direction, reevaluate where you are, set out from there, reevaluate, etc. Maybe you'll reach your goal someday. But different people react to this kind of situation in different ways. Some say that we aren't really making progress to get to Peking until we are past the Urals, so we shouldn't really start the journey until we have everything mapped out to get the Urals. This is what I think explains the statement that changing to MARCXML is not a step toward linked data, since it's not a big enough step. Others sit around, and say how important it is to get to Peking, how there is no choice except to do so. Yet, when they get up from the couch, all they do is walk over to the refrigerator to grab a beer, and go back to sit on the couch. This is how I see FRBR/RDA, which bustles around but changes nothing. There is the saying, A journey of a thousand miles begins with one, single step. To start on the journey, we must take that first step out of the house. That is how a journey really begins: by taking one single step out the door, understanding there's still a long way to go. This is how I see doing things such as switching to MARCXML. If we can't take that step until we have RDA with RDF, that is years and years away. If then. We absolutely have to take that first step out the door. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] Linked data
Karen Coyle wrote: snip One hint, though, if I may, is that the goal of linked data is NOT to then put the data in a database. The goal is this one that you list as the third rule The third rule, that one should serve information on the web against a URI ... is the goal: to make your data available on the web. That means not in a closed database, but actually on the web. It's like putting your documents on the web so that anyone can link to them, but in this case you are putting your data on the web. Because each thing in your data has a URL, the web allows you to make links. /snip But it is my understanding that you can go through a database to get to the data, and as a result a URI includes the OpenURL. This is a relative reference URI, where you have to establish a base URI. See http://tools.ietf.org/html/rfc3986#section-5.1. Here's an example OpenURL I found, which I think everybody on this list can understand: http://resolver.ukoln.ac.uk/openresolver/?sid=ukoln:ariadnegenre=articleatitle=Information%20gateways:%20collaboration%20on%20contenttitle=Online%20Information%20Reviewissn=1468-4527volume=24spage=40epage=45artnum=1aulast=Heeryaufirst=Rachel The big point is the ? which means that this is a query, or a search in a database. OpenURL says that everything *after* the ? should be standardized (i.e. any database should be able to accept this type of standardized query) while everything before the ? (i.e. the base URI) can change. This is why I have thought that OpenURL demonstrates the power of consistent, standardized metadata: so long as everything is consistent, the data in one database can be used to automatically find and reliably query another database. But of course, if everybody follows their own rules, the entire thing breaks down. In the example above, for the volume number, is it 24 or XXIV? Notice also the author's name, which follows UNIMARC practice of coding first and last names separately. When the base URI changes, as they always do, so long as everything is set up correctly, all you have to do is change the part before the ? one time in your wonderful relational database, and all is fine since the rest is created automatically from the record itself. And since it is standardized, you can search any and all (in theory) databases just by adding new base URIs. In this way all you need is highly standardized data, which is the specialty of catalogers. I have always thought that OpenURLs should be very powerful tools for catalogs, and it is crystal clear to everyone that if you use Mark Twain and the others use Samuel Clemens the system simply won't work, so the power of consistent standardized metadata becomes desirable even to the public. Concerning linked data, it is simply the way the World Wide Web works, plus there is the assumption that the more links a resource has both to it and from it, the greater use it has for everyone. I am sure that almost any page you see on the web is composed of dozens of separate files brought together from all kinds of places: within the site itself with such files as headers and footers, images, and from other sites on the web. Some of these files in turn import other files from other places, which can also import still other files, and on and on. Just examining the NY Times page, http://www.nytimes.com/, each image is a separate file, there are ads belonging to other sites, there is a part giving the temperature in NYC which is probably brought in from outside. I have seen in the past, news feeds from other newspapers as well, I think from Reuter's. But linking files together--sometimes very small files or even program files such as javascripts that you don't even see such as web counts and others--in all kinds of ways is how the web has worked from the very beginning. This is why you need a browser that does the job of bringing it all together. Linked data actually does more or less the same thing, so it is nothing really new from the technical standpoint, but it is based more on semantics and meaning. So, if somebody wants pictures of Rome, the system should be smart enough to know the different forms to get you Rome, Roma, Rzym, and so on. Of course, in practice this means that *computers* need to understand that these are the same. To make your resources work on with linked data, you do things in RDF, which is a type of XML. This is no different from using style sheets on your website, and you do thinks in CSS. But all of this is being done now in dbpedia. Look at http://dbpedia.org/page/Benjamin_Spock, scroll to the bottom and you can see the record in different types of RDF. This is one of the reasons why I think switching to MARXML would be one single step in the right direction, and also why we should really consider working with dbpedia: a lot of the technical work has been done already. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services
Re: [RDA-L] Browse and search RDA test data
Jonathan Rochkind wrote: snip I don't see any significant increase in flexibility to share Marc records by 'switching' to MarcXML. Am I missing something? What exactly would be the advantages of 'switching' to MarcXML? /snip When we talk about MARC as it is used by libraries today, we cannot separate it from the underlying ISO2709 format, since this is the primary (and still the only?) means that we transfer records from one catalog/database to another. It is the ISO2709 format that is completely inflexible. What we see on our computer screens when we catalog something is *not* the MARC format that we are really working with. Originally, library records were stored, searched, displayed, etc. from the ISO2709 format, but as relational databases appeared and XML indexes such as Lucene and Zebra appeared, the storage of records took on different forms, but the *transfer* of the records has always remained in ISO2709 format, that the computers compile at the time of transfer using Z39.50. So, if we look at http://tinyurl.com/6hfuqjf, and at the bottom, click on Select Download Format to one of the MARCs, save it and open it in Notepad (or whatever), this is what is transferred. I am 100% certain that this is not how the record is stored within the Voyager database at LC, but when a library wants to transfer the record into their own catalog, this is the method: by compiling that information into an ISO2709 record. The record itself: 01468cam a2200325 a 4510008000500178008004100025035002100066906004500087955012200132010001700254020003600271040001800307043001200325050002300337082001500360129003752450115004042600056005193350057550400640061066300674650005000737650005000787650003300837856009500870856008700965920004101052991004901093 1182910 20041208175945.0 971106s1998 caua b s001 0 eng 9(DLC) 97043755 a7bcbucorignewd1eocipf19gy-gencatlg apc14 to ja00 11-07-97; jk27/jk15 (desc) to subj. 11-13-97; jk14 to DDC 11-17-97;aa05 11-19-97; cip ver. jb09 09-22-98 a 97043755 a0520212010 (cloth : alk. paper) aDLCcDLCdDLC ae-- 00aNB623.C2bJ64 1998 00a709/.2221 1 aJohns, Christopher M. S. 10aAntonia Canova and the politics of patronage in revolutionary and Napoleonic Europe /cChristopher M.S. Johns. aBerkeley :bUniversity of California Press,cc1998. axvii, 271 p. :bill. ;c27 cm. aIncludes bibliographical references (p. 237-259) and index. 10aCanova, Antonio,d1757-1822xCriticism and interpretation. 0aArt patronagezEuropexHistoryy18th century. 0aArt patronagezEuropexHistoryy19th century. 0aNeoclassicism (Art)zEurope. 423Contributor biographical informationuhttp://www.loc.gov/catdir/bios/ucal052/97043755.html 423Publisher descriptionuhttp://www.loc.gov/catdir/description/ucal042/97043755.html a** LC HAS REQ'D # OF SHELF COPIES ** bc-GenCollhNB623.C2iJ64 1998tCopy 1wBOOKS This is completely inflexible. The first 5 places 01468 define the length of the entire record. The record cannot vary even 1 character from this length, otherwise it will break. The horrifying string of numbers afterward define the lengths of each field, counting the indicators and subfields. In fact, the field numbers themselves, i.e. 100, 245, 300, etc. are embedded inside this horrifying string of numbers and are separated from their text fields below. So, for the heading of Canova as subject, somewhere in that number string is the 600 followed by the length of the string after that, including the indicators and subfield codes, plus Criticism and interpretation. For a long time there was no problem with a completely inflexible record like this since the whole idea was to transfer entire catalog cards from one library system to another. That is no longer the case at all today, and hasn't been for quite some time now. How can that format above work with linked data in various ways without breaking everything? How would the FRBR entity structure work in ISO2709? Because it must work with ISO2709 since that is how our records are transferred. So, while we can do anything we want *within* our own catalogs, making all sorts of wonderful things, they can't be transferred anywhere else because of this obsolete transfer format, i.e. without considerably reworking it. How could this work with linked data, bringing in information from other places? I compare it to working at Hoover Dam, filled to teeming with fresh water that we keep making sweeter and cleaner, while there are all kinds of towns out there wanting our water desperately, but the pipes out of the dam only have a capacity of 1 or 2 gallons per minute and they leak like sieves. My water ends up useless. While I won't argue that it may be possible to rework the ISO2709 format to work with linked data, why should we even think about it when we have XML? It would be completely wasted work. Nobody without an ISO2709 parser would even consider using such a format. This is why
Re: [RDA-L] Browse and search RDA test data
Bernhard Eversberg wrote: snip Am 14.01.2011 09:54, schrieb Weinheimer Jim: When we talk about MARC as it is used by libraries today, we cannot separate it from the underlying ISO2709 format,... Oh but we can, we certainly can and we should and we do. A MARC record can easily be rendered like this: ... /snip I can, and have, reformatted a native ISO2709 record into all kinds of other format: csv, Refworks, OAI-PMH, MARCXML and so on, (although even then it's easier starting with XML since you don't need to parse the thing to begin with) but when I then want to transfer that record that I worked with into my catalog, I have to recompile it back into an IS2709 record so that I import using Z39.50, when we are stuck with each and every one of the limitations of ISO2709. The one and only purpose today of ISO2709 is to transfer MARC21 records from one library database to another library database. That is the entire problem since it impacts on everything we do. It is the primary way of getting records from one catalog to another, e.g. records are uploaded to WorldCat in ISO2709 and downloaded using that. The Z39.50 search in MARCedit utilizes ISO2709 and then recompiles. Since the method of transfer is ISO2709, we remain stuck with the limitations of that obsolete format. But I may be wrong. How would we work with linked data with importing of related information, e.g. a contents note and a couple of analytics, in the current world of ISO2709? Can you give me an example? Of course, it would be relatively easy with MARCXML, but it must result in that ISO2709 string with all of the lengths defined in the beginning, as I wrote before. I confess that I cannot imagine how the FRBR entity relationship model could work, which is all based on linked data, although in XML it would be no real problem. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Browse and search RDA test data
Bernhard Eversberg wrote: snip That may be true for some ILS systems but certainly not for all of them. If it is, then it is a weakness of that system, not a feature of MARC. Get rid of those systems or get vendors to understand that this mode of communication is - though it needs not be thrown overboard - not the only mode that is required but what you need is configureble export. Even Z39.50 is not tied in with ISO2709, it is just a convention that this is most frequently used for communication. /snip Bernhard, Sorry to press the point but I think it is a vital one: using MARC in its ISO2709 form *cannot* work with linked data. At least, it cannot work without *major revamping* which is not worthwhile to undertake. So long as MARC is linked to ISO2709, we remain stuck in place since all you can do with it is transfer a complete record from one library catalog into another library catalog. Once we are in an XML-type of world, retaining the numbered fields and subfields is OK, although at that point, it is of relatively minor importance. Once the data is in XML, you can do anything--anything--with it: transform them into other bibliographic formats, into citations, pdfs, docs, or even movies. We could even create records in 3D, if that's what we want! http://www.youtube.com/watch?v=u7h09dTVkdw Z39.50 itself may have a future or not; I don't much care one way or the other since tools exist today to do what we need to do. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Browse and search RDA test data
Bernhard Eversberg wrote: snip Am 14.01.2011 12:24, schrieb Weinheimer Jim: Bernhard, Sorry to press the point but I think it is a vital one: using MARC in its ISO2709 form *cannot* work with linked data. For all I know, I have to disagree. It is all a matter of field content and then what the software does with that - no matter how it is wrapped up for communication. A MARC field can carry a link (an Identifier) and the software can use it in whichever way, wherever and whenever needed, no matter how the record is wrapped up during storage or transfer. This is in no way different from XML. It may be a matter of what you are familiar with. If it is XSLT and nothing else, then XML is of course appealing. Other data manipulation languages can do just the same things, in different ways, and some do it more elegantly than XML. /snip I hate to keep harping on this, but I think it is a crucial point since I believe that ISO2709 is one of the key problems holding us back; certainly more important than adopting FRBR or RDA. As I said before, ISO2709 may be able to be revamped to handle linked data, but it seems senseless to me to do that work if tools already exist that can handle the job. If, as you point out, linked data is merely a matter of adding some identifiers, *maybe* it can work although it seems to me that such a system will always need special parsing and recompiling over and over again to be useful. For example, merely doing a linked data search using an ISBN is impossible with an ISO2709 record as it stands. And although XML may not be the best solution, it can do all of this right now, today, and browsers can handle XML. Somehow, I don't think an ISO2709 parser/compiler would make it into browsers today. And I think time is of the essence to demonstrate how libraries can fit into this coming information world. ISO2709 served its purpose well, but it is a completely obsolete format that was created for the needs and the technology of the time. It needs to go be placed into the trashcan of history. Once again, I confess I may be wrong. I am willing to learn. But please, no theory; just some practical examples of how ISO2709 can fill the bill and how it would be better than MARCXML. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Browse and search RDA test data
Bernhard Eversberg wrote: snip Really, I'm not a great fan of MARC, but we do it injustice if we insist it go away because of ISO2709. The latter has to go, and can go, and isn't being used nor required nor standing in the way in many applications right now, with no harm done to MARC whatsoever. /snip No, no. I guess I am not making myself clear. MARC does *not* have to go away, just its ISO2709 incarnation. If you look at the MARC standards in the Leader and Directory http://www.loc.gov/marc/bibliographic/bdleader.html, http://www.loc.gov/marc/bibliographic/bddirectory.html, it defines the ISO2709 structure. The record you show is *not* what people download when they get the MARC format for their catalog. Here it is, straight from the LC catalog: 01070cam a2200289 i 451000900050017900800410002690600450006792500440011295501260015601000170028202000180029904000280031704200080034504300120035305000240036508200200038924500740040926000610048334600544336002100590337002500611338002300636650004500659651004400704651003200748 16097519 20101123143634.0 100219t20102010ncuab 000 0 eng a7bcbccorignewd2eepcnf20gy-gencatlg 0 aacquireb2 shelf copiesxpolicy default apc20 2010-02-19axh00 2010-09-15 to USPL/STMirf08 2010-10-07 (telework) to SLerf08 2010-10-13 to Deweywrd07 2010-11-23 a 2010923073 a9780977968169 aDLCbengcDLCerdadDLC apcc an-us-nc 00aVK1024.N8bN67 2010 00a917.5604/44222 00aNorth Carolina lighthouses :ba field guide to our coastal landmarks. aGreensboro, N.C. :bOur State Magazine,c[2010], (c)2010. a103 pages :billustrations, maps ;c20 cm atext2rdacontent aunmediated2rdamedia avolume2rdacarrier 0aLighthouseszNorth CarolinavGuidebooks. 0aNorth CarolinaxDescription and travel. 0aNorth CarolinavGuidebooks. So to get the display you showed for the ISBN 020 \\$a9780977968169 MARCedit had to dig out the 020 from the Directory and match it with the ISBN. It did all this by *counting characters*, not by fielding as it is handled today: 020a9780977968169/020. In ISO2709, everything is buried and must be exhumed. A move to using MARCXML for record transfer gets rid of these hassles (so long as we do not insist on the round-tripability with ISO2709, as it does now, see point 3 of http://www.loc.gov/standards/marcxml/marcxml-design.html) while maintaining the MARC codings. With XML, we can add all kinds of linked data. MARC in its non-ISO2709 incarnation can stay forever, that's fine with me. Lots of programmers have issues with MARCXML, and they make some good points; still, I figure we need to move forward ASAP, and their--very legitimate--issues can be dealt with gradually. But those issues shouldn't stop us moving forward. snip It is not ISO2709 that has to do that handling, it is the software processing MARC records. And this processing, I'm very sure, nowadays doesn't, internally, use the ISO directory structure at all but just the tags and codes. Internally, records will most often be represented like this: (the MARCEDIT structure shown by my database) /snip Internally, each database can be different, as each one is today. As I said ISO2709 no longer is used for internal purposes (except for some CDS-ISIS catalogs), and is used only for record transfer. I think we *may* actually agree ? James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Browse and search RDA test data
Jonathan Rochkind wrote: snip Many ILS use the MARC _schema_ (aka vocabulary, aka list of fields and subfields) as their internal data model, if not the serialized transmission format. The MARC 'schema' is kind of implicit, defined as a byproduct of the transmission format, which is in part what makes it so cumbersome to deal with. And, unfortunately, it's actually the schema, NOT the transmission format, that is a problem with MARC. It is, as everyone keeps saying, easy enough to change the serialized transmission format to something else (MarcXML, an tab delimited spreadsheet, even RDF (based on marc tags!) if you want, no problem) -- which is exactly why it's not a barrier. The barrier is the lack of power in the actual 'vocabulary' -- a flat list of numeric tags each of which has a single flat list of no more than ~35 single character subfields -- is the barrier. And somewhat harder to change across an ecosystem developed assuming it. /snip I completely agree. It's just I consider this step #2. By switching our focus to providing MARCXML as a primary transmission format for our records, we will still be stuck with a completely flat everything--which is bad--but it could be done probably with not much pain, and it will at least be in XML when we, and hopefully others in the world, can gain a bit of flexibility to begin to play in all kinds of different ways, especially compared with what we have now. To wait even longer to find agreement on anything more is tough. I think we are running out of time. Look at the debate just over capitalization! One baby-step at a time By the way, the Koha open source catalog stores the MARCXML record and uses them through Zebra indexing (exactly how I'm not sure), plus there are various mysql relational tables. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Linked data
J. McRee Elrod wrote: snip So based on the URL definitions Kevin supplied, these UTLAS/Pica databases are relational if linkages are inhouse, but linked if to outside data, e.g., to the NAF as opposed to authorities in my system? Or must the internal or external data meet some additional standard? /snip That's just the way it works. For example, in my catalog: http://www.galileo.aur.it/cgi-bin/koha/opac-detail.pl?bib=2506 there linked data in various ways: the book cover is from Amazon, I've added a Google Translate box, the Get a Citation is linked with Worldcat, there is a sharing box, and at the bottom, there is a link to the scans in Google Books. More can be done using LibraryThing and Amazon reviews, and who knows what more there will be in the future? What do you think of this? http://www.galileo.aur.it/cgi-bin/koha/opac-detail.pl?bib=20627 James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Browse and search RDA test data
Bernhard Eversberg wrote: snip About current MARC practice, your'e right. While I've never been a dyed-in-the-wool MARC enthusiast, I'm realist enough to recognize that any migration into something else, and then what really?, would be a galactic task. There will have to be a MARC implementation of those ER values or RDA will remain either a theorist's glass bead game, or it will live on as nothing more than the dumbed-down version reflected in that test stuff. The ALL CAPS skirmish drawing on forever and overshadowing all the rest of the endeavor. /snip Well, when you look at it that way, in this sense it's another one of those retrospective conversion projects that probably everybody on this list has known and loved. When I was doing research on the history of the library catalog of Princeton University, I found ten or twelve conversions since 1755, including when the library burned down a couple of times. (I include recopying the manuscript book catalogs in this, because things were normally reconsidered, reclassed, etc. By the way, one letter I found from a cataloger in 1866 was unforgettable since he was describing the work he was doing and would lose his mind just a few months later!) When comparing those jobs with what faces us now, I think this conversion will be much easier than before, i.e. in the sense of the actual work, but the task itself is far more complex. It's difficult at this point to understand exactly what we should *convert into*, while it was easier to sit and copy records from one volume to another, or from one size card to another, or from the card to the MARC record, etc. This is on a completely different plane. My own suggestion would be to do this as quickly as possible with a minimum of information loss. So, the conversion itself could be done incredibly fast by converting to MARCXML (yes, I know that's bad) but at least then we would gain some genuine flexibility to be able to share records. An application profile could be drawn up to allow inclusion of XML information from other projects and perhaps allow some of the more specific relationships mandated by FRBR/RDA (which are in our records now but some are not coded so specifically). This could probably be done rather quickly, and some open source catalogs created to deal with these records could be devised, since many exist now. Koha, for instance, works on MARCXML. Some internal tweaking would be needed, but perhaps not all that much. Of course, the separate records/entities for WEMI would be thrown overboard, at least for the foreseeable future, but people probably know my opinion on that I think this would be a definite step forward, but a small one. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Browse and search RDA test data
Mike Tribby wrote: snip Perhaps not surprisingly, I find myself in agreement with both Mac and Hal. And I would ask Jonathan and any other list members who see value in all-caps display of titles if they have any thoughts on how to transcribe a title in which all letters are caps, but the letters at the start of the title (and possibly at the start of each word) are _larger_ caps than the caps that make up the rest of the title. I don't think my keyboard or my cataloging software is capable of creating caps in different sizes in the same field, at least not easily. /snip I assumed that the idea of accepting all caps was to be able to accept ONIX data more easily, but I just looked up in their guidelines (http://www.bisg.org/docs/Best_Practices_Document.pdf p. 11): Titles should be presented in the appropriate title case for the language of the title and then they have several examples of capitalization in English, Spanish, and French. In addition, on the next page, we read: Titles should never be presented in all capital letters as a default. [In fact, the word never is underlined--JW] The only times that words in titles should be presented in all capital letters is when such a presentation is correct for a given word. Acronyms (e.g. UNESCO, NATO, UNICEF, etc.) are an example of a class of words that are correctly presented in all uppercase letters. When acronyms are made possessive, however, the terminal “s” should not be capitalized. And so, the plot thickens! Their guidelines look fairly good to me. Would this be a case of definitely saying that the information received was substandard? James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] Browse and search RDA test data
In basic typography, all caps are avoided in regular body text because it is considered to be the equivalent of screaming. All caps are normally reserved to emphasize limited areas or words, such as section titles. Here's an example of many: Three Reasons to Avoid Using “ALL CAPS” in Website Copy http://designfiles.net/studio-news/reasons-avoid-caps-website-copy/ A lot of people really hate all caps (I do, for example). Since I wouldn't want to really alienate my users, I would probably write the style sheet in my catalog to reformat my text, probably to capitalize, even though this would capitalize every word including the, is, and acronyms such as Cia, Fbi, Un, etc. which would be bad as well, but in my opinion, it would better to risk having my users think I am ignorant of the rules of capitalization than to risk making them angry with all caps or lower case (the only quick and easy options with CSS). Otherwise, there would have to be a lot more work on the programming end. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/ From: Resource Description and Access / Resource Description and Access [rd...@listserv.lac-bac.gc.ca] On Behalf Of Christopher Cronin [cron...@uchicago.edu] Sent: Tuesday, January 11, 2011 8:32 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Browse and search RDA test data Hi Karen, My initial impression is that when we see all caps in fields like the 245, 250, 260, 490, it will often be the result of direct transcription of how those data appeared on the resource, or will perhaps be an RDA record created from ONIX data. One of our catalogers has noted the consequence of this for users who import MARC records from our catalog into citation tools like EndNote or RefWorks, and the like, and how those tools will treat the data. It's one thing I have meant to experiment with for records we have identified, because that may influence our policies on capitalization conventions going forward. Chris Cronin University of Chicago On Jan 11, 2011, at 12:54 PM, Karen Coyle li...@kcoyle.net wrote: Thanks, Bernhard. This is very useful. I was rather surprised (in my first foray into the data) to see some titles presented in all upper case: 100 1\$aGentry, Paul,$ephotographer. 245 10$aNEW YORK :$bFROM LAND, SEA, AIR /$cPRINCIPAL PHOTOGRAPHY BY PAUL GENTRY. 260 \\$aNew York, NY :$bMud Puddle Books,$c[2007?], ?©2007 100 1\$aDiSanza, James R. 245 10$aBUSINESS AND PROFESSIONAL COMMUNICATION :$bPlans, Processes, and Performance /$cJames R. DiSanza, Nancy J. Legge. 250 \\$aSECOND EDITION. Is this truly RDA compliant? Anyone know? kc Quoting Bernhard Eversberg e...@biblio.tu-bs.de: The official test data as made available by LC last week: http://www.loc.gov/catdir/cpso/RDAtest/rdatestrecords.html have been imported into a database and can now be browsed and searched: http://www.biblio.tu-bs.de/db/a30/rdatest.htm There are about 14.000 records, both bib and authority. (The database is much larger. and has all sorts of stuff from various sources.) The internal format of this database is not MARC21, but for every record, you get the MARC record in addition to a legible display. (The other stuff in the database has no MARC data attached.) Not all of the vernacular characters are correctly displayed, esp. the non-European ones. This setup is not for any production purposes, many details might be improved, given more time. On the initial display, you see a menu in the main panel and the content type index in the right hand panel. From the menu, select Index by all types to get the index of all types, including the authority data. Click the Menu tab to get back to the menu, not the browser back button! (If you are interested: Under the Intern tab, you see the internal record structure. Click the Edit+ button at the bottom to get a labeled display.) B.Eversberg -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Purpose of transcribed imprint (was: Form)
Erin Blake wrote: snip For my own research, and for many users I serve professionally (in an independent research library), it is vital to have both transcribed and normalized information for primary resources. I can find things published in London, England, through MARC 752 ‡a Great Britain ‡b England ‡d London. I can find engravings published by John Bowles through 700 ‡a Bowles, John, ‡d 1701-1779, ‡e publisher; but through 260‡b I can see that there are two distinct versions of the plate, each with a varying address for Bowles' firm. /snip This is great that you can do those things, but when we get into the larger world of metadata, there are problems with the reliability of the result. For example, you can search for 752$d for place of publication, going down to the city, plus the publisher through a 700$e search, and that is fine. But these types of access points are not on every record in every library. So, this works within the confines of the (magnificent!) Folger collection, but it ceases to function, or at least functions differently, the moment the searcher steps outside the single catalog, i.e. it may function for some other records in some other catalogs, but even then, it is so hit or miss that for anyone except the genuine expert who knows the variations in all the different cataloging practices, the existence of this information, or lack of it, must be considered random. I have only seen a few of these records, but for example, the Early American Imprints series includes the 752, but it appears that when the author is also the printer, there is not a separate 700$e made for the author as publisher, e.g. in Princeton's catalog we can see where James Parker is added as a printer in only one of these books he printed, apparently because he authored one of them. http://catalog.princeton.edu/cgi-bin/Pwebrecon.cgi?Search_Arg=CMT9208TSSearch_Code=GKEY^CNT=50HIST=1 vs. http://catalog.princeton.edu/cgi-bin/Pwebrecon.cgi?Search_Arg=006430461Search_Code=GKEY^CNT=50HIST=1. Therefore, if there were a separate search for printers limited to 700$e, when you searched for Parker, you would retrieve only one of these. When this is translated into the world of union catalogs, the task is for the users to know what is really happening when they search a 752 field, or when they do a search for a printer, and this becomes even more complex. For instance, see this Worldcat record which has Parker's name only in the publication information without a 752 or 700 of any kind with his heading: http://www.worldcat.org/oclc/30550049. Naturally, this method is not used for (most) modern imprints. By pointing this out, I am not finding fault with anything at all, just trying to emphasize the amount of knowledge assumed when someone would search, e.g. for someone as a printer: not only do they need to know about the history of the man or woman as printer, but also how all these different catalogs deal with this kind of information, and how each library's treatment is mashed/blended/wrung through union catalogs such as WorldCat. If researchers do not understand such intricacies, they could believe they are doing far more than they actually are when they do a search for James Parker as printer, or when they search for printers in Woodbridge, New Jersey; by definition, they are only getting subsets of the whole. This is a fact, and it is important for searchers to realize it. This is what I mean by the reliability of the result. When it comes to matters of general intellectual input (authors, editors, translators to a lesser degree), there is a lot more standardization, but in other areas such as what you mention, there are special, local practices. Today, I think it is becoming more and more important to always assume that our users do not understand this sort of complexity. And they won't ask questions. So, what can we do in this new environment to help users get some level of awareness of such problems and how to deal with them? I think there are many ways that the catalog can provide help, but we need to think in entirely new ways. And let's not even contemplate what will happen when Google Books enters the fray! James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
[RDA-L] New Cataloging Matters podcast
All, Apologies for cross-posting. This is to announce that I just added the latest “Cataloging Matters” (no. 7) podcast to my blog at http://catalogingmatters.blogspot.com/2010/12/cataloging-matters-podcast-no-7-search.html. This one discusses search. Please feel free to forward this to anyone who may be interested. James Weinheimer j.weinhei...@aur.edumailto:j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Abbrevitions in RDA records
-Original Message- From: Resource Description and Access / Resource Description and Access [mailto:rd...@listserv.lac-bac.gc.ca] On Behalf Of Karen Coyle Sent: Thursday, December 09, 2010 5:22 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Abbrevitions in RDA records Quoting Weinheimer Jim j.weinhei...@aur.edu: In an earlier message, I pointed out that if an abbreviation problem actually exists, then there should be some sort of focus on the users and the real problems that *they* encounter. I will stick my neck out and declare definitively that when a user looks at our records, they will discover a multiplicity of abbreviations they will not, and cannot possibly, know. These abbreviations are found in titles, in notes, and in many other areas. These abbreviations are probably not the ones such as p. or etc. or et al. but abbreviations such as ILO WTO TSO MAB and many others. From the user's point of view, it doesn't matter if these are abbreviations or acronyms or what: they don't understand the vast majority of them. This is an acknowledged problem in a part of the data that libraries control: name and subject headings. Cross references from abbreviations/acronyms to spelled out forms are used in the authority files. These xrefs may not be apparent to users, but that is a systems problem, not a data creation or cataloging problem. I believe that some older cataloging rules allowed catalogers to add to transcribed data anything that they thought users needed by enclosing that information in square brackets. This is pretty intrusive, I find, in terms of legibility. My gut feeling is that we should leave transcribed fields alone. There is no reason why some acronyms couldn't be spelled out in added titles, and it is possible that some of that could be aided with machine algorithms (e.g. suggesting re-written titles based on machine matching of text to a table of abbreviations). Acronyms in transcribed fields interfere with searching -- a user will not know whether to type IBM or International Business Machines when doing a general keyword search. In the original online catalog we developed for the University of California we automatically extracted the keywords for spelled out and abbreviated forms of certain content so that searching would retrieve the items regardless of the form of the term. This was used for titles and I believe also some notes. Because it was machine extracted there was a margin of error: MIA could be Missing In Action or Miami International Airport, as one example. That's why I prefer the idea of using machine algorithms as suggestions, not automated extraction. I don't think we can completely resolve the abbreviation issue in the transcribed parts of our records, and I'm not convinced that is a reasonable goal. It does make sense to me to continue to control the links between abbreviations and spelled out forms in any of our controlled vocabularies, and to offer disambiguation where needed (a' la Wikipedia). Of course, we also shouldn't ADD TO the abbreviation problem, but that gets back to how we code our data. kc -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Abbrevitions in RDA records
Sorry about the previous message. I pushed the wrong button! Karen Coyle wrote: snip I don't think we can completely resolve the abbreviation issue in the transcribed parts of our records, and I'm not convinced that is a reasonable goal. It does make sense to me to continue to control the links between abbreviations and spelled out forms in any of our controlled vocabularies, and to offer disambiguation where needed (a' la Wikipedia). /snip And I return to my point: if we say that the public has problems with abbreviations, why should we only deal with our controlled ones, and ignore the abbreviations that cause them the most trouble? This makes no sense to me. It reminds me of a fellow I worked with back when I worked in grocery stores, and whenever a customer asked him for help, he would almost always say, Sorry, that's not my department and walk away. The reason? He would only help people on the aisles that he stocked. Yet, he claimed that he was very helpful to the customers! I agree that solving the abbreviations problem is not a reasonable goal and there are other more pressing problems, but we should also not delude ourselves into thinking that typing out the abbreviations people already know and are going to have to deal with anyway in the millions of older records, is any kind of help at all. So, if we really want to help, it will have to be through some sort of automated means, and this implies maintaining the consistency we already have. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Abbrevitions in RDA records
This thread has turned out to be very revealing in many ways. I feel compelled to point out that our cataloging rules are *supposed* to be centered on the user (or the patrons, or the public, or the readers, or however someone prefers to label them). In fact, in the past I have had to endure some rather scathing remarks concerning just this topic. In an earlier message, I pointed out that if an abbreviation problem actually exists, then there should be some sort of focus on the users and the real problems that *they* encounter. I will stick my neck out and declare definitively that when a user looks at our records, they will discover a multiplicity of abbreviations they will not, and cannot possibly, know. These abbreviations are found in titles, in notes, and in many other areas. These abbreviations are probably not the ones such as p. or etc. or et al. but abbreviations such as ILO WTO TSO MAB and many others. From the user's point of view, it doesn't matter if these are abbreviations or acronyms or what: they don't understand the vast majority of them. Therefore, if we conclude that there is an abbreviation problem, and further, if we maintain that our cataloging rules are to be user centered, then we must not ignore the totality of abbreviations the users see in the catalog, preferring to concentrate our efforts only on the relative paucity of those that come from the controlled lists based on our cataloging rules. If cataloging rules are to be user centered as many so fervently declare--and I agree--then we should take that sentiment seriously. We should focus on *their* experience, not just ours. It's fair to predict, and I hope, that library catalogs will expand their scope to include articles from open archives and records from all kinds of other bibliographic agencies, therefore it is logical to assume that such an expansion will make matters far more complex for our users than ever before, including the area of abbreviations. Our considerations should be: Is there really a problem with users understanding abbreviations? How important is it? And if it is important enough, how do we really and seriously help our users deal with the abbreviations (i.e. all of them) that they see in a catalog? I think there are methods to deal with this kind of problem, as I mentioned before, with APIs, plugins and so on, but typing (re-typing) the relatively few abbreviations under our control, and in the process upsetting the consistency we currently have, should not be considered a serious solution for our users and the problems they really face, nor should such an obsolete method be seriously entertained in the 21st century. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] Straight jacket?
Mac wrote: snip The relationships among authors and works, manifestations and works, are for too varied to be expressed in set vocabularies. Creating them seems like a Medieval exercise in theology. /snip Jonathan Rochkind wrote: snip If catalogers are unwilling to create records that can be used by software, then we are doomed to irrelevancy to our users. /snip There does not need to be a contradiction here. Mac is right: there *are* too many relationships to be expressed in a predetermined set of vocabularies. This is a simple fact, and the system should be flexible enough to do what the facts of the task require. If a system does not allow what the specialists determine is needed, it should be seen as a problem with the *system* and not that the specialists are wrong. This is the way it works for all kinds of professions out there. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] Recording Relationships in MARC
Concerning abbreviations, there are an entire range of options today instead of the rather atavistic method of retyping everything. I personally think automated methods, plus using our MARC fields and language of the item would solve at least 90% of all of the abbreviation problem. Many abbreviations are only valid in certain fields, e.g. see Yale's list of (uh-oh!) AACR2 abbreviations for a nice overview: http://www.library.yale.edu/cataloging/abbrev.htm. Other ideas come from sites such as http://www.abbreviations.com/, which has different methods for finding out the meaning of an abbreviation from widgets to iPhone apps. They also have an API that can work as a web service. If the library world did something like this, it could solve the abbreviation problem not only for English-speaking people, but for everyone everywhere, no matter what language they speak. This is, of course, assuming that there actually is an abbreviations problem and that it is of sufficient import that we must take major efforts to solve it. Whether this is true or not is another matter, but it only makes sense to at least try some automated methods before embarking on a major task of manual retyping. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] Recording Relationships in MARC
Jonathan Rochkind wrote: snip I don't think anyone is realistically suggesting that existing legacy records be manually changed to not have abbreviations. RDA is just suggesting that going forward they are not used. For all the carping from catalogers that love abbreviations, I do not understand what the benefit is supposed to be. [For what it's worth, it would actually be _easier_ for software to take fully spelled out words and abbreviate them in display, then it is to expand abbreviations. Although not neccesarily a walk in the park either way.] /snip Why shouldn't we change? In a word, to maintain consistency. Isn't it the systems people who complain all the time that our data is lousy because data is entered in all kinds of different ways? So, if we don't redo the old stuff (which I agree certainly isn't worth it) but we change going forward, we break consistency and make automated solutions even more difficult, as has been pointed out in different ways by many programmers on various lists. If we change without touching the legacy data, the argument that we are doing it for the utility of our patrons falls apart since they will still have to face the onerous task of figuring out what p. means for a long, long time. (And as an aside, I realize that there is some inconsistency now, with older records having illus. for instance, but there are relatively few of these) When it comes to abbreviations, we must see the real problem: our users have to face records in our catalogs that have all kinds of abbreviations: IBM, etc., p., et al., Oxfam, AIDS, FAO, UN, GOP, and on and on and on. If we were serious about dealing with the abbreviations problem from our *patron's point of view*, we should not expect our patrons to be able to distinguish library-controlled abbreviations from all of the others, and then deal only with that part of the problem, which is the part of the least interest to our users, and ignore the huge number of other abbreviations they see all the time that they may not understand. Therefore, if we consider that there is an abbreviations problem, then it should be discussed and the parameters should be delineated; then we should determine the relative importance of abbreviations vs. other issues facing us, and then take steps to deal with it if it is decided it is important enough. But we should realize that breaking consistent practice has major consequences in a computerized environment. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] Protesting RDA, utilize URIs in RDA
Bernhard Eversberg wrote: snip URIs, just like textual strings, are subject to change although not meant to be. Bare IdNumbers are a little better (and much shorter). In most cases, URIs are all alike, and the only difference is an IdNumber contained in them. So, why the trouble to store the entire URI with every record affected, when the number is all that is actually needed, and a changed URI most often differs not in the number but in some other part. For example: We might have 650 $u http://id.loc.gov/authorities/sh85090739 for the subject heading Neo-Kantianism. /snip A URI does not have to be a number--it is *any character string* that identifies a resource uniquely, and this includes textual strings as well. This coincides precisely with what our authority headings have been designed to do and I see no reason why we should not try to take advantage of this huge amount of work right now. So, for libraries that follow LCSH, the URI could just as easily be http://id.loc.gov/authorities/Neo-Kantianism; since sh85090739 is *supposed* to equal Neo-Kantianism (that is, if the catalogers have been doing their jobs competently) and consequently, there is no need for the nightmarish change of all our headings to numbers. This is how it works now in dbpedia with the URI using a textual string: http://dbpedia.org/resource/Neo-Kantianism. (Looks like the English abstract should be added to this record) If this is the case, your suggestion for adding the http://id.loc.gov/authorities/; as a separate function could work right now, today. The problem is that changes would have to be made at id.loc.gov to make it work as a real web service, so as to provide the XML that local catalogs could work with. As a simple illustration of how something similar works, see how I have implemented OCLC's web service see, e.g. http://www.galileo.aur.it/cgi-bin/koha/opac-detail.pl?bib=26352 and click on Get a citation in the right-hand column. There could be much better and cooler possibilities than this, however, for example, bringing in related information for the subjects. What about those libraries that do not use LCSH but another controlled vocabulary? They could provide the same service for their headings and their catalogs, and then at the higher LCSH-Other controlled vocabulary level, related terms could be linked in some way similar to VIAF, or I am sure there are other ways as well. In dbpedia, you can see it in the Neo-Kantianism record (above) using the owl:sameAs. This is how linked data can work, there could be owl:sameAs for all kinds of authority files, including dbpedia. Imagine the power of something like that. Would this work 100%? Anything you decide to undertake will have problems, but it could provide at least 75-80% if not more, and could be done right now, with a minimum of cost and no disruption to cataloging productivity. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] Web catalog
Karen Coyle wrote: snip Actually, I don't think that the cataloger has to think about the resulting page, especially because the resulting page could differ greatly using the same catalog data. That's the big change that I see: that the catalog record is no longer the display form of the data, but is the underlying data that could result in any number of different displays. I think the cataloger needs to understand what data is needed/desired to describe and identify the thing being cataloged. I don't think this is terribly different from your intended meaning, Jim, but I did want to remove the page structure from the discussion. /snip Thanks for clarifying that Karen. Yes, the record of the manifestation/edition no longer has to be the same as the display of the data. Different catalogs and organizations can display the same information in vastly different ways. This amount of, I'll call it freedom, although it makes me very nervous, can be liberating at the same time. For me, playing around with the displays is actually one of the fun parts! James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Protesting RDA, utilize URIs in RDA
Bernhard Eversberg wrote: snip Compromise: Let machines do the work, ok, but think hard where and in what way to involve them. What I was suggesting is not really a different approach: Don't store http://www.something.xyz/abc/IdNumber but just IdNumber and have presentation/service software add the rest according to current fashion. /snip Yes. In my own opinion, implementing linked data does not necessarily mean redoing everything in your database to create new links, along the lines of adding all of the LCSH numbers to our records (blah!). That would be an incredible amount of work, and would ensure that all of that work would relate only to the library community, since nobody else will ever change to our LCSH numbers. I see linked data rather as taking the *data you already have* and repurposing it to interoperate in innovative ways with other resources. I think there is room for a lot of creativity along these lines. The final products may be quite surprising. I think we all agree here James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Protesting RDA
Brenndorfer, Thomas wrote: snip Throughout the RDA text, the first choice listed for identifying entities or showing relationships is to use an identifier (such as a URI). This is followed by an authorized access point, and then in some areas, by textual descriptions. The reason for this is RDA's objective in supporting three scenarios: catalog card production, MARC catalogs that rely on linked headings, and object-oriented databases (http://www.rda-jsc.org/docs/5editor2.pdf). What is clear though is that access points are a permanent feature of the cataloging landscape-- they will always exist and are part of all three scenarios. The main difference is that relating entities in the future won't be dependent on the form of access points, which is a good idea considering how often they can change. For example, headings change with the addition of death dates, or when authors request that elements be removed (as I discovered recently for an author whose name was attached to many series headings and subject headings). In addition, the arrangement of RDA into elements that support attributes and relationships for entities is the basis of interest in the Linked Data community. There is a W3C Incubator Group discussing such issues now, and RDA is the game in town in support of these efforts (http://www.w3.org/2005/Incubator/lld/). In addition to promoting the use of identifiers for specific entities, all RDA elements (and a lot of controlled vocabulary) have registered URIs (http://metadataregistry.org/schema/list.html). 100 $q or Fuller Form of Name is a registered element http://RDVocab.info/ElementsGr2/fullerFormOfNamePerson /snip Thanks for pointing this out, but it still doesn't address the point I was trying to make: we should not pretend to ourselves that changing Elvis Presley's or Richard Wagner's authorized form, [or] in other words, changing one *textual string* into any other *textual string*, is any kind of a change at all. This is the sort of change that allows others to make fun of us and that gives cataloging and catalogers a bad name can anyone maintain with a straight face that the form Presley, Elvis (Elvis Aron), 1935-1977 instead of Presley, Elvis, 1935-1977 will make any kind of substantial and meaningful difference for our patrons If the purpose of RDA is to utilize URIs (which at the current rate may happen by the year 2050 if we are lucky), what is the purpose of going through the *huge task* of changing one textual string to another textual string? This makes absolutely no difference to our users (unless somebody out there can point to some fairly convincing research), while making an incredible amount of completely useless work for catalogers, when we could be doing work that is more productive. This is an example of what I have been mentioning of changes for theoretical purposes instead of practical purposes. Libraries and catalogs are facing some of the most serious challenges they have faced in a long, long time, and none of these challenges have anything to do with the *text of a heading* or in problems of *cataloging rules*. In other regards, such as how people are able to find those headings; what happens after they do find a heading, and so on, innovating in these areas would be the types of changes that could matter to our users, but yet we concentrate on the forms themselves. Even if we were to change the forms, we should aim in the directions that our users would like. I think we have some excellent evidence for their preferences in the disambiguation pages of Wikipedia--built by the users themselves, e.g. http://en.wikipedia.org/wiki/David_Johnson or http://en.wikipedia.org/wiki/IBM_%28disambiguation%29 or http://en.wikipedia.org/wiki/War_%28disambiguation%29, where the distinguishing factor isn't so reliant on dates, but on descriptive terms, e.g. for war: ... Write after read, a data hazard WAR (Sun file format) (Web application ARchive), a file format used to package Java applications KDE WAR (file format) (Web ARchive), a file format for storing a web page early versions of Decwar, a pioneering multi-user computer game ... I also prefer these types of forms, but they are not the directions RDA is leading us. I think it's time (and has been for quite awhile) for libraries and the catalogs to make some kind of big splash; to do something that will make people (i.e. our users) sit up and take notice. We have to do something that will make a difference to them. Many other organizations out there are focusing on making these big splashes right now, as we discuss. RDA has a few distant, theoretical, vague goals that are disputed in themselves, but we still should not delude ourselves that any of the changes they posit will make any difference to our users. If, by some miracle, URIs were actually implemented in our records within a mere 10 years or so (which would be the equivalent of light speed), I am
Re: [RDA-L] Protesting RDA
I am sending this to both Autocat and RDA-L Deborah Tomaras wrote, through J. McRee Elrod snip I believe that time is running out for any organized opposition to RDA, from those who either want it altered or abolished; certainly, by April of next year, if not earlier, it will be a fait accompli. So I am now proposing that the opposition organize, and influence RDA while we possibly still can. Here are some things that I believe we might need: /snip also, in another message on Autocat, Ms Tomaras wrote: snip If, in the course of the many years developing RDA, any studies were conducted showing that this change were truly better for users, and desired by them, I might be more convinced. If cost mockups had been done, and discussion made about how to help smaller or cash-strapped organizations switch, I might be more convinced. /snip While it probably comes as no surprise that I fully support these efforts, at the same time I realize that whenever major changes are proposed, it means that major disruptions will be inevitable. Therefore, disruptions in and of themselves are not necessarily bad during moments of change. The question is and will be: are these disruptions manageable, and are they worth the cost, as she pointed out in her message? I want to repeat: I have nothing but deep respect for everyone working so diligently on RDA, and I mean it sincerely. I respect their abilities and knowledge and I realize that theirs is a thankless task in many ways. Nevertheless, when a person truly believes the field is endangered, they are ethically compelled to speak out. This is how I felt when retraining costs became a practical impossibility for my institution in the current environment, and as I slowly realized and accepted how little FRBR/RDA really change anything. (I have tried to demonstrate this in my series of podcasts) In my opinion, one of the major problems I see with RDA is that it doesn't go far enough. As an example, we should not pretend to ourselves that changing Elvis Presley's or Richard Wagner's authorized form, in other words, changing one *textual string* into any other *textual string*, is any kind of a change at all. This is the sort of change that allows others to make fun of us and that gives cataloging and catalogers a bad name. We must face facts: can anyone maintain with a straight face that the form Presley, Elvis (Elvis Aron), 1935-1977 instead of Presley, Elvis, 1935-1977 will make any kind of substantial and meaningful difference for our patrons, instead of... If we are really aiming to change matters, we should replace the textual string with a URI and then lots of people will gain multiple options that we can only imagine at this point. So, if the textual string for Elvis actually changed to http://dbpedia.org/page/Category:Elvis_Presley or http://viaf.org/viaf/23404836/#Presley,_Elvis,_1935-1977 or something in this vein, it would be a genuine gain for our patrons that *every single person* could point to--from searchers to catalogers to budget administrators. I have no doubt that this would change libraries and catalogers far more than the elementary addition of a $q. Switching over to URLs would signal that the traditional library cataloging community were ready for genuine cooperation with other communities, and it would mean taking advantage of the power that modern technology gives us. To me, the RDA changes to Elvis' and Richard Wagner's headings are just more convincing evidence that the problems facing cataloging are absolutely not related to cataloging rules, but to all kinds of other areas. Additionally, if the URIs were implemented correctly, such a major change could be done more or less automatically by computer technicians instead of every single cataloger changing everything they do. So, which would involve greater changes and possibly, greater disruptions, along with promises of greater possibilities: changing the text of Elvis' heading or embracing the power of the web? If these were some of the directions the changes were going, I would be all for them. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] Seeking a Web-based FRBR Catalog (catalogue)
The problem with finding a genuine FRBR catalog is that it exists only in theory: for a true FRBR catalog to exist, you need another structure underlying the edifice, one based on the FRBR entity/attribute model, and nothing like that exists yet (that I know of anyway). For that to happen, we need a complete change in MARC format (which was created to exchange information on separate cards, i.e. complete information for each manifestation or edition), plus we would need changes in rules, to ensure that the information required in each entity is there, e.g. that the work record has the required information for all the relevant authors and subjects, that the expression record has the information for editors and versions, etc. etc. To create such a structure will require quite literally a sea change in how every cataloger works, and more importantly, how they think. Naturally, there would be tremendous concerns over retrospective conversion; otherwise we risk making everything we have now more or less obsolete. In the meantime there are some projects that attempt to replicate the experience of an FRBR catalog, and the others have suggested several excellent ones. I personally like the example at http://zoeken.bibliotheek.be. Such projects are incredibly useful since they demonstrate that there is a lot we can do with the records we have right now, and these projects by no means exhaust the possibilities. I think it would be wise to take a step back and, using these projects which simulate a genuine FRBR tool, to ask seriously: would building a genuine FRBR sort of tool really provide our patrons with what they want or need? Does an FRBR tool answer the real-life questions our public brings to the catalog? Is it best, in these exceedingly trying financial conditions, to redo everything to build a tool that people *may not* find particularly useful? I am as yet unaware of any user studies along these lines in relation to FRBR/RDA, but there are many studies of users, how they search for information and what they expect from it, from other viewpoints. Two of the latest are at: http://www.libraryjournal.com/lj/communityacademiclibraries/887740-419/discovery_face-off_draws_a_crowd.html.csp (the Charleston Conference. I only read the LJ account, but I just discovered that some of the presentations are up at http://www.slideshare.net/event/2010-charleston-conference) and Project Information Literacy's report at: http://projectinfolit.org/pdfs/PIL_Fall2010_Survey_FullReport1.pdf There are many other highly useful studies however, some of the most interesting coming from library anthropologists(!). James Weinheimer j.weinhei...@aur.edumailto:j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/ From: Resource Description and Access / Resource Description and Access [mailto:rd...@listserv.lac-bac.gc.ca] On Behalf Of Rosa Matthys Sent: Monday, November 29, 2010 10:04 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Seeking a Web-based FRBR Catalog (catalogue) Another example is http://zoeken.bibliotheek.be Some queries with a good grouping result are: http://zoeken.bibliotheek.be/?q=jane austen http://zoeken.bibliotheek.be/?q=bach cello suites Regards Rosa Matthys Coördinatie centraal catalogiseren Coordination Central Cataloguing rosa.matt...@bibnet.bemailto:rosa.matt...@bibnet.be +32 (0)9 223 42 11 +32 (0)486 85 79 27 Bibnet vzw www.bibnet.behttp://www.bibnet.be/ Priemstraat 51 B-1000 Brussel Van: Resource Description and Access / Resource Description and Access [mailto:rd...@listserv.lac-bac.gc.ca] Namens Mike McReynolds Verzonden: maandag 29 november 2010 21:39 Aan: RDA-L@LISTSERV.LAC-BAC.GC.CA Onderwerp: Re: [RDA-L] Seeking a Web-based FRBR Catalog (catalogue) Thank you very much! On 11/29/2010 2:22 PM, Andrew Hankinson wrote: Here are a couple: Australian Music Centre catalogue: http://www.australianmusiccentre.com.au/about/websitedevelopment Scherzo, Variations/FRBR test catalogue: http://webapp1.dlib.indiana.edu/scherzo/ There are a number of projects at OCLC on FRBR, although their main one, FictionFinder, seems to be down for maintenance: http://www.oclc.org/research/activities/past/orprojects/frbr/default.htm And then there's the FRBR blog, which has a ton of links to other FRBR projects: http://www.frbr.org/ Cheers, -Andrew On 2010-11-29, at 3:00 PM, Mike McReynolds wrote: Good Day: I've been seeking examples of FRBR catalogs on the Web to point to as examples. Despite searching the RDA-L archives, library literature, the IFLA Web site and Google, I've not been able to locate a single example of a FRBR catalog. This would be helpful
[RDA-L] Imagining different types of standards (Was: Statement Naming More Than One Person, Etc.: Mark of omission before supplied information)
Brenndorfer, Thomas wrote: snip Perhaps it would have been better to use an example from Codex Alimentarius that resembled the textual properties displayed on bibliographic resources which catalogers must take into account in assisting people in identifying those resources. The General Standard for the Labelling of Prepackaged Foods (http://www.codexalimentarius.net/download/standards/32/CXS_001e.pdf) prescribes a series of instructions for recording the the name of the food that is no less onerous than the rules for bibliographic description in libraries: 4.1 The name of the food 4.1.1 The name shall indicate the true nature of the food and normally be specific and not generic: 4.1.1.1 Where a name or names have been established for a food in a Codex standard, at least one of these names shall be used. 4.1.1.2 In other cases, the name prescribed by national legislation shall be used. 4.1.1.3 In the absence of any such name, either a common or usual name existing by common usage as an appropriate descriptive term which was not misleading or confusing to the consumer shall be used. ... /snip Thanks for pointing that out. This is a much better example of what I have in mind. For example, I can imagine that determining a *precise form* of a named entity may become less important as URIs begin to be implemented and displays of names become more fluid. Still, I can imagine a highly predictable type of form that would, in a sense, guarantee access to the name for librarians; in other words, an expert form of the name and that could continue current AACR2-type practices more or less. Of course, the same methods could work for subjects as well, and perhaps better. So, if we have a form of subject that really no one would ever think of, e.g. Byron, George Gordon Byron, Baron, 1788-1824--Homes and haunts--England--London, this would not necessarily be the first thing displayed and it could be something more like Lord Byron and British pubs! :) James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Statement Naming More Than One Person, Etc.: Mark of omission before supplied information
J. McRee Elrod wrote: snip Mark Ehlert said: (Something to fall back on when the RDA text is wishy-washy--which says something about the RDA text as is stands now.) The end result will be increased variation in practice among those creating bibliographic records. /snip Although I am a fervent believer in consistency, I believe that the future of bibliographic standards will come to resemble other standards, e.g. standards for food. As an example, you can look at the standards of the Codex Alimentarius and how they work: http://www.codexalimentarius.net/web/standard_list.jsp If you look at almost any standard, for example, the following is taken from the one for honey, we see standards such as: 3.4 MOISTURE CONTENT (a)Honeys not listed below - not more than 20% (b) Heather honey (Calluna) - not more than 23% or 3.5.2Sucrose Content (a)Honey not listed below - not more than 5 g/100g (b) Alfalfa (Medicago sativa), Citrus spp., False - not more than 10 g/100g Acacia (Robinia pseudoacacia), French Honeysuckle (Hedysarum), Menzies Banksia (Banksia menziesii),Red Gum (Eucalyptus camaldulensis), Leatherwood (Eucryphia lucida), Eucryphia milligani (c)Lavender (Lavandula spp),Borage (Borago- not more than 15 g/100g officinalis) I freely confess that I do not understand the first thing about making honey, so all of this means nothing to me, but I accept that to experts it means something very specific and is very important. And as a consequence, everybody who cares about honey actually cares about these standards, although the vast majority of people who eat honey don't even know these standards exist and even fewer have read them. We can also see from just these little examples that food standards are almost always minimums and not maximums, i.e. they allow plenty of room for additional quality but certain minimums are guaranteed. I think there is a lot we can all learn from such standards. So, I think that as future bibliographic standards evolve, they will become guidelines for minimums, and not how they are now: thou shalt transcribe the statement of responsibility from precisely these sources of information using precisely these methods. Exactly how these new types of standards will work in practice, I cannot very well imagine at this point, but it seems something like this may be the only way to ensure some level of reliability that different bibliographic agencies can achieve. We have to face facts: it is becoming ever more essential that libraries and library catalogers get all the help they can. This will mean real and true cooperation with other relevant bibliographic agencies. This was never possible before but today, using modern technology, the possibility for cooperation on a previously unimaginable level is available. This will mean however, fundamental changes for absolutely *everyone* involved, not least of all, libraries. Based on the development of standards in other areas, perhaps determining minimal levels is a more profitable way to go than the traditional library method of: everyone will do *this* in precisely *these ways*. This has a possible consequence of lack of consistency, and this must be dealt with in some way. Right now, I don't know how it could be done. Incredible changes are happening now anyway, and apparently more will come very soon. Here is a recent article from the Guardian that describes a bit of what our British colleagues may be seeing. http://www.guardian.co.uk/books/2010/nov/22/library-cuts-leading-authors-condemn “Writers Philip Pullman, Kate Mosse and Will Self have criticised government cuts that could see up to a quarter of librarians lose their jobs over the next year. Widespread library closures are expected as councils cut their services and look to volunteers in an attempt to balance budgets hit by the coalition's spending review.” Profound changes are happening to the profession right now and practical methods must be taken to deal with them. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] More granulalrity if imprint year coding?
Hal Cain wrote: snip Quoting Deborah Fritz debo...@marcofquality.com: I think that what John actually said was and *not just* with regard to the 260 field, my emphasis added, i.e., plans are afoot for adding granularity to the 260 *and* other fields. Which is certainly good news-for however long we are going to continue to use MARC for RDA. Which for some will be a long time, I think, seeing how many smaller libraries I know that have little or no prospect of getting funding for replacing their existing MARC systems. On the other hand, some will need specialist help to rejig their MARC mapping to accomodate RDA records, but that will come rather cheaper than system replacement. It would be a service to us all to be able to incorporate new MARC subfielding (such as in 260) in one operation. /snip I agree with Hal on this: any changes will take an awful long time to percolate through the system. The purpose of my original post on this topic was to point out the difficulties of everyone agreeing that this particular item I am looking at is the same as this other particular item I am looking at. In other words, I was trying to point out the real difficulty of determining what is a manifestation. It is only a matter of *definition*, and different bibliographic universes will define their equivalent of a manifestation in different ways, and not only that, each individual cataloger/metadata creator who works within a separate bibliographic universe--all of whom may be highly experienced and knowledgeable--will also interpret things in their own ways. I cannot imagine that another bibliographic universe (e.g. publishers, rare book dealers, etc.) will change everything they do simply because our bibliographic universe changes our definition of what is a manifestation. After all, we wouldn't change for them. If something that should be one of the simplest aspects of cataloging turns out to be so difficult to reconcile in practice (This is--or is not--a copy of that), then how in the world does that leave us with any hope at all to reach agreement on expression and work, which I don't think anyone maintains are simpler in any way at all? Finally, our records can no longer be considered separately from other records in different bibliographic universes out there, and they *will* (not must) interoperate all together somehow! Understand my despair? So, my concern is not so much that we need additional subfields (although Jonathan is absolutely right about systems needing them), because additional subfields necessarily increase complexity. Greater complexity should be avoided because it takes more time to do and catalogers need to be trained to input information consistently, otherwise we get hash. Just adding a bunch of subfields that are misused serves no purpose. Nevertheless, in certain *rare* cases however, adding subfields may actually *simplify* cataloger's work and in my experience, 260$c may be an example of one of those cases. Or maybe not. I think it should be considered, but practical considerations (i.e. simplification) need to take precedence. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
[RDA-L] New Cataloging Matters podcast
All, Apologies for cross-posting. This is to announce that I just added the latest Cataloging Matters podcast to my blog at http://catalogingmatters.blogspot.com/2010/11/cataloging-matters-no.html. This one continues my personal journey with FRBR. Please feel free to forward this to anyone who may be interested. James Weinheimer j.weinhei...@aur.edumailto:j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] All our eggs in one basket?
Karen Coyle wrote: snip We do not have a single source of data today. We have publisher web sites, Books in Print, publisher ONIX data, online booksellers, Wikipedia, LC's catalog, WorldCat, thousands of library databases, a millions of citations in documents. There is the question of is this data authoritative?... /snip Also, if the informational world were amenable, a lot of this information *could* come from the item itself. For example, metadata could be harvested from the meta fields of a web page. See as an example, the metadata in the Slavic Cataloging Manual, now at Indiana University http://www.indiana.edu/~libslav/slavcatman/. Look at the Page Source mostly found under View in most browsers and you will see some metadata for this item. Spiders could be configured to harvest this data. Or, in an XML document, a lot of this could come from the information itself, e.g. a title of a book could be encoded as 245a or dc.title (although I would like some way to distinguish a title proper). The ISBD principle of exact transcription would fit in perfectly. Also, as information is updated, the updates could be reflected everywhere immediately. The mechanics of much of this exists right now. The main problem is that there is very little agreement over coding or how data is input. For example, see almost any NY Times article http://www.nytimes.com/2010/11/15/world/asia/15prexy.html, and look at the meta fields there. This can give an idea of the possibilities, as well as the challenges in getting control of all of this. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] 300 Punctuation
Myers, John F. wrote: snip This is what happens when we continue to coopt a communication standard developed to print cards for use as a vehicle to convey data in electronic interfaces. Nearly every quirk in MARC can be traced back to its foundation as a card printing mechanism (and the lack of programming sophistication when it was originally developed). /snip One thing I think needs to be kept in mind is the purpose of the ISBD punctuation, which is language-independent. Here is a record I took at random from the catalog of the Russian National Library. Even though not everybody reads Russian, any cataloger in the world can immediate understand what the various parts are because of the punctuation. (I switched my email format to HTML, so I hope it works for everybody) Достоевский, Федор Михайлович (1821-1881). Село Степанчиково и его обитатели : Из записок неизвест. / Ф.М.Достоевский. - Изд. для слабовидящих. - М. : ИПТК Логос, 1997. - 550 с. ; 20 см. - (Круг чтения). I think this important function can be retained in a non-ISBD punctuation atmosphere-at least kind of. We can have different interfaces so that each person can decide upon the language he or she wants to view the catalog in, but even then, it seems as if there will be some kind of a limit on the number of languages offered, and the idea of above, where any cataloger can understand that record will not be possible. Of course, we need to consider the possibility of various types of automatic translations a la Google Translate, and/or automatic transliteration as well. Retaining the international comprehension would be very nice but maybe it can't be done. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] FRBRized data available for bulk download
Karen Coyle wrote: snip If you look at the simple Group1 diagram: http://archive.ifla.org/VII/s13/frbr/fig3-1.jpg you see that a manifestation can manifest more than one expression. So there are two (at least) ways to go: 1) consider the aggregate a manifestation and an expression and a work; but that doesn't explain why manifestation and expression are many-to-many 2) consider an aggregate a manifestation of more than one expression, and each expression expresses a single work (note the arrows between expression and work -- each expression can express only one work). It seems to me that the aggregate form (#1 here) completely negates the separation between work, expression and manifestation -- we get back to traditional cataloging where we've only got one thing -- which is defined by the manifestation. It also means that once again just about every publication becomes a separate thing and we are back to showing our users long lists of bibliographic records for the same text. If that's the goal, why did we bother with FRBR in the first place? What does it gain us? /snip If I understand this correctly, this is what Bernhard has been mentioned several times, but in one of my replies, I mentioned how I would *index* a single volume of conference proceedings, and one volume with a single record could easily turn into 40 or 50 separate items--a trend that is unsustainable in a practical sense, in my opinion, but who knows? It seems to me there are many possible ways to go on this. I guess that when I considered aggregate works, I was thinking of mashups (e.g. what is the Youtube main page with dozens of videos), otherwise isn't it just the same as any other compilations, series treatments, and various types of multipart items, as Karen mentions? Still, it seems as if there should be some idea somewhere of standardization. For example, what is the difference between cataloging and indexing, or does FRBR view the two tasks as merging? James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/
[RDA-L] Podcast: The Functional Requirements for Bibliographic Records: a personal journey. Pt. 3
Apologies for cross-posting. All, This is to let everyone know that I have added a new podcast of Cataloging Matters, which is pt. 3 of my personal journey with FRBR at http://catalogingmatters.blogspot.com/2010/10/functional-requirements-for.html Please share this with others as you find appropriate. James Weinheimer j.weinhei...@aur.edumailto:j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Recording Extent, Other Physical Characteristics, and Dimensions for incomplete serials
John Hostage wrote: snip The v. is a specific material designation that tells you the serial is held in the form of volumes, rather than some kind of discs, microfiches, postcards, or bits and bytes. But it's true that this kind of information is probably lost on the user. /snip John is correct here, and while the information may be lost on the user, it still provides information to the experts who actually manage the collection and are the closest users of the records, themselves. Catalog records exist for two groups: the public and the librarians. I don't believe one is more important than the other, since if a collection is to function correctly, which I am pretty sure our patrons want, the managers need additional tools and information beyond what the public may need. There is so much on web pages that I do not understand, e.g. on Google, I have no idea what the Wonder Wheel does; in Microsoft Word and Excel, I probably understand about 30-40% of what I see there. It doesn't bother me, though. I think regular patrons are the same thing: they don't spend that much time or even care that much about the metadata record, since what they really want is the book, serial, article, film, etc. that the record describes. I question whether it is such a serious thing that the public does not understand everything they see, and that they may not understand little bits and pieces of a record. We can see it on lots of sites out there every day, and nobody seems to care very much. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] Interesting conversations about RDA and FRBR ...
Bernhard Eversberg wrote: snip It also goes well with the paradigm of all known retrieval systems, based as it is on the idea of the result set, resulting from a query that uses attributes of various kinds, and all of them can be viewed as attributes of items. Certain combinations of attributes define subsets of items - some of these subsets can be called manifestations, expressions, or works. The identification of the work, however, remains the open question. It has to be done somewhere. Traditionally, it was pinned down by the uniform title, and many of our records have this as a distinctive attribute. Add to it the language, date, form, medium, numeric designation, key, coordinates, etc. - and you single out the crucial subsets that FRBR views from the top down. /snip I don't know if I agree that the identification of the work has to be done somewhere. Perhaps in some formats (I am thinking primarily of music), it is more important than others, but even then I don't know if people are able to find what they want using the newer tools, e.g. ITunes and Youtube. But in library catalogs (both OPAC and cards), very few people I have met even understand what a uniform title is, much less be able to work with it. This is not to say that searching by work is unimportant, but people must first be made aware that it is even possible, while the very concept of controlled vocabulary (even personal name control) is being forgotten among the general population. What I like from those comments, and especially the thread of Karen Coyle's, is that people there seem to be approaching the problem in a fresh, new way, instead of saying that first of all anything must fit into this WEMI pattern. At least from my understanding of the thread, what is especially forward-looking is the focus on the individual attributes without grouping them into a prearranged structure. Each community should be able to group them as they wish; which they will anyway! Free the attributes! James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] Interesting conversations about RDA and FRBR ...
Bernhard Eversberg wrote: snip For classical music, it is indispensable. Apart from this, I think, one must certainly retain it for prolific authors, difficult though they are to define. LibraryThing, from the outset, had no such notion. Later, however, they realized that some kind of grouping was badly needed, and they came up with the Canonical title! They invented the notion of the Series as well, after realizing that this kind of grouping can be very useful, and their understanding of it is even wider than ours. So, they uncannily re-invented the bibliographic wheel. Can we go ahead and abolish or even neglect it, make it square or something? /snip But who are the ones doing the reinventing? As only one example in music, there is the Classical Archives at http://www.classicalarchives.com/ and their searching module is quite interesting. Play with their advanced search and see what you get--something that would be difficult to get out of traditional library catalogs that I think the public most probably likes. The Internet Movie Database is very useful too. When (and if) libraries put their records online in a more accessible manner, they will be the last ones, and it will be very difficult to know precisely who will be doing the reinventing. snip But we cannot base decisions solely on what average or even above-average patrons know or instinctively want or what we believe they want. As soon as they start thinking and consciously working with bibliographic data, the LT lesson teaches us, they start re-discovering and re-inventing. /snip I also believe it is difficult to know, but FRBR/RDA make precisely those same assumptions. Still, when things are reconsidered independently, there may be a rediscovery, but it is rarely the same as the original knowledge--there is more often than not several new and important twists provided for the new people. But instead of pitting it as us vs. them, (Us vs. Classical Archives IMDB) another way of looking at it is that we are all in it together, and we are doing the same work over and over and over. This is the sort of thing that I think could be improved by working together and sharing this kind of information (OK, the Classical Archives is a paid service, but they aren't the only ones out there) so that everyone can benefit. If there were different choices as to the clicks selected in the Classical Archives, with some of the choices coming to our materials, that would help us and our patrons, too. snip But first of all, liberate works that are now incarcerated inside all sorts of collections or multiparts (whose workness is somewhat dubious). Here, the notion of the (physical) item is really not the best of concepts, in terms of usability of the catalog, to base a description and a record on. /snip A terrifying possibility, but one that I agree is probably necessary, although libraries do not, and will not, have the resources to do it. I remember working on single volume conference publications that could take days because each one had dozens of individual papers, and instead of one item, the single volume became 40 or 60 or more records. I think the only way it could be done practically would be through some kind of crowdsourcing. Also in this regard, with the recent, and very positive, DMCA changes and the possibilities to remix, the very notion of implementing FRBR-type structures for these materials is staggering. See: http://www.eff.org/press/archives/2010/07/26 James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] Interesting conversations about RDA and FRBR ...
J. McRee Elrod wrote: snip Jim said: I remember working on single volume conference publications that could take days because each one had dozens of individual papers, and instead of one item, the single volume became 40 or 60 or more records. Picture a work/expression/manifestation record for each paper, and you have 180 records. /snip Wow! You're right. I hadn't thought of that. Somehow, it seems to be going the wrong way. It reminds me of inputting Russian diacritics, and to input some of the Cyrillic characters, e.g. a Russian ia, with the ligatures, in RLIN, I had to push (I think I remember) a total of 8 keys. Then we went to Notis and it went to something like (again, I think) 10. Then came Voyager, and I couldn't believe we had to press even more keys! I thought, Who's figuring this out, anyway? Some sadist? That's when I started learning how to make macros. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/
[RDA-L] Cataloging Matters Podcast No. 4: The Functional Requirements for Bibliographic Records, a personal journey, part 2
All, Apologies for cross-posting. I have just made another podcast of Cataloging Matters, which is part 2 of my personal journey with FRBR. It is available on my blog at: http://catalogingmatters.blogspot.com/2010/09/cataloging-matters-podcast-no-4.html, along with the transcript. Please forward this to any others who may be interested. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] New ed. of Chicago Manual of Style
Hal Cain wrote: snip Quoting Adam L. Schiff asch...@u.washington.edu: I was sitting at lunch today, reading our weekly alternative newspaper The Stranger, and lo and behold they have a book review of the new (16th) edition of The Chicago Manual of Style: http://www.thestranger.com/seattle/hyphenate-this/Content?oid=4830760 The are a number of changes to the style manual mentioned in the review that have implications for RDA instructions and examples. RDA A.10: The guidelines for English-language capitalization basically follow those of the Chicago Manual of Style.(1) Certain guidelines that differ have been modified to conform to the requirements of bibliographic records and long-standing cataloguing practice. [snip] Why should cataloguers (as evidenced and prescribed by RDA) follow styles which differ from the leading English style guides in the various English-language countries? We're constantly being told that the data we craft may be employed not only in bibliographic catalogues of the kind we're used to but elsewhere, in as many different contexts as people can imagine. While I doubt some of those claims, I think some of the difference of style we're used to are retained for no good reason. /snip Of course, every style guide is different, and champions of each format think that *their* form is best and will fight to the very end to keep what they have. One of the new needs the users have from our bibliographic records that they didn't need back in Cutter's day is to be able to get automatic citations. People want them badly, and the reference librarian part of me wants them badly too, because people always mess up citations. It would be great if there were only a single citation format (or, by the way, a single way of cataloging!) but there isn't and won't be for a long, long time, if ever. Fortunately, modern tools are powerful enough to make everybody more or less happy, and OCLC is doing a fine job of it. For example, take a record from my catalog, http://www.galileo.aur.it/cgi-bin/koha/opac-detail.pl?bib=7144, and click in the right-hand column Get a Citation. A box will open up with citations ready to copy paste. This is made available through OCLC and some very innovative RSS feeds (not MARC format!), and where OCLC does some additional filtering behind the scenes, e.g. take a look at the forms of author's names in each of the formats. The problem is, there are lots of duplicate records in OCLC, and multiple possibilities result, as we see here. I could easily limit this to the first five, but the first five do not necessarily seem to be the best choices, so I am letting it all hang out. Still, this is a great tool that has helped my patrons immensely and I applaud OCLC for this! It should also help catalogers understand how text in a database can be reworked for different display; e.g. we see the first names reformatted (capitalized, only initials, etc.). There are many ways of accomplishing these transformations and all of this allows for many possibilities. I would like to point out that although automatic citations are a new need in library terms, in absolute terms, they are pretty old. According to Wikipedia, the first citation management software came out in 1984 (Reference Manager), Endnote came out in 1988, which has been some time ago, so in many ways, we are catching up here, too. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] Time and effort
Jonathan, That looks really handy and saves a lot of time. It looks like you are doing this with OpenURL, and it's a great example of how powerful it can be. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/ From: Resource Description and Access / Resource Description and Access [rd...@listserv.lac-bac.gc.ca] On Behalf Of Jonathan Rochkind [rochk...@jhu.edu] Sent: Saturday, September 04, 2010 7:20 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Time and effort That's pretty neat stuff Jim. My Umlaut software approaches from a different direction, taking known items (rather than searches) and trying to find supplementary in other specific databases; for now mostly focusing on finding electronic full-text or searching (which is useful even without full text), but also including some actual supplementary info like 'cited by' information for journal articles. More sources of supplementary info could be found later. Here are some examples. Oh, it's also worth noting that what makes it more feasible to do this kind of thing is the numeric identifiers in our records: ISBN, ISSN, LCCN, OCLCnum. And supplementary databases that use those same identifiers -- Google Books even has LCCN and OCLCnum in it, for matching. Every time somebody cataloging workflow removes useful identifiers like this from the record because we don't need them, or 'our system can't handle them', it saddens me. Likewise, when actual offiial cataloging 'standards' put such useful identifiers in uselessly ambiguous places (like sticking valid alternate-version ISBNs or ISSNs in a $z subfield!). http://findit.library.jhu.edu/go/2133277 http://findit.library.jhu.edu/go/2133279 http://findit.library.jhu.edu/go/2133280 From: Resource Description and Access / Resource Description and Access [rd...@listserv.lac-bac.gc.ca] On Behalf Of Weinheimer Jim [j.weinhei...@aur.edu] Sent: Saturday, September 04, 2010 8:58 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Time and effort Hal Cain wrote: snip Meanwhile the most vexing problem I encounter is not the structure of the data and how it's encoded, it's the endless duplicate records in the databases -- and in OCLC's case the non-AACR2 foreign records which often are the only ones for materials I'm dealing with -- and I can assure Jim, that those I've already entered are beginning to attract requests from users. We must be doing something right. [and] I wonder how documents figure in the economy of Jim's library? Not every information need can be met from documentary resources, but if the documents don't any longer matter then what's the purpose of the library to make it different from any other kind of instructional support? /snip I guess I am coming off as anti-book, or at least anti-physical resource and wildly pro-virtual anything. Actually, I like to think that I am pro-everything, or at least, that I do not want to prefer one format over any other. Anybody who comes to my apartment, filled to bursting with books of all sorts, with print outs, etc. immediately sees that I am anything except anti-book, and I openly declare myself to be an addict. But, when I, or one of my patrons, or anyone, is reading a book, they need to be aware of all sorts of other information around that book. There has always been this information, and some of it has been organized, but much more has not been, or at least it has been so difficult to find and access that it hasn't been worth the trouble. Here is a concrete example of what I mean: Here is a record for a book A war like no other : how the Athenians and Spartans fought the Peloponnesian War / Victor Davis Hanson. http://www.worldcat.org/oclc/57211303. In this record, we can see links from his heading and the subject to other records that are *only within the OCLC database*. That is useful to *those who understand,* but it turns out that this fact, which seems very simple, is not understood by many people. But avoiding this difficulty for the moment, these links are far from what is out there that people want or need. One very important resource is a video of a lecture he gave about his book that can be watched at http://www.c-spanvideo.org/program/189156-1. But there are book reviews, blog entries by academics, and it goes on and on and on. The moment someone enters into this microcosm of materials surrounding this book, the interested reader (for lack of any other word) suddenly steps into a far different world of debates, differences of opinion, differences of interpretation, subtleties etc., which is incomparably more interesting than the single book he or she happens to be holding, where everything is more or less cut and dried. The part that goes beyond the book itself
Re: [RDA-L] Time and effort
Abbas, June M. wrote: snip But, in light of all of these insightful discussions, is linked data even going far enough? Is it really providing users with useful representations of the objects in our collections? Is MARC + FRBR (encoded by whichever standard the community settles for) BUT released from relational database structure constraints = Enough? Are we yet capturing attributes that our users search for? that they naturally use to organize their own collections (see Flickr, YouTube, LibraryThing Common Knowledge project)? I humbly submit, NO. Throw in years of user behavior research with an emphasis on the newer research on Web 2.0 and libraries and user-centered design with these users in mind, and what do we have? /snip These are some excellent and forward-looking questions. I completely agree with Karen Coyle about the primary importance of linked data. For a nice overview of at least a lot of my own views, you can see the blog posting of a long thread at NGC4LIB at http://celeripedean.wordpress.com/2009/11/09/ngc4lib-on-tim-berners-lee-and-the-semantic-web/, but it is more important for everyone to watch the interview with Tim Berners-Lee at http://fora.tv/2009/10/08/Next_Decade_Technologies_Changing_the_World-Tim-Berners-Lee, which I found inspiring and demonstrates some of the areas where I believe we could participate as very important players. For some other, very good ideas, see Eric Morgan's post on NGC4LIB at https://listserv.nd.edu/cgi-bin/wa?A2=NGC4LIB;mvatdw;20100831080151-0400 and the thread (which does get technical in some places). It is my own opinion that whatever we produce cannot ever be Enough for what people want and need from information. (Thanks for putting it that way, June!) Those ways of thinking about the catalog are over, and I think, forever. While this may be sad and regrettable, I think it is part of growing up and it is just as well if those ideas are buried. Once that is accepted, then we can figure out the best ways of fitting into the new structures, and provide the very best that we can, and then link into the best of the other things that others out there are producing, and will continue to produce; then the synergisms produced *cooperatively* can be something completely and totally new. When the idea of linked data is really understood, you realize that the sky really is the limit, and while some things produced may not be so positive in some people's opinion, other things will pop up that will be beyond anything we can imagine right now, and can quite literally blow everyone's minds, as Berners-Lee described so well. This is an idea of the future that I would be proud to be a part of. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] Time and effort
Brenndorfer, Thomas wrote: snip Why wouldn't people in a library want to find/identify/select/obtain the resources they want? /snip It is interesting that whenever I question the FRBR user tasks of (here we go one more time!) find/identify/select/obtain: works/expressions/manifestations/items by their authors/titles/subjects people tend to believe that I am maintaining that *nobody ever* wants this traditional type of access. This is not at all what I think, but what I do maintain is that it is not the only way to find information as it was in the card catalog (and it was!), and that the traditional way is not even of primary concern with our patrons today; in fact, even the very concepts of the traditional methods are becoming more and more removed from the experience of younger patrons. My evidence for this is that people genuinely like Google-type searching and databases, and it is *impossible* to do anything like the FRBR tasks in those databases. They prefer these methods to ours. Therefore, to maintain that the public wants and needs the FRBR tasks is illogical and untenable. Also, analysis of the FRBR user tasks often stops after the find/identify/select/obtain part, which really is almost totally speculative since those are the things people do completely on their own, and what they *really and genuinely* do is extremely difficult to know. In any case, what should be of primary concern for catalogers right now are the rest of the tasks, since that is what we are proposing to build and spend our resources on, i.e. creating the works/expressions/manifestations/items finding them by their authors/titles/subjects. We need to ensure that what we make is what people want before we spend huge amounts on changes, which could all be pointed in the wrong directions. All this seems very non-controversial and obvious from a managerial point of view, and in fact, even to disagree would be very strange. How in the world could anyone say that something no one wants should be built? Yet, if there is evidence that there is a genuine movement among our patrons that they say they need FRBR displays so badly, to the detriment of productivity and so on, then I would agree that it needs to be implemented. To me, maintaining that FRBR is what people want and need is obviously indicative of when your only tool is a hammer, everything looks like a nail. The error is assuming that the tool we have made for such a long, long, long time; a tool that our patrons have had no choice except to use or go without, is therefore what people want and need. This is not progressive thinking and we need to be humble. The undeniable fact is people flocked to other tools the moment they had a chance. I want to emphasize that while I also believe that people really do *need* the access that the traditional library catalog provides, my experience shows they may not *want* it. There are many reasons for this, along with consequences, which I will not enter into here. Once again, I shall state that *I do not know* how people search information and how they use it. I have noticed tremendous changes in my own patterns, and what I have witnessed from people I work with, it is also very different. Since I understand how traditional access methods work, I can also see that these new methods are lacking in many ways (e.g. not even any decent author searches??), and in the hands of people less trained, these new patterns can lead to incredible confusion and frustration. I confess I am not really sure exactly what it is that I do that is different in my patterns of discovery, use and expectations of information from what I did many years ago, but I only know that it's a lot different. I also know that I like these new methods. A lot. These are the attitudes that I think we need. For a couple of specific points: snip RDA makes WEMI explict, finally, so we can get started fixing the problems of the past, and start thinking about new catalog designs built on a stronger foundation. /snip Of course, this assumes that our patrons want this so badly that we must retrain, retool, and redo practically everything to achieve it. It also assumes that WEMI displays cannot be created automatically with what we have now. I have seen absolutely no evidence to support any of this. snip Our circulation and reference desk statistics attest to that shifting dynamic as usage has climbed, and the sheer number and diversity of information sources hinders people as much as it helps them, leaving a tremendous ongoing need for reference service (and now training needs for all the new technology). /snip I guess you are saying that your library statistics, e.g. numbers of reference questions, etc. have climbed. I'm happy for you, but the statistics I have seen out there show completely different trends. Here are just a few that I have noted. The initial ARL statistics are particularly pertinent (still the
Re: [RDA-L] Time and effort
Kelleher, Martin wrote: snip People like Google searches, but only when they work well [and] But the Google effect, myth or no myth, continues to be used as an excuse to, well, not bother, at the end of the day, based on the dream that keyword is king - whereas a better way of looking at it would probably be it's a particularly popular fruit, even if people get sick of all the pips But still end up buying because it's the only one that's sold in all the shops, or even because they don't know there are so many other fruits.. /snip I completely agree with this, but I don't know if most non-librarians and/or non-catalogers do. People *really do* like Google, and they even *trust* Google! I also have run across the idea among many people who believe that even if Google isn't perfect today, everyone will see significant improvements tomorrow (and this is undeniable), and it is far more worthwhile to devote resources toward improving full-text retrieval than jazzing up our horses and buggies. Naturally, we need is change, but more importantly, we need change for the better, and one way of changing for the better is to figure out how to merge the best of what we do with the best of the new tools so as to make something that truly is far more powerful than ever before. There is no reason not to acknowledge, understand and take advantage of the power of all the tools out there. If something like this were the goal, I would have much less against big changes in cataloging rules and procedures. In this vein I ask: is the power of the traditional tools we make *really* in the FRBR tasks? Or is it something else? James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] Time and effort
Miksa, Shawne wrote, concerning the initial steps of implementing AACR2: snip Again, all very interesting and I think pertinent to current discussions surrounding RDA development, testing, and possible implementation in the years to come. I would not suppose that any implementation is going to happen next year-mostly likely not for a few years-in which case it would prudent to start planning now on how to implement, or not. As I have said in previous postings (either here or on NGC4LIB), we don't yet have enough data to make such decisions. In looking back at the context surrounding AACR2 implementation we can see that we obviously enjoy a vast technology communications advantage and the ability to exchange information almost instantaneously. However, funding training and implementation and the amount and length of individual time and effort each of us has to put into studying and learning a new way of cataloging is, in my opinion, unchanged. /snip While this may be correct for that historical moment in the implementation of AACR2, the basic purpose of the recommendation of the Working Group (at least as I understand it) is that no arguments are made for actual improvements over what we have now (again quoting from their report): The business case for moving to RDA has not been made satisfactorily. The financial implications (both actual and opportunity) of RDA adoption and its consequent, potential impact on workflow and supporting systems may prove considerable. Meanwhile, the *promised benefits of RDA-such as better accommodation of electronic materials, easier navigation, and more straightforward application-have not been discernible in the drafts seen to date*. [my emphasis--JW] To state it yet one more time, if a case can be made that all these changes and disruptions are worth it for something better, I think there would be fewer problems. But I still have not seen how RDA or FRBR will make anything better for anyone: not for the users, not for reference, and certainly not for catalogers. Can someone please explain where we can expect to see the improvements and capabilities over what we have now? When the library world was moving to AACR2, although all knew there would be incredible disruptions, there were definite, concrete advantages that everyone could understand, although many still didn't think it was worth the change: if all of the English-speaking library world would accept the same rules and practices for description and for name headings, then the amount of copy cataloging could increase tremendously (as it in fact did), but nothing similar is planned with the implementation of RDA, at least so far as I know. For example, are publishers really ready to get on the bandwagon to create RDA records, even though they won't create AACR2 records? It would surprise me, but I am willing to be surprised. If not publishers, then are there other bibliographic agencies who will join in? Which ones? Are RDA/FRBR displays really what our public want and need? Will there be improvements in access? Will productivity increase? Where and why? Is all this really too much to ask? If there are no improvements going forward, why do it? (That was what my first podcast was about) Although such questions may be awkward to raise, we must nevertheless raise these sorts of questions, and answer them as well, since sooner or later, upper echelons will ask these sorts of questions and demand answers. I think it would be better to answer such highly predictable questions sooner rather than later. There could be many improvements made right now without major disruptions, first, by moving toward a more XML-type format that the public could utilize and making our records open. Participating in cooperative projects such as dbpedia could make our work more widely used and appreciated far more than it is now. I am sure others on this list would have many more ideas. Beyond all of these considerations, at least some efforts should be made toward understanding what are the needs of our users, and since these needs are obviously changing, to try to determine in what direction their needs are heading. Only then can we start to decide what to build and how we should change. But it must be accepted that catalogers are *most definitely NOT* the people to know what people need from information. That can only come from reference librarians and the public, the researchers, scholars, and students, themselves. While I am the first to declare that we need major changes--*real changes*--they must be changes that move us forward, and not simply toward another, more complicated way of doing what we do now. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy http://catalogingmatters.blogspot.com/
Re: [RDA-L] Time and effort
Laurence S. Creider wrote: snip I agree that the testing process is being conducted with careful deliberation, and I have much respect for the way the Library of Congress is handling the process. Still, publishing, charging, and testing an incomplete product with a decision on implementation to come after the testing is finished sounds like rushing to me. /snip Although I don't think we can fault RDA for being rushed (many very good people have been spending a lot of valuable time on it for quite a number of years), I don't think being rushed or not is all that pertinent. It is still all based on the business case for RDA: if an adequate business case can be made (i.e. we will be able to provide x number of services that we cannot currently, or that our productivity will rise y number of times, etc.), then we could perhaps consider rushing into it and pick up the pieces later. But if a convincing business case cannot be made, then it doesn't matter to me if the implementation date is only after 10 or 20 years--it shouldn't be implemented if no practical advantages will be gained. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy http://catalogingmatters.blogspot.com/
[RDA-L] Cataloging Matters Podcast: FRBR, a personal journey
All, Apologies for cross-posting. I have just added a new podcast about FRBR, which I have entitled: The Functional Requirements for Bibliographic Records, a personal journey. This is part 1. You can hear it and see the transcript at: http://catalogingmatters.blogspot.com/2010/08/cataloging-matters-no-3-functional.html Please forward this to others who may be interested. James Weinheimer j.weinhei...@aur.edumailto:j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] Another Cataloging Matters podcastt
Thank you for the very kind words and the support. I am back from vacation and managed to fix the latest of my podcasts at any rate, the one about SkyRiver and OCLC at http://catalogingmatters.blogspot.com/2010/08/cataloging-matters-podcast-2-skyriver.html As I wrote earlier, I still have a lot to learn! I'll try not to let this happen again! The next one will be available in a week (or so). Remember, it's an irregular! James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy From: Resource Description and Access / Resource Description and Access [rd...@listserv.lac-bac.gc.ca] On Behalf Of Olivier Rousseaux [rousse...@abes.fr] Sent: Wednesday, August 18, 2010 12:52 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Another Cataloging Matters podcastt Personal and friendly greetings from France. I am a french librarian quite concern about all the topics you deal with in your podcast, and far more... Thank you for telling all over the world that one may be at least puzzled about RDA, FRBR, what there are made for and so on.. I think that one only official thougt will never be enough about anything (and so RDA can't be) and that past is a necessary (and most of the time is a respectuf) thing for future to be... Every one can't speak or write as you do I don't always agreee with you about evrything you but my english is not so good... :-))) Yes, your thoughts may interest people... Go on... Sincerely yours, Olivier Rousseaux Agence bibliographique de l'enseignement Supérieur - Montpellier, France - Mail Original - De: Weinheimer Jim j.weinhei...@aur.edu À: RDA-L@LISTSERV.LAC-BAC.GC.CA Envoyé: Mardi 17 Août 2010 21:36:37 Objet: Re: [RDA-L] Another Cataloging Matters podcastt To all who are interested: I have been on vacation for awhile and just discovered that, due to popular demand the audio of my podcasts are not available. Demand has made me go over my limit, and I can't fix it while I am on vacation. So, I was right: I have a lot to learn concerning these matters and I will find adequate solutions when I get back. Still, it's nice to know that people are interested in my thoughts! James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy
[RDA-L] Another Cataloging Matters podcastt
All, I just put up another Cataloging Matters podcast at: http://catalogingmatters.blogspot.com/2010/08/cataloging-matters-podcast-2-skyriver.html This one is about some of my own thoughts concerning the Skyriver-OCLC lawsuit. Please share this with others you think may be interested. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy
Re: [RDA-L] Cataloging Podcast
Karen, Thanks for your comments. My replies are included: snip 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. /snip 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. snip And RDA itself is being tested (albeit using MARC) by dozens of libraries in the US. http://www.loc.gov/bibliographic-future/rda/test-partners.html http://www.loc.gov/catdir/cpso/RDAtest/rdatraining.html 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. /snip 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 don't think they would should 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? snip 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. /snip RDA attempts to bring the FRBR conceptual model
Re: [RDA-L] OPAC displays for a digital environment
Bernhard Eversberg wrote: snip J. McRee Elrod wrote: We agree with Martha Yee (see below*) that the best display of descriptive information for electronic resources is the unlabeled ISBD choice and order of elements (including collation), as it is for all other library resources. For the display standard, I agree. /snip If I may engage in a bit of deconstruction, I would like to change the display standard to a display standard because I don't think it is possible today to achieve such a thing as *the* display standard. Semantic meaning, which is important, is achieved in another way in today's environment. Therefore, I see the ISBD display as, for instance, the expert's display, a standard display that the experts can rely on. But each database manager, and perhaps each user, will be able to determine the display he or she wants. snip The data model we need for today's environments needs to be an entirely different thing. First of all, it should not focus on physical entities and their complete description in one record, complete in itself and without actionable links to other entities. That's what the MARC record still is, in actual practice. As long as this does not change fundamentally, there is little RDA can effect. (The potential is all there in MARC, but practice must change. There's no need to kill it.) For RDA is based on a data model that breaks the self-contained description up into different kinds of entities, and ties them together by actionable links. /snip While I agree that we could probably use a new data model, I think that first it is necessary to find out what both we and the public need. The FRBR/RDA data model is certainly highly suspect. Perhaps the answer will be to separate our current resources into different entities--or not. Perhaps they will be different entities than what we envision now. All of this is impossible to know without testing. The easiest way to know what people would want is, as I have mentioned in previous messages, to follow what Tim Berners-Lee suggested and open up our data to the public, while linking what can be linked, and see what happens. I have a feeling that we would all be very surprised what people would want from our records and how they may utilize them. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy
Re: [RDA-L] OPAC displays for a digital environment
Jonathan Rochkind wrote:[rochk...@jhu.edu] snip Jim, I agree, but to _achieve_ data that can be displayed in flexible ways, you need to have it based on an explicit and rational, well-designed data model. We do not have this, and this is what keeps us from doing particularly flexible things with our data -- our data goes into a Marc record designed to store it for printing to a catalog card, and if you want to do something with it substantially different than a traditional catalog card print out, you run into trouble. ... So to my mind, your statement here (which I agree with) contradicts your earlier statement where you disagree with Karen suggesting we need to focus on the data model. You suggest that FRBR may not be the right data model, or may not be perfect -- indeed it may not be -- when it comes to FRAD, I agree heartily it's entirely insufficient, although when it comes to FRBR I think it's good enough to move forward with. The key thing is we _need_ to move forward. /snip Jonathan, I see where you are coming from and I certainly share your concern. I don't see exactly where I contradicted myself, but I'll look a little closer, thanks for pointing it out. I do agree completely that we desperately need a decent data model and we need to move forward. Still, you emphasize need while I emphasize forward. If implementing RDA could be done without the massive costs of retraining, retooling, rewriting, re-everything, I might not care so much. If libraries were swimming in dough, I also might not care so much. But as I wrote in some post somewhere, we are going through some of the hardest, most difficult economic situations of our lives. Implementing RDA will involve costs, and will cost so much that, for example, at many libraries, they can't even consider doing it or if they do it, it will be at the cost of jobs and/or acquisitions. Therefore, implementing RDA will split the library world at one of the worst possible times. It has to. I think it is absolutely necessary to stick together now, more than ever. At the same time, there is no proof that switching will improve matters in any way for either ourselves or our users. As a result, implementing RDA and FRBR will be merely a leap of faith on an untested product. I don't even think too many savvy business people would take that risk. I am very concerned that libraries will devote all these resources and nothing will change: people still won't want our records, we will be even less productive than now, our records will become less comprehensible and the quality will go down because of the added complexity, and so on. This would be devastating. What are some of the practical consequences? I think this table from LC is excellent Mapping of MARC Data Elements to FRBR: http://www.loc.gov/marc/marc-functional-analysis/source/table3.pdf Imagine the feeling of horror in the cataloger whose job it will be to populate something like that. There are lots of question marks and I may disagree with some mappings myself. Not that I am finding fault for those who did it. I always feel so sorry for people who take on mapping projects like this--everybody finds fault with it! Remember, this is easy compared to the cataloging. Let's create an RDF for AACR2. Is it impossible? I think not. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy
Re: [RDA-L] Cataloging Podcast
Bernhard Eversberg wrote: snip Isn't this just as well, if in fact it doesn't live up to being groundbreaking kind of innovation that would be called for in this day and age? Instead, it draws out the lines sketched by Cutter already, but then little more. There's not a word about catalog enrichment, blank chapters about the integration of subject access, no guideline for indexing or the presentation of result lists, nothing about interoperability with other standards, even ISBD, - all of that is left to local decisions and vendors. And then it is a large grab bag of options that make it unusable unless accompanied by a long list of decisions and commentary. It remains to be seen how much of the relatively new aspects will be accepted by LC after The Test. For then, that will be what becomes reality, and not much beyond it. What can be hoped for, I think, is a slightly better AACR, not more. /snip Thanks for the encouragement! Of course, I think you're right, but I guess I would like to look in more positive directions. I think we need to take a step back even further than you have and ask what we want and what our patrons want from the records we are to make. The digital world is quite different from the printed world, and I think we all still coming to terms with that, including myself. (I am assuming here that there is no need to change substantially any ISBD/AACR2 rules *for physical items*. Perhaps a few little tweaks here and there, but nothing substantial) There is a significant problem carrying over our normal procedures from physical items, those that will be around more-or-less forever, to digital items, that we know will either disappear completely in a greater or lesser amount of time, or lacking that, will become completely different. This means that the description I make for a printed item will remain valid 200 years in the future, even though the rules may have changed, the description will still describe the item, but for digital/virtual items, it is different. For example, we must assume that *all* pdf files today will not be readable in 25 or 50 years or so. But, I believe we can assume that the *human-readable information* will be the same, i.e. although the pdf file may become a qdf or sdf or tdf or whatever they will have in 50 years and all pdfs will be converted into the new format(s). Therefore, we can assume that all of the pdfs in Google Books will be converted someday to the as yet unknown pdq format, which will be different in every way from the pdf format, *except* that the final result that people see will look exactly the same as it does today, and this new file will have exactly the same human-readable information. In this way, I believe that it is vital for a conversation to take place in the future about content vs. carrier. We must assume that any records we make for digital resources describing the carrier will eventually need major revision in the description area. Since our current standards for description are based so closely on describing the carrier, which works fairly well in the print world, it breaks down in the digital world, failing the test of practicality for catalogers and librarians because we are creating zillions of records that we know will need substantial revisions, while at the same time (at least, I think) failing the test of usefulness for our patrons (who many times don't need this kind of information, and it will be obsolete sooner or later anyway). Since content is becoming independent of carrier in many ways, bibliographic description is a major issue that will have to be addressed someday. Somehow, describing content will become of prime importance. I think there are several ways to address the issue, but in any case, dealing with descriptive cataloging of digital resources, which I think will still be needed, will nevertheless be quite different. It is one area that maybe, perhaps, the FRBR concept of expression may come in useful, but it will have to be reconsidered from its vary basis and become different from what, at least I, have understood it to mean. Again, I want to emphasize that I am not talking about physical items. We have had adequate methods to control those materials for a long time. This is one reason why I have been so disappointed with RDA: these are some of the issues we need to deal with, and you point out many others. While we need changes in cataloging quasi-ephemeral digital/virtual materials, that doesn't mean that I should have to relearn the cataloging rules for cataloging a book or serial! James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy
Re: [RDA-L] Cataloging Podcast
Diane I. Hillmann wrote: snip Jonathan, I think you're right about this, and I think the general habit of looking at RDA primarily as a set of cataloging rules leads to this mode of thinking. /snip On 8/4/10 10:00 AM, Jonathan Rochkind wrote: snip I would not assume that. One way that the digital world is quite different than the printed world is that in the digital world, we present our metadata _in a digital environment_. Even our displays of records for printed materials are presented to users on computer screens. Most of our metadata control practices were created for generating printed cards. Personally, I think the changes required for metadata that will live in the digital world are even more difficult and a greater conceptual break than any changes required to describe digital items. /snip So I still do not understand why we have to have new rules (or new rule numbers) for determining and inputting the title of a book? What has changed? What was so bad about the previous rules that they needed complete refreshing? I don't think I can be accused of being a Luddite; but someone needs to see/understand the title of a book whether it is on a card or a computer display. That title, because it is on a physical item stored somewhere, will never change, therefore, the title recorded in the catalog record will never need to change. For digital/virtual items that change all the time, all these considerations must be thrown out the window. It would be fine to say that for these materials, we have completely different rules, practices and even approaches, just as there are for manuscripts. I could understand that. I think Diane's RDF work may be very useful in the future. But the way we catalog an electronic item should not impact how we catalog a physical item. That doesn't make sense, unless the idea is that we must shoehorn everything into an FRBR world where everything has all those extra records for works, expressions and so on. That is an unwarranted assumption, I believe. The model was never tested for conformance to reality, for practical considerations, or for value to our users. Bernhard pointed out the areas where changes are needed and I think that would be a great starting point. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy
Re: [RDA-L] Consolidated ISBD
Bernhard Eversberg wrote: snip ISBD, however, is not a code of cataloging rules. The introduction says: The International Standard Bibliographic Description (ISBD) is intended to serve as a principal standard to promote universal bibliographic control, that is, to make universally and promptly available, in a form that is internationally acceptable, basic bibliographic data for all published resources in all countries. The main goal of the ISBD is, and has been since the beginning, to provide consistency when sharing bibliographic information. /snip I'm trying to understand how ISBD is *not* a code of cataloging rules, or as I prefer to think of it: standards for input of bibliographic information. snip The printed records were thus conceived, at that time, as a communication format for the transmission of structured information. No verbal or numeric tagging could be employed in printed bibliographies, as goes without saying, but the punctuation had to do double duty for that purpose. /snip While I can understand this idea that the primary goal was to communicate structured information, and the only way of doing that in a print world was through punctuation, I think that this obscures the fact that the focus was still on the information to be communicated, and the punctuation was less important. My evidence is to compare the ISBD with the user guide for Dublin Core (http://dublincore.org/documents/usageguide/elements.shtml) So for example, the DC guidelines for Title are (in their entirety) --- 4.1. Title Label: Title Element Description: The name given to the resource. Typically, a Title will be a name by which the resource is formally known. Guidelines for creation of content: If in doubt about what constitutes the title, repeat the Title element and include the variants in second and subsequent Title iterations. If the item is in HTML, view the source document and make sure that the title identified in the title header (if any) is also included as a Title. Examples: Title=A Pilot's Guide to Aircraft Insurance Title=The Sound of Music Title=Green on Greens Title=AOPA's Tips on Buying Used Aircraft --- Contrast this to the in-depth ISBD guidelines for title (available through http://sites.google.com/site/opencatalogingrules/isbd-areas) and anybody can see immediately DC gives practically no guidance when compared with ISBD. This is not to criticise, but merely to point out that one has standards for input (cataloging rules) and the other does not. In many ways, I see the current discussions as very similar to those in the later 19th century when libraries wanted to exchange catalog cards. The problem was: each library had their own size card and cabinets, and a uniform size card was absolutely necessary if they were going to be exchanged. It was also one of those debates that you either won completely or lost completely, since if your size card was not accepted, you had to recatalog everything, which was a terrifying prospect even then. So, you were either a big winner or big loser but in the end, they discovered that all they had agreed upon was an empty card with a hole in the same place! While that was important, it paled in comparison with the need for and the complexity of sharing the information on the cards in some kind of coherent way--which was the entire purpose. It was *not* about just sharing cards, but sharing the information on those cards. Figuring out a standardized empty card was only the first, and relatively easiest step. (As an aside, at Princeton Univeristy the cards were too big and Ernest Richardson, then the librarian, tried having his catalogers cut down the cards and then write somewhere else on the card what was cut off. That one didn't succeed!) Certainly we should not have to enter punctuation by hand today. Not that it's so difficult to learn to do (pretty much the easiest part of ISBD) but it's a little bit like plowing a field with an ox and plough. There are better and more productive tools available. And concerning displays, we must emphasize the possibility of multiple displays. I think having a standardized one, primarily for use by librarians, is a good idea, but other displays are much more useful for our public, e.g. citations they can copy and paste, exportable records for personal reference databases, and others. I have also felt that multiple displays could be made far more useful for both users and catalogers than those I have seen. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy
Re: [RDA-L] Signatory to a treaty
If I may make an observation on this topic, which I have followed very carefully. This discussion has shown me that the determination of attribute vs. entity is a highly subtle one, loaded with lots of booby-traps and false paths along the way. Getting a competent understanding of this will require quite a bit of training and probably, a fair amount of consultation with colleagues to ensure everything is done correctly and accurately. Most probably, once it comes to everyday practice, we will find many other parts of RDA will be similar. While I have no doubt that library catalogers can eventually be trained to do this adequately, other library personnel will probably not be able to do it, and non-library metadata creators in general will have neither the time nor the patience to deal with such esoteric matters. Therefore, this will be for library use only. Perhaps other non-library project will be able to take our records (sorry for using such an outmoded term!), that is, if they would want to. But what was the final result of the discussion about treaties? The same access as we have today. Certainly we can get rid of LCRI 21.35A2 Treaties, etc., between four or more governments (http://sites.google.com/site/opencatalogingrules/21-35a2-treaties-etc-between-four-or-more-governments) and say that we can add all signatories--so long as the resulting record isn't too terrifying, and a tool is made that lets me add them all quickly and not demand a couple of days to add every country! But even more, it seems to me that we should consider the future catalog not as a separate entity from the rest of the web, but as an integral part of it (I hope as an important part of it as well). The library catalog should not be something that duplicates the work of others, and sometimes their work is much better. We should also recognize that there are many places people can go, and even should prefer, for the kind of information found in a catalog record about a treaty, e.g. not only the major collection at the U.N. http://treaties.un.org/Pages/Home.aspx?lang=en with a fabulous database where you can find and search specific signatories in all kinds of ways, but there are many other sites as well, linked to so nicely e.g. at http://www.justlawlinks.com/GLOBAL/international/citreaty.htm. So, let me ask the terrible question which will most probably make some others angry: once somebody knows these sites, who will want to use our stuff, RDA or not RDA? These are the future directions of our users--they are going there; they *should* be going there, and libraries must follow or be left behind. Libraries could help build and maintain these types of sites in order to link to and through them in a whole number of interesting and innovative ways to save our time, and increase access for all. The catalog should no longer be seen as a separate entity but for efficiency's sake to use the power of the web to really cooperate with all kinds of partners out there. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992
Re: [RDA-L] Contents of Manifestations as Entities
BEER,Chris wrote: snip Of course - browse is simply a single view of data, using a single type of abstraction layer (human readable in this case) to generate that view. /snip I do think that browse is a bit more than that: it is the way people are *supposed* to search the system. It is the way the catalog was designed to function correctly. 99% of the control that librarians provide is based on headings. Browse searches make these headings much more comprehensible than simple keyword. For example, subject headings with their many subdivisions, make sense only in the aggregate, and are designed to be browsed alphabetically (mostly). Uniform titles are the same, along with corporate bodies. Personal names, less so, but with personal names, the variants (4xx, 5xx) are critical to browse. The problem is, the moment keyword became the dominant way for people to search (which was about 2 minutes after it was implemented), the traditional browse became stranger and stranger. Catalogers and other librarians caught on to this change very slowly, and some never at all. The undergraduates I work with now think browses are very, very weird. As a result, our catalogs, traditionally based on browsing cards, based in turn on printed catalogs, are becoming more and more distant from our patrons. Librarians never really reconsidered the function of the catalog--they just tacked on keyword and thought they were done. The task is not to expect everyone to use the browse search again and teach/force them to do it, since this is impossible and retrograde, but to adapt the power of our records to the new environment where traditional browsing does not occur and never will again. We must accept that those days are gone forever. At the same time, browsing the headings is very powerful and something you *cannot* do in a search engine. Tools such as Aquabrowser have tried some new methods to a point, but I don't know if any has succeeded. I like to think of these things in a different way: there were always big problems with browsing. It was never the greatest thing to do and it was always very complicated. How can we make it better? James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992
Re: [RDA-L] expressions and manifestations
Karen Coyle wrote: snip Quoting Laurence Creider lcrei...@lib.nmsu.edu: Is their a technical reason for your statement MARC is not up to providing the appropriate subfields? MARC21 certainly allows for indication of the thesaurus from which subject terms are taken, and presumably that could be extended to other fields as well. There are a number of reasons. Here are a few: 1) there are only 36 possible subfields in every field. In many fields, there are none or at most one left to use /snip This assumes we are stuck forever with ISO2709 records transferred using Z39.50. The moment we change to almost any other format, we have an infinite number of fields and subfields. For example, here is part of a MARCXML record (totally made up): datafield tag=700 ind1=1 ind2= subfield code=aJones, John/subfield subfield code=t The tree frogs of Texas /subfield We can add a subfield: subfield code=relationb/subfield (b is a code defined as: Has part or earlier version or based on or whatever you want. If we want natural language text, we can do that too.) subfield code=relationHasPart/subfield /datafield We can't do this in our current MARC format since we are stuck with single digit subfield codes because of the limitations of ISO2709: 700 1\ $aJones, John$tThe tree frogs of Texas$relationHasPart [theoretically, today we could add the entire UNICODE character set, but I doubt if a lot of people would want to add a subfield lambda λ or shin ש! In any case, there is little sense to expand an obsolete format] In fact, once we move beyond ISO2709, we could even do things that can interoperate with other formats, e.g. Dublin Core (for an analytic): DC.Relation.hasPart datafield tag=100 ind1=1 ind2= subfield code=aJones, John/subfield /datafield datafield tag=245 ind1=1 ind2=4 subfield code=aThe tree frogs of Texas/subfield subfield code=cJohn Jones/subfield /datafield datafield tag=300 ind1= ind2= subfield code=ap. 34-85/subfield subfield code=bill./subfield /datafield ... /DC.Relation.hasPart This is just as easy with RDF or almost any other modern format. The number of codes and relationships will be endless and we can gain a lot of freedom once we dump that outmoded, obsolete ISO2709 format, which has fulfilled its function but is now holding us back. This does *not* mean that we must abandon MARC. Each bibliographic agency can add on its own sets of fields and subfields, so long as the XML is correctly defined. Whether we need an endless number of codes, fields and subfields I do not want to discuss here. But I think people can understand why non-librarians see that ISO2709 is a kind of straight-jacket in today's world. A lot of those same non-librarians also conclude that MARC format is just as obsolete, but I disagree and believe that MARC can survive so long as we rethink it. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992
Re: [RDA-L] expressions and manifestations
Karen has delineated the problem very well, but we should all just admit that *any solution* on these analytic-type records will definitely *not* be followed by everyone. I don't think that lots of libraries outside the Anglo-American bibliographic world would ever agree to use a 505 (although I personally like them!). The best we can do is to decide to help one another as much as possible. This is why I think the solution lies much more in terms of open data. Someone on one of the lists suggested the TED talk of Berners-Lee (thank you, whoever you are!). I finally saw it last night available at: http://www.ted.com/talks/tim_berners_lee_the_year_open_data_went_worldwide.html and I suggest that everyone watch this. (TED talks are very short. This one is less than 6 minutes, so it shouldn't take too much time) What he demonstrates is something absolutely amazing, and it happened only because some agencies put their data in a place for others to take and share in different ways! I found it quite inspiring. How could this work with our data? If there were an open way of sharing data, I can imagine that, e.g. Mac in Canada makes a record with a 505 note. It is placed into something like the Internet Archive. Bernhard in Germany is working, finds the record with the 505 and runs a very clever macro that he and his friends have made and turns the record into something more suitable for his purposes. Maybe it's not 100%, but even 70% will save a lot of manual editing. He places his version somewhere, so now there are two versions. We can probably see that there could be multiple versions rather quickly. Some other person, perhaps a non-librarian, wants to take all of these versions and merge them in another incredibly clever way and this person adds his/her own information. What would this be? Right off, I can think of a public, cooperative effort to input tables of contents, with links if possible. This would definitely be appreciated by everyone in the world. Now we are getting something absolutely new. At this stage, there will be a real desire for genuine cooperation since everyone can see how they can all benefit if they work together. Plus, it all happens while everyone is still helping one another in very concrete ways that everyone can point to. Is this pie-in-the-sky? Definitely not. It is happening *right now* in other information communities, as Berners-Lee shows. And it has happened very, very quickly. The problem is deciding to take the leap and let our information--now seen in proprietary terms--into the world. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992
Re: [RDA-L] RDA requirements in LMS
Hello Su Nee (I hope I got your name correct!), Koha 3.0 works with MARCXML now. This is where you can see it in action at the John C. Fremont Library District (below). Again, open source is free but this does not mean there are no associated costs. For example, someone could say that they will give you a free house, and you may be happy but if they are only giving you all the wood, bricks, mortar, and so on, it still needs to be built. Some open source projects are like this; others are more advanced. With Koha, it has advanced significantly to where you will have relatively little maintenance problems. Customizing it is actually the fun part and if you know basic web programming (HTML, Javascript, Style sheets) you can do a lot. If you don't have those skills, there is still a lot you can do, but these skills are easily and cheaply available everywhere now. Suffice it to say, that if you want to change something in Koha, it can be done without asking anyone's permission. With proprietary software, you must ask and wait, sometimes forever. But as an example of what you can do, look at my catalog (based on Koha 2.2.7) http://www.galileo.aur.it/cgi-bin/koha/opac-main.pl which I have modified a lot. I made my own display and it works in different ways from other catalogs. For instance, I have managed to embed tutorials, and one I will suggest you look at, which is an overview of my catalog: http://issuu.com/j.weinheimer/docs/aurcatalog?mode=embedviewMode=presentationlayout=http%3A%2F%2Fskin.issuu.com%2Fv%2Fcolor%2Flayout.xmlbackgroundColor=61A900showFlipBtn=true and then look especially at the Extend Search which is used only in my catalog: http://issuu.com/j.weinheimer/docs/extendingthesearch?mode=embedviewMode=presentationlayout=http%3A%2F%2Fskin.issuu.com%2Fv%2Fcolor%2Flayout.xmlbackgroundColor=61A900showFlipBtn=true Another example: I managed to work with the Worldcat API to provide automatic citations, e.g. see http://www.galileo.aur.it/cgi-bin/koha/opac-detail.pl?bib=25256 and click on Get a Citation It is only with open source that you can experiment in these ways. Otherwise, you can only wait and receive what the owners decide to give you. Try my Extend Search and let me know what you think. Hosting your own web server (on a local machine) can be quite an experience. I host mine locally, and sometimes you get hit with spammers and so on and you have to deal with it yourself. These are matters beyond my capabilities, but there is a professor here who enjoys playing with perl and linux, so between the two of us, we have been able to deal with it. But if you don't want to deal with these things, you can find someone else to host your site, for pay. I don't know how much something like that would cost, but probably not very much. There are some hosts that specialize in Koha, also. I want to convert to Koha3.0 but I have run into conversion problems and can't do it yet. If I could, I wouldn't waste a second! The Extensible Catalog also looks very, very nice but I have no experience with it. http://www.extensiblecatalog.org/ It can work with Drupal, but there are lots of possibilities using plug-ins and add-ons with browsers like Firefox (also open source). I hope this helps you. Ciao, Jim James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:rd...@listserv.lac-bac.gc.ca] On Behalf Of Goh Su Nee Sent: Wednesday, March 10, 2010 11:46 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] RDA requirements in LMS Hi James, Thanks very much for your useful comments. I'm not a technical person and thus wouldn't know much about the implications of open-source software. I only know that it's free and that it normally requires a fair amount of programming expertise and effort for customization purposes. What do you think would be the advantages of an open-source software LMS besides the cost benefit? Would you know any non-open-source software LMS that would meet the demands of RDA, XML or MARCXML? Best regards, Su Nee, Goh -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:rd...@listserv.lac-bac.gc.ca] On Behalf Of Weinheimer Jim Sent: Friday, 12 February, 2010 12:06 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] RDA requirements in LMS With modern databases, the same record can be exist in various ways. For example, the Koha catalog places the records in a relational database, plus the records exist also in MARCXML that drive the Zebra indexing. To demonstrate this rather vaporous statement, look at the Koha catalog at the John C. Fremont Library District http://jcfld.us.to/ (chosen at random). Do a search
Re: [RDA-L] RDA requirements in LMS - Apology
Pardons to all. I made a mistake. This message should have been sent privately since this is getting too far off-topic. Jim James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:rd...@listserv.lac-bac.gc.ca] On Behalf Of Weinheimer Jim Sent: Wednesday, March 10, 2010 12:14 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] RDA requirements in LMS Hello Su Nee (I hope I got your name correct!), Koha 3.0 works with MARCXML now. This is where you can see it in action at the John C. Fremont Library District (below). Again, open source is free but this does not mean there are no associated costs. For example, someone could say that they will give you a free house, and you may be happy but if they are only giving you all the wood, bricks, mortar, and so on, it still needs to be built. Some open source projects are like this; others are more advanced. With Koha, it has advanced significantly to where you will have relatively little maintenance problems. Customizing it is actually the fun part and if you know basic web programming (HTML, Javascript, Style sheets) you can do a lot. If you don't have those skills, there is still a lot you can do, but these skills are easily and cheaply available everywhere now. Suffice it to say, that if you want to change something in Koha, it can be done without asking anyone's permission. With proprietary software, you must ask and wait, sometimes forever. But as an example of what you can do, look at my catalog (based on Koha 2.2.7) http://www.galileo.aur.it/cgi-bin/koha/opac-main.pl which I have modified a lot. I made my own display and it works in different ways from other catalogs. For instance, I have managed to embed tutorials, and one I will suggest you look at, which is an overview of my catalog: http://issuu.com/j.weinheimer/docs/aurcatalog?mode=embedviewMode=presentationlayout=http%3A%2F%2Fskin.issuu.com%2Fv%2Fcolor%2Flayout.xmlbackgroundColor=61A900showFlipBtn=true and then look especially at the Extend Search which is used only in my catalog: http://issuu.com/j.weinheimer/docs/extendingthesearch?mode=embedviewMode=presentationlayout=http%3A%2F%2Fskin.issuu.com%2Fv%2Fcolor%2Flayout.xmlbackgroundColor=61A900showFlipBtn=true Another example: I managed to work with the Worldcat API to provide automatic citations, e.g. see http://www.galileo.aur.it/cgi-bin/koha/opac-detail.pl?bib=25256 and click on Get a Citation It is only with open source that you can experiment in these ways. Otherwise, you can only wait and receive what the owners decide to give you. Try my Extend Search and let me know what you think. Hosting your own web server (on a local machine) can be quite an experience. I host mine locally, and sometimes you get hit with spammers and so on and you have to deal with it yourself. These are matters beyond my capabilities, but there is a professor here who enjoys playing with perl and linux, so between the two of us, we have been able to deal with it. But if you don't want to deal with these things, you can find someone else to host your site, for pay. I don't know how much something like that would cost, but probably not very much. There are some hosts that specialize in Koha, also. I want to convert to Koha3.0 but I have run into conversion problems and can't do it yet. If I could, I wouldn't waste a second! The Extensible Catalog also looks very, very nice but I have no experience with it. http://www.extensiblecatalog.org/ It can work with Drupal, but there are lots of possibilities using plug-ins and add-ons with browsers like Firefox (also open source). I hope this helps you. Ciao, Jim James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:rd...@listserv.lac-bac.gc.ca] On Behalf Of Goh Su Nee Sent: Wednesday, March 10, 2010 11:46 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] RDA requirements in LMS Hi James, Thanks very much for your useful comments. I'm not a technical person and thus wouldn't know much about the implications of open-source software. I only know that it's free and that it normally requires a fair amount of programming expertise and effort for customization purposes. What do you think would be the advantages of an open-source software LMS besides the cost benefit? Would you know any non-open-source software LMS that would meet the demands of RDA, XML or MARCXML? Best regards, Su Nee, Goh -Original Message- From: Resource
Re: [RDA-L] Question about RDA relationships (App. J) / Multiparts
Bernhard Eversberg wrote: snip John Attig wrote: I don't believe that FRBR deals explicitly with multiparts; Well, the section 5.3.6.1 Whole/Part Relationships at the Item Level explicitly addresses the issue. Without, admittedly, giving much guidance for dealing with it. in FRBR terms, the entire multivolume set would constitute one item belonging to the manifestation of the expression of the work representing the set as a whole. And how useful ist that? Shakespeare's As you like it as a part of a Collected Plays edition is not a manifestation of the work? Even if within this collection it is a separate volume with its own title page and perfectly citable? I believe we shouldn't like it that way. Alternatively, each volume would be an item belonging to the manifestation of the expression of the work embodied in that volume. It seems to me that FRBR lets you model the situation either way -- or both. For an isolated catalog, this used to be acceptable. For cooperative cataloging, it meant lots of duplicates in the database. For the RDA vision of a Bibliographic Universe of Everything, it is not even good enough. /snip In my experience, the one area of bibliographic control that has the least amount of agreement is in the analytics: each bibliographic agency has its own idea of precisely what belongs to precisely what and how to describe it. Therefore, we have major problems in even getting a basic understanding of series, serials, sets, and collections such as conference proceedings. I honestly do not think that we can ever hope to get anything even close to a general agreement on this, so we have to look to other solutions. This relates back to user needs. People want the work or expression, while most more or less don't care about the physical embodiment. I certainly agree with Bernhard that very few people know to search for Shakespeare selections or Shakespeare works to get a copy of As you like it. This is one of those searches that tended to work much better in a card catalog where people had no choice except to browse by author, than it does today with keyword searching. People normally want individual articles from Time Magazine, not the whole thing. I think this can be extended to all kinds of collections, especially conference proceedings where access can be woefully inadequate. Of course, while people want individual papers they *may* also want to know about the materials related to the one they are looking at. With online resources, these considerations will probably only get more and more tricky. I think we should rather explore ways of bringing all of these different views of works and expressions together instead of trying to mandate that everything fit to a Procrustean Bed. The power of computers is such that I have no doubt it can be done today, but the displays could be very strange. Or, it could turn out that bringing these differing views together may make the bibliographic record more understandable and useful than ever before. (Sorry for using such an obsolete term as bibliographic record!) Although I am certainly no fan of FRBR, I believe the model could accommodate this. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992
