Koha 2.2 Users Guide

Setting Up Your Koha System Once the Koha software has been downloaded and installed, it is not ready to use. While a commercial ILS will generally be delivered to you ready to use, you will have spent many hours with the vendor describing your library, your data, your cataloging practices, etc., so that the vendor can configure the software and make it useful to you. (At least that is what should happen if all goes well.) In the case of Koha, there is often no vendor involved, so you should be prepared to configure Koha yourself. This can be a very long and involved process (so this chapter is by far the longest chapter in this book), but it is not technically difficult -- unless you want to do some sophisticated customizing! When Koha is first delivered to the librarian(s), the technicians that have installed it will have set it up with two web addresses: one for accessing the Online Public Access catalogue (OPAC), and one for accessing what is generally called the "Intranet." The Intranet address is the one that will be used by the librarians to get to the Koha programs they will use to manage library circulation, cataloging, etc. Often the OPAC and the Intranet addresses are almost the same, the only difference being an additional ":8080" at the end of the Intranet address. So, for example, the OPAC address might be something like "http://www.mykoha.org," while the Intranet address will be "http://www.mykoha.org:8080." Whatever the addresses may be, the first thing the librarian will do is open a web browser and type in the given web address for the Intranet. If everything is installed correctly, the librarian should see a screen inviting him/her to login to Koha. The Intranet interface is tested only with Mozilla/Firefox. It should work (partially) with Internet Explorer. The OPAC should work fine with any navigator.

Koha Intranet Login Screen As with the web addresses for connecting to Koha, the librarian should have received the Koha administrator login name and password from whomever installed the software. If no other login name was chosen, "kohaadmin" is installed by default (but there is no default password, so you must get that from the person who performed the installation). Once you have completed the login, you come to the main page of the Koha Intranet.

Koha Intranet Main Page Although it is tempting to scroll down through the list of functions and start playing with Koha, please don't -- we have work to do! Before Koha is ready to use, you need to choose "Parameters" from the list of functions and tell Koha some important things about your library. The Parameters page is one of the busiest pages in all of Koha, with a long list of system parameters that must be set before you can use Koha (followed by a list of tools). Some of them have been set in the process of installing the software, but can be changed now if necessary.

Top of the Koha Parameters Page Don't let this list overwhelm you -- we will deal with each item individually and in some detail. The process of setting parameters will take some time, however, varying from a few hours to a few days, depending on how much time you will need to think about and organize your system data. Time spent in making wise decisions at this point will be amply rewarded in time saved later. Despite the fact that the screen says, "Fill these tables in the order they appear," we are going to skip to the bottom of the list of parameters and start with "System preferences."

System Preferences This page allows you to set the system preferences that control much of the basic behavior of Koha. These preferences should be set before any other parameters. If the system preferences page (or any other page you have seen so far) is in French, that means the installer(s) have installed both the English and the French "SQL Directories" (or only the French SQL Directory). While you can change the language of much of Koha from this page, the language of the descriptions that appear on this page cannot be changed. If your descriptions are in the wrong language, ask the installers to re-install now (before you start setting parameters) and install only your preferred language SQL Directory.

System Preferences page The layout of this page is pretty simple. Three columns list the name of the preference, its current value, and a brief description of what the preference controls. The preferences grouped into tabs relating them to Koha functions: Administration, Acquisitions, the catalogue, Circulation, Members, the OPAC, and some other preferences that do not fit into the other categories. Some of these you won't need to change at all. To change a preference, click on the folder icon. Don't click on the trash icon, which deletes the preference, unless you're a Koha developer -- and even then make a backup of the systempreferences table first. There is also a button at the bottom of the page for adding more system preferences. Most libraries will have no reason to either add or delete system preferences; the only time such action would be needed would be if a library was making some major changes to the Koha code. But the Koha philosophy is to give you as many options as possible, so this screen makes it easy to add and delete preferences if necessary. The preferences (variables) and their values are stored in the systempreferences table in the Koha database. When you choose to edit a preference, there is a standardized screen that appears to allow you to make your modifications. This screen requires some explanation.

System Preference Editing Screen The upper box in this window contains a very brief description of the system preference you are editing, the preference ("Variable") name, and its current value. This is the box in which you will make your changes and save them by clicking on the "OK" button. But what is that strange lower box labeled "Koha Internal" that tells you that you probably have no reason to change anything there? That box defines the type of values that you will be allowed to enter in the "Value" area of the upper box. In the screenshot that we are using as our example, the variable is the "acquisitions" system preference and the type (as defined in the lower box) is a "choice" variable -- meaning that you will be able to select a value from a pull-down list. The values that will appear in the pull-down list are defined in the "Variable options" area of the lower box. Had the variable been of a type that allowed you to type anything you wanted in the "Value" area (such as an e-mail address or an ISBD formula), then the "Variable type" in the lower box would be "free." If you wanted a bigger area for typing (and you might for defining an ISBD formula), then you could change "free" to "Textarea" and define the size of the text area by putting the number of columns and rows in the "Variable options" area. But in most cases, you will have no need to change anything in the lower box and will simply change the "Value" in the upper box and save it by clicking "OK." Again, Koha gives you the ability to change things you will probably never need to change -- but in case you might, you can. There is no recommended order for setting the preferences, so we will look at them group by group.

Admin dateformat Choose "metric," "us," or "iso" date format: "us" = mm/dd/yyyy "metric" = dd/mm/yyyy "iso" = yyyy/mm/dd This controls how dates are displayed on the Koha screens, not how they are stored in the database (usually yyyy-mm-dd). insecure If you are planning to be the only user of your Koha installation and find the login annoying, you can set this preference to "yes" to turn security off. But in almost every other case, the best choice is "no." If you choose "yes," users do not have to login and all information is open to anyone. Obviously, if your Koha is going to be used for a regular lending library, you want to have security turned on -- just say "no."

Acquisitions acquisitions The choices are either "normal" or "simple." "Normal" sets the system to track orders and update budgeting and vendor information as you add materials to your collection. "Simple" tells Koha that you are going to add materials to the collection without tracking orders. So if you plan to use Koha to monitor your budget and your orders with vendors, leave this preference as "normal." If you already have a system for monitoring your budget and orders (or simply don't plan to do any monitoring), change this to "simple." gist The "gist" is the "GST" (Good and Sales Tax) rate. If your local tax laws require you to pay taxes on purchases from your suppliers, enter the tax rate here, expressed as a decimal number and not a percent. (In other words, if the tax rate is 6.5 percent, enter ".065".). Set to "0" if you are not required to pay tax. The "gist" preference does not apply to fees and fines you charge borrowers, so if you are required to charge tax on such fees, you will need to include the tax in the fee amounts you set in the "Item types" and "Issuing rules" parameters.

Authorities authoritysep The description reads, "The separator used in authority/thesaurus. Usually '--'." What does that mean? Basically, Koha is asking what symbol is used in your language to separate the levels of your subject headings. In English, for example, subject headings and their subdivisions are separated by "--" as in "Women--United States--Bibliography." If a different symbol is used for this purpose in your language, change the value of this variable to that symbol. A detailed explanation of how Koha handles authorities will follow in the discussion of setting up your MARC parameters.

Catalogue ISBD Koha 2.2 can display records in a format that roughly conforms to the International Standard Bibliographic Description standards. ISBD is a family of standards developed by the Section on Cataloguing of the International Federation of Library Associations and Institutions (IFLA) to standardize, as much as possible, the descriptive portion of bibliographic records produced in different countries. The standards specify the descriptive elements constituting the record, their order, and the punctuation between them. (See http://www.ifla.org/VII/s13/pubs/isbdg2004.pdf) In order to do this Koha requires that you fill this field with the proper set of instructions, or formula, for organizing your MARC tags into an ISBD-conformant display. The online help (click "Help" in the upper right corner of the System preferences screen) provides some instructions and an example of a French language display using UNIMARC tags. Libraries using MARC 21 instead of UNIMARC probably have records that already contain punctuation conforming to the Anglo-American Cataloging Rules, second edition (AACR2). A reasonably good "AACR2" display can be constructed for such libraries, too -- just put something like this in the value field for the ISBD variable:#050|<label>Call Number: </label>|{082a}{050a}{ / 050b}| #100|<label>Main Entry: </label>|{100a}{ 100b}{ 100c}{ 100d}{110a}{ 110b}{130a}| #245|<label> </label>|{245a}{ 245b}{ 245c}{ 245h}{ 246i}{ 246a}| #260||{ 250a}{ 250b}{-- 260a}{ 260b}{ 260c}| #300| <label> </label>|{300a}{ 300b}{ 300c}| #020| <label> ISBN</label>|{ 020a}{ 024a}| #440| <label> </label>|{440a}{ 440v}| #500||{\n500a}| #511||{511a, }| #520|<label> </label>|{\n520a}{ 520b}| #600| <label>Subjects: </label>|{ 600a.}| #650|<label> </label>|{\n650a }{-- 650x}{-- 650z}{-- 650y}| #651|<label> </label>|{\n651a }{-- 651x}{-- 651z}{-- 651y}| #852| <label>Held at: </label>|{\n852a}{, 852b}{, 852c}| See the related comments in the User Comments section. autoBarcode The barcode number to be assigned to items is automatically assigned (sequentially) by Koha if this is set to "yes" ("1" = "yes") and you set your MARC preference to "no.". You will not be asked for a starting number or for any preferred type of barcode if you choose "yes" -- you simply get whatever Koha gives you. For most libraries, where preprinted barcodes are attached to items as they are cataloged, this will not work. In these cases, you should choose "no" and plan on adding the barcode to the catalogue record while you are adding other item information (such as price, accession date, etc.). hide_marc This is a feature for libraries that want to use MARC records, but don't want to see "too much" MARC. For librarians unfamiliar with MARC, some of the complexities of tags and subfields can be daunting. This feature hides some of those complexities. itemcallnumber This is one system preference that you may want to set after you set your other MARC parameters. This preference holds the MARC tag/subfield that is used to calculate the itemcallnumber variable that is a new Koha feature starting with version 2.2.2. If you set this preference now, please make a note of it and keep it handy when you set your other MARC parameters. If you decide to set it after setting your other MARC parameters, don't forget to come back to it! Prior to version 2.2.2, Koha could use several MARC subfields to hold various parts of a single call number that was assigned to a group of items related to a single bibliographic record. Displaying the call number correctly often required the user to modify some of the display templates to suit their individual library's cataloging practice. The itemcallnumber feature greatly simplifies Koha's handling of call numbers in screen displays, but the previous option is still available to Koha users. Putting an itemcallnumber subfield in a MARC record holdings tag allows you to set a call number on individual items, rather than on an entire group of items related to the same bibliographic record. While MARC holdings tags (either the 852 MARC 21 tag, or a user-defined 9xx tag) often contain subfields for holding particular parts of a call number, they may not have a subfield that is set up to hold the entire call number. If you choose to use item call numbers -- for example, to place a copy of a book in one branch in the reference collection, while in another branch it is placed in the non-fiction collection -- then you must use this preference to tell Koha which subfield in your MARC holdings tag contains the entire call number. Please note that in the example given above, the issuing rules for the item in the reference collection and for the item in the non-fiction collection will be the same: issuing rules are determined by the item type, not the item call number. To assign different issuing rules to the two items, they would have to be assigned to separate bibliographic records, with differing item types for each record. There will be more discussion of item types when we come to that section of our discussion of parameters. If you are migrating MARC records that do not have the entire call number in a subfield of the holdings tag, and you want to use the itemcallnumber feature, a programmer can write a simple script to compile the parts of your call numbers and insert the newly-constructed entire call numbers into your holdings tags. See the related comment in the User Comments section. marc This preference allows you to turn MARC support on or off. Set it to "no" if you do not intend to use MARC records. marcflavour Koha not only lets you specify whether or not you will be using MARC records, it also gives you a choice of MARC "flavors" -- MARC 21 or UNIMARC. Your choice will tell Koha how to interpret your MARC records.

Circulation ReturnBeforeExpiry This preference, if set to 1, will not allow a borrower to borrow items past the expiration date of their membership. Instead, Koha will recalculate the due date to be the same as the membership expiration date. This feature is useful for schools, which may set students' expiration dates to be the same as their graduation dates. The library would want all items to be returned before the students graduate and depart. maxoutstanding This preference sets the maximum amount of outstanding charges a borrower may owe before he/she is barred from making reserve requests. The number represents units of your local currency -- for example, "5" means "$5.00," if the dollar is your local currency. Partial "units" will be rounded to the nearest whole unit. For example, 5.25 will not be stored as "5.25," but as "5" -- so keep it simple! If you want to have no limits, leave this preference set at 0. maxreserves This preference sets the maximum number of active reserves a borrower can have at any one time. noissuescharge This sets the maximum amount of outstanding charges a borrower may owe before he/she is barred from checking out items. As with maxoutstanding, the number represents units of your local currency. printcirculationslips If your library uses receipt printers to provide borrowers with a list of items they have just checked out, you should turn this option on. If set to 1, circulation "slips" are printed on a receipt printer connected (or networked) to your server. If set to 0, no slips are printed.

Members NotifyBorrowerDeparture This system preference represents a number of days. If a borrower tries to check out items, and their registration is due to expire within this number of days, then the librarian sees a warning message. For example, is a borrower's registration is due to expire on the 15th of the month and NotifyBorrowerDeparture is set to 10, then beginning on the 5th of the month the librarian will see a warning if the borrower checks out items. This is a useful feature for schools, where a student's registration often expires on the date when they are scheduled to leave the school. Compare this system preference to the ReturnBeforeExpiry preference described in the preceding section. autoMemberNum The membership number (patron card number) to be assigned to new library users is automatically assigned by Koha if this is set to "yes" ("1" = "yes"). As with the autoBarcode preference, if you choose "1" you will not be asked for a starting barcode or barcode type. For libraries that use preprinted barcodes on their library cards, this preference should be set to "0" (="no"). Both autoBarcode and autoMemberNum refer to the visible numbers that will be attached to items and borrower cards. Koha will also assign internal control numbers for items and borrowers, called itemnumber and borrowernumber, that are both used for cross-referencing data in various Koha tables. These internal control numbers are always automatically assigned by Koha. checkdigit This preference determines the type of validity checks that will be done on membership numbers (patron card numbers): none or "Katipo" style checks. In almost all cases, you will choose "none." The checkdigit function was developed for the Horowhenua Library Trust ("HLT"), the library system that commissioned Katipo Communications, Ltd. to write the first version of Koha at the end of 1999. The function checks if patron card numbers that are automatically generated (when the autoMemberNum preference is turned on) are in the correct sequence and match pre-printed barcodes purchased by HLT. Unless you are starting a new library and using the same pre-printed barcodes used by HLT, you will leave this preference set to "none."

OPAC BiblioDefaultView This preference defines how Koha will display a bibliographic record that has been retrieved from a catalogue search. The choices are "normal," "marc" or "isbd." "normal" displays the record in the standard Koha format, showing most of the basic bibliographic information. "marc" displays the entire MARC record from Koha's MARC database. "isbd" displays an ISBD formatted record. (See the "ISBD" system preference below for more information about ISBD. All of these display modes can be modified by changing the HTML templates you are using, and you also have the ability to switch between views once the record has been displayed on the screen. This preference simply sets Koha's initial behavior when displaying a record. When first setting up your Koha system, "normal" is generally the best choice. LibraryName The text of this variable will be the library name and/or message that will be shown on the main OPAC page. If you are not familiar with HTML (Hyper-Text Markup Language), you may want to find someone to help with this. You will be using simple HTML tags to format your name and message. Here, for example, is the default name and message:Koha Free Software ILS Koha : a gift, a contribution in Maori The letters and slashes enclosed by wedges (<>) are the HTML tags. All text between and will appear in italics, all text between and will be in bold face, and the ("break") tags mark the ends of lines of text. OpacPasswordChange This preference controls whether or not a borrower can change their password through the OPAC. It is particularly useful for applications that use LDAP authentication for borrowers, since Koha would have no control over the LDAP password. SubscriptionHistory This system preference sets the type of details that OPAC users will see when they search for information about your library's periodical subscriptions. The choices are "simplified" or "full." simplified The OPAC user will see the name of the periodical, the date when the library began receiving the periodical, how often the periodical is issued, and the date when the library last renewed the subscription (or the date of the last issue received, if the library no longer subscribes). This information will be followed by a list of received issues and missing issues. full The OPAC user will see the name of the periodical followed by a list of issues, showing the date of each issue, the number of each issue, and the status of each issue -- arrived, awaited, late, or missing. hidelostitems If you do not want items in your catalogue which have been tagged as "lost" to appear in the results of OPAC searches, set this preference to "Yes." If you always want all items displayed, regardless of their "lost" status, leave this value set to "No." opaclanguages This preference sets your language preference. Despite the name, this choice can control the language used for all Koha screens, not just the OPAC. All of Koha is available in either English ("en") or French ("fr"), portions have been translated into Italian ("it") and Taiwan-Chinese ("zh-TW"), and more languages are being added. The top language in your list will be tried first when Koha displays a screen of information. opaclargeimage This system preference allows you to place your own custom logo on the OPAC main page. Normally, OPAC users will see the default Koha logo:

Koha logo If you want to use your own logo, this system preference should contain the path to your .gif image file. (The size of the default logo is 310x440 pixels.) opacsmallimage As with the opaclargeimage, this preference allows you to substitute a custom logo for the default Koha logo that normally appears in the upper left corner of OPAC pages other than the main page. (The size of the default small Koha logo is 35x50 pixels.) opacstylesheet In order to be compliant with the web standards recommended by the World Wide Web Consortium, Koha makes use of cascading style sheet (CSS) files to determine many of the aspects of how a Koha screen appears. The default CSS file for the OPAC is opac.css, which can be found in the /usr/local/koha/opac/htdocs/opac-tmpl/default/en/includes directory in most Koha installations. There is also a second choice of style sheet if you set this system preference to /opac-tmpl/css/opac2.css. If you would like to use your own cascading style sheet for the OPAC, enter the complete "href" path to the file as the value of this preference. For example, the href path (or URL) to the default style sheet would be /opac-tmpl/default/en/includes/opac.css. opacthemes Koha makes use of HTML templates to build the web pages that are displayed on the screen. By modifying these templates, the user can change the way data appears on Koha's screens. There are several groups of templates that have been developed which are complete enough to qualify as OPAC "themes," providing a consistent and distinctive look and feel across many of the Koha OPAC pages. Two themes in particular -- "css" and "npl" -- provide some interesting designs for OPAC pages: css is the current OPAC theme that is installed by default. (The theme that is actually named "default" is similar, but not currently as web compliant as the css theme.) Developed primarily by Paul Poulain, it uses cascading style sheets -- hence the name "css." Unless otherwise noted, the screen shots in this manual depict the css theme. npl is a completely different theme, though it also uses cascading style sheets. This theme was developed by Owen Leonard at the Nelsonville Public Library -- hence the name "npl."

OPAC home page in "npl" theme As with opaclanguages, the first choice on your list will be tried for each page, but if there is no template for that page in your chosen theme, Koha will revert to the default theme. In most Koha installations, the templates for each theme are found under the /usr/local/koha/opac/htdocs/opac-tmpl directory. suggestion If set to 1, the Suggestions feature is activated in the OPAC. This feature allows OPAC users to suggest book purchases. When a suggestion is made in the OPAC, it is assigned the status "ASKED." A librarian then manages the suggestion and can set the status to "REJECTED" or "ORDERED." When a book is ordered and has arrived in the library, the status becomes "AVAILABLE." Suggestions that are not yet "AVAILABLE" are visible to all users of the OPAC.

Koha OPAC home page with "suggestion" parameter activated. If the "suggestion" parameter is not activated or the user is not logged in, the "View and manage suggestions" button will not appear. virtualshelves This preference turns the virtual shelves option on or off ("1" or "0"). Users who login to the OPAC can set up and manage their own "virtual bookshelves" of favorite library items if this feature is turned on. There are three types of virtual shelves: Private These shelves can only be viewed or modified by the logged-in user who created them. For example, a borrower might select titles of books in the library's catalogue that he/she wants to read someday and can add these titles to a private virtual shelf for later reference. Public Any logged-in OPAC user can view these virtual shelves, but only the shelf creator can modify the contents. This type of virtual shelf might be used by a teacher to keep a list of library items for students to read, or a library might create "bestseller" lists for the public using public virtual shelves. Free Any logged-in OPAC user can view or modify these virtual shelves. These shelves thus become a sort of "public forum." Someone might start a free virtual shelf of "best computer books," for example, and other users could then add (or delete!) items from the list.

Others delimiter When exporting statistical data for reports, Koha can produce delimited files for importing into other applications. This preference sets the default delimiter. For instance, if you want Koha to produce comma-separated value (csv) files for importing into a spreadsheet application, you would choose the "," as the default delimiter. Disable_Dictionary The Koha OPAC by default allows users to "pre-search" the catalogue for words in titles, authors names, or subjects. This feature can greatly reduce the number of inappropriate records returned by a catalogue search, but some libraries may want to disable the feature by turning this preference on. The feature is accessed through the Advanced Search and is triggered by clicking on the three dots [...] after the Title, Author, or Subject search fields.

Dictionary Search By choosing from the list of terms returned by the dictionary search, a more accurate search of the general catalogue can be accomplished. IndependantBranches If this preference is turned on, all branches are treated as independent libraries working with one common database. Any staff member (with the necessary authority) can create basic bibliographic records for the database, or issue and return any book in the database. But staff at one branch cannot add items to another branch, or add borrowers to another branch, nor can they modify items or borrowers that "belong" to another branch. The exception to this rule is that any librarians with "superlibrarian" privileges can do any of these things; they are not restricted by this system preference. This preference does not affect the display of catalogue records in the OPAC -- searches will always display results from all branches. KohaAdminEmailAddress This is the e-mail address that will receive requests from borrowers for modification of their records. When borrowers login to the OPAC and review their accounts, they may see errors in their personal details. Koha allows them to fill out a form requesting corrections to their details, and this form is then e-mailed to a library administrator for review and action. This system preference tells Koha how to address those e-mails MIME Koha can export statistical reports to spreadsheet files in either Microsoft Excel or OpenOffice format. Use this preference to determine which format Koha will use. template This preference should probably really be called "intranetthemes," because it is the counterpart of the "opacthemes" preference. This preference controls which group of templates will be used for your Intranet screens. Currently the only choices are "default" and "npl." The "css" and "vanilla" themes that are available for the OPAC are not available here, because they do not provide Intranet templates. timeout This is the Inactivity timeout period (in seconds). If a workstation is idle for longer than this period, the user will have to login again. Now that you have set all of your system preferences, it's time to return to the Parameters page and work your way through the rest of the things listed there.

- User comments - (Send comments and remarks to st.hedges AT gmail DOT com. They will be added to this section.) Posted by Joshua Allen Holm There is a minor problem with the ISBD values. The 082 entry for call number will not display when called on the #050 line. This block should fix the problem:#082|<label>Call Number: </label>|{082a}| #050|<label>Call Number: </label<|{050a}{ / 050b}| #100|<label>Main Entry: </label>|{100a}{ 100b}{ 100c}{100d}{110a}{ 110b}{130a}| #245|<label> </label>|{245a}{ 245b}{ 245c}{ 245h}{ 246i}{ 246a}| #260||{ 250a}{ 250b}{-- 260a}{ 260b}{ 260c}| #300| <label> </label>|{300a}{ 300b}{300c}| #020| <label> ISBN</label>|{ 020a}{ 024a}| #440| <label> </label>|{440a}{ 440v}| #500||{\n500a}| #511||{511a, }| #520|<label> </label>|{\n520a}{ 520b}| #600| <label>Subjects: </label>|{ 600a.}| #650|<label> </label>|{\n650a }{-- 650x}{-- 650z}{-- 650y}| #651|<label> </label>|{\n651a }{-- 651x}{-- 651z}{-- 651y}| #852| <label>Held at: </label>|{\n852a}{, 852b}{, 852c}| Anyone wishing to use these values, please note: When cutting and pasting the block above, it is very important to either remove all line breaks first or change the ISBD variable type to Textarea with the variable options 80|20 first. (Click OK after changing the variable type then click edit again to be able to paste the text into a text area). Posted by Thomas Dukleth I have seen that the postings on the koha and koha-devel lists have had very incomplete and inaccurate ISBD mappings from MARC 21 for use in the Koha ISBD System Preference. Here is a coded mapping for ISBD for MARC 21. The mapping that I have used follows the IFLA ISBD rules as closely as can reasonably be managed in the current Koha implementation with modest exception for some minor concessions to readability usage in Koha. Main author form is implemented appended before the first ISBD section which can be appropriate for a main author form. Subject headings have been separated by newlines for readability. It would be easy for the user to correct those issues. The initial main author may be removed. The newlines before 6XX $a may be replaced by a blank space. There are some punctuation and other issues remaining but they do not seem consistently resolvable without some major corrections to Koha functionality that would not happen before Koha 3.0. Some ISBD section closing punctuation might be improved with further experimentation. I have not thoroughly proofread my work but it seems to show no intrinsic problems to the extent that I have tested it. #100||{ 100a }{ 100b }{ 100c }{ 100d }{ 110a }{ 110b }{ 110c }{ 110d }{ 110e }{ 110f }{ 110g }{ 130a }{ 130d }{ 130f }{ 130g }{ 130h }{ 130k }{ 130l }{ 130m }{ 130n }{ 130o }{ 130p }{ 130r }{ 130s }{ 130t }| #245||{ 245a }{ 245b }{245f }{ 245g }{ 245k }{ 245n }{ 245p }{ 245s }{ 245h }| #246||{ : 246i }{ 246a }{ 246b }{ 246f }{ 246g }{ 246n }{ 246p }{ 246h }| #242||{ = 242a }{ 242b }{ 242n }{ 242p }{ 242h }| #245||{ 245c }| #242||{ = 242c }| #250| - |{ 250a }{ 250b }| #254|, |{ 254a }| #255|, |{ 255a }{ 255b }{ 255c }{ 255d }{ 255e }{ 255f }{ 255g }| #256|, |{ 256a }| #257|, |{ 257a }| #258|, |{ 258a }{ 258b }| #260| - |{ 260a }{ 260b }{ 260c }| #300| - |{ 300a }{ 300b }{ 300c }{ 300d }{ 300e }{ 300f }{ 300g }| #306| - |{ 306a }| #307| - |{ 307a }{ 307b }| #310| - |{ 310a }{ 310b }| #321| - |{ 321a }{ 321b }| #340| - |{ 3403 }{ 340a }{ 340b }{ 340c }{ 340d }{ 340e }{ 340f }{ 340h }{ 340i }| #342| - |{ 342a }{ 342b }{ 342c }{ 342d }{ 342e }{ 342f }{ 342g }{ 342h }{ 342i }{ 342j }{ 342k }{ 342l }{ 342m }{ 342n }{ 342o }{ 342p }{ 342q }{ 342r }{ 342s }{ 342t }{ 342u }{ 342v }{ 342w }| #343| - |{ 343a }{ 343b }{ 343c }{ 343d }{ 343e }{ 343f }{ 343g }{ 343h }{ 343i }| #351| - |{ 3513 }{ 351a }{ 351b }{ 351c }| #352| - |{ 352a }{ 352b }{ 352c }{ 352d }{ 352e }{ 352f }{ 352g }{ 352i }{ 352q }| #362| - |{ 362a }{ 351z }| #440| - |{ 440a }{ 440n }{ 440p }{ 440v }{ 440x }|. #490| - |{ 490a }{ 490v }{ 490x }|. #800| - |{ 800a }{ 800b }{ 800c }{ 800d }{ 800e }{ 800f }{ 800g }{ 800h }{ 800j }{ 800k }{ 800l }{ 800m }{ 800n }{ 800o }{ 800p }{ 800q }{ 800r }{ 800s }{ 800t }{ 800u }{ 800v }|. #810| - |{ 810a }{ 810b }{ 810c }{ 810d }{ 810e }{ 810f }{ 810g }{ 810h }{ 810k }{ 810l }{ 810m }{ 810n }{ 810o }{ 810p }{ 810r }{ 810s }{ 810t }{ 810u }{ 810v }|. #811| - |{ 811a }{ 811c }{ 811d }{ 811e }{ 811f }{ 811g }{ 811h }{ 811k }{ 811l }{ 811n }{ 811p }{ 811q }{ 811s }{ 811t }{ 811u }{ 811v }|. #830| - |{ 830a }{ 830d }{ 830f }{ 830g }{ 830h }{ 830k }{ 830l }{ 830m }{ 830n }{ 830o }{ 830p }{ 830r }{ 830s }{ 830t }{ 830v }|. #500| |{ 5003 }{ 500a }| #501| |{ 501a }| #502| |{ 502a }| #504| |{ 504a }| #505| |{ 505a }{ 505t }{ 505r }{ 505g }{ 505u }| #506| |{ 5063 }{ 506a }{ 506b }{ 506c }{ 506d }{ 506u }| #507| |{ 507a }{ 507b }| #508| |{ 508a }{ 508a }| #510| |{ 5103 }{ 510a }{ 510x }{ 510c }{ 510b }| #511| |{ 511a }| #513| |{ 513a }{513b }| #514| |{ 514z }{ 514a }{ 514b }{ 514c }{ 514d }{ 514e }{ 514f }{ 514g }{ 514h }{ 514i }{ 514j }{ 514k }{ 514m }{ 514u }| #515| |{ 515a }| #516| |{ 516a }| #518| |{ 5183 }{ 518a }| #520| |{ 5203 }{ 520a }{ 520b }{ 520u }| #521| |{ 5213 }{ 521a }{ 521b }| #522| |{ 522a }| #524| |{ 524a }| #525| |{ 525a }| #526| |{\n510i }{\n510a }{ 510b }{ 510c }{ 510d }{\n510x }| #530| |{\n5063 }{\n506a }{ 506b }{ 506c }{ 506d }{\n506u }| #533| |{\n5333 }{\n533a }{\n533b }{\n533c }{\n533d }{\n533e }{\n533f }{\n533m }{\n533n }| #534| |{\n533p }{\n533a }{\n533b }{\n533c }{\n533d }{\n533e }{\n533f }{\n533m }{\n533n }{\n533t }{\n533x }{\n533z }| #535| |{\n5353 }{\n535a }{\n535b }{\n535c }{\n535d }| #538| |{\n5383 }{\n538a }{\n538i }{\n538u }| #540| |{\n5403 }{\n540a }{ 540b }{ 540c }{ 540d }{\n520u }| #544| |{\n5443 }{\n544a }{\n544b }{\n544c }{\n544d }{\n544e }{\n544n }| #545| |{\n545a }{ 545b }{\n545u }| #546| |{\n5463 }{\n546a }{ 546b }| #547| |{\n547a }| #550| |{ 550a }| #552| |{ 552z }{ 552a }{ 552b }{ 552c }{ 552d }{ 552e }{ 552f }{ 552g }{ 552h }{ 552i }{ 552j }{ 552k }{ 552l }{ 552m }{ 552n }{ 562o }{ 552p }{ 552u }| #555| |{ 5553 }{ 555a }{ 555b }{ 555c }{ 555d }{ 555u }| #556| |{ 556a }{ 506z }| #563| |{ 5633 }{ 563a }{ 563u }| #565| |{ 5653 }{ 565a }{ 565b }{ 565c }{ 565d }{ 565e }| #567| |{ 567a }| #580| |{ 580a }| #581| |{ 5633 }{ 581a }{ 581z }| #584| |{ 5843 }{ 584a }{ 584b }| #585| |{ 5853 }{ 585a }| #586| |{ 5863 }{ 586a }| #020| <label>ISBN: </label>|{ 020a }{ 020c }| #022| <label>ISSN: </label>|{ 022a }| #222| = |{ 222a }{ 222b }| #210| = |{ 210a }{ 210b }| #024| <label>Standard No.: </label>|{ 024a }{ 024c }{ 024d }{ 0242 }| #027| <label>Standard Tech. Report. No.: </label>|{ 027a }| #028| <label>Publisher. No.: </label>|{ 028a }{ 028b }| #013| <label>Patent No.: </label>|{ 013a }{ 013b }{ 013c }{ 013d }{ 013e }{ 013f }| #030| <label>CODEN: </label>|{ 030a }| #037| <label>Source: </label>|{ 037a }{ 037b }{ 037c }{ 037f }{ 037g }{ 037n }| #010| <label>LCCN: </label>|{ 010a }| #015| <label>Nat. Bib. No.: </label>|{ 015a }{ 0152 }| #016| <label>Nat. Bib. Agency Control No.: </label>|{ 016a }{ 0162 }| #600| <label>Subjects--Personal Names: </label>|{\n6003 }{\n600a}{ 600b }{ 600c }{ 600d }{ 600e }{ 600f }{ 600g }{ 600h }{--600k}{ 600l }{ 600m }{ 600n }{ 600o }{--600p}{ 600r }{ 600s }{ 600t }{ 600u }{--600x}{--600z}{--600y}{--600v}| #610| <label>Subjects--Corporate Names: </label>|{\n6103 }{\n610a}{ 610b }{ 610c }{ 610d }{ 610e }{ 610f }{ 610g }{ 610h }{--610k}{ 610l }{ 610m }{ 610n }{ 610o }{--610p}{ 610r }{ 610s }{ 610t }{ 610u }{--610x}{--610z}{--610y}{--610v}| #611| <label>Subjects--Meeting Names: </label>|{\n6113 }{\n611a}{ 611b }{ 611c }{ 611d }{ 611e }{ 611f }{ 611g }{ 611h }{--611k}{ 611l }{ 611m }{ 611n }{ 611o }{--611p}{ 611r }{ 611s }{ 611t }{ 611u }{--611x}{--611z}{--611y}{--611v}| #630| <label>Subjects--Uniform Titles: </label>|{\n630a}{ 630b }{ 630c }{ 630d }{ 630e }{ 630f }{ 630g }{ 630h }{--630k }{ 630l }{ 630m }{ 630n }{ 630o }{--630p}{ 630r }{ 630s }{ 630t }{--630x}{--630z}{--630y}{--630v}| #648| <label>Subjects--Chronological Terms: </label>|{\n6483 }{\n648a }{--648x}{--648z}{--648y}{--648v}| #650| <label>Subjects--Topical Terms: </label>|{\n6503 }{\n650a}{ 650b }{ 650c }{ 650d }{ 650e }{--650x}{--650z}{--650y}{--650v}| #651| <label>Subjects--Geographic Terms: </label>|{\n6513 }{\n651a}{ 651b }{ 651c }{ 651d }{ 651e }{--651x}{--651z}{--651y}{--651v}| #653| <label>Subjects--Index Terms: </label>|{ 653a }| #654| <label>Subjects--Facted Index Terms: </label>|{\n6543 }{\n654a}{--654b}{--654x}{--654z}{--654y}{--654v}| #655| <label>Index Terms--Genre/Form: </label>|{\n6553 }{\n655a}{--655b}{--655x }{--655z}{--655y}{--655v}| #656| <label>Index Terms--Occupation: </label>|{\n6563 }{\n656a}{--656k}{--656x}{--656z}{--656y}{--656v}| #657| <label>Index Terms--Function: </label>|{\n6573 }{\n657a}{--657x}{--657z}{--657y}{--657v}| #658| <label>Index Terms--Curriculum Objective: </label>|{\n658a}{--658b}{--658c}{--658d}{--658v}| #050| <label>LC Class. No.: </label>|{ 050a }{ / 050b }| #082| <label>Dewey Class. No.: </label>|{ 082a }{ / 082b }| #080| <label>Universal Decimal Class. No.: </label>|{ 080a }{ 080x }{ / 080b }| #070| <label>National Agricultural Library Call No.: </label>|{ 070a }{ / 070b }| #060| <label>National Library of Medicine Call No.: </label>|{ 060a }{ / 060b }| #074| <label>GPO Item No.: </label>|{ 074a }| #086| <label>Gov. Doc. Class. No.: </label>|{ 086a }| #088| <label>Report. No.: </label>|{ 088a }| Posted by Paul Poulain Let me explain itemcallnumber. To define a "book", you need two different things: its classification => meaning what the book is related to. Many libraries use Dewey, but not all. Many use LCCN (not in France), or another classification (for example : AMS for mathematical libraries). its physical location in the shelves => the "call number". The difficulty here is that most libraries, and they are right, have call numbered their "books" like they have classified them. So, classification = callnumber. But that's not the same concept: a single book (= 1 callnumber) can have X classifications in some cases (= some subjects) X books can have the same callnumber, or different call numbers, even if they have a single classification (=when the library has a callnumber not 100% related to classification) That's why I introduced itemcallnumber in Koha 2.2 branch. We need a CLASSIFICATION at the biblio level and a CALL NUMBER at the item level! Usually they contain the same information, that's why there is a systempreference where you can say "OK, computer, automatically report subfield XXXy from biblio into item when adding an item."

Setting Operating Parameters Koha allows you to set various parameters to suit your library's needs. Some of these -- most notably the item types -- must be set before Koha can function. Others may be set later as needed for your particular library. We'll start with the parameters which control the operating environment of the library. In the next section, we'll deal with setting the parameters of your bibliographic data (which can be a very complex process).

Library Branches This parameter tells Koha about your library's public service outlets. Even if you have only one outlet, you need to give Koha some information about it. You may find that some information about your primary outlet already exists, since the installation script gives the installing technician the option of setting some basic information as part of the installation process. That information can now be changed or refined, if necessary. Begin by defining your branch categories. If, for example, you have one main library and several branch libraries, you might set up an "MAIN" (Main) category and a "BR" (Branch) category, with descriptions "Main library" and "Branch library."

Adding branch categories Now add the names and addresses, phone numbers, etc of your libraries in the "Branches" section. (All of your libraries should be described here, not just the branch libraries.) Give each library a unique and easily-remembered code (maximum of four characters). This code will be used in Koha's database to identify each library. When libraries are listed in Koha, they will be listed in alphabetical order by code. Until you set your branch the first time you use a computer to circulate items in Koha, the branch will default to the first library in the alphabetical code list -- be careful to set the branch the first time you use Koha or whenever you add a new computer! After you set the branch the first time, a cookie is stored on that computer so you will not need to set it again.

Adding branch descriptions Some libraries have also set up "virtual" branches with names like "At bindery" or "In storage" to make it easier to pinpoint the location of items that are temporarily not available. If you are going to do this, remember that these virtual branches will appear in the OPAC just as if they were real branches, and you will need to set your issuing rules for these branches accordingly. As you add branch categories and branches, the list on your "Branches" screen will grow. Make sure that each branch is assigned to a defined branch category, and you should be ready to go on to the next step.

Branches

Printers If you are going to be using a printer (or several printers) that is attached to your Koha server for producing statistical and operations reports, then you need to give each printer a name and tell Koha how to access it. You do this by telling Koha which print queue to use. In Linux, each printer configuration in your printcap file defines a print queue. The default print queue is "lp," but if you use more than one printer you will have other queues, probably with names like "text" or "postscript." Tell Koha which printer queue(s) you want to use for printing reports directly from the server.

Printers screen You can always print Koha screens directly to a printer attached to your workstation just by using your web browser's Print function. See the related comment in the User Comments section.

Item Types Item types are the "categories" into which your library items are divided. Defining item types must be done before Koha can function, and it should be done carefully and with a great deal of thought, because issuing rules, statistics, OPAC searches, and many other Koha functions will be based on these categories. You can define as many item types as you want. For instance, you probably want to have videocassettes in a different category from non-fiction books, and mysteries in a different category from children's picture books. If you already are using a commercial Integrated Library System, you almost certainly already have all of your materials divided up into such categories. Now you need to tell Koha what your categories are.

Adding Item Types The itemtype code is limited to four characters. This "Item type" code is rarely displayed by Koha; instead the "Description" of the type will be what users see. "Rental charge" is any amount you might charge to users for borrowing items of a certain type (like videos). "Number of renewals" specifies how many times a borrower of items of this type may renew the loan. "Not for loan" would be checked for item types such as reference materials which do not leave the library. Item types are useful for many things, and very important in controlling how Koha works. To cite just two examples: borrowers can limit their searches to items of a certain type; issuing rules are set according to item types (and borrower categories and branches). Setting up item types is one of the first things you should do after installing the Koha software.

Sample item types While some of your parameter settings may be delayed until after you have tested Koha for a while, item types are critical to the way Koha behaves and should be set early and carefully.

Borrower Categories Here is where you define the types of users of your library and how they will be handled.

Borrower category administration The borrower category administration page warns that you need a "C" (child) and "I" (institution) category. Koha will not fail if you do not have these category codes, but there are some features of Koha that expect these codes. The borrowing record of a "C," for example, will automatically be linked to the record of the child's parent. An "I" code allows the librarian to save information about the institutional borrower that is slightly different from the information saved about regular borrowers. If you do not want to have children's records attached to their parents records, and/or do not have institutional borrowers, you may ignore the warnings about these two special borrower categories.

Adding borrower categories Start by assigning a "Category Code" and a "Description" to each borrower type. The code is limited to no more than two characters and may be anything you choose. "Enrollment period" is a number indicating how many years a user's enrollment is valid. If your enrollments expire after four years, for example (as in a school?), then set this number to 4. If enrollments never expire, set this to an impossibly high number (99). "Upper Age Limit" and "Age Required" set the age parameters for this type of user. If you issue children's cards to users between the ages of 2 and 18, for example, then "Age Required" would be "2" and "Upper Age Limit" would be "18." If there is no upper age limit, set this value to 999 (the highest allowed). "Enrollment Fee" and "Reserve Fee" (if any) should be entered either as whole numbers or with six decimal places, with no currency notation (e.g. "1.250000" instead of "$1.25"). "Overdue Notice Required" lets you bypass generating overdue notices for this user type.

Issuing Rules Here is yet another important parameter to set before using Koha, since it controls many aspects related to the circulation of library materials. Item Types and Borrower Categories, however, must be defined before you can define your Issuing Rules. (Your branches should be defined, too, if your issuing rules will vary from branch to branch.) If you try to define issuing rules before item types and borrower categories are set, the grid at the bottom of the screen will be empty and you cannot proceed.

Issuing rules screen The on-screen help is pretty extensive for this parameter. The grid at the bottom of the screen contains the descriptions of all your item types (in the rows) and all of your borrower categories (in the columns), with each borrower column subdivided into boxes for issues and fines. In addition, the last row and the last column are both labeled with an asterisk. If a box in the grid is left blank, its value will be calculated based on the value in the "*" boxes, as explained in the "Default values" area of the on-screen instructions. Actually, the instructions regarding "Default values" should currently be ignored. Changes to Koha have broken the default values capability for the past few versions of Koha, including version 2.2.5. This should be corrected in the near future; meanwhile, you must be sure to fill in the values for every borrower category and every item type and every branch, or you will receive error messages when trying to issue items to borrowers. The "issue" boxes are filled with two whole numbers, separated by a comma. The first number tells Koha how many days a borrower from the corresponding category can borrow an item of the corresponding type. The second number tells Koha how many items of the corresponding type can be borrowed by a borrower from the corresponding category. In the screenshot above, an institutional borrower can borrow most items for 28 days, with an upper limit of 5 items of most types. Every other category of borrower can borrow most items for 21 days, with varying limits on the number of items of each type which may be borrowed. Koha will not accept an entry of "0,0" in these boxes, so if you want to block a certain category of borrower from borrowing a certain type of item, set one of the numbers to "1" and the other to "0." Each of the "fine" boxes in the grid contains three numbers separated by commas. Each number defines the fine, how many days overdue the item must be before the fine is assessed (and a first notice prepared), and how many days after that the fine is assessed again (and a second notice sent). For example, if you charge adults 1 dollar (or Euro, or whatever currency) for overdue videos after three days and add another dollar charge after another five days, put "1,3,5" in the box in the grid that aligns with "Adult" and "Video recording." If you charge adults 25 cents for overdue fiction books after a grace period of seven days and repeat the charge seven days later, then the entry in the corresponding box in the grid would be "0.25,7,7". After the first and second notice are given, Koha prepares a "final notice" after the number of days set by the final number in the grid and sets the charge to the maximum that you set in the "noissuescharge" system preference. Fines are calculated by the fines2.pl script, located in the misc directory. If your system administrator puts this script in crontab, set to run after midnight, fines will be calculated every night. You should review this script first, however, because you may well want to customize it to handle fines differently from the default Koha behavior.

Stop Words Here you should list all of the words you wish Koha to ignore when performing catalogue searches or building the keyword index. Normally, you will not want Koha to save keyword references to articles like "The" and "A" and other very common words. Saving keyword references to these words does not help to limit a search and will make the keyword index very large and "cluttered" with words that are not really useful. The "stopwords" list defines these unnecessary words for your installation. You must define at least one stop word, or Koha searches will crash.

Simple Stop Words List for English (Note that the box beside the "OK" button is a search box for longer lists that span several screens.) If you are proficient at MySQL, it is often faster and easier to find an existing stopwords list, edit it, put it in the correct format, and use the MySQL "Load Data Infile" command to import the list into the stopwords table. Many academic libraries in the USA publish their stopwords list on the Internet, or you can ask other Koha libraries if they would share their stopwords list.

Z39.50 Servers Koha comes with Z39.50 client software for searching other libraries' MARC records; this parameter defines the Z39.50 servers you want Koha to search. In Koha version 2.x.x, the Z39.50 client will not work if Koha is installed on Windows or Mac OS X. This should change with the release of version 3.0.0. Z39.50 is an international standard for searching and retrieving information from remote databases. In practice, it provides a way for libraries to search and retrieve records from other libraries. Z39.50 client software is often provided as a component of an integrated library system; the server software is much less common. Index Data of Denmark (http://www.indexdata.dk) provides many of the software tools used for Z39.50, and also maintains a list of Z39.50 servers around the world. In this area, you can define servers for searching. Be sure the servers you choose support the MARC format you have chosen in your system preferences. To add servers, you will need to know the domain name or IP address of the server, the port number to use, and the name of the database to access. Be sure to choose servers which deliver records in the proper MARC format for your Koha installation. If you have a login name and password for Z39.50 servers that do not accept anonymous connections, Koha will save your user ID and password in addition to the other information it needs to make a connection. (For anonymous servers, leave the userid and password fields blank.)

Z39.50 Servers Setup The other fields on the form control whether or not the server is automatically searched when you request a Z39.50 search (put a "1" in the "Checked" field) and the order in which it is checked. It is a good idea to be selective in choosing servers. Defining more than five or six checked servers may slow down your Z39.50 search results.

Book Funds If you have set your "acquisitions" system preference to "normal," you now need to give Koha some information about your materials acquisition budget. (If you chose "simple" acquisitions, ignore this parameter.) "Book Funds" are accounts that you establish to keep track of your expenditures for library materials. They may be used for any kind of materials (not just books) and should match the line items in your materials budget. For instance, if your library establishes a budget line for books, another for audiovisual materials, a third line for magazines, and a fourth budget line for electronic databases, then you would have four Book Funds. The process of setting up the funds involves two steps: naming the funds, and setting the budget.

Defining Book Fund Names Each Book Fund has a unique fund code, limited to no more than five characters, that identifies it. You should decide on your fund codes (e.g. something like BOOKS, AV, MAGS, DATA for the four book funds described above) and enter the code in the "Book fund" box, then a full name in the "Name" box. If a fund is restricted to use by one branch, you may also choose that branch from a pull-down menu containing the names of all the branches you have defined. The list of branch names available for selection is not affected by the IndependantBranches systempreference. Once you have set up a fund, you will see a link to a page for setting up the fund budget. Here you will enter the beginning and ending dates of your budget period and the amount of money in that particular budget line.

Setting Book Fund Budgets Do not use any kind of currency notation (like "$") or commas when entering the budget number. (Commas will be converted to decimal points.) You may set up several budgets for each fund, if you like, each budget covering a different time period. Your dates will not be saved correctly unless you have already set your date format in the System Preferences section of the Parameters page -- DO THIS BEFORE setting budgets.

Currencies Define the currencies you deal with here. You should at least define your local currency here, giving it a name (like US DOLLAR or EURO) and setting the "rate" at 1. If you do business with vendors who charge in a different currency, enter a name for that currency (e.g. PESO) and set the approximate exchange rate compared to your currency.

Currencies Setup Note that currency names are limited to 10 characters or less. The exchange rate is used to calculate the remaining balances in your materials budgets when you purchase materials using "normal" acquisitions.

- User comments - (Send comments and remarks to st.hedges AT gmail DOT com. They will be added to this section.) Posted by Rachel Hamilton-Williams There are two sorts of printing you can do within Koha and depending on what sort of library you are running, you may not need them both. You can print anything you see on screen from your web browser like any other webpage. That just requires that your workstation (PC) has access to a printer either via your local network, or plugged directly into your PC. SO if all you want to do is print the things you see on screen then that is all the printing you need. To use this sort of printing you just go (In Windows anyway) File > Print > choose printer, and other options. If you use circulations (Loaning things), you have the option of Koha printing some files that you *Don't* see on screen. SO Koha can print slips to give to your borrowers, and it can print overdue notices. Koha prints those automatically so the SERVER (rather than your PC) also needs to know the path to send these files to a printer. That means the Printer needs to be "seen" by the server - so it has to either a network printer, OR it can be plugged directly into the server (depending I suspect on your server hardware). Either way however KOHA will need to be told the path to the printer, because you won't be doing that via a print dialogue box every time it prints. That path is what you put into the parameters option for printing. IF you DON'T circulate books/items, you won't need to setup network printing because I'm pretty sure that all the automatic printing is tied up in circulation.

Setting Bibliographic Data Parameters If you set your System Preferences to use MARC bibliographic data, the last set of parameters you need to define is by far the most complex and the most important. MARC bibliographic data is coded with markup tags in accordance with long and involved sets of rules, and each flavor of MARC has somewhat different rules. Because Koha can be used with more than one flavor of MARC, you need to spend some significant time telling Koha how to handle your particular MARC data. Koha also comes with some special MARC tools that can make your daily cataloging chores easier, but you also need to set the parameters for those tools before they can be used. All in all, there's a lot of work involved in setting the bibliographic data parameters, so be sure to allow yourself plenty of time, and consider setting these parameters with the assistance of the person(s) who will be doing your bibliographic cataloging. If you are not going to have the assistance of someone who has done MARC cataloging, then it is strongly suggested that you get familiar with the basics of MARC before you start. A good overview of MARC 21 cataloging principles can be found at http://www.loc.gov/marc/96principl.html, and a detailed discussion of MARC 21 bibliographic data tags can be found at http://www.loc.gov/marc/bibliographic/ecbdhome.html. For more information about UNIMARC, see http://www.ifla.org/VI/3/p1996-1/sec-uni.htm. This manual does not explain MARC. If you are not familiar with MARC tags, subfields, indicators, etc., most of this section of the manual will be meaningless to you. Take some time now and learn the basic principles of MARC cataloging.

Biblio Framework (MARC Structure) -- first look 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.

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.

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.

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. You can define biblio frameworks without defining any authorised values, but if you wish to make full use of Koha's features, you will probably define authorised values as part of the process of defining the biblio frameworks, moving back and forth from the Biblio Framework screens to the Authorised Values screens.

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.

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. Currently (in Koha version 2.2.3), the Authorised Values feature for tags is not functional -- it only work with MARC subfields. In some future version, this feature may be fixed, but if it proves to have only limited usefulness, it may also be dropped from Koha.

Biblio Framework (MARC Structure) -- 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."

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.

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 parenthetical "example for 200a" refers to UNIMARC tag numbers. 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. Koha currently does not use data from any MARC tags below 010, but you can define tags below 010 and use them to store data from imported MARC records. Koha can also calculate a Leader for your MARC records -- see the section on plugins for more information. See the related comments in the User Comments section. 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!

Authorised Value We have already discussed authorised values in the context of MARC tags, but their most important use is with subfields instead of tags. If you choose a category of authorised value from the pull-down list, then the only values that the catalogers can enter into this subfield will be values they choose from that category. Even if you have not defined any authorised value categories, you will have two automatic pull-down choices: "branches" and "itemtypes." You can prevent the catalogers from manually entering branch codes and item types in subfields of your holdings tag by choosing one of these authorised value categories. For example, as you are setting the structure for your holdings tag, you can set up a subfield meant to contain the branch location of an item so that it pulls an authorised value from the "branches" category. Then as catalogers are adding holdings to your catalogue, they will find a pull-down list of all your branch names in this subfield; they will only be able to choose a name from this list, and cannot type in anything else. If you also link this subfield to items.homebranch or items.holdingbranch, you will always be able to accurately track an item's location. You must use the "itemtypes" authorised values for at least one of your MARC subfields and then link that subfield to biblioitems.itemtype. You must have two subfields in your MARC holdings tag that use the "branches" authorised values, and those two subfields must be linked to items.homebranch and items.holdingbranch. (The holding branch value in the items table will change as an item is transferred from branch to branch, but it still must have an initial value set when an item is cataloged.)

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.

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.)

Plugins Plugins are small computer programs (Perl scripts, to be exact) which can be used to calculate the value of a subfield. To date, most plugins that are available as part of the Koha code deal with UNIMARC fields, but a programmer could create a custom plugin to do anything you want. For example, you might want to create a plugin that would take the MARC 21 Library of Congress Control Number (subfield 010a), add your organization code to the beginning, add a cataloger-defined character at the end, and save the result as your System Control Number (035a). A programmer could create this plugin for you, name it something like control_numbers.pl, and save it with your other Koha code. Then as you are editing your MARC 21 subfield 035a, you could choose the control_numbers.pl plugin from the pull-down list. The Koha plugins are stored in your Koha intranet/cgi-bin directory, in the subdirectory value_builder. Now (in our theoretical example) when the catalogers are adding a record, they would see three dots (...) after subfield 035a. Clicking on these dots would open a pop-up window that asks the cataloger to enter the special character to be added to the end of the LC Control Number; the plugin would then use the value already entered in 010a, your organization code, and the special character to construct the System Control Number and insert it into the subfield. The cataloger would always have the option of changing this value, or simply entering the System Control Number manually instead of using the plugin.

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: When setting up your Biblio Framework, add a tag 000 and call it "Leader" (or whatever you wish to call it). 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. 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.

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.

Link A link is somewhat like a simplified plugin. If you have two MARC subfields that will always contain the same value -- for example, the two subfields in your holdings tag that will store home branch and holding branch for a system that has only one branch -- then you can link the second subfield to the first and the value will be automatically entered into the second subfield as you enter i