1. Koha 使用手冊
採用革努通用公共許可證(GNU General Public License, GPL)第二版
(http://www.gnu.org/licenses/gpl.html)
��.1設定
a. 系統偏好
i. 管理
ii. 採訪
iii. 權威記錄
iv. 館藏目錄
v. 流通
vi. 讀者
vii. 線上公用目錄
viii. 其他
b. 設定作業參數
i. 分館
ii. 印表機
iii. 館藏型式
iv. 讀者類別
v. 借閱規則
vi. 停用字
vii. Z39.50 伺服器
viii. 採購預算
ix. 貨幣
x. 其他
c. 設定書目資料參數
d. 工具
e. 樣版
��.2線上公用目錄
a. 機讀編目格式書目架構 - 初體驗
3.2. Authorised Values
3.3. Biblio Framework (MARC Structure) -- subfields
3.3.1. Authorised Value
3.3.2. Thesaurus
3.3.3. Plugins
3.3.4. Leader plugins
3.3.5. Link
3.4. Koha to MARC Database Links
3.5. MARC Check
3.6. Thesaurus Structure
3.7. - User comments -
��.3流通
2. ��.4採錄及編目
��.5期刊
��.6報表
��.7定期維護
��.1資料庫結構
��.2翻譯
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 均已具備:
• 線上公用目錄檢索全部館藏
18. a. ReturnBeforeExpiry[圖書到期日在借書證有效日之前]
b. maxoutstanding[最高應付費用]
c. maxreserves[預約額度]
d. noissuescharge[拒絕借書的應付費用]
e. patronimages[讀者照片]
f. printcirculationslips[列印借書清單 ]
圖書到期日在借書證有效日之前
設定為是,則不允許圖書的到期日超過借書證有效日,Koha 重新調整到期日為有效日的最後一
天。
學校圖書館很喜歡這個偏好,學生的圖書到期日等同於借書證的有效日期;老師的圖書到期日
等同於聘書的有效日期。
最高應付費用
讀者積欠圖書館費用,達到這個額度時 ,不再幫該讀者辦理各項預約事宜,祗提供基本的服
務。此數值是整數金額,沒有小數。不管讀者積欠多少錢,仍提供同樣服務,則設定為 0。
預約額度
設定每個讀者同時可以預約的最高數量。
21. 有 26 種偏好:
a. AmazonAssocTag
b. AmazonContent
c. AmazonDevKey
d. AnonSuggestions
e. BiblioDefaultView[顯示書目格式]
f. Disable_Dictionary[字典查詢]
g. LibraryName[圖書館名稱]
h. OpacNav
i. OpacPasswordChange[密碼變更]
j. SubscriptionHistory[期刊資訊]
k. hidelostitems[隱藏遺失的館藏]
l. opacbookbag
m. opaccolorstylesheet
n. opaccredits
o. opacheader
p. opaclanguages[語言]
q. opaclanguagesdisplay
r. opaclargeimage[自訂大圖示]
s. opaclayoutstylesheet
t. opacreadinghistory
u. opacsmallimage[自訂小圖示]
v. opacstylesheet[串接樣式表]
w. opacthemes[主題]
x. opacuserlogin
y. suggestion[採訪建議]
z. virtualshelves [虛擬書架]
顯示書目格式
檢索目錄後,顯示在螢幕的格式,有三個選擇: 條列式(normal)、機讀編目格式(marc)、國
際書目著錄標準(isbd)。
條列式,顯示基本的書目資訊,Koha 的內定格式。
機讀編目格式,顯示書目資料完整的機讀編目格式。
22. 國際書目著錄標準,顯示國際圖書館協會聯盟公布的書目格式。
可修改 HTML 樣版,修改顯示的格式,已顯示的格式,也可以即時切換;初始值為條列
式。
字典查詢
Koha 的線上公用目錄允許讀者預查目錄的書名、作者、標題,以減少不正確的回應;不
過,有些圖書館寧願關閉此功能。
進入進階查詢後,點選書名、作者、標題輸入欄右邊的三個黑點,就可使用此功能
23. 圖 1.9. 字典查詢
選擇傳回來的字詞,再到館藏查詢,有助於得到更精準的結果。
圖書館名稱
顯示在線上公用目錄的圖書館名稱,也可以是其他的訊息。
可使用 HTML 語法, 內定的訊息是:
<i><b>Koha<br/>Free Software ILS<br/><br/></b>Koha : a gift, a contribution<br/> in Maori</i>
在大小括號內的是 HTML 標籤, 在 <i> 與 </i> 之間的文字是斜體字, 在 <b> 與 </b> 之間的
文字是黑體字, <br/> 表示此列結束。
密碼變更
讀者經線上公用目錄變更密碼,特別適合使用輕量型目錄存取通訊協定(LDAP)認證的環境,因
為 Koha 無權控制輕量通訊協定的密碼。
45. 圖 1.19. 英文的停用字
熟稔 MySQL 的話,可以用「Load Data Infile」指令,更快速容易的建立停用字表。很多圖書館
公開它們的停用字表,直接下載就行了。
1.2.7. Z39.50 伺服器
它的意思是「應用服務定義及協定規範」,就是可以查詢下載其他圖書館的書目資料。俗稱的
複本編目,或是「從國圖抓書目資料」。
Koha 2.x.x 安裝於 MS Windows 或 Mac OS X 時,不能使用 Z39.50 客戶端;這個 Bug 將於 3.0.0
版修訂。
46. Z39.50 係指國際標準 ISO 23950: "Information Retrieval (Z39.50): Application Service Definition
and Protocol Specification" [應用服務定義及協定規範],也是美國的國家標準 ANSI/NISO
Z39.50,在技術層面上,幾乎完全相同。臺灣的中國國家標準 CNS 13461 資訊檢索服務與協
定,指的是同一件事。目前由美國國會圖書館負責維護。
Z39.50 係查詢及檢索遠端資料庫的國際標準,實務上,圖書館透過它,查詢及檢索遠其他圖書
館的書目記錄。客戶端軟體通常是圖書館自動化系統的一部份,伺服器端軟體較少,丹麥的
Index Data 公司提供多種使用 Z39.50 的軟體工具,還有一個全球的 Z39.50 伺服器清單。臺灣的
全國圖書資訊網(nbinet.ncl.edu.tw)、國立政治大學中正圖書館(jenda.lib.nccu.edu.tw)、國立臺灣
大學圖書館(tulips.ntu.edu.tw)都在名單之列。
選擇支援 MARC 書目格式的圖書館,從 Z39.50 目錄 http://targettest.indexdata.com/ 選取使用相
同 MARC 書目格式的圖書館,通常是匿名簽入,若需帳號密碼,鍵入後,Koha 會記得它,不
需每次鍵入。
圖 1.20. Z39.50 伺服器設定
50. Rachel Hamilton-Williams 的意見
Koha 有兩種列印的方式,視圖書館的類型而定,通常祗需要其中之一。
從瀏覽器列印看到的網頁內容,就像其他的網頁,使用直接連結個人電腦的印表機,或網路印
表機。使用瀏覽器的檔案 > 列印 > 選擇印表機即可。
使用流通功能時,可以讓 Koha 列印螢幕看不到的檔案,如: 借書收據、逾期通知。Koha 自動
列印這些檔案,所以伺服器需要知道這些檔案該送到什麼印表機。
伺服器需要看到印表機,所以必須是網路印表機或直接連到伺服器的印表機;不論何種方
法,Koha 要知道印表機的路徑,不可能每次從對話盒去設定路徑。
不辦理流通業務,就不需要設定網路印表,因為所有的自動列印,都與流通有關。
3. 設定書目資料參數
在系統偏好管理的館藏目錄裡,設定變數 marc 為 1 時,表示使用 MARC 書目資料,接下來就
要設定複雜而重要的參數。各種 MARC 有互異的規則,以欄位方式標示其內容。Koha 可以使
用多種 MARC,所以,需告知 Koha 處理特定 MARC 資料的方法。Koha 使用特別的 MARC 工
具,簡化煩瑣的日常編目作業,但需先設定參數才能用它們。
設定書目資料參數很囉唆,多留些時間,在編目員的協助下設定它們,否則,就要熟稔 MARC
編目作業後,再來設定它們。有關 MARC 21 的背景及原則,參見
http://www.loc.gov/marc/96principl.html, 詳細的書目資料欄位,參見
http://www.loc.gov/marc/bibliographic/ecbdhome.html,有關 UNIMARC 的事宜,參見
http://www.ifla.org/VI/3/p1996-1/sec-uni.htm。
51. 本使用手冊不解說 MARC,應先熟悉 MARC 的欄位、分欄、指標等資料,才能閱讀本節
的資料。
1.3.1 機讀編目格式書目架構 - 初體驗
彈性是 Koha 的基本原則,使用者可以完全掌控 Koha。在 MARC 方面亦復如此,使用者有三個
選擇: 不用 MARC、採用 MARC 21、採用 UNIMARC(CMARC),使用者必須精準的告訴
Koha,顯示 MARC 資料的方式、連結 MARC 資料至 Koha 資料庫的方法。
書目記錄架構允許使用者定義多種顯示架構,以新增 MARC 資料入 Koha。首先,定義使用到
的 MARC 欄位,及忽略的欄位。
安裝的時候,可以選擇下載採用 MARC 21 或 UNIMARC(CMARC) 資料,或者不用任何 MARC
資料庫;順利安裝後,就可以使用指定的 MARC 格式,在書目架構管理頁面,選定 MARC 的
欄位,告訴 Koha 在每個架構裡,使用適當的欄位。
53. 圖 預設書目架構的欄位管理
這個畫面有六個欄位: 欄位、標籤、可重複、必要、容許值、分欄等
The columns on this screen: contain the tag number; the name of the tag ("Lib" is an abbreviation of
the French word "libellé"); whether or not the tag is repeatable (according to the rules of your chosen
MARC dialect); whether or not you want the tag to be mandatory (according to your library's
cataloging practice); columns for authorised values and editing subfields (both of which we will discuss
elsewhere); an edit icon; and a delete icon. A pull-down menu at the top of the page allows you to
switch between your biblio frameworks, and a "search" box next to it allows you to skip to a specific
tag.
If you are certain that you will never use a MARC tag, then you can delete it, but since this will not
result in any appreciable improvement in performance, it is probably better to leave it. There will be
tags you want to add, however. (The "Add Tag" button is at the bottom of the screen and cannot be
seen in the screenshot above.) If you are using older MARC tags that are not in the list of tags supplied
with Koha, then use this page to add them. Similarly, you will probably need to add the holdings tag
you currently use, or at least check the subfield structure of the 852 tag if you use it for holdings.
If you click on the edit icon, you will be able to change the values for each MARC tag.
Figure 1.26. Editing MARC Tags
54. 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.
Tip
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.
55. 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
defined here.
Figure 1.27. Authorised Values Administration
As an example, let us assume that your Koha installation is used by several libraries, and you use
MARC 21. You might want to restrict the 850a MARC subfield to the institution codes for just those
libraries. In that case, you could define an authorised values category (perhaps called "INST") and
enter the institution codes as the authorised values for that category. (By the way, category names are
limited to eight characters.)
56. 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.
Note
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
57. 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)
58. 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.
59. Note
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.
Note
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
60. are managed separately from the rest of the bibliographic record; libraries routinely add or delete item
information from MARC bibliographic records, as extra copies of library materials are added or
removed from the collection.
Koha requires that one -- and only one -- MARC tag will be linked to the original Koha "items" table.
Some of the fields in the items table are meant to hold data indicating the current status of an item, and
will not be linked to the MARC record. Other important data will come from your MARC "holdings"
tag: items.barcode, items.dateaccessioned, items.homebranch, items.price, and items.itemcallnumber
are good examples. So whatever MARC tag you use for your holdings information (whether it be 852
or 9xx, or whatever) should be "managed in tab items (10)" -- and that should be the only MARC tag
managed in that tab -- and it should be linked to the appropriate fields in the original Koha items table
-- and be the only MARC tag linked to the items table. If you manage more than one MARC tag in the
items tab, or link more than one MARC tag to the items table, Koha will not work.
The "hidden" and "URL" checkboxes have pretty clear on-screen explanations. If the "hidden" box is
checked, the subfield will be used by Koha, but never seen by the catalogers. Instead of manually
filling such a subfield, Koha will follow instructions from the "default options" to fill the subfield. The
"URL" checkbox simply tells Koha that the content of this subfield should appear as an active
hyperlink when the record is displayed in the catalogue.
The "Default Options" section allows you to use several unique features of Koha to fill subfields with
default values. We will look closely at each of these features in the next sections. None of these options
must be used -- they are truly "optional" -- but they can make some of your cataloging chores simpler.
Note the warning on the screen -- you cannot choose to use more than one type of default option for a
given subfield.
Once you have completed editing your subfields, you will have completed the most difficult and time-
consuming part of preparing Koha for use. You are almost done!
3.3.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.
61. Note
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.)
3.3.2. Thesaurus
Koha's "thesaurus" feature is a way to use MARC authority records -- not to be confused with Koha's
"authorised values" -- to make sure only standardized names, titles, etc. are used in your catalogue
records. There will be much more detailed discussion of authority records in a later section ("Thesaurus
Structure"); this section will provide only a basic overview of how to activate this feature.
If you wish to provide access to authority records for a given subfield -- MARC 21's 700a subfield, for
instance, to make sure an author's name is available in an added entry in its approved form -- you will
need to create a subfield "9" for that tag (e.g. tag 700, subfield 9) by adding it at the end of the subfield
editing screen.
Figure 1.30. Adding subfield 9
62. 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.)
63. 3.3.3. 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.
Tip
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.
3.3.4. Leader plugins
Beginning with version 2.2.4, Koha comes with special plugins for building Leader information for
MARC records.
The Leader is a fixed field at the beginning of each MARC record that contains coded information for
the processing of the record. It does not have a number, as the other MARC tags do -- it is simply the
"Leader."
Koha has no need for Leader information and does not use it. However, Koha can store Leader data,
and can help you build your own Leader data. Here is how:
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.
64. 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.
3.3.5. 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 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
65. 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.
66. 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
revision.
67. 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)
68. 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)
69. If you are using a different flavor of MARC, you will need to define the authority record structure
manually, or modify the MARC 21 or UNIMARC structure to conform to your MARC flavor. The
SQL statements to create the default framework, if it was not created during the installation process, are
stored in your Koha intranet directory in the sub-directory scripts/misc/sql-datas. Otherwise, you
should have no need to modify any of the default framework, unless you intend to create your own
authority records.
You now need to define some authority types by clicking on the "Add authority type" button at the
bottom of the administration screen. As an example, we will set up an authority type to be used for
personal names, using MARC 21 authority and bibliographic tags.
Figure 1.36. Personal name authority type
70. 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.
71. Note
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)
72. 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
73. Clicking on the curved arrow in the "Get It" column will retrieve the values in the authority record and
insert them into your bibliographic record. Any of your subfields which have the thesaurus option
enabled will be modified with the values in the "Report tag" you set up in your Thesaurus Structure. In
our example, we asked for the contents of tag 100 to be "reported," and we enabled the thesaurus
option for subfields 700a, 700b, 700c, and 700d. So clicking on the arrow inserts the value from 100a
into 700a, 100b into 700b, etc. Not only that, but because the 700 tag in this particular bibliographic
record is now linked to this particular authority record (through subfield 9), this bibliographic record
will be automatically modified if this authority record is ever modified.
Establishing an effective link between authority records and bibliographic records will require that you
spend a lot of time working back and forth between your Thesaurus Structure and your Biblio
Frameworks. But for libraries that have a database of authority records, the thesaurus is a very powerful
cataloging tool!
74. 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
version 3.0.
2. 線上公用目錄
流通
採錄及編目
期刊
報表
定期維護
資料庫結構
翻譯
參考書目
75. 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/
��.12000 年各層級圖書館資訊系統軟硬體規範書,http://catweb.ncl.edu.tw/2-1-19.htm
��.2GNU 通用公共許可證, 一九九一年六月 第二版,
http://www.linux.org.tw/CLDP/OLD/doc/GPL.html; 譯自:
http://www.gnu.org/copyleft/gpl.html
��.3Koha Users Around the World,http://wiki.koha.org/doku.php?id=kohausers