Koha 2.2 使用手冊
vii. Z39.50 伺服器
Koha 2.2 是整合式圖書館自動化系統(Integrated Library System，ILS)，採用革努通用公共許可
證(GNU General Public License, GPL)授權的自由軟體，Koha 給使用者四大自由:
1999 年，紐西蘭的 Katipo 公司替赫羅范努瓦圖書館信託(Horowhenua Library Trust，HLT)開發
此系統。其功能符合 2000 年各層級圖書館資訊系統軟硬體規範書的要求，適合臺灣地區的圖書
館使用，2007 年 10 月，已有七個單位採用此系統。
Koha 目前已經發展到 Koha 2.2.9，發展版本為 Koha 3.0，計畫管理者為 Joshua Ferraro，Liblime
Koha 支援 MARC 21 及 UNIMARC(CMARC)書目格式。
Koha 的最大優點是採用 GNU 通用公共授權，即自由軟體。不祗是軟體免費，而且可以應圖書
Apache HTTP Server、Perl 程式語言及 MySQL 資料庫的應用能力，就可以安裝使用 Koha。雖
本文的對象是圖書館員，不是電腦技術員；假設該圖書館已順利安裝 Koha, 已從其他系統將資
路係用於流通、編目、分類等事務。內定值是一樣 的，內部網路 多了「:8080」，天主教輔仁
內部網路在 Mozilla/Firefox 上做過全面的測 試，Internet Explorer 祗能使用部份的功能；線上公
(請把你的建議及想法寄給 mao aT lins dOT fju.edu.tw, 將會加到這個部份裡。)
Rachel Hamilton-Williams 的意見
表機。使用瀏覽器的檔案 > 列印 > 選擇印表機即可。
使用流通功能時，可以讓 Koha 列印螢幕看不到的檔案，如: 借書收據、逾期通知。Koha 自動
在系統偏好管理的館藏目錄裡，設定變數 marc 為 1 時，表示使用 MARC 書目資料，接下來就
要設定複雜而重要的參數。各種 MARC 有互異的規則，以欄位方式標示其內容。Koha 可以使
用多種 MARC，所以，需告知 Koha 處理特定 MARC 資料的方法。Koha 使用特別的 MARC 工
編目作業後，再來設定它們。有關 MARC 21 的背景及原則，參見
http://www.loc.gov/marc/bibliographic/ecbdhome.html，有關 UNIMARC 的事宜，參見
本使用手冊不解說 MARC，不熟悉 MARC 的欄位、分欄、指標等資料，本節的資料沒有
意義，先弄清楚 MARC 是什麼，再往下看。
1.3.1 書目架構(MARC 結構)初體驗
彈性是 Koha 的基本原則，使用者可以完全掌控 Koha。在 MARC 方面亦復如此，使用者有三個
選擇: 不用 MARC、採用 MARC 21、採用 UNIMARC(CMARC)，使用者必須精準的告訴
Koha，顯示 MARC 資料的方式、連結 MARC 資料至 Koha 資料庫的方法。
書目記錄架構允許使用者定義多種顯示架構，以新增 MARC 資料入 Koha。首先，定義 使用到
的 MARC 欄位，及忽略的欄位。
123Biblio Framework (MARC Structure) -- first look
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
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
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.
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
3.2. 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
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.
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.
3.3. 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."
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 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
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.1. 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.)
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
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.)
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
3.3.4. Leader plugins
Beginning with version 2.2.4, Koha comes with special plugins for building Leader information for
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
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
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.
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.
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 it in the first.
3.4. Koha to MARC Database Links
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.
3.5. MARC Check
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
3.6. Thesaurus Structure
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
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.
You might also consider setting up the display to give you more information, such as adding subfields
100b, 100c, and 100d to the list so you can see more information about an author. If you include all of
these subfields on the same line with your 100a subfield in the "Summary" box, they will appear on the
same line in your search display.
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
3.7. - User comments -
(Send comments and remarks to <st.hedges AT gmail DOT com>. They will be added to this section.)
Posted by Thomas Dukleth
Fixed fields and control fields without subfields can be created in the Koha MARC frameworks by
creating a field with whatever field name is needed and creating a subfield with '@' as the subfield
identifier. Koha will treat these special subfields as fields without indicators even if the record editor
shows unused blank phantom indicators. The leader is field 000 with subfield '@'. If fields 000 to 008
are missing from Koha MARC frameworks, the user can add them along with any other omissions in
the Koha framework editor in Koha System Administration.
Fields and their subfields will appear in the MARC views and the record editor if their subfields or '@'
pseudo subfields are set to managed by Koha in the MARC framework editor. To have them appear in
the detail view requires editing the templates. Subfield order will be simple alphabetic order unless you
hack Koha significantly or wait for version 3.0.
Collective field indexing can be provided for any field/subfield by providing field and subfield linking
in the search also text box in the MARC framework editor. This collective field linking is not
compliant with searching several indexes separately in accordance with the structure of the
bibliographic record, but it is much faster. Record indexing will run from a different database design in
Koha 2.2 Users Guide : Using the Power of Free and Open Source Software for Library Management /
Stephen Hedges, Joshua Ferraro and others, 2006, http://www.kohadocs.org/usersguide/
��.2GNU 通用公共許可證, 一九九一年六月 第二版,
��.3Koha Users Around the World，http://wiki.koha.org/doku.php?id=kohausers