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