[Koha-devel] MARC Holdings, Koha, and Migration

[Thomas D]

Things that you were afraid to ask about for MARC holdings and why it mostly
does not matter yet for Koha, with a MARC 21 holdings mapping supplement.

UNIMARC and MARC 21 holdings are considered below in a rather tedious
manner.  A mapping of common standard MARC 21 subfields to a single local
use field for linking to the Koha items table is presented in the last
section for migration purposes.

Please comment and offer corrections, etc., especially about the migration
mapping.  Even if you would ignore the tedium of the previous sections,
please comment about the migration mapping if you have an interest in
migration issues for Koha.  I have not tested this mapping in an actual
implementation and may even be mapping MARC 21 to orphaned columns in the
items table.  If the migration mapping may be useful, it should form part of
a migration how-to document.


STATEMENT OF REASSURANCE 

Let me state at the outset, that I am satisfied that the current limitation
for linking the Koha items table to one and only one MARC field is not a
problem restricting Koha from functioning in any important way for its
current likely users.  Development resources should be concentrated
elsewhere.  At some suitable point in the future, it would be appropriate to
revisit this issue.  I have brought this issue forward previously with a
less complete understanding of how and why Koha holdings works the way that
it does.


CURRENT KOHA HOLDINGS MODEL

Koha has adopted a holdings implementation modelled on the French
Recommendation 995, http://www.adbdp.asso.fr/outils/infogestion/r995.htm . 
Using this model, holdings information for one record is retained in one and
only one local use field.  Using Koha with MARC 21, any single field may be
adapted for that purpose.  952 is the Koha default implemented at NPL.


UNIMARC HOLDINGS

UNIMARC had omitted holdings support from the bibliographic format. 
Implementers used local use fields or some other means for holdings
information.  The French government supported recommendation 995 for public
libraries.  The IFLA recently approved a UNIMARC holdings format as a
separate record from the linked bibliographic record,
http://www.ifla.org/VI/8/projects/UNIMARC-HoldingsFormat04.pdf .  Paul
Poulain reports the UNIMARC holdings format as not yet adopted by any ILS
that he knows.

Related bibliographic control number 004 in UNIMARC holdings identifies the
control number 001 for the corresponding UNIMARC bibliographic record on the
same system.  Other system control number 035 in UNIMARC holdings matches
035 in UNIMARC bibliographic on the same system for identifying the control
number 001 for a bibliographic record obtained from another system.  In
accordance with the approval of the UNIMARC holdings format, two fields are
being added to the UNMARC bibliographic format.  Location and call number
852 is being added to UNIMARC bibliographic to match the corresponding 252
field in UNIMARC holdings.  Electronic location and access 856 is being
added to UNIMARC bibliographic to match the corresponding 252 field in
UNIMARC holdings.  Within UNIMARC holdings, copy number $t is the linking
subfield for identifying the particular copy across multiple fields.


UNIMARC SERIALS HOLDINGS

The UNIMARC holdings format allows storing complex serials holdings
information in a format that is easy for machines to parse, although,
difficult for humans to read.  Display presentation and complementary
textual holdings fields allow for easy human readability of complex serials
holdings.

Complex serials holdings can be stored in the following fields.  aptions and
patterns fields 500-502 are optional.  Enumeration and chronology - basic
bibliographic unit 510 is mandatory if applicable.  The other enumeration
and chronology fields 511 and 512 are optional.  The simpler textual
holdings fields 520-521 are optional.  500-502, 510-512, and 520-521 are
linked together by interfield linking data $6.

Recommendation 995 only allows for simpler format textual holdings that are
easy for humans to read but difficult for machines to parse.  At some future
time, when Koha needs to support more complex needs of academic libraries or
other libraries with complex serials holdings, to provide for the
configuration of OpenURL resolvers this issue should be addressed.


MARC 21 HOLDINGS

MARC 21 bibliographic has always provided multiple holdings fields.  MARC 21
holdings format for storing holdings information in a separate record linked
to the bibliographic record has become more popular in recent years. 
Despite the holding standard for MARC 21, some systems have implemented
nonstandard local use holdings fields and subfields.  Certainly, some
information often not considered to apply well to standard holdings fields
or not provided in the standard at all requires local use field or subfield
implementation.  Koha's use of a local use field for holdings is certainly
not exceptional.  At the beginning of the year, OCLC announced their plan to
implement holdings in separate holdings format records by year's end.

In the the MARC 21 bibliographic format, as in the MARC 21 holdings, format,
copy number $t is the linking subfield for identifying the particular copy
across multiple holdings fields.  For those cases where a subset of the copy
is required, materials specified $3 is the linking subfield for identifying
the subset.  Control number for related bibliographic record 004 in MARC 21
holdings identifies the control number 001 for the corresponding MARC 21
bibliographic record on the same system.  System control number 035 in MARC
21 holdings matches 035 in MARC 21 bibliographic on the same system for
identifying the control number 001 for a bibliographic record obtained from
another system.


MARC 21 SERIALS HOLDINGS

MARC 21 holdings fields from both MARC 21 bibliographic records and MARC 21
holdings records allow storing complex serials holdings information in a
format that is easy for machines to parse, although, difficult for humans to
read.  Display presentation and complementary textual holdings fields allow
for easy human readability of complex serials holdings.

Complex serials holdings can be stored in the following fields.  Captions
and patterns fields 853-855.  Enumeration and chronology fields 863-865. 
The simpler textual holdings fields 866-868.  853-855, 863-865, 866-868, and
item information fields 876-878 are linked together by field link and
sequence number $8.  If the enumeration and chronology fields 863-865 are
not used, then location 852 or textual holdings fields 866-868 are linked to
item information fields 876-878 by $3.

The all holdings in one local use field model that Koha uses based on
Recommendation 995 only allows for simpler format textual holdings that are
easy for humans to read but difficult for machines to parse.  At some future
time, when Koha needs to support more complex needs, of academic libraries
or other libraries with complex serials holdings, to provide for the
configuration of OpenURL resolvers this issue should be addressed.


DEVELOPMENT OF KOHA HOLDINGS MODEL

An account of the development of the Koha holdings model can be found in the
"Koha diary" along with much other useful history.  Hedges, Stephen. A Koha
diary : implementing Koha at the Nelsonville Public Library. kohadocs.org.
2005. http://www.kohadocs.org/koha_diary.html .

The diary describes part of  how the default Koha table linkings to MARC
fields had originated.  Poulain, Paul. Re--dumpmarc : date--Wednesday May
21, 2003, 10:02 AM ; to--shedges / from--paul.p.

Stephen is quoted.  "We've been discussing our item information. There is
_so_ much valuable information in our old system about each item that we
don't want to lose, but which doesn't fit into a MARC tag. Things such as
date last seen (which is also in Koha items table) or date last borrowed
(also in Koha). We're very tempted to just write a script to read the item
information from our old system and load it directly into the Koha items table."

Paul replied.  "Why don't you add specific non-standard marc tags in the
parameters table and map them to the corresponding koha fields ? Note that I
agree to say that there are only a few 852 subfields code that are free in
MARC21 (1,4,5,7,9,d,o,u,v,w,y if my table is right), but it may be enough."

Local use field 952 had been used for holdings by the ILS that NPL had been
using prior to migrating to Koha and was retained for the Koha to MARC items
linkings and presented as a default for Koha.  The substitution of a local
use field avoids the risk of some possible future assignment of unassigned
subfields for those items table columns that are not part of the MARC standard.


MARC 21 TO KOHA HOLDINGS MAPPINGS

Mapping existing standard data to a MARC 21 local use field is necessary
when migrating holdings to Koha.  If using the default local use field 952,
the following may be a common mapping.  Be sure to construct unique $952
fields populated from the corresponding $t.  Mappings with multiple
subfields listed should have all listed subfields mapped to the
corresponding local use 952 subfield where the last populated subfield value
would overwrite any previous populated value for that local use 952 subfield.

Map 852 $t, 876 $t, 877 $t, and 878 $t to 952 $t for items.copynumber.  (If
you have been using $3, you should find some way of combining $t with $3 to
form a unique whole number.)

Map 852 $p, 876 $p, 877 $p, and 878 $p to 952 $p for items.barcode.

Map 541 $d; or 876 $d, 877 $d, and 878 $d to 952 $d for items.dateaccessioned.

Map 850 $a, 852 $a, or 852 $b to 952 $b for items.homebranch.  Be sure to
convert to the 4 character all caps code as defined for Koha branches.

Map 541 $h; or 876 $c, 877 $c, and 878 $c to 952 $o for items.price.

Map 365 $b; or 876 $c, 877 $c, and 878 $c to 952 $r for items.replacementprice.

Map 852 $b to 952 $d for items.holdingbranch.  Be sure to convert to the 4
character all caps code as defined for Koha branches.

Map 506 $a, 876 $h, 877 $h, and 878 $h to 952 $y for items.notforloan.  Be
sure to convert to an integer boolean.

Map 876 $j, 877 $j, and 878 $j to 952 $1 for items.itemlost.  Be sure to
convert to an integer boolean.

Map 876 $j, 877 $j, and 878 $j to 952 $w for items.withdrawn.  Be sure to
convert to an integer boolean.

Map 852 $k, 852 $h, 852 $i, and 852 $m concatenated together sequentially to
952 $h for items.itemcall number.

Map 506 $a, 876 $j, 877 $j, and 878 $j to 952 $4 for items.restricted.  Be
sure to convert to an integer boolean.

Map 852 $c, 856 $u, 876 $l. 877 $l, and 878 $l to 952 $c for items.location.

Migrating MARC 21 holdings to Koha would certainly be easier if Koha
supported multiple fields for holdings.  However, as stated above, that is
an issue best left for a future time.


Thomas D

---------------------------------------------
Protect your mails from viruses thanks to Alinto Premium services 
http://www.alinto.com