Pergamon Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Importing MARC Files and Variants ======

===== Item MARC Import Process =====

MARC is a bibliographic format for transfering information about catalogue items between computer systems. It should be noted that MARC is now a very old concept, and while the 'current' format is now MARC21, the very nature of the format was designed for use with sequentially read records from //tape// drives. It is still used however, simply because so many software applications understand it and it has a comprehensive definitions of fields.

The downside of MARC's age, is that different proprietary users (e.g. book suppliers, LMS suppliers etc.) have gradualy introduced their own minor variations on how a MARC file is written, which were never designed to be or a part of the MARC standards. Many different minor variants of files may therefore be sent to you by different suppliers.

BISON tries to cope with as many of these variants as possible, with a gread deal of redundancy built in which can deal with even more unexpected modifications.

Once you have added one or more files and selected **[Load All]**, BISON moves through each file and determines how best to import them. If a file is found to be a MARC file (with a suffix of UKM, MRC etc.) that file is handed to the MARC Data Processor window.

Importing a MARC file requires three steps:

  * First, we need to **Process** the MARC file, which reads the sequential information for each book record, breaking apart each field, each of which might have many 'tags' of data attached to it. These tags are stored in a temporary manner, as it is not instantly clear what tag goes where - especially as many suppliers use different tags for the same data (an Author for example, might be in three different places!).
  * Next, we need to **Map** these fields to places we know in the Pergamon database. Some are obvious and BISON will give suggestions, while others may need you to make a local, human decision. If you regularly get your MARC files from the same source however, such as a book supplier, we can record these decisions in a **Preset**, then select that preset again in the future.
  * Finally, we can **Save** all of the book data into the database, using the mapping information to put the MARC tags in the correct places.
 
==== Process the MARC file ====

{{ :pergamonmu:bison:items_12.png?direct&200|}}This is the easy bit!

BISON already knows where the file is at this point, so all you need to do is make sure that you are on the **[Load MARC]** tab and select **[Process]**.

BISON will open and load the MARC data and after a short while you should see a long list of **RCN** (Record Control Numbers) appear in the window - these are the unique ID's of the records in the file.

{{:pergamonmu:bison:items_13.png?direct&200 |}}If the RCN's appear 'odd', such as different types of information on each line or otherwise not consistent, do not try to process the file any further. Select **[Cancel]** and contact your Support so that they can take a look at the file for you. A good set of RCNs will look like a long list of ISBN13 numbers, or at the very least be obviously **consistent on every line**.

**Note:** In computing terms, updating the screen is one of the slowest jobs that can be done. As a result, individual computers may not update the screen with each RCN as it is processed, so you will not see a streaming list building in front of you. Instead, there may be a short period of inactivity, followed by all fo the RCN's bursting onto the screen in one go. This is completely normal and dependant upon the individual workstation, and does not indicate a problem with import.

==== Mapping the Fields ====

{{ :pergamonmu:bison:items_14.png?direct&200|}}Select the **[Map Fields]** tab. At the top of this tab you will be able to select an existing Preset, modify, create and delete new presets.

The bulk of the tab contains a list of all of the unique MARC Tags that were found in your file along with the list of fields that they match in Pergamon (note that this is a composite of the entire file - any individual tag may not appear in **every** record to be imported). At the start they will all be unmapped, so begin by selecting **[Default Mapping]** from the list of available presets.

{{:pergamonmu:bison:items_15.png?direct&200 |}}Any line which has a gap in the **Pergamon** column, or where you believe that the mapping is wrong for this file, can be altered by **right-clicking** with the mouse in that field. Select the most appropriate mapping from the menu presented (an explanation of the various fields can be found at the bottom of this page).

Once you believe that your mappings are correct, use the **[Save As]** button to save those choices as a new preset for future use.

Do not worry if none of your fields seem to contain a usable HID (Accession Number) - few book suppliers provide them (unless they have also barcoded them for you at source), as they really need to be matched to your own printed barcodes. If no HID can be found in the MARC file, Pergamon will generate one for you.

**Note:** If you have pre-printed barcodes that do not fit a specific order and need to **manually** match books to barcodes, it is best to select the **batch HID** option rather than the **generate next item** system - this will allow you to edit unique book barcodes without creating books that are out-of-sequence in your wider catalogue stock.

==== Saving the new records ====

Because of the way in which MARC data must be imported and processed, saving catalogue records is performed while the raw MARC data is still available - unlike importing from a text file or xlsx, where the items can be viewed prior to finally saving them in the database.

To start the saving of records into the databse, select the **[Import]** button on the **[Map Fields]** tab.

If you opted to save the new items into a **new** package, it is here that you will be prompted for a name for the new package.

Items imported into a package, new or existing, are automatically **received** and made active within the catalogue for the purposes of circulation.

----

==== Understanding the MARC / Pergamon field mappings ====

Note that the following **technical** discussion is not required for the use of BISON and is present for background information only.

===== MARC Tags =====

