As has been mentioned, one of the most basic principles of Koha is flexibility: so far as it is possible, the Koha user should be able to control what Koha does and how it does it. This principle extends to Koha's handling of MARC, as seen by the fact that Koha allows you to select no MARC, MARC 21, or UNIMARC for your bibliographic data format. This means, however, that the user must give Koha very specific instructions on how to display MARC data, and how to link MARC data to Koha's database.

Biblio Frameworks allow the Koha user to define several different ways of displaying a framework for adding MARC data to Koha. You do this by specifying which MARC tags you want to use and which you want to ignore in each framework.

When Koha was installed, the installer had the option of downloading either a MARC 21 or a UNIMARC "database" (or no MARC database at all). If this was done, you now have a database table containing most of the MARC tags and subfields in current use for your preferred MARC "dialect." Now you will use the "Biblio framework" administration page to select MARC tags and tell Koha which tags you want to use in each framework.

Figure 1.24. Biblio Framework Page (as installed)

You will always have a least one framework to define, which will be the default framework. Click on "MARC structure" to begin this process. (MARC 21 tags are used in all screenshots and examples in this manual.) The screen you now see lists MARC tag numbers and some basic information about each tag.

Figure 1.25. MARC tags

The columns on this screen: contain the tag number; the name of the tag ("Lib" is an abbreviation of the French word "libellé"); whether or not the tag is repeatable (according to the rules of your chosen MARC dialect); whether or not you want the tag to be mandatory (according to your library's cataloging practice); columns for authorised values and editing subfields (both of which we will discuss elsewhere); an edit icon; and a delete icon. A pull-down menu at the top of the page allows you to switch between your biblio frameworks, and a "search" box next to it allows you to skip to a specific tag.

If you are certain that you will never use a MARC tag, then you can delete it, but since this will not result in any appreciable improvement in performance, it is probably better to leave it. There will be tags you want to add, however. (The "Add Tag" button is at the bottom of the screen and cannot be seen in the screenshot above.) If you are using older MARC tags that are not in the list of tags supplied with Koha, then use this page to add them. Similarly, you will probably need to add the holdings tag you currently use, or at least check the subfield structure of the 852 tag if you use it for holdings.

If you click on the edit icon, you will be able to change the values for each MARC tag.

Figure 1.26. Editing MARC Tags

The values that can be changed on this screen are the name of the tag as it will be displayed in the librarian's interface ("Lib for librarians"), the name of the tag as it will be displayed in the OPAC, whether or not the tag can be repeated within a MARC record, whether or not it is mandatory, and finally, a pull-down menu (initially empty) of "Authorised" values. Since this is a feature that is not commonly found in an ILS cataloging system, now is a good time to interrupt the process of defining the biblio frameworks and discuss Authorised Values.

Koha allows you to restrict the values that catalogers can place in some MARC tag indicators and MARC subfields, allowing only certain pre-defined "authorised" values. These authorised values are defined here.

Figure 1.27. Authorised Values Administration

As an example, let us assume that your Koha installation is used by several libraries, and you use MARC 21. You might want to restrict the 850a MARC subfield to the institution codes for just those libraries. In that case, you could define an authorised values category (perhaps called "INST") and enter the institution codes as the authorised values for that category. (By the way, category names are limited to eight characters.)

Once the 850a subfield is linked to the INST authorised values category in your MARC tag structure, catalogers must choose a value from the list you define here, and may not type in any other value. In other words, the catalogers could not type in the 850a field, but instead would see a pull-down menu. If the INST category was setup as it is in the screenshot above, then the pull-down menu would have two choices: "Athens County Library System" and "Nelsonville Library." Depending on which of these the cataloger chose, Koha would insert the appropriate authorised value into the MARC record -- "ONe" if the choice were "Nelsonville Library," for example.

Koha automatically sets up authorised value categories for your item types and branch codes, and you can link these authorised values to MARC subfields when you set up your MARC tag structure.

To go back to our discussion of editing MARC tags in the Biblio Frameworks, the authorised value allowed for a tag is the tag indicator pair. Many tags in MARC 21 should have both indicators set to the "undefined" character (#), so you could make an authorised values category called "indicatr" and enter an authorised value of "##" as the only entry. Then you could select the "indicatr" authorised value category when editing one of the tags that require undefined indicators. The real power of authorised values, however, is demonstrated when they are used with MARC subfields. So let's go back now to our MARC tag structure and look at the MARC subfields.

The MARC subfield structure that you define will determine how Koha behaves for your catalogers. Needless to say, it is probably a very good idea to involve them in this part of the parameterization of your Koha installation!

To edit MARC subfields, navigate to the MARC tag structure administration screen and click on the "subfields" button. In our examples, we will start by clicking on the "subfields" button associated with MARC 21 tag 100, "MAIN ENTRY--PERSONAL NAME."

Figure 1.28. Subfield structure for tag 100

As you can see most of the subfields are ignored in this particular Koha installation. Subfield 100a, however, has quite a few constraints. If we move to the bottom of this screen, we find an icon of a folder opening. Click on this icon to open the subfield editing screen to see what the possible subfield constraints are and how to change them.

Figure 1.29. Tag 100 subfields (editing)

The subfield editing screen is very busy, with a lot of features that are unique to Koha. We will examine each of these.

The screen displays all of the subfields that can be used with a tag, so it can be quite long (as in this case). Looking at the section for "Tag 100, Subfield a," we first see a group of "MARC constraints." These determine how the information in the subfield is to be used by Koha. The "repeatable" and "mandatory" checkboxes will allow catalogers to repeat a subfield, or will cause Koha to issue an error warning if the cataloger leaves a mandatory subfield empty. "Search also" is an interesting feature that allows a catalogue search to check several MARC subfields at the same time. In this example, a catalogue search for a certain author will check first for the author's name in subfield 100a of all MARC records, but will also check in 700a (in case the name is an added entry), and in 110a and 710a (in case the "author" is an organization). You could add more subfields here -- perhaps 511a, in case the "author" is actually a performer -- by typing them in the text field, enclosing each subfield identifier in single quotes and separating them with commas.

The "Koha link" constraint requires some background explanation. Koha was originally written without any provision for using MARC records, and may still be used without MARC records. This is possible because the "original" Koha keeps basic bibliographic data in database tables and fields that were designed by the original developers of Koha. Since the time when MARC capability was added to Koha, the developers have referred to these tables and fields as the "original Koha database" and called the MARC records and MARC structural data the "Koha MARC database." Many of the simple tasks and searches that a library performs in the process of checking books in and out are still more efficiently managed by the original Koha database. So as you are building your MARC structure, you must tell Koha which MARC subfield data should be automatically loaded into the original Koha database, or Koha will not work.

When you fill in the "Koha link" constraint, you choose from a pull-down list of all the tables and fields in the original Koha database, presented in the form "table.field." The table names are not that important for purposes of establishing your Koha links; the field names should be sufficient to help you decide which links are appropriate. Only one MARC subfield can be associated with an original Koha field. This means two things: 1) you must use the "Search also" constraint if you want simple searches to look in more than one MARC subfield, as we have with MARC tag 100a; and 2) most of your MARC subfields will not be linked to an original Koha field -- there are many more MARC subfields than original Koha fields.

The "Editor constraints" section mostly controls how this subfield is presented to the catalogers. The "Text for librarian" and "Text for OPAC" will be the descriptive name of this subfield in the librarian's interface and the public catalogue respectively. The "Managed in tab" constraint allows you to choose from a pull-down list with the values "ignore," numbers "0" through "9," and "items (10)." "Tab" is not the keyboard "tab" used for indenting text; in this case, "tab" refers to a tab like you would find on a manila file folder, or in a web browser that supports tabs. It allows you to subdivide the MARC tags and subfields the catalogers will be using into several browser tabs, so the cataloging web page will not be too long. Ignored subfields simply do not appear at all, while subfields "managed in tab 0" will appear in the first tab, subfields "managed in tab 1" will appear in the second tab, etc. (Numbering things beginning with "0" instead of "1" is a convention of computer programming.) For instance, you might choose to put all of the MARC subfields associated with the MARC 21 number and classification tags 010 to 088 (except for the subfields you want to ignore) in tab 0, all main entry tag subfields (tags 100-130) in tab 1, etc. This will keep the cataloging web page more manageable.

The "items (10) tab" is reserved for subfields that only contain item information. The items information appears on a separate screen from the rest of the basic MARC bibliographic record in Koha, since items are managed separately from the rest of the bibliographic record; libraries routinely add or delete item information from MARC bibliographic records, as extra copies of library materials are added or removed from the collection.

Koha requires that one -- and only one -- MARC tag will be linked to the original Koha "items" table. Some of the fields in the items table are meant to hold data indicating the current status of an item, and will not be linked to the MARC record. Other important data will come from your MARC "holdings" tag: items.barcode, items.dateaccessioned, items.homebranch, items.price, and items.itemcallnumber are good examples. So whatever MARC tag you use for your holdings information (whether it be 852 or 9xx, or whatever) should be "managed in tab items (10)" -- and that should be the only MARC tag managed in that tab -- and it should be linked to the appropriate fields in the original Koha items table -- and be the only MARC tag linked to the items table. If you manage more than one MARC tag in the items tab, or link more than one MARC tag to the items table, Koha will not work.

The "hidden" and "URL" checkboxes have pretty clear on-screen explanations. If the "hidden" box is checked, the subfield will be used by Koha, but never seen by the catalogers. Instead of manually filling such a subfield, Koha will follow instructions from the "default options" to fill the subfield. The "URL" checkbox simply tells Koha that the content of this subfield should appear as an active hyperlink when the record is displayed in the catalogue.

The "Default Options" section allows you to use several unique features of Koha to fill subfields with default values. We will look closely at each of these features in the next sections. None of these options must be used -- they are truly "optional" -- but they can make some of your cataloging chores simpler. Note the warning on the screen -- you cannot choose to use more than one type of default option for a given subfield.

Once you have completed editing your subfields, you will have completed the most difficult and time-consuming part of preparing Koha for use. You are almost done!

3.3.2. Thesaurus

Koha's "thesaurus" feature is a way to use MARC authority records -- not to be confused with Koha's "authorised values" -- to make sure only standardized names, titles, etc. are used in your catalogue records. There will be much more detailed discussion of authority records in a later section ("Thesaurus Structure"); this section will provide only a basic overview of how to activate this feature.

If you wish to provide access to authority records for a given subfield -- MARC 21's 700a subfield, for instance, to make sure an author's name is available in an added entry in its approved form -- you will need to create a subfield "9" for that tag (e.g. tag 700, subfield 9) by adding it at the end of the subfield editing screen.

Figure 1.30. Adding subfield 9

Koha uses subfield 9 to store the link between a bibliographic record and an authority record. Make sure this subfield is managed in the same tab as the other managed subfields for this tag, and then click the "hidden" checkbox so it will not be displayed with the rest of the record.

Go to the subfield that will hold the value you want to standardize (e.g. 700a in MARC 21 for an author's name). For this subfield, choose an appropriate thesaurus category (that you have created in your Thesaurus Structure) from the pull-down menu -- perhaps category "PN" ("Personal Name").

Now when the catalogers are adding a record, they will see three dots (...) after the textbox of the 700a subfield. Clicking on these dots will open a pop-up window allowing the cataloger to search your authority records for a standardized version of the author's name. If the desired name is found in your authority records, it can be automatically copied into the 700a subfield. (If the desired name is not found, the cataloger can enter the name manually.)

3.3.4. Leader plugins

Beginning with version 2.2.4, Koha comes with special plugins for building Leader information for MARC records.

The Leader is a fixed field at the beginning of each MARC record that contains coded information for the processing of the record. It does not have a number, as the other MARC tags do -- it is simply the "Leader."

Koha has no need for Leader information and does not use it. However, Koha can store Leader data, and can help you build your own Leader data. Here is how:

1. When setting up your Biblio Framework, add a tag 000 and call it "Leader" (or whatever you wish to call it).

2. In this 000 tag, create a subfield "@" and name it "leader" (or something). This @ subfield will be the subfield that stores the Leader data. If you are importing MARC records directly into Koha, you can now store the Leader in this 000 tag and @ subfield.

3. If you wish Koha to help you build Leader data for MARC records you create with Koha, select the plugin marc21_leader.pl (for MARC 21) or unimarc_leader.pl (for UNICODE) for the @ subfield.

When you create (or edit) bibliographic records, clicking on the three dots following the tag 000@ field will open a pop-up window to guide you through the creation of your MARC Leader.

Figure 1.31. Leader pop-up window

Make the appropriate choices from the pull-down menus, and Koha will create the encoded Leader data and insert it into your 000@ subfield. You now have Leader data stored with your records, should you ever need it for some other application.

This page provides a simplified way to map your MARC tags and subfields to the "original" Koha database tables. This can also be done while setting the MARC tag structure, as we have seen, but it is easier to see the relationship between the MARC database and the Koha database here.

Figure 1.32. MARC to original Koha links

The pull-down menu at the top lists all the Koha tables that can receive values from the MARC records. The columns from each table are listed in the area below the pull-down menu. Do not expect to have every Koha table.column mapped to a MARC subfield. Some (such as biblionumber, biblioitemnumber, and itemnumber) are values generated by Koha and will probably be automatically mapped. Others are flags which are set in the course of normal circulation activities and will contain information that is not part of your MARC record.

This is a one-to-one mapping. In other words, a MARC tag/subfield can be mapped to one, and only one, Koha table.column. MARC data that is not mapped to a Koha table does not disappear -- it is simply not available for display on circulation screens and on some search results screens.

Once you have completed the process of setting up your default Biblio Framework (MARC structure) and have reviewed your Koha-MARC links, click on this link to activate a small program that checks for major errors in your MARC setup.

Figure 1.33. Checking MARC setup

This MARC check does not guarantee that you will like the first results of your efforts to set up your MARC displays, etc. -- it simply checks for major errors. You will probably revise your MARC setup several times before you are completely pleased with it. Be sure to run this program after every revision.

Catalogers often rely on MARC authority records to keep personal names, place names, subjects, etc. standardized across a catalogue. For example, if you have several books by the late Pope in your collection, the bibliographic records you import from other sources may have the author's name in a variety of forms: "John Paul II, Pope, 1920-2005"; or "Joannes Paulus II, Pope, 1920-2005"; or "Juan Pablo II, Pope, 1920-2005"; or "Jean Paul II, Pope, 1920-2005"; or "Johannes Paul II, Pope, 1920-2005"; or "Joann Pavel II, Pope, 1920-2005" to name some of the many possibilities. But you want all of the books to be displayed whenever a catalogue user searches for "John Paul II." To do this, you modify the bibliographic records so they conform to an authority record that specifies the "correct" form of the name as "John Paul II, Pope, 1920-2005."

Individual catalogers almost never create their own database of authority records, but instead buy or download authority records from a trusted source. These authority records have their own MARC structure, which looks somewhat like a simplified MARC bibliographic record structure. If you have access to such a database, you can setup Koha's Thesaurus Structure to allow you to retrieve values from the authority records as you create or modify your bibliographic records.

When you select "Thesaurus structure" from the Koha parameters page, you will see this screen at first:

Figure 1.34. Thesaurus administration (unchanged)

The Koha installation process offered the opportunity to install a default authority record framework for MARC 21 or UNIMARC. If this was done, you can click on the "MARC structure" button for the Default framework and see the structure that has been setup for your authority records:

Figure 1.35. Authority record structure (MARC 21)

If you are using a different flavor of MARC, you will need to define the authority record structure manually, or modify the MARC 21 or UNIMARC structure to conform to your MARC flavor. The SQL statements to create the default framework, if it was not created during the installation process, are stored in your Koha intranet directory in the sub-directory scripts/misc/sql-datas. Otherwise, you should have no need to modify any of the default framework, unless you intend to create your own authority records.

You now need to define some authority types by clicking on the "Add authority type" button at the bottom of the administration screen. As an example, we will set up an authority type to be used for personal names, using MARC 21 authority and bibliographic tags.

Figure 1.36. Personal name authority type

The "Authority type box" accepts a code for this authority type. For personal names, you could use "PN." The "Description" is the term that will appear in some pull-down menus and is purely for information -- in this case it explains what "PN" means.

The "Summary" textbox holds the list of authority record subfields which will be displayed when the cataloger accesses the authority records to look for a match for a personal name in a bibliographic record. (Displaying the entire authority record would result in a display that would be too big to be useful.) Each subfield should be enclosed in square brackets. In our example, a search of the authority records for a personal name will display the MARC 21 personal name heading tag (100), using both the subfields that hold the regular form of the name (100a) and any fuller version of the name (100q). The search will also display the "see from" tracing tag (400) and the "see also" tracing tag (500). (For personal names in UNIMARC, you might use "[200a][200b][200c] [400a][400z] [100a]") The display of the summary of the authority records in the search results list would thus contain the heading field, the "see from" tracing fields, and the "see also" tracing fields.

The "Report tag" is the authority tag from which a value will be retrieved and "reported" back to the bibliographic record when the cataloger selects an authority record from a search results list.

Our Thesaurus Structure screen now looks like this:

Figure 1.37. Thesaurus administration (modified)

You can continue to add other authority types for place names, organization names, etc. The code for every authority type you define will automatically appear in the "Thesaurus" pull-down list when you setup your Biblio Frameworks.

To follow along with our example, let us assume that you have a database of authority records, you have defined a "PN" authority type as above, and have defined a (MARC 21) Biblio Framework with a subfield "9" defined (for holding the link to an authority record) and with the "Thesaurus" value for subfields 700a, 700b, 700c, and 700d set to "PN." In your authority records database, you have the following record:

040    $b eng
100 0# $a John Paul $b II, $c Pope, $d 1920-2005
400 0# $a Joannes Paulus $b II, $c Pope, $d 1920-2005
400 0# $a Juan Pablo $b II, $c Pope, $d 1920-2005
400 0# $a Jean Paul $b II, $c Pope, $d 1920-2005
400 0# $a Johannes Paul $b II, $c Pope, $d 1920-2005
400 0# $a Joann Pavel $b II, $c Pope, $d 1920-2005
510 2# $a Catholic Church. $b Pope (1978-2005: John Paul II)
700 04 $a Juan Pablo $b II, $c Papa, $d 1920-2005 $7 aacr//spa
700 06 $a Jean Paul $b II $c pape, $d 1920-2005 $7 aacr//fre
700 04 $a Jean Paul $b II $c (Pape), $d 1920-2005 $7 ncafnor
700 04 $a Johannes Paul $c Papst, $b II $7 rak

The cataloger is working with a bibliographic record for a book written by "Joannes Paulus II, Pope, 1920-2005" and wants to add an entry to the bibliographic record with the authorized version of the name in English. The cataloger would go to the 700a subfield in the bibliographic record and click on the three dots (...) that appear after the subfield because this subfield has thesaurus access enabled. A search box pops up and the cataloger can perform a search for the name as it appears in the bibliographic record to find any matching entries in your authority records.

Figure 1.38. Authority record search

Clicking on the curved arrow in the "Get It" column will retrieve the values in the authority record and insert them into your bibliographic record. Any of your subfields which have the thesaurus option enabled will be modified with the values in the "Report tag" you set up in your Thesaurus Structure. In our example, we asked for the contents of tag 100 to be "reported," and we enabled the thesaurus option for subfields 700a, 700b, 700c, and 700d. So clicking on the arrow inserts the value from 100a into 700a, 100b into 700b, etc. Not only that, but because the 700 tag in this particular bibliographic record is now linked to this particular authority record (through subfield 9), this bibliographic record will be automatically modified if this authority record is ever modified.

Establishing an effective link between authority records and bibliographic records will require that you spend a lot of time working back and forth between your Thesaurus Structure and your Biblio Frameworks. But for libraries that have a database of authority records, the thesaurus is a very powerful cataloging tool!

(Send comments and remarks to <st.hedges AT gmail DOT com>. They will be added to this section.)