STANDARD FOR UNIVERSITY OF CALIFORNIA
UNION CATALOG INPUT RECORDS 

The Standard for University of California Union Catalog Input Records defines the standards for libraries to follow when contributing records to the Melvyl (R) catalog.  The document addresses such areas as record format, required maintenance data, local data format, ftp requirements for records submitted to the catalog, and instructions for planning changes to record input streams. (The original version of this standard was approved by Library Council, September 12, 1984. The standard was subsequently revised and approved by Library Council on May 21, 1990; it was revised again and approved by the Systemwide Operations Planning and Advisory Group on December 6, 2001; another revision was done on 1/26/03 to reflect decisions approved by the Systemwide Operations Planning and Advisory Group on October 25, 2002. Last updated: 7/01/04.)  An online version of this document is located under Union Catalog Input Standards at: http://www.cdlib.org/inside/projects/melvyl/catalog_contributors.html

NOTE:  For practical reasons, CDL will continue to accept record input via the bibliographic utilities OCLC and RLIN.  For the most part, the requirements in this document are not an issue for record input from those two utilities.
 
I.	RECORD STANDARDS
 
1.	FORMAT STANDARDS
 
Users submitting records to CDL must adhere to standards for bibliographic records as outlined in the MARC21 Format for Bibliographic Data (Washington, D.C.: Network Development and MARC Standards Office, Library of Congress) and in MARC21 Format for Holdings Data (Washington, D.C.:  Network Development and MARC Standards Office, Library of Congress.)

2.	RECORD MAINTENANCE INFORMATION STANDARD
 
Maintenance is performed on records in the Melvyl catalog based on their maintenance key (unique record identification number) and their date stamp (version identification).  An incoming record can only update a record in the database with a matching record identification number and a later version identification date. 
 
2.1	 Record Identification
 
Each record must have a record identification number from the system where it was input. This number is used in the Melvyl catalog to control update transactions.  No record in the Melvyl catalog can be updated except by a record with a matching record identification number.
 
To be used for this purpose, the record identification number must have the following characteristics:
 
-	The number must be unique within the originating system.
 
If the number itself is not unique, then the record must contain other information that can be used to create a unique key.  For example, the OCLC number is unique only with the addition of the library identifier or location code.
 
-	The number should not change over the life of the record.
 
    	               If it does change, there must be a way to record the original number in the record.

-	The record must contain unambiguous information identifying the system of origin.
 
   	               This information is best conveyed as part of the identification number.
 
-	The record identification number must be in a standard field.
 
The record identification number should be communicated in the MARC 001 field.  
 
2.2	Record Identification Across Systems

Contributing libraries that move from one technical processing system to another must maintain the record identification number from the original system and any other information required to link records from the current system to the record previously input to the Melvyl catalog, or must send a snapshot. CDL will provide specifications for any system needing to use the record identification number fields.
  
2.3	Version Identification
 
Each version of a record must be identified by a date carried in the MARC 005 field.  The date must be in the ANSI standard format described in the MARC21 documentation for the 005 field. The specificity of the date depends entirely on how the system creates output files:
 
-	In a system that writes only "snapshots" of changed records, where each record can appear only once on a given file, the date portion of the field is all that needs to be filled in. Remaining positions (time of day) are zero.  The date can either be the latest update to the record, or the date of the creation of the file.
 
-	Where transactions are written at the time updates take place on the system, and a record can appear multiple times in an input file, the date field must include date and time of day of the actual record update.
 
2.4   Delete Records
 
Any record to be deleted from the union catalog must be submitted with its LEADER STATUS (MARC 05) set to the value “d”.  Because record deletion is based on record maintenance information (record identification number plus version identification) and not on the contents of the bibliographic data, the incoming delete record does not have to contain bibliographic data that is identical to the record it will delete from the database.

2.5	On-Order and In-Process Records

On-order and In-process records that may reside in the local systems of contributing libraries should not be included in Melvyl catalog input files.

3.	BIBLIOGRAPHIC FIELDS
 
All bibliographic fields, in the range 001--899, must follow the MARC21 format

       It is recommended that records contain at least the bibliographic fields required by the “Standard 
for Minimal Level MARC Bibliographic Records for University of California Libraries”, proposed by HOTS and approved by SOPAG for implementation as of January 1, 2003.  This standard describes the fields that are needed for successful merging and is located online under Union Catalog Input Standards at: http://www.cdlib.org/inside/projects/melvyl/catalog_contributors.html
	4.    LOCAL DATA FIELDS
                 
4.1  Format
 
