Re: MARC21 record to CIP block
On Jul 13, 2006, at 7:22 PM, [EMAIL PROTECTED] wrote: However, can anyone here tell me of any tool or tutorialof how to create a CIP block out of a MARC 21 record? It's not a CIP block, but Thom Hickey at OCLC created a sweet XSL stylesheet for turning MARCXML into something like a catalog card [1]. I used it for a little project I worked on [2]. Now, granted this isn't CIP. But I think that using XSLT in this way is a useful way to convert MARC data into a more presentable format. If you take this approach and come up with a good CIP block stylesheet please let us know :-) The catch is that you'll have to convert your MARC21 to MARCXML presumably, but there are several tools for that [3-4]. An alternative approach is to use something MARC::Record to dig around in the field/subfield structure and extract what you want. If you are more familiar with Perl than XSLT this might be amore palatable approach. There is a tutorial (such as it is) on using MARC::Record [5]. Perhaps someone on this list already has code to do this, so it was definitely worth asking. Good luck! //Ed [1] http://www.mail-archive.com/code4lib@listserv.nd.edu/msg00396.html [2] http://catalog.sanfordberman.org/record/xml/179088 [3] http://search.cpan.org/~esummers/MARC-XML-0.83/ [4] http://www.loc.gov/standards/marcxml/marcxml.zip [5] http://search.cpan.org/dist/MARC-Record/lib/MARC/Doc/Tutorial.pod
RE: MARC21 record to CIP block
I've been working on code to produce a CIP (P-CIP in my case) block from a MARC record, using a very literal translation of Visual Basic code into Perl. Currently, it should be able to produce the datablock, but does not yet insert line breaks/formatting. The module is currently tailored for QBI's PCIP, but if I have a chance, I may post some of the code to my site this weekend. Example of input and output: MARC (MARCMaker format provided for readability): =LDR 00880nam 22002898a 4500 =001 qbi02200951\ =002 006bb =003 IOrQBI\\ =005 20030103071854.0 =008 021205s2003iluabf\\\b001\0deng\d =010 \\$a 200199 =020 \\$a199649 =037 \\$a$bQBI =040 \\$aIOrQBI$cIOrQBI =999 \\$aPCIP for QBI Web pages =050 \4$aBF575.H27$bS65 2002 =082 04$a158.1$221 =100 1\$aSmith, Rob$q(Robert Bobbie Bob),$d1966- =245 14$aThe library, the phonebook, and the philosophical origins of happiness /$cby Rob Smith and Bob Jones. =250 \\$a1st ed. =263 \\$a03-- =300 \\$ap. cm. =504 \\$aIncludes bibliographical references and index. =650 \0$aHappiness. =650 \0$aLibraries$xPsychological aspects. =650 \0$aTelephone$vDirectories$xPsychological aspects. =700 1\$aJones, Bob$q(Bob Robert Rob),$d1981- becomes: Smith, Rob (Robert Bobbie Bob), 1966- The library, the phonebook, and the philosophical origins of happiness / by Rob Smith and Bob Jones. -- 1st ed. p. cm. Includes bibliographical references and index. LCCN 200199 ISBN 1-996-4-9 1. Happiness. 2. Libraries--Psychological aspects. 3. Telephone--Directories--Psychological aspects. I. Jones, Bob (Bob Robert Rob), 1981- II. Title. BF575.H27S65 2002 158.1--dc21 qbi02200951 -- Bryan Baldus [EMAIL PROTECTED] http://home.inwave.com/eija
Re: MARC21 record to CIP block
Hi, I know its not quite AACR2, but why not make your new marc record available at at suitable URL and put the address in the verso of you book so it can be downloaded by libraries that want it. Stephen On 13 Jul 2006 16:22:00 -0700, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: Hi there, I authored a book and send one copy with an LCCN number which was aquired through the PCN program to the LC. Since, they have decided upon creating a record for it. Now I'm considering changing the book slightly and so I'd like to add a text block which at least looks similar to a CIP block. However, can anyone here tell me of any tool or tutorialof how to create a CIP block out of a MARC 21 record? Sincerely, Johannes Wilm http://www.johanneswilm.org -- -- Stephen De Gabrielle
Re: MARC::* concern (Re: MARC::File::XML suggestion)
This is all fine, but lets talk in unit tests for MARC::Record if we can. They will make plain what the actual behavior is, and will let us talk about what the preferred behavior could be. Sorry to be so short, but there's only so much time in the day. //Ed On Jul 13, 2006, at 2:55 PM, Thomas Dukleth wrote: The MARC record management libraries need to allow management of the legacy records we actually have and the records that existing systems currently use. Some problems that MARC record management libraries need to manage: 1. CHARACTER VARIANCE FOR FIELD CODES. Large union catalogue systems such as RLIN and OCLC have already specified almost every numeric MARC 21 local use field for their own purposes. Canadian local use fields for equivalence or cross-reference between languages are part of the MARC 21 standard even if they are only used in Canada. RLIN itself has specified so many local use fields that they have added field codes with letters instead of only numbers to provide more local use fields for special purposes of theirs. Local system use of field codes that are not strictly numeric would seem to be a reasonable solution to the problem of too many potential reserved uses of local use fields. Such usage would allow local use fields which do not interfere with the established local use.fields of popular union catalogue systems. 1.1. NO PROBLEMS WITH RECORD MANAGEMENT MODULES? I have not observed problems with field codes containing non-numeric characters using MARC::Record or MARC::File::XML. However, I have not tested extensively and want to be certain that no problems would not arise from such usage in future. 2. CHARACTER VARIENCE FOR SUBFIELD CODES. On Thu, July 13, 2006 4:41 pm, Paul POULAIN wrote: Could it be possible to have an option that deals with invalid subfieldcodes : Whether valid or not, real systems use punctuation symbols to designate subfields so as not to interfere with standard usage. No, $9 is not always enough. Use of $% and $@ is widespread. RLIN uses $% to store the control number of a linked authority record. UNIMARC has provided $3 for the same purpose. The problem of how to match bibliographic records to authority records has been left to system designers for MARC 21. Punctuation symbols may be sufficiently numerous for some purposes but I can certainly imagine a case in a system where actually using capital letters in addition to the standard lowercase letters would be very helpful. 2.1. PROBLEMS WITH RECORD MANAGEMENT MODULES. I have not tested this but expected that at least some punctuation might be liable to be a problem for some record management modules. Paul Poulain reports this as a problem for MARC::File::XML. I believe his case had problems with $> as a subfield in addition to possibly capital letters. On Thu, July 13, 2006 4:41 pm, Paul POULAIN wrote: * die (actual behaviour) Maybe this would not be a problem for some punctuation, but I would like to be certain that it would not to be a problem for any punctuation nor for capital letters either. 3. SYSTEMS ANSWERING REAL NEEDS. Systems are designed to answer real needs in the real world. Of course, extensions to standard usage should sometimes be filtered out to facilitate maximally interoperable record exchange when exported for use outside the system for which the extensions were created. However, the recipient of an unfiltered record may not have the option of choosing a filtered record if only unfiltered records are available. The record recipient's system has to cope with available records or not use them. If system designers are adding elements to MARC, which extend the standard without conflicting with the standard; then the libraries used to manage the records must support such records. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783
Re: MARC21 record to CIP block
well, it is available from the LOC website, so I really shouldn't need to make a new one, should I? On 7/14/06, Stephen DeGabrielle <[EMAIL PROTECTED]> wrote: Hi, I know its not quite AACR2, but why not make your new marc record available at at suitable URL and put the address in the verso of you book so it can be downloaded by libraries that want it. Stephen On 13 Jul 2006 16:22:00 -0700, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: > > Hi there, > > I authored a book and send one copy with an LCCN number which was > aquired through the PCN program to the LC. Since, they have decided > upon creating a record for it. Now I'm considering changing the book > slightly and so I'd like to add a text block which at least looks > similar to a CIP block. > > However, can anyone here tell me of any tool or tutorialof how to > create a CIP block out of a MARC 21 record? > > Sincerely, > Johannes Wilm > http://www.johanneswilm.org > > -- -- Stephen De Gabrielle -- Johannes Wilm http://www.johanneswilm.org tel: +4794352594
Re: MARC::* concern (Re: MARC::File::XML suggestion)
On Fri, July 14, 2006 2:17 pm, Edward Summers wrote: > This is all fine, but lets talk in unit tests for MARC::Record if we > can. They will make plain what the actual behavior is ... I was commenting here about my concern raised by the findings of Paul Poulain. I had no test of my own showing any problem. Paul may not have a formal test himself. In due course, I will report my own very different field ordering problems with tests which may have some relation to anomalies relating to the use of letters as part of field codes. "There is only so much time in the day", and I want to think carefully about the exact behaviour or function that I would prefer to my present workarounds before posting. I also want to experiment with new functionality for accessing subfields first. In the original form I had seen Paul report a problem, the problem had seemed to be from the use of punctuation symbols for subfield codes. He described the issue as one of invalid subfield codes in his post on the perl4lib list. They may well have been invalid codes in his case for the records that he had. I wanted to be certain that it was understood that the use of characters outside the character range specified in a standards document is not necessarily an invalid use. The standards simply do not specify all that systems use and find necessary. I had no report or tests to offer for this particular problem myself. I hoped a hoped to caution against designing a presumption that some characters were invalid if Paul had correctly identified such a problem. I have no problem to report about this issue but I will report about the problem which I do have and I may find a relation for the ordering of codes. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783