The typical MARC file format actually contains more than simply 'tags', but it is really only the tags that we are interested in here because it is where the catalogue data is stored. Note that the following article is not at the higher level of a true 'library catalogue' explanation, and really relates to how MARC tags are effectively 'distilled' into a form that we can use in a live, working, everyday school or community library management system.

Once we have processed the file format of a typical MARC record, we could say that each piece of important data is represented by a 'tag' or 'code' in the form '123.4' - so in some ways, similar to a Dewey code (though in reality, it was never intended this way).

The major part (the '123') represents a type of field - such as 'Author'. The minor part (the .4), represents a possible component of that field such as 'First name', 'Second name', 'Date of Birth' etc. (In reality, the 'Author' field is actually represented by the '100.?' range of tags.)

Some MARC tags we can map directly and write straight into the Pergamon database (e.g. '250.a' is 'Edition'). Others need to be combined together to be useful (e.g. '100.a' and '100.h' are both required to construct the Author name as they represet the first and last name separately). There is also nothing to say that the fields cannot repeat (e.g. A keyword could be '650.a', v, x, y or z, and we might get many of them, repeated a number of times!).

===== Mapping to Pergamon =====

BISON views all of these data fields more from their perspective of a final meaning in the Pergamon database. The fields that BISON currently processes, in plain English and ignoring the tabs for now, are:

  * <Do Not Map>
  * Abstract
  * Audience
  * Author (Full)
  * Author (Forename)
  * Author (Surname)
  * Class / Dewey
  * Class / Dewey (Seg.Point)
  * Class / Dewey (Fic.Code)
  * Edition
  * HID (Accession No.)
  * Keyword
  * Language
  * Media
  * Personal Name (Full)
  * Personal Name (Forename)
  * Personal Name (Surname)
  * Physical Desc - Pages
  * Physical Desc - Enriching/Illustrations
  * Physical Desc - Dimensions
  * Physical Desc - Media
  * Physical Desc - Weight
  * Price
  * Publisher
  * Publisher Year
  * RCN (Record Control Number)
  * Serial (ISBN)
  * Series - Title
  * Series - Number in Series / Volume
  * Title
  * Title Statement 1
  * Title Statement 1 (Forename)
  * Title Statement 1 (Surname)
  * Title Statement 2
  * Title Statement 2 (Forename)
  * Title Statement 2 (Surname)
  * Vendor
		
Many of these fields mean effectively the same thing - in the files provided to you from your book suppliers for example, Author, Personal Name, Title Statement 1 and Title Statement 2 //almost// translate to being the same thing and might as well be regarded as such(do not take this as gospel - in practice for example, 1 and 2 usually refer to an author and an illustrator).

You may never have heard of many of these, but do not worry about it - BISON has, and knows how to intelligently combine them, take one as preference over another and even disregard some of them as redundant. All you need to do it tell BISON where to get the data from.

As a starting point, BISON's 'default' mapping assumes the following, built from processing a range of supplier files and files supplied by SLS over the last few years - this is therefore a practical, real-world mapping rather than being just theoretical:

  * 001.- - RCN
  * 008.- - Language
  * 020.a - Serial (ISBN)
  * 020.c - Price
  * 021.a - Serial (ISBN)
  * 082.a - Class / Dewey
  * 100.a - Author (Surname)
  * 100.h - Author (Forename)
  * 245.a - Title
  * 512.a - Abstract
  * 520.a - Abstract
  * 521.a - Audience
  * 082.b - Class / Dewey (Seg.Point)
  * 082.d - Class / Dewey (Fic.Code)
  * 250.a - Edition
  * 650.a - Keyword
  * 650.v - Keyword
  * 650.x - Keyword
  * 650.y - Keyword
  * 650.z - Keyword
  * 700.h - Personal Name (Forename)
  * 700.a - Personal Name (Surname)
  * 300.a - Physical Desc - Pages
  * 300.b - Physical Desc - Enriching/Illustration
  * 300.c - Physical Desc - Dimensions
  * 245.h - Physical Desc - Media
  * 300.e - Physical Desc - Media
  * 300.q - Physical Desc - Weight
  * 020.c - Price
  * 350.a - Price
  * 260,b - Publisher
  * 260.c - Publisher Year
  * 400.a - Series - Title
  * 490.a - Series - Title
  * 490.v - Series - Number in Series
  * 245.d - Title Statement 1
  * 245.e - Title Statement 2
  * 953.a - Vendor
  * 971.a - Vendor

**Note** that not all tags supported are contained within this list - this is mainly because many tags are used in different ways by different suppliers in a varied fashion, which makes their inclusion in the default mappings redundant. Your book supplier for example, or an SLS providing a resource box, might have used a tag in the 900.x range, which is quite flexible, to store their HID (Accession number, or barcode). If you encounter tags in your MARC files that have a specific meaning, select the correct mapping and save the new mappings as a local preset.


----


{{:logo.png?nolink |}}\\
[[:start|Pergamon Wiki Home]]\\
[[pergamonmu:bison:main|BISON Home]]\\
[[pergamonmu:bison:import_items|BISON Item Import]]
Pergamon Wiki

User Tools

Site Tools

Page Tools