Local data must follow MARC21, either as embedded MARC21 fields or as a separate MARC21 holdings record.  Where possible for processing into the union catalog, CDL prefers to receive embedded holdings.  MARC21 defines specific fields and subfields for the recording of location and call number information, as well as local notes, copy level information, and other processing information.  (See chart in section 4.3, which lists most of the fields and subfields used in CDL processing and display.)

4.2  Location and Call Number
 
Each incoming record must contain at least one valid location code and a corresponding call number.  

Location codes must be no more than 20 characters in length, and must be entered onto a master table of location codes at CDL before records containing those codes can be processed.  Instructions for submitting new or changed location code data to CDL can be found in the document “Instructions for Requesting Changes to the CDL Location Tables,” located online under Location Table Maintenance at http://www.cdlib.org/inside/projects/melvyl/catalog_contributors.html
 
4.3  Level of Reporting 

Reporting must be at the level that is supported by the MARC21 852 field, which is the data necessary to locate the item.  In general this is:

Data Element	MARC field	Comments	
Location (Institution level). 	852 $a		
Sublocation	852 $b		
Shelving location	852 $c		
Non-coded location qualifier	852 $g	CDL will use for RLF storage notes	
Call number classification part	852 $h		
Call number item part	852 $i		
Shelving control number	852 $j	Undifferentiated call numbers. 	
Call number prefix	852 $k		
Post call number note	852 $m		
Item – piece designation	852 $p	CDL will use for RLF numbers.	
Public note	852 $z		
Holdings	852 $3	Summary: ANSI/NISO level 3	
UC Collection Development notes	852 $D	Derived by the CDL from the input value
NOTE:  as of 10-2003, Collections Development Committee advises this is not in use.	
UC Collection Development code	852 $O	Campus supplied value
NOTE:  as of 10-2003, Collections Development Committee advises this is not in use.	

              Multiple 852s must not be sent for items at the same shelf location.

	       Summary holdings must be supplied at level 3 of the ANSI/NISO Z39.71 – 1999 standard for 
	       Holdings Statements for Bibliographic Items.  The standard states “ Level 3 provides a 
statement of summary extent of holdings which is always compressed at the highest level 
possible. The summary holdings statement may be either open or closed. This level requires 
inclusion of the Item Identification Area, the Location Data Area, the Date of Report Area and 
applicable Extent of Holdings Area data elements. If enumeration and/or chronology are 
applicable, only the highest levels (first order designators) are included. “

Summary holdings can be transmitted in an 866 $a, if the order of the 852/866 can be maintained in the record.  Alternatively, summary holdings can be transmitted in the $3 (materials specified) subfield of the 852 field.  

Example record 1:  summary holdings are included in the 852 $3

852 01  $a CU-SB $b MAIN $c SEL $h QD1 $i .C443 $z Current issues shelved in SEL Serial 
Area  $3 v.15 (1967)-v.49 (2001)

852 01  $a CU-SB $b MAIN $c MAANX $h QD1 $i .C443 $3 v.6 (1958)-v.14 (1966)

Example record 2:  summary holdings are included in ordered 866 fields (the 866 follows the 852 location to which it pertains)

852 01  $a CU-SB $b MAIN $c SEL $h QD1 $i .C443 $z Current issues shelved in SEL Serial 
Area 

866 30 $a v.15 (1967)-v.49 (2001)

852 01  $a CU-SB $b MAIN $c MAANX $h QD1 $i .C443 

866 30 $a v.6 (1958)-v.14 (1966)

4.4  Other Local Data
 
Systems often carry non-bibliographic information related to functions like circulation and acquisitions.  Before sending additional local data a contributing library will work with the CDL to determine the best way to remove the data for union catalog processing.

	5.    RELATIONSHIP OF BIBLIOGRAPHIC AND HOLDINGS RECORDS

Each contributing library should submit a single bibliographic record for each bibliographic entity (usually a title) held, with all holdings carried in that bibliographic record or in linked holdings format records.  Each update must include the bib record and ALL related holdings records.  These will be treated as a single update in the union catalog.

	6.    CHARACTER SET STANDARD  

Records must conform to the MARC21 Standard, MARC-8, or the equivalent characters in the UCS/UNICODE UTF-8 set.  This subset of UNICODE is described on the MARC Standards pages of the Library of Congress website.  

Any given file must come in one or the other of these characters sets and not a mixture of the two.

	7.    CONSISTENCY OF FORMAT  

Even though all files submitted to CDL must contain records that meet the CDL input standard, CDL understands that there will be subtle local data format differences between input sources and that these differences will sometimes result in individual pre-load conversion programs. However, CDL must be able to process all files submitted by an input source through a single pre-load conversion stream.  Therefore, a contributor may use only one local data format in records submitted for inclusion in the Melvyl Catalog.

II.	FILE AND TRANSMITTAL STANDARDS 
 
1.	TRANSMITTAL OF FILES BY FTP
 
Files must be transmitted by FTP.  

A transmittal should include a bibliographic file as well as a label file.   For each file sent to CDL, information about the file must be submitted at the same time, as described in the document “Guidelines for FTPing to CDL.” This document can be found online under FTP Instructions at   http://www.cdlib.org/inside/projects/melvyl/catalog_contributors.html

2.	RECORD SELECTION

Files of records sent to the CDL must contain only records intended for input to the union catalog.  Update transactions that do not result in changes to the catalog should not be sent.  For example, circulation, check-in, or payment transactions should not result in output to the Melvyl catalog, but update of a heading or change of location should.

3.	UPDATE METHOD

Files sent to the CDL may be either “snapshots” that contain the entire set of records to be contributed to the Melvyl catalog or may be “updates” containing only those records that have had update transactions since the previous file.  Routine updates must be done via update files.  Use of snapshots should be reserved for major projects (such as local system changes) and must be approved by CDL.  Since snapshots require special processing, details involving their use should be worked out with CDL well in advance of transmission.

4.	FILE FREQUENCY
 
Input files must be produced on a regular schedule (i.e., weekly, bi-weekly, monthly) and must not be sent any less frequently than quarterly. Anticipated schedule changes must be reported at least one update cycle in advance.

5.	BACKUP OF INPUT BY SUBMITTING LIBRARY
 
A file sent to CDL may be unreadable.  Therefore the submitting library must be able to resubmit the file, or to include the missing records as part of a later file.  Re-submittal of files must be possible up to three weeks after the original file creation date.

6.	UNANTICIPATED RECORD CHANGES FOR MELVYL CATALOG INPUT

Changes in the contributing library input are sometimes discovered during the processing of input files that affect CDL’s ability to successfully load the records. Contributing libraries will be consulted when this occurs to determine the appropriate action to be taken.   

7.	UNANTICIPATED CHANGES THAT PREVENT LOADING OF AN INPUT SOURCE

In this instance, a problem is detected at CDL which is severe enough for CDL to suspend loading of all records from a source.  A general guideline is that any input file in which over two percent of the records cannot be processed is of this severity.  

CDL will immediately discuss problems of this magnitude with the contributing library liaison.   If the problem is to be solved by CDL action, CDL management will determine a priority for the task.  While the contributing library liaison is always contacted by CDL when such problems occur, library administrators will also be notified in cases of repeated problems that jeopardize CDL’s ability to load the library’s input stream.  Written notification will first be made at the level of the Head of Technical Services and/or the Assistant University Librarian responsible for library systems.  Notification may proceed to the University Librarian/Library Director if the problem remains unresolved.  Any contributing libraries whose input is delayed due to other emergencies will also be notified by CDL

III.	STANDARDS FOR CHANGES TO CURRENT PROCESSING METHODS

	1.   CHANGES IN EXISTING SYSTEMS THAT AFFECT MELVYL CATALOG INPUT 
 
Requests for CDL programming modifications to accommodate a change in input records should be made at least three months in advance of the date the change will go into effect.  Requests should include a detailed description of the change, the expected result of the change, and the reason for the change. Each request will be reviewed by CDL using established standards to see if and when the change can be implemented.  If approved, the requesting library will be asked to submit detailed specifications and test records. 

	2.   CHANGING TO A NEW SYSTEM FOR MELVYL CATALOG INPUT

For the smoothest transition, the contributing library should consult with CDL as soon as the  timetable for implementation of a new system is being developed. A minimum of six months advance notice is required by CDL to add  the programming for a new input stream to its development schedule

The requesting library must also submit to CDL detailed specifications describing its new record format.  CDL will review the specifications and work with the library to eliminate any obvious problems.  Once specifications are agreed upon, the contributing library’s systems office or vendor should proceed with the necessary development, if any, to produce output records meeting the specifications.  During the development of output capability, test output records should be produced and reviewed by the library to verify that specifications are being met. Debugging of output programs is the responsibility of the contributing library. After the library is satisfied that the output is being produced correctly, a test file must be sent to CDL where it will be evaluated and tested by running it through the code developed by CDL from submitted specifications.  When the test file runs successfully, dates for start-up of the new input stream will be worked out jointly.
 
Record specifications must be given to CDL at least three months in advance of submitting output from the new local system.  Test records must be sent to CDL at least six weeks in advance of the switchover.