Re: [RDA-L] ISBD and RDA
Jonathan Rochkind wrote: I don't know if OCLC is, but I know that Ex Libris is considering it for their upcoming metadata management module of the 'universal resource manager', which is pretty much vaporware right now, but they're thinking in the right direction. I bet biblios.net would consider it too, if RDA resulted in a metadata element set that was actually useable. We may have to find ways to, not abandon OCLC (which I would not want to do), but not be beholden to use OCLC alone either. All of these are valid considerations, but it still doesn't address that concerns in my post: 1) What are the costs for retraining an experienced professional? 2) How long will it be before productivity returns to today's level? (and this cannot be the ultimate goal, of course, because things must improve) 3) What are the real benefits from implementing RDA that are not merely theoretical? How much will productivity rise? How much more usable copy will become available? How will record quality improve? 4) Is it worth the costs? These are the realities of the situation today. I don't think many institutions can justify paying for subscriptions to RDA for the staff while at the same time we are cutting databases to users. I know I certainly couldn't make a case for it. Could you? Add to this the additional costs of retraining, now that simply sending people to conferences is becoming extremely difficult and matters complicate even more. From what I could glean from the German report sent by Stephen, (and I may be wrong), the justification for moving to AACR2/MARC2 was that by accepting AACR2 the amount of copy cataloging records would go up significantly, and by accepting MARC21 the internal processing would be simplified. Therefore, costs would ultimately go down. Completely logical and correct. But I fail to see anything similar with accepting RDA. As a result, if I were going to implement RDA at my library, I must find some justifications for it that will convince people to reallocate money and resources for it. I can't figure out anything, and I don't think that simply saying, Well, everybody's doing it will work. I'm sure I'm not alone in this. What are others planning to do? Jim Weinheimer
Re: [RDA-L] ISBD and RDA
Interesting, I'm curious for more details about what you do -- and how it came to be -- that no cataloger in Germany actually deals directly in MARC, while in the US catalogers seem to think there is no way possible BUT dealing in MARC, to the extent that some have argued on this list that there is no better way possible to refer to data elements than MARC fields! While MARC was intended as and is described as a transmission format, in the US it has basically come to hold the role of a schema or data element standard, and also generally IS the form that day to day catalogers work in. I don't think this has been all that good for us. But I'm curious how Germany avoided it. Jonathan From: Resource Description and Access / Resource Description and Access [rd...@listserv.lac-bac.gc.ca] On Behalf Of Bernhard Eversberg [...@biblio.tu-bs.de] Sent: Wednesday, April 08, 2009 4:07 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] ISBD and RDA Weinheimer Jim wrote: From what I could glean from the German report sent by Stephen, (and I may be wrong), the justification for moving to AACR2/MARC2 was that by accepting AACR2 the amount of copy cataloging records would go up significantly, and by accepting MARC21 the internal processing would be simplified. Therefore, costs would ultimately go down. Completely logical and correct. Right. Except that we would have to swallow inconsistencies in our databases. There are two major types: 1. Different forms of names and titles: Of course, we don't want Munich for München in corporate names, for instance 2. Different entities: What do we consider a title change, a corporate body, a subordinate body, do we regard families as creator entities and so further. Type 1 can be solved by implementing VIAF, which is why DNB was among those who initiated the project. Type 2 had been recognized and was work in progress among the rulemakers before that infamous decision for the move toward AACR2. It would have been worked out and the resulting inconsistencies would have been tolerable. The move to MARC21 is a different story and not very relevant to cataloging since no cataloger here would have to learn MARC! We have various workform formats here, but nowhere does anyone have a catalogers' software that would have to be changed to MARC21. Its only function will be that of communication between systems. This means there was no real need to trash our old code RAK and move to AACR2. After the now infamous decision, however, out of the blue, the latter got trashed. An uneasy situation, to say the least. Cost estimates are anybody's guess. Translation of RDA and subsequent as well as supportive textual matter has to be added into it. Ultimately, yes, cost's ought to go down. Neither the timeframe nor the costs to get it all done, and how to get it done, are known right now. B.Eversberg
Re: [RDA-L] ISBD and RDA
Jonathan Rochkind wrote: Interesting, I'm curious for more details about what you do -- and how it came to be -- that no cataloger in Germany actually deals directly in MARC, while in the US catalogers seem to think there is no way possible BUT dealing in MARC, Clearly a case of a lack of imaginative powers, if you ask me. (Is this somehow related to the purported monolinguality of the average American? No blame intended, of course.) While MARC was intended as and is described as a transmission format, in the US it has basically come to hold the role of a schema or data element standard, and also generally IS the form that day to day catalogers work in. The latter is not the case here. They work in formats that look totally different, but may be compatible in the sense that a mapping is possible - not always 1:1 of course. It then is the job of the software to translate what the cataloger is seeing into an internal representation that may or may not resemble MARC. IOW, catalogers don't always look at data as it is, and they certainly dont't look at data as it is communicated between systems. A few illustrated examples tell more than so many words: http://www.allegro-c.de/formate/examp/ (German and English text. Click on the 4 blue headlines, and look at least at the two-volume example a little more closely) B.Eversberg
Re: [RDA-L] ISBD and RDA
Bernhard Eversberg wrote: It then is the job of the software to translate what the cataloger is seeing into an internal representation that may or may not resemble MARC. IOW, catalogers don't always look at data as it is, and they certainly dont't look at data as it is communicated between systems. A few illustrated examples tell more than so many words: http://www.allegro-c.de/formate/examp/ (German and English text. Click on the 4 blue headlines, and look at least at the two-volume example a little more closely) From this example, what I get is that while catalogers in Germany might not be dealing with MARC21 directly, they are still dealing with the same concept, i.e. data tagged with numeric labels in a specific data structure. It doesn't really look much different from what everybody does in the U.S. What is really needed is a software application that takes an entirely different approach, such as prompting the cataloger for data in the cataloger's own language (e.g., if it is a book being cataloged, questions like What is the title on the title page?, How many pages are in the book?, Are there illustrations?, etc.). Of course there would need to be much flexibility in how this is applied, because specific questions like this would greatly aid an inexperienced cataloger, but slow down a very experienced cataloger! Kevin M. Randall Principal Serials Cataloger Bibliographic Services Dept. Northwestern University Library 1970 Campus Drive Evanston, IL 60208-2300 email: k...@northwestern.edu phone: (847) 491-2939 fax: (847) 491-4345
Re: [RDA-L] ISBD and RDA
Kevin M. Randall wrote: From this example, what I get is that while catalogers in Germany might not be dealing with MARC21 directly, they are still dealing with the same concept, i.e. data tagged with numeric labels in a specific data structure. Yes, obviously. It doesn't really look much different from what everybody does in the U.S. Except for the multiparts, they *are* much different. We regard volumes as separate entities from the work as a whole, and link them, as to be seen in example 3. What is really needed is a software application that takes an entirely different approach, such as prompting the cataloger for data in the cataloger's own language (e.g., if it is a book being cataloged, questions like What is the title on the title page?, How many pages are in the book?, Are there illustrations?, etc.). Of course there would need to be much flexibility in how this is applied, because specific questions like this would greatly aid an inexperienced cataloger, but slow down a very experienced cataloger! Right. I'd like to see that approach implemented. But writing in MARC (or something formally similar) is like writing shorthand: Once you've mastered it, nothing can beat it for speed. And speed is money in this trade. B.Eversberg
Re: [RDA-L] MARC as short hand
Mary said:
The other issue that is periodically raised is that the interface should be
sophisticated enough that just as the opac user does not need to know MARC to
search for items, so the cataloger does not need to know MARC
because they are able to enter all data--based on a template.
I find MARC to be a wonderful shorthand. If we were to have natural
language templates, the number of templates required, or the
complexity of a single template, would be staggering, e.g., What
person wrote this text, wrote this program, composed this music, wrote
this libretto, compiled this dictionary or bibliography, or was the
criminal defendant at this trial? Isn't 100 simpler?
From James example:
130 Main Entry--Uniform Title Einheitssachtitel
240 Uniform title Einheitssachtitel
240 UK Uniform title - excluding collective titles Einheitssachtitel
IMNSHO the number tag is more exact than the terminology, even though
the German is more precise and less wordy than the English.
Kevin proposed:
... such as prompting the cataloger for data in the cataloger's own
language (e.g., if it is a book being cataloged, questions like What
is the title on the title page? ...
Here the question(s) would have to be, in addition to the above, What
is the title in the title frame?, What title are you applying to
this naturally occurring realia?, etc., etc., etc. At least 75% of
our work is cataloguing resources other than books (because most books
are already catalogued). We must stop thinking in such narrow terms.
Just give me 245 please.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Re: [RDA-L] MARC as short hand
It wouldn't be natural language questions like What person wrote this
text, wrote this program, composed this music, wrote this libretto,
compiled this dictionary or bibliography, or was the criminal defendant
at this trial?
Although those maybe could be provided as hints for the un-initiated.
It would instead be RDA element names, terms of art which have
definitions in RDA.
This would be better than using 'data elements' defined by what was
intended and designed as a _transmission format_, not a data
vocabularly, but which we've been using as a data vocabulary for lack of
anything else sufficient. The problems with this are that not everyone
uses (or should have to use) the MARC transmission format -- see
Germany, for example. We want to create data that can be shared with
people who use other transmission formats. The other bigger problem with
this is simply that MARC, being designed as a transmission format NOT a
data vocabularly is just insufficient as a data vocabularly in many ways
we've discussed ad nauseum before.
(If you think ISBD was sufficient, then I'd ask why we haven't actually
been using it as such; and I'd ask if you would be happy replacing MARC
tags with ISBD data element terms. No, ISBD isn't granular enough?
Well, that's why RDA provides a new element vocabulary that is intended
to be granular enough, and to be designed as an actual data vocabularly,
not a transmission format.).
Jonathan
J. McRee Elrod wrote:
Mary said:
The other issue that is periodically raised is that the interface should be sophisticated enough that just as the opac user does not need to know MARC to search for items, so the cataloger does not need to know MARC
because they are able to enter all data--based on a template.
I find MARC to be a wonderful shorthand. If we were to have natural
language templates, the number of templates required, or the
complexity of a single template, would be staggering, e.g., What
person wrote this text, wrote this program, composed this music, wrote
this libretto, compiled this dictionary or bibliography, or was the
criminal defendant at this trial? Isn't 100 simpler?
From James example:
130 Main Entry--Uniform Title Einheitssachtitel
240 Uniform title Einheitssachtitel
240 UK Uniform title - excluding collective titles Einheitssachtitel
IMNSHO the number tag is more exact than the terminology, even though
the German is more precise and less wordy than the English.
Kevin proposed:
... such as prompting the cataloger for data in the cataloger's own
language (e.g., if it is a book being cataloged, questions like What
is the title on the title page? ...
Here the question(s) would have to be, in addition to the above, What
is the title in the title frame?, What title are you applying to
this naturally occurring realia?, etc., etc., etc. At least 75% of
our work is cataloguing resources other than books (because most books
are already catalogued). We must stop thinking in such narrow terms.
Just give me 245 please.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Re: [RDA-L] MARC as short hand
No, I did not mean ISBD Punctuation, I meant the ISBD elements, as I wrote.
So, J., why not talk in ISBD elements instead of MARC tags, to be
inter-operable with people who don't use MARC?
For better or for worse, the RDA elements are, to my mind, intended as a
replacement to the ISBD elements. I know that J. thinks this is a bad
thing. It would be interesting to find out if RDA considered basing it's
element set off of ISBD instead of FRBR. The RDA elements are meant as
an implementation of FRBR, rather than ISBD. FRBR is also an IFLA thing
though.
Jonathan
J. McRee Elrod wrote:
Jonathan said:
It would instead be RDA element names, terms of art which have
definitions in RDA.
Including computer defined as a media type, rather than a piece of
equipment? Many of the RDA definitions are circular, and some off
base.
(If you think ISBD was sufficient, then I'd ask why we haven't
actually been using it ...
By ISBD I assume you mean ISBD punctuation. We have been using
ISBD, very sucessfully.
No list of terms, be it RDA elements or ISBD areas, can be exhaustive.
That's why language neutral codes, be they MARC or RAB are better.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Re: [RDA-L] MARC as short hand
In article 49dcccd5.6080...@jhu.edu, you wrote:
So, J., why not talk in ISBD elements instead of MARC tags, to be
inter-operable with people who don't use MARC?
We find that numbers are language and script neutral, and that we can
do cross walks from MARC to any tag system a particular client may
want. Crosswalks to and from MARCxml work, but a cross walk back from
any other taging system we have experienced is more problematic.
You can put all 1XX/7XX in a single Author field, and all 6XX in a
single Subject field, the terms separated by delimiters, but you
can't reverse the process.
That's why we keep our clients' databases in MARC, and provide
replacement records when system migration time comes.
We would not wish to attempt this with the poorly and confusingly
defined RDA elements, or even ISBD elements, some of which translate
into more than one MARC field.
If it ain't broke, don't fix it.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Re: [RDA-L] MARC as short hand
In article 49dcf6f6.3060...@jhu.edu, you wrote: The thing is, it is very broke. What's not working for you? Things I've seen people say AACR2/MARC can't do, we find they do quite well. Most of the problems we see mentioned have to with the ILS, not the AACR2/MARC record. Other difficulties mentioned betray a lack of knowledge of MARC. e.g., 6XX $3 for indicating to which part of a resource a subject heading applies. Crosswalks can take care of interoperability. Mac
Re: [RDA-L] ISBD and RDA
Bernhard Eversberg wrote: Kevin M. Randall wrote: It doesn't really look much different from what everybody does in the U.S. Except for the multiparts, they *are* much different. We regard volumes as separate entities from the work as a whole, and link them, as to be seen in example 3. But I see that as a difference in method of analysis (e.g., contents notes vs. separate bibliographic records). It still exhibits the phenomenon that Jonathan talked about, where the MARC (or whatever other) format is serving the role of a data element standard for a great many catalogers. Because their work needs to be carried out using the label names in the record format (e.g., 245, 331, or 4000 for title statement), the catalogers end up actually THINKING in terms of the format that they use on a daily basis. Kevin M. Randall Principal Serials Cataloger Bibliographic Services Dept. Northwestern University Library 1970 Campus Drive Evanston, IL 60208-2300 email: k...@northwestern.edu phone: (847) 491-2939 fax: (847) 491-4345
Re: [RDA-L] ISBD and RDA
Weinheimer Jim wrote: From what I could glean from the German report sent by Stephen, (and I may be wrong), the justification for moving to AACR2/MARC2 was that by accepting AACR2 the amount of copy cataloging records would go up significantly, and by accepting MARC21 the internal processing would be simplified. Therefore, costs would ultimately go down. Completely logical and correct. Right. Except that we would have to swallow inconsistencies in our databases. There are two major types: 1. Different forms of names and titles: Of course, we don't want Munich for München in corporate names, for instance 2. Different entities: What do we consider a title change, a corporate body, a subordinate body, do we regard families as creator entities and so further. Type 1 can be solved by implementing VIAF, which is why DNB was among those who initiated the project. Type 2 had been recognized and was work in progress among the rulemakers before that infamous decision for the move toward AACR2. It would have been worked out and the resulting inconsistencies would have been tolerable. The move to MARC21 is a different story and not very relevant to cataloging since no cataloger here would have to learn MARC! We have various workform formats here, but nowhere does anyone have a catalogers' software that would have to be changed to MARC21. Its only function will be that of communication between systems. This means there was no real need to trash our old code RAK and move to AACR2. After the now infamous decision, however, out of the blue, the latter got trashed. An uneasy situation, to say the least. Cost estimates are anybody's guess. Translation of RDA and subsequent as well as supportive textual matter has to be added into it. Ultimately, yes, cost's ought to go down. Neither the timeframe nor the costs to get it all done, and how to get it done, are known right now. B.Eversberg
