Von: Heuvelmann, Reinhold Gesendet: Dienstag, 23. November 2010 15:36 An: 'wolkanl@oclc.org' Cc: 'Fons,Theodore'; Patton,Glenn; 'Norbert.Weinberger@oclc.org'; Altenhoener, Reinhard; Polak-Bennemann, Renate; Althaus, Bernd; Feilhauer, Petra; Werner, Claudia Betreff: German National Library: MARC 21 Records for OCLC WorldCat Dear Larry, thank you for your valuable response to our MARC 21 test files, and for providing us with your summarized and detailed test results. We were glad to hear that, as you put it, "in general, things look very good" and that you believe you "should be able to use the MARC 21 files without too much additional work." Grouping your results, I would like to talk about four kinds of issues. They resemble the remarks and points from our earlier paper "Issues between German and Austrian libraries and OCLC exchanging MARC 21 data" and Glenn Patton's response, this time on a more concrete level. 1.) The first and most comprehensive category is our usage of local elements, i.e. MARC 21 fields XX9, X9X, 9XX, MARC subfields $9, and MARC indicator values "9", which (by MARC 21 design principles) are dedicated within the MARC 21 formats to transfer local or regional information with relevance. Among them are two field numbers that are used by both OCLC and us, but in totally different meanings (029 and 090). All these elements have been defined by us because there was no room for the information in the existent official MARC format, and on the other hand we need them when we convert our data into MARC. In an international environment, the data in these fields and subfields doesn't have to be retained, at least for the moment (maybe it will be of interest later on, see the description at http://www.d- nb.de/eng/standardisierung/formate/marc_dnb.htm ). So it can be filtered out when you import the data into the database. Thus, I suggest to delete or ignore all the fields with a "9" in its tag number (the one exception is 490, of course), and I suggest you to delete all subfields $9. As for the indicators, they should be set to default values (082 second Indicator "4" instead of "9", 246 Blank instead of "9"). The records themselves have to be imported when our local elements have been deleted from them and when the indicators have been standardized. 2.) A second group is formed by some official fields that are used in different ways. This is true for field 773 with only a subfield $q and/or $w. In this field we link from the record describing a part (or volume) of a publication to the publication as a whole. Leader/19 always has a "c" for "Part with dependent title" - this is an official element that was inserted into the leader by us. You can find background information in the MARBI papers at http://www.loc.gov/marc/marbi/2007/2007- dp01.html#section12 and http://www.loc.gov/marc/marbi/2007/2007- dp01.html#section25 and http://www.loc.gov/marc/marbi/2007/2007- 06.html#p5 . Again: if this doesn't work, the information can be ignored. 3.) A third group contains some elements that are not yet known by your version of the MARC format, e.g. field 365, which is a valid MARC field, see http://www.loc.gov/marc/bibliographic/bd365.html . For these issues, I suggest to include the MARC elements into your system. If this is not doable in the short run, the data may again be ignored, at least for the moment. 4.) And the fourth group is the kind of real mistakes, e.g. a missing 245 in a bibliographic record, or a missing 245 $a in a bibliographic record. I don't know exactly how your routines can handle this. If anything else fails, we can consider not importing these records. But: It would be helpful if you report them to us, so we can correct our conversion routines and have a second try. (By the way, records of Series "S" are MARC 21 Authority records taken from our German Subject Authority file, Leader Pos. 06 Type of record always contains a "z" for "Authority data", and so they are not intended to be imported into WorldCat). There may be some minor details, I haven't counter-analyzed your "Error validation reports" line by line. But for now I think we should concentrate on the major issues, in order to get things running as soon as possible. I would like to suggest we stay in close contact. Is it possible to get a response from you about the technical decisions and provisions not too far from now, maybe by the first week of December? In general and as a rule of thumb our priority is to see our data imported in WorldCat, and we think this should be of major interest to OCLC as well. We expect to establish effective workflows, for which batchloading our database as a whole will be a milestone, and a basement for synchronizing our data with WorldCat and for exchanging OCLC numbers and other data (Dewey Classification Numbers, etc). I am looking forward to our continued cooperation. Best regards Reinhold -- Reinhold Heuvelmann German National Library Information Technology / Data Formats Adickesallee 1 D-60322 Frankfurt am Main Telephone: +49-69-1525-1709 Telefax: +49-69-1525-1799 mailto:r.heuvelmann@d-nb.de http://www.d-nb.de