Submitting Updates to SUNCAT
In general terms, updating of contributing library files in SUNCAT will work in the following way. Update files will contain either new, changed and deleted serial records (our preferred method), or a complete file of all the serials records in the catalogue. Libraries that are unable to send partial file updates are welcome to send full file updates instead. Deletions in full file updates are worked out by comparing the previous file loaded with the new file; records that are in the earlier file but not in the new file have been deleted. These are then marked up for deletion and copied to the new file. Pre-processing work that was done to the library's initial full file will be done to update files. For each incoming record, the system will look to see if the local control number already exists for that contributing library. If it does, the incoming record will completely overlay the existing record. If it does not, the record will be loaded as new. If the incoming record has a deleted status then the incoming record will overlay and delete the existing record.
Updates are requested monthly, unless an alternative schedule is agreed with the SUNCAT team.
If there are any changes to the way the data is processed in your library (for example, you add new locations, use tags for different purposes, have adopted different cataloguing policies between e-journals and print journals, etc.), please inform the SUNCAT team so that we can alter our data conversion script accordingly. If we are not told, there is the danger that your data may present incorrect information in SUNCAT, or records may be rejected that should be included.
What to supply
Please return the questionnaire in the appendix with your first update file.
- Serial bibliographic records (and associated holdings) that are new or changed since the full file (or previous update).
- Information is also required on new and changed serial holdings since the full file (or previous update) was supplied – supply the entire record (bibliographic and holdings).
- As with the initial file of records exclude order records and “suppressed” records and/or holdings.
- Serial bibliographic records that have been deleted since the full file (or previous update) was supplied.
- Information is also required on deleted serial holdings since the full file (or previous update) was supplied - supply the entire record (bibliographic and holdings).
How to supply
- The method of supply is ftp, to the SUNCAT ftp server.
- At time of supply, send an email to the SUNCAT email address with a count of bibliographic records.
- If the initial file was not FTPed to SUNCAT, please inform the team of how update files will be sent.
Processing of update files
After your updates have been processed, you will be notified of any new or updated records that do not meet the SUNCAT entry standard, or which have invalid characters (from Marc8 to UTF conversion). In addition, you will be notified of any records which have an earlier system date than the existing record.
To check the date of your last update (and frequency of updates), as well as those of all our Contributing Libraries, please refer to the Updates page.
Appendix: SUNCAT Contributing Libraries Updating Questionnaire
Are you able to supply updates as requested? If not, please state what form your updates will take. Please indicate the frequency you will be supplying updates.
Have rejected records from the initial load been corrected?
Will your updates and deletions require different pre-processing to your full file? (i.e. has your library system changed, or has there been in a change in the way serial holdings are stored)
Have you changed your character encoding? (e.g., from UTF-8 to Unicode)
Are you able to supply deletions as requested?
Will deleted serial bibliographic records be indicated by Leader character position 5=d? If not, how will they be indicated?
Will you be supplying your deleted bibliographic records in the same file as new and updated records, or will they be supplied separately? (We are aware that some library systems store deletions separately.)
Does your library system "suppress" or "withdraw" bibliographic records or holdings instead of deleting them? If yes, can records or holdings which have a changed status be identified, and, how will the changed status be indicated?
Do you perform batch deletions? If yes, will these be indicated in the same way as other deleted records?
Notes for specific LMS on extracting updates
ver. 17 (as reported by Bristol): When running p_print_03 for deleted records, ensure that the question at the end of the input screen saying: "Export deleted records?" is set from the default to "Yes". The default is "No", and, in this case, no deleted records are included in the export, and blank files are produced. If the answer is "Yes", deleted records are included in the export file.