Resources - Metadata

This section contains information on policies, workflows, how-to's, and configuration settings for metadata in the WRLC Alma environment.

Resources - Metadata Configuration

Resources - Metadata Configuration

Authority Control

The WRLC Network Zone runs two different jobs in Alma for authority control: the Link BIB Headings job, and the Preferred Term Correction job. The former links authority headings to an authority record, and the latter changes the heading from the non-preferred term to the preferred term. Both jobs run daily for records linked to the Network Zone; they are specifically applied to bibliographic records that have been updated or added to the repository since the last job, and for headings linked to authority records that have been updated since the last job. More information can be found in the Alma Knowledge Center.

Ex Libris runs a re-indexing job on all repository records twice a year (from November to January, and from May to July). This process applies both authority control jobs to all records in the repository; this is the only time that the jobs will run on old records as well as new ones.

The WRLC did not have authority control jobs running in the Network Zone until 2022. In the Fall of 2021, the WRLC Metadata Committee reviewed authority control in Alma and came to the conclusion that, although the jobs are not perfect, the benefits outweigh the drawbacks. A detailed description of this review can be viewed in the Authority Control Testing Fall 2021 document created by the WRLC Authority Control Subgroup. The official WRLC Policy on Authority Control can be found in the WRLC Network Zone Bibliographic Record Policies document.

In addition, WRLC created several Authority Control rules to mitigate some of the mistakes commonly committed by the Link BIB Heading and Preferred Term Correction jobs. Detailed information about WRLC’s authority control rules and their functions can be found in the Issues and Solutions for Authority Control in Alma document presented to the Metadata Committee in January of 2022.

The jobs and rules mentioned above are configured in the Network Zone, and therefore only apply to records linked to the Network Zone. Below are instructions on how to recreate WRLC’s Authority Control Rules for the Institution Zone, so that they are applied to Institution Zone only records.

Institution Zone Instructions : 

Use the following instructions below if you wish to recreate the NZ settings in your own IZ

User Roles Needed :

Instructions :

Name : Motion Pictures $$x Periodicals $$x History

Input Parameters:

Workflow Setup:

AC1.PNG

Name : Shakespeare, William, $$d 1564-1616 $$x Comedies.

Input Parameters

Workflow Setup

AC2.PNG

Name : Undifferentiated personal name

Input Parameters:

Workflow Setup:

AC3.PNG


C.Create the following 2 Authority Control Rules under the Preferred Term Correction tab

Name: Undifferentiated non-preferred personal name

Input Parameters:

Workflow Setup:

Do not apply preferred term correction

AC4.PNG

Name: 655 LCSH Headings

Input Parameters:

Workflow Setup:

Do not apply preferred term correction

AC5.PNG

Additional Instructions :

Creating an Authority Control rule for Undifferentiated non-preferred personal names (see here) requires an Indication Rule. Below are instructions on how to copy the NZ Indication Rule into your Institution Zone, so that you can use the rule for your Authority Control rule.


  1. Go to the Metadata Editor
  2. In the upper left-hand corner, select Rules and then select Indication to view all Indication Rules
  3. Search for the Indication Rule titled WRLC Undifferentiated 400 field. Right-click on the name of the rule, then choose Duplicate
  4. A Duplicate Rule save page will appear. Click Save.
  5. The new indication rule is saved to the Institution Zone, and can be used on Authority Control Rules in the Institution Zone.

Resources : 

Resources - Metadata Configuration

Metadata Editor Warnings (MARC21 Bib Extensions)

When a record is opened in Alma’s Metadata Editor, Alma checks the record for a variety of characteristics such as missing information, invalid information, duplicate records, and so forth. If an issue is found, it is presented as a warning at the bottom of the screen. These warnings are controlled in Alma configuration through extension packs, which are xml files that describe the use and function of each field in MARC21.

In addition to the out-of-the-box extension packs, the WRLC Network Zone has both added and edited several extension packs in an effort to minimize the number of incorrect warnings in the Metadata Editor. The extension packs in the WRLC NZ that have been edited from the out-of-the-box configuration are for MARC fields 082 and 590; the new extension packs that have been added to the WRLC NZ are for MARC fields 012, 019, 029, and 891.

Because this is configured in the Network Zone, it is only applicable to records linked to the Network Zone. If your institution would like to recreate these configurations for Institution Zone only records, the NZ settings would need to be recreated in your Institution Zone configuration.

Institution Zone Instructions

Use the following instructions below if you wish to recreate the NZ settings in your own IZ

User Roles Needed :

Instructions : 

  1. Go to Configuration > Resources > Cataloging > Metadata Configuration
  2. Choose the MARC21 Bibliographic active profile
  3. On the Profile Details page, click Shared Extensions
  4. Download each of the extension packs contributed by 01WRLC_NETWORK. For each, an xml file will be saved to your Downloads folder in your computer.
  5. Download the extension pack for MARC field 029 (contributed by 01CSCU_WCSU). An xml file will be saved to your Downloads folder in your computer.
  6. Return to the Profile Details page, and click Add Extensions (to Institution)
  7. Upload one of the newly downloaded xml files, then click Add Extensions
  8. Repeat the steps above for each extension
  9. Return to the Profile Details page, and click the blue Deploy button at the top right-hand corner of the screen

Resources :



Posted 03/14/2023 by Jackie Saavedra (WRLC Network Zone Manager)

Resources - Metadata Configuration

Merge Rules

It is WRLC policy to use one of three specific merge rules when merging records; these rules were written so as to preserve local WRLC notes in the bib record. The decision to use specific WRLC merge rules was made by the WRLC Metadata Committee in July of 2018.

What are the three WRLC merge rules?

All of the rules can be found in the Metadata Editor under the Rules > Merge > Shared folder

1. CONSORTIUM NZ / IZ Overlay all fields but local 

DESCRIPTION : CONSORTIUM NZ / IZ Overlay all fields but local for Integration Profile, Import Profile, Combine and Merge Inventory

merge-rules-11.PNG

merge-rules-12.PNG

There are two identical copies of this rule; one that is saved in the Network Zone (and is used on NZ records), and the other that is saved in the Institution Zone (and is used for IZ only records). 

This rule is to be used for most merge cases, specifically for

For both integration and import profiles, the primary record is the existing record in Alma; for the combine and merge function, the primary record is the record in the left pane of the Metadata Editor (the one that is opened first). For more information about primary and secondary records as they pertain to merging, please see the Knowledge Center page on Primary Records.

2. CONSORTIUM NZ / IZ Search external overlay all fields but local 

DESCRIPTION : CONSORTIUM NZ / IZ Overlay all fields but local for Search External Resources

merge-rules-13.PNG

merge-rules-14.PNG

There are two identical copies of this rule; one that is saved in the Network Zone (and is used on NZ records), and the other that is saved in the Institution Zone (and is used for IZ only records). 

This rule is ONLY meant for merging a record using the “Copy & Merge” function in the “Search External Resources” page of the Metadata Editor.

When copy cataloging using Search External Resources, the primary record is the record found via the external resource (NOT the existing record in Alma). For more information about primary and secondary records as they pertain to merging, please see the Knowledge Center page on Primary Records.

3. CONSORTIUM NZ Add local fields

merge-rules-10.PNG

There is only one copy of this rule, and it is saved in the Network Zone (because this rule is only used on NZ records).

This rule is to be used when one wishes to import records directly to the Network Zone using an import profile. More information on the official WRLC Network Zone policy for this merge rule can be found here. 

What do the WRLC merge rules do?

CONSORTIUM NZ / IZ Overlay all fields but local for Integration Profile, Import Profile, Combine and Merge Inventory rule

Completely replaces the primary record with the secondary record except for the following:

CONSORTIUM NZ / IZ Overlay all fields but local for Search External Resources

Keeps the primary record unchanged except for:

The intention is to create a simple merge rule that will preserve all local field numbers (009, 09X, 59X, 69X, 9XX), regardless of whether or not they are actually coded as a local extension.

CONSORTIUM NZ Add Local Fields 

Adds only local fields from the imported record to the Network Zone record via an import profile. Please see the relevant Network Zone Policy for more information.

When are merge rules used in Alma? 

1. When copy cataloging using an external resource in the Alma Metadata Editor.

In this scenario, you will want to configure the CONSORTIUM NZ / IZ Search external overlay all fields but local merge rule for your external resource.

merge-rules-1.png

The merge rule used in this scenario is configured for that specific resource under the Configuration Menu > Resources > Search Configuration > External Search Resources page. 

merge-rules-2.PNG

2. When importing records using an import profile

Under the Match Actions section of an import profile, you can choose which merge rules to use.

In this scenario, you will want to use the CONSORTIUM NZ / IZ Overlay all fields but local merge rule when importing records into the Institution Zone.

When importing records directly into the Network Zone, you must use the CONSORTIUM NZ Add local fields rule. This is according to WRLC Network Zone policy (see below).

Record load profile

Policy Statement: Record load profiles should generally only import to the Institution Zone; the Use Network Zone setting for each institution’s import profile should be set to No.

Import profiles can match to the Network Zone, but if a matching record is found the NZ record must be used (only local fields may be added), and if a matching record is not found the incoming record must be imported to the IZ only. To use this method, the following settings should be used: Use Network Zone: “Yes”, Upon Match: “Merge”, Merge method: “CONSORTIUM NZ AddLocalFields”, Upon No Match: “Import to IZ.”

3. When importing records from OCLC Connexion to the Institution Zone

In this scenario, you will want to configure the CONSORTIUM NZ / IZ Overlay all fields but local merge rule for your IZ's OCLC Connexion Integration Profile.

Alma uses an Integration Profile (to be found under the Configuration Menu > General > External Systems > Integration Profiles) to import records from OCLC to Alma. If the Integration profile is configured to not use the Network Zone (see image below)...

merge-rules-5.PNG

...then Alma will use the merge method configured under the Actions tab of the Integration Profile for merging.

When Alma finds a match with an imported OCLC record and a pre-existing Institution Zone record (the system will use the criteria stipulated under the Serial match method and Non serial match method configured in the Integration Profile; for more information on match methods, see the WRLC NZ policy on Bibliographic Utilities), the two records will be merged using the merge method chosen in the Integration Profile.

merge-rules-6.PNG

4. When merging two already existing records in the Metadata Editor

Each time you use the Merge Records & Combine Inventory function in the Metadata Editor, you choose which merge rule to use in the pup-up window.  

merge-rules-4.png

In this scenario, you will want to use the CONSORTIUM NZ / IZ Overlay all fields but local merge rule when the primary record is on the left-hand side of the Metadata Editor split screen (the one that is opened first). For more information about primary and secondary records as they pertain to merging, please see the Knowledge Center page on Primary Records.

Full instructions on how to merge two records can be found in the How to merge bibliographic records page of the WRLC Wiki.

Keep in mind that you can merge two bibliographic records only when both records are Institution Zone records, or both are Network Zone records. You CANNOT merge an Institution Zone bib record with a Network Zone bib record

When are merge rules NOT used in Alma?

1. When importing records from OCLC Connexion to the Network Zone

Alma uses an Integration Profile (to be found under Configuration Menu > General > External Systems > Integration Profiles) to import records from OCLC to Alma. If the Integration profile is configured to use the Network Zone (see image below)...

merge-rules-7.PNG

...then the Integration Profile IGNORES the merge method chosen under the Actions tab of the Integration Profile. 

If a match with a Network Zone record is found, that Network Zone record is used, and the record will NOT merge with the OCLC record.

2. When linking an IZ record to a matching NZ record

You can share an Institution-Zone record with the Network Zone in the Metadata Editor by choosing File > Share with Network. If Alma finds a match between the IZ record and an NZ record, you can preview the match or select from among multiple matches. Select Link beneath the matching record to link the Institution Zone record with the Network Zone record. 

merge-rules-8.png

When an IZ record is linked with an NZ record, the NZ record metadata overlays the IZ record metadata; no merging occurs. The only metadata in the IZ record that merge into the NZ record are local extensions.

Extra Resources

Ex Libris Alma Knowledge Center - Working with Merge Rules

Resources - Metadata Configuration

Match Profile in the Metadata Editor

Match methods in Alma are primarily used in import profiles to determine whether an incoming record is considered a duplicate of an existing record. 

Match methods are also used in the Metadata Editor, specifically when linking records from the Institution Zone to the Network Zone, and when using Search External Resources.  In both workflows, a list of record(s) is given if a match is found for the open record in the Metadata Editor.

Match Profile Configuration for the Metadata Editor

The matching records are determined by the match profile configured in Alma. This configuration can be found under the Configuration Menu > Resources > General > Other Settings page. 

It is WRLC policy to use the Fuzzy Match Method for both serials and non serials.

You must choose the same match profile for both the Network Zone and the Institution Zone. The Share with Network functionality may fail if the configuration settings differ between the Network Zone and the Institution Zone.

Non Serial Match Profile

match-method-1.png

The parameter value for the non_serial_match_profile setting in the WRLC NZ and IZs should be as follows:

com.exlibris.repository.mms.match.CDLMatchingProfile

Serial Match Profile

match-method-2.png

The parameter value for the serial_match_profile setting in the WRLC NZ and IZs should be as follows:

com.exlibris.repository.mms.match.CDLSeMatchingProfile

Fuzzy Match Algorithm

Both the Fuzzy Non-Serial Match Method and the Fuzzy Serial Match Method use the following algorithm to find a match:

Alma attempts to find records with, at least, one of the following matching IDs:
If no matches are found through this attempt:
The following title and author fields are used for matching:
  • MARC 21 Title: 245 a; 210 a; 246 a
  • MARC 21 Author: 100 a-d,jq,u; 110 a-e,n,u; 111 a,c-e,n,q,u; 700 a-d,jq,u; 710 a-e,I,n,u; 711 a,c-e,I,j,n,q,u
  • UNIMARC Title: 200 a,e,d,h,i; 531 a
  • UNIMARC Author: 700 a-d,f,p; 701 a-d,f,p; 710 a-h,p; 711 a-h,p; 720 a,f; 721 a,f; 702 a-d,f,g; 712 a-h,p; 722 a,f
Examples:

When the 100/245 match and the 210 exists in the Alma record but is lacking in the incoming record, will there be a match? Yes. Once the records are matched by the 100/245, that is enough. There is no need to check the 210.

When the 100/245 match and the 246 exists in the Alma record but is lacking in the incoming record, will there be a match? Yes. Once the records are matched by the 100/245, that is enough. There is no need to check the 246.

When the 100/245 match and the 246 exists in the Alma record has one or more 700 fields but the incoming record is lacking all or some of the 700 fields, will there be a match? Yes. Once the records are matched by the 100/245, that is enough. There is no need to check the 700 field(s).

If no matches are found in either attempt, Alma issues a message that no matches have been found.

 

Resources - Metadata Configuration

Item Description Templates

Alma allows for a template to be configured when generating an item description based on the enumeration/chronology fields in an item record.

WRLC has 32 different item description templates configured in our Network Zone and pushed to all Institution Zones.

These templates are only applied to item records with one of the following material types :

Code Description
BOOK Book
ISSUE Issue
ISSBD Bound Issue

For a full list and description of these templates, please see the Templates configured in the WRLC NZ section of the Item Record Description Policies and Templates page.

To view the NZ template configurations in your own IZ, go to Configuration > Resources > General > Description Templates; they will be listed under the Network Rules list section.

desc_template_config2.PNG

The NZ templates are configured so that they have precedence over any templates configured in the individual Institution Zone. This means that NZ description templates are applied to item records first, and then IZ-only description templates are applied.

desc_template_config3.PNG

This setting is configured in Configuration > Resources > General > Other Settings. The parameter network_description_templates_rules_precedence should be set to true in all WRLC Institution Zones.

desc_template_config1.PNG

Resources - Metadata Configuration

Bibliographic Record Deletion - Related Records

Alma allows the ability to prevent the deletion of related records in the Network Zone. In the Bibliographic Record Deletion - Related Records page of Alma Configuration (which can be found under Configuration > Resources > Collection Retention), you can specify which types of related records will result in a warning or a block if staff try to delete them.

In the WRLC Network Zone, only the following relation types are enabled as a Block; this means that any records with a Contains (774 field) relationship or a Part Of (773 field) relationship with another record will NOT be deleted by Alma. For more information, see the Related Record Types section in the Alma Knowledge Base.

wiki-bib-record-deletion-1.PNG

wiki-bib-record-deletion-2.PNG

This prevents the accidental deletion of boundwith records in the catalog that use the 773 or 774 fields for linking. For more information on creating boundwiths in Alma, see the Configuring Related Records for Physical Inventory in the Alma Knowledge Base.

For more information about deleting NZ bibliographic records, please see the WRLC policy.

Resources - Metadata Policies

Resources - Metadata Policies

Fields That can be Deleted in the WRLC Network Zone Without Consultation

Updated March 22, 2024

Please direct any questions or comments about this document to the WRLC Metadata Committee: metadata@list.wrlc.org

When in doubt: ask.  Any questions about deleting fields in Network Zone (NZ) bib. records can be posted to the message board of the WRLC Metadata Basecamp: https://3.basecamp.com/3574750/projects/10052002

Any deletion mentioned in this document can be done as an edit or as part of merging bib. Records without consultation.

The following fields may be deleted without consultation:

  1. Access points with $$2 nab or $$2 nbc.  These start with a number like 86.40 or 86.04.

    Example:

    650  7 86.40 philosophy of law $$0 (NL-LeOCL)0077607767 $$2 nab

  1. Access points from the Book Industry Study Group vocabularies.  These are in all-caps and have $$2 bisac or $$2 bisacsh or $$2 bisacrt or $$2 bisacmt.

    Example:

    650  7 POLITICAL SCIENCE $$2 bisac

  1. Access points that duplicate other, controlled access points.

    Example:

    650  0 Gorillas as pets.

    650  4 Gorillas as pets.

  1. Access points that are just translations of corporate names or titles.

    Examples:

    610 20 United Nations. [keep]

    610 20 Vereinte Nationen. $$2 gnd $$0 (DE-588)4077323-1 [delete]


    630 00 United Nations Framework Convention on Climate Change $$d (1992 May 9) [keep]

    630 06 Convention-cadre des Nations Unies sur les changements climatiques (1992 mai 9) [delete]

  1. Non-local 9xx fields generated on import.

    Examples:  

    938  $$a YBP Library Services $$b YANK $$n 15604791

    948  $$h NO HOLDINGS IN CAO - 11 OTHER HOLDINGS

    994  $$a Z0 $$b CAO

  1. A field that duplicates the function of another preferred field.

    Examples:

    546    $$a In English, French, German, and Spanish. [keep]

    500    $$a In English, French, German, and Spanish. [delete]

  1. A field that applies to a non-WRLC institution.

    Example:

    561    $$a Gift of Herbert Pell, March 18, 1943. $$5 DLC

    583    $$a Commitment to retain ǂc 20151204 ǂ2 pda ǂ5 OTUTLD

  1. 856 fields with URLs leading to institution-specific resources. 

    Examples: 

    856 41  $$u http://site.ebrary.com/lib/georgemason/Doc?id=10090633 

    856 42  $$u http://find.galegroup.com/gdl/start.do?prodId=GDL&userGroupName=wash31575 

  1. Non-local 0XX fields that exist in OCLC master records.

    Examples:

    029  NZ1 $$b 4240676

    084  GD 30 $$2 blsrissc

  1.  AVA and ITM fields. These fields were incorrectly added to bibliographic records by Alma, and can be deleted.

    Examples:

    AVA  $$0 99100748753604109 $$8 22276190790004109 $$a 01WRLC_HOW $$b HUF $$c Founders Stacks $$d F1401 .J68 v.35       no.3 1993 $$e available $$f 1 $$g 0 $$i HU $$j hufperm $$k 0 $$o 22276190790004109 $$p 1 $$q Founders Library


    ITM  $$d 1989 v. 20 issue 4 mo. OCT $$i perl $$s wrlc danc $$e 1989 v. 20 issue 4 mo. OCT $$m ISSUE $$n 27010901818292            R15M11S21T12 CD $$b 32003000212874 $$z R15M11S21T12 CD

Resources - Metadata Policies

Formatting Copy-Specific Metadata

Adding Copy-Specific Metadata in Alma

Copy-specific information can be included in the following fields. Some of these fields may need to be configured for display and/or search in some instances of Primo VE. 

Copy-specific metadata in holdings records:

541 - Immediate Source of Acquisition Note

Example:

561 - Ownership and Custodial History

562 - Copy and Version Identification Note

Example: 

563 - Binding Information

Example:

Copy-specific metadata in bibliographic records:

099 - Local call number

Example:

246 - Varying Form of Title

Include $$g or $$i with organization name for Primo VE display.  Include $$5 with MARC organization code.

Examples:

500, 501, 506, 526, 540, 541, 561, 562, 563, 583, 584, 585 - Notes

Include $$3 with organization name and, if necessary, copy information for Primo VE display.  Include $$5 with MARC organization code.

Examples:

59X - Notes

Include organization name in $$a or $$3 for Primo VE display.

Example:

655 - Index Term--Genre/Form

Include $$3 with organization name and, if necessary, copy information for Primo VE display. Include $$5 with MARC organization code.

Examples: 

700, 710, 711, 730, 740 - Added Entry

Include $$3 with organization name and, if necessary, copy information for Primo VE display.  Include $$5 with MARC organization code.

Examples: 

773, 774 - Linking Entry

Include $$5 with MARC organization code.

Example:

9xx - These may be locally/consortially defined and customized for Primo VE display and keyword searching. If the fields are intended for public display/access the institution and copy to which the field refers should be specified in a human readable way appropriate to the field (usually $$3 or $$g). $5 is optional but likely helpful for future compatibility. If the fields are not intended for public display/access they should be in the IZ only.”

Examples:

Resources - Metadata Policies

Item Record Description Policies and Templates

Item record descriptions for print periodicals should follow the guidelines below. Every effort should be made to adhere to these guidelines for newly cataloged items. Legacy records should be corrected only as time and resources allow.


For a full list of WRLC recommendations for print periodicals, please see the following document : Recommendations for Print Periodicals in the Washington Research Library Consortium

Item Field Designations


ENUM/CHRON Field

Enter in Field

Prefix Autogenerated

Example Entry

Enumeration A

Volume


Volumen (es)


Jahrgang/Jahrg (de)


Band/bd. (de)


Jaargang (nl)


Anno (it)


Annus (lt)


Annee (fr)


Tome (fr)


Tomo (es)

v.

23

Enumeration B

Number


numero (es)


Heft (de)

no.

2

Enumeration C

iss.

459

Chronology I

Year

2018 or 5778

Chronology J

Month or Season

Mar. or Autumn

Chronology K

Day

23

Enumeration D

Supplements, Index, or Other

v.3, no.5 (2020 Oct.)-v.4, no.3 (2021 Jun.)

Language of auto generated prefix

The auto generated prefixes are in English. Policy is left to each individual school on whether to always use English, or to use the language of the item being cataloged. If using the language of the item, the prefixes must be changed manually in the Description field of the Item Record.

Month abbreviations

Enter using the appropriate abbreviation. Policy is left to each individual school on whether to always use English, or to use the language of the item being cataloged.


If a language is not listed here, consult the CONSER documentation.


English

Jan.

Feb.

Mar.

Apr.

May

June

July

Aug.

Sept.

Oct.

Nov.

Dec.

French

janv.

févr.

mars

avril

mai

juin

juil.

août

sept.

oct.

nov.

déc.

German

Jan.

Feb.

März

Apr.

Mai.

Juni

Juli

Aug.

Sept

Okt.

Nov.

Dez.

Spanish

enero

feb.

marzo

abr.

mayo

jun.

jul.

agosto

sep.

oct.

nov.

dic.

Portuguese

jan.

fev.

marco.

abril

maio

junho

julho

agosto

set.

out.

nov.

dez.

Latin

Ian.

Febr.

Mart.

Apr.

Mai

Iun.

Iul.

Aug.

Sept.

Oct.

Nov.

Dec.

Italian

genn.

febbr.

mar.

apr.

magg.

giugno

luglio

ag.

sett.

ott.

nov.

dic.

Dutch

jan.

feb.

maart

apr.

mei.

juni

juli

aug

sept.

oct.

nov.

dec.

Enumeration D (Special Cases)

Enumeration D should be used for descriptive information that does not fit in the categories designated for Enumeration A-C and Chronology I-K. This can include new series (n.s.), parts (pt.), indexes, supplements, and others. 


All prefixes for Enumeration D should be written in the Enum D field; no prefixes will be added to the Enum D value in the Description field.


In addition, complex descriptions for bound periodicals should be written with prefixes in Enumeration D; the information should not be written in any other Enumeration or Chronology fields. For an example, see Template {EnumD}


If Enum A-C and Chron I-K are used along with Enum D, the value in Enumeration D will always be added to the end of the Description field. For examples, see Template X {EnumD}

Templates configured in the WRLC NZ

For more information about how these templates are configured in Alma, see the Item Description Templates page.

temp.2-1.PNG

temp.2-2.PNG

temp.3-1.PNG

temp.3-2.PNG

temp.4-1.PNG

temp.4-2.PNG


temp.5-1.PNG

temp.5-2.PNG

v.{EnumA}: no.{EnumB} ({Chronl}: {ChronJ})

v.x: no.x (Year: Mo./Season)

Example : v.101: no.3 (2022: Mar.)

temp.6.PNG

v.{EnumA}: no.{EnumB} ({Chronl})

v.x: no.x (Year)

Example : v.101: no.3 (2022)

temp.7.PNG

v.{EnumA}: no.{EnumB}

v.x: no.x

Example : v.101: no.3

temp.8.PNG

v.{EnumA}: {EnumC} ({Chronl}: {ChronJ} {ChronK})

v.x: iss.x (Year: Mo. Day)

Example : v.101: iss.7 (2022: Mar. 21)

temp.9-1.PNG

temp.9-2.PNG

v.{EnumA}: {EnumC} ({Chronl}: {ChronJ})

v.x: iss.x (Year: Mo.)

Example : v.101: iss.7 (2022: Mar.)

temp.10-1.PNG

temp.10-2.PNG

v.{EnumA}: {EnumC} ({Chronl})

v.x: iss.x (Year)

Example : v.101: iss.7 (2022)

temp.11-1.PNG

temp.11-2.PNG

v.{EnumA}: {EnumC}

v.x: iss.x

Example : v.101: iss.7

temp.12-1.PNG

temp.12-2.PNG

no.{EnumB}, iss.{EnumC} ({Chronl}: {ChronJ} {ChronK})

no.x, iss.x (Year: Mo. Day)

Example : no.3, iss.7 (2022: Mar. 21)

temp.13-1.PNG

temp.13-2.PNG

no.{EnumB}, iss.{EnumC} ({Chronl}: {ChronJ})

no.x, iss.x (Year: Mo./Seas)

Example : no.3, iss.7 (2022: Mar.)

temp.14-1.PNG

temp.14-2.PNG

no.{EnumB}, iss.{EnumC} ({Chronl})

no.x, iss.x (Year)

Example : no.3, iss.7 (2022)

temp.15-1.PNG

temp.15-2.PNG

no.{EnumB}, iss.{EnumC}

no.x, iss.x

Example : no.3, iss.7

temp.16-1.PNG

temp.16-2.PNG

v.{EnumA} ({Chronl}: {ChronJ} {ChronK})

v.x (Year: Mo. Day)

Example : v.101 (2022: Mar. 21)

temp.17-1.PNG

temp.17-2.PNG

v.{EnumA}({Chronl}: {ChronJ})

v.x (Year: Mo.)

Example : v.101 (2022: Mar.)

temp.18.PNG

v.{EnumA}({Chronl})

v.x (Year)

Example : v.101 (2022)

temp.19.PNG

v.{EnumA}

v.x

Example : v.101

temp.20.PNG

no.{EnumB} ({Chronl}: {ChronJ} {ChronK})

no.x (Year: Mo. Day)

Example : no.3 (2022: Mar. 21)

temp.21-1.PNG

temp.21-2.PNG

no.{EnumB} ({Chronl}: {ChronJ})

no.x (Year: Mo.)

Example : no.3 (2022: Mar.)

temp.22.PNG

no.{EnumB} ({Chronl})

no.x (Year: Mo.)

Example : no.3 (2022)

temp.23.PNG

no.{EnumB}

no.x

Example : no.3

temp.24.PNG

iss.{EnumC) ({Chronl}: {ChronJ} {ChronK})

iss.x (Year: Mo/Sea. Day)

Example : iss.7 (2022: Mar. 21)

temp.25-1.PNG

temp.26-2.PNG

iss.{EnumC} ({Chronl}: {ChronJ})

iss.x (Year: Mo/Sea)

Example : iss.7 (2022: Mar.)

temp.26-1.PNG

iss.{EnumC} ({Chronl})

iss.x (Year)

Example : iss.7 (2022)

temp.27-1.PNG

temp.27-2.PNG

iss.{EnumC}

iss.x

Example : iss.7

temp.28-1.PNG

temp.28-2.PNG

{Chronl}: {ChronJ} {ChronK}

Year: Mo/Sea. Day

Example : 2022: Mar. 21

temp.29-1.PNG

temp.29-2.PNG

{Chronl}: {ChronJ}

Year: Mo/Sea.

Example : 2022: Mar.

temp.30.PNG

{Chronl}

Year

Example : 2022

temp.31.PNG

{EnumD}

Example : v.3: no.5 (2020: Oct.) - v.4: no.3 (2021: Jun.)

temp.32-1.PNG

temp.32-2.PNG

X {EnumD}

Example 1 : v.2: no.4 (2018) pt.1

temp.33-1-1.PNG

temp.33-1-2.PNG

Example 2 : v.13-24 index

temp.33-2-1.PNG

temp.33-2-2.PNG




Approved by the Metadata Committee April 28, 2023










Resources - Metadata Policies

Making Changes to WRLC Network Zone Bibliographic Records

Last revised: September 30, 2022

Please direct any questions or comments about this document to the WRLC Metadata Committee: metadata@list.wrlc.org

When in doubt: ask.  Any questions about editing or changing Network Zone (NZ) bib. records can be posted to the message board of the WRLC Metadata Basecamp: https://3.basecamp.com/3574750/projects/10052002

The following kinds of changes, as an edit or as part of merging, may be made without consultation:

Any change mentioned in this list can be done as an edit or as part of merging bib. records.

  1. Any of the deletions listed in the Fields That can be Deleted Without Consultation document.

  2. If your institution has the only holding on the bib. record, you may make any changes, so long as they conform to the WRLC metadata Principles and Policies.

  3. Corrections of obvious typos/mistakes in fields and subfields that are not transcribed.

  4. Adding new fields, so long as they are valid and appropriate for the NZ.

Example:

English title already present in record:

245 00 $$a Abū Ḥāmid al-Ghazzālī fī al-dhikrá al-miʾawīyah al-tāsiʻah li-wafātih : $$b ashghāl al-Nadwah al-Dawlīyah "al-Ghazzālī al-Yawm, li-mādhā"?, Bayt al-Ḥikmah, 17-21 Māy 2011 / $$c rājaʻahu wa-aʻaddahu lil-nashr Miqdād ʻArafah Mansīyah.

Add title in Arabic script:

245 00 $$a ابو حامد الغزالي في الذكرى المئوية التاسعة لوفاته : $$b اشغال الندوة الدولية "لغزالي اليوم، لماذا"؟، بيت الحكمة، 1721 ماي 2011 / $$c راجعه واعده للنشر مقداد عرفة منسية.

  1. Making changes or additions that update a record to current metadata standards (example:  upgrading a record from AACR2 to RDA) if the changes don’t involve major changes like changing the main entry.

  2. Updating authorized access points (e.g. 1xx, 6xx, 7xx, 8xx) to current forms.

  3. Upgrading a regular contents note to an enhanced contents note.


Example:

505 00 $$t Title A / $$r Author A -- $$t Title B / $$r Author B. [after]

505 0  Title A / Author A -- Title B / Author B. [before]

  1. Upgrading a MARC tag to the current standard.

546    $$a In English, French, German, and Spanish. [after]

500    $$a In English, French, German, and Spanish. [before]


020    $$a 156478181X $q ([paperback]) [after]

020    $$a 156478181X (pbk.) [before]


041    $$a eng $a fre $a spa [after]

041    $$a engfrespa [before]


758    $$1 [URI] [after]

758    $$0 [URI] [before]


  1. Changing anything in transcribed elements or certain descriptive parts (e.g. 245, 26x, 300, 490, 505, etc.) if you have the piece in hand.

The following kinds of changes, as an edit or as part of merging, should not be done without consultation:


Any change mentioned in this list cannot be done without consultation as either an edit or as part of merging bib. records.


  1. Any deletions not listed in the Fields That can be Deleted Without Consultation document.

  2. Major changes to the record that are not related to upgrading it to current metadata standards.

  3. Changing anything in transcribed elements or certain descriptive parts (e.g. 245, 26x, 300, 490, 505, etc.) if you do not you have the piece in hand.

  4. Changing anything in a record that is for something that is likely in an institution’s special/rare/archival collections (examples: coded 040 $$e appm, bdrb, cco, cgcrb, dacs, dcgpm, dcrb, dcrmb, dcrmc, dcrmg, dcrmm, dcrmmmss, dcrms; anything produced/published before 1900; one-of-a kind resources like manuscripts). Exceptions:  you may update an obsolete AAP to its current authorized form and correct typos in AAPs.

  5. Any job or automated process run on a set or sets of NZ bib. records. Please post a message to the WRLC  message board of the WRLC Metadata Basecamp: https://3.basecamp.com/3574750/projects/10052002 if you want to propose running a job or automated process that could alter NZ records. This does not apply if you are running jobs to manipulate only your local (IZ) fields.

  6. Making changes or additions that update a record to current metadata standards (example:  upgrading a record from AACR2 to RDA) if they involve major changes like changing the main entry.

  7. When closing a serial or integrating resource record, please alert other institutions that have holdings, and make the following changes:

Set the Type of date in the 008 to d. Add date 2 (use chronological designation if different from publication date).

Add publication dates for first and last issues, if these are in hand (if inferring a publication date from chronological designation or copyright date, use brackets).

264 _1 .... $$c -[1932]

Add a note for the last issue, or similar information if the last issue is not in hand. CONSER prefers unformatted notes.

362 1_ Ceased with: Volume 7, no. 4 (Spring, 1932).

362 1_ Ceased in 1932.

Add or modify note for the latest issue consulted.

588    Latest issue consulted: Volume 7, no. 4 (Spring, 1932).

Please see:  https://www.loc.gov/aba/pcc/conser/issues/CSR.html

Resources - Metadata Policies

Principles for Working in WRLC’s Alma Network Zone

Last revised: March 29, 2019

Please direct any questions or comments about these principles to the WRLC Metadata Committee: metadata@list.wrlc.org

  1. Do no harm. Please see the WRLC Network Zone Bibliographic Record Policies, the Making Changes to WRLC Network Zone Bibliographic Records, and the Fields That can be Deleted in the Network Zone Without Consultation documents.

  2. When in doubt: ask. Any questions about editing or changing Network Zone (NZ) bib. records should be posted to the message board of the WRLC Metadata Basecamp: https://3.basecamp.com/3574750/projects/10052002 

  3. Most bibliographic records for non-electronic resources that have OCLC numbers and that have been cataloged should reside in the Network Zone with a linked record in each holding library’s Institution Zone (IZ). Exceptions are allowed for rare resources, special collections, and any other records an institution wishes to manage locally.

  4. In general, add information applicable to the work/expression/manifestation to the record in the NZ, not your local IZ (e.g., tables of contents; summaries; added entries for editors; additional subject or genre headings; etc.)

  5. Be careful when editing specialized records (CONSER, pcc, dcrm(b)). For CONSER and PCC, add information, but do not change anything in the record unless you are certain there is an error. For records that are for something that is likely in an institution’s special/rare/archival collections, please see the Making Changes to WRLC Network Zone Bibliographic Records document.

Resources - Metadata Policies

Recommendations for Print Periodicals in the Washington Research Library Consortium

The following are recommendations for print periodicals written by the Serial Holdings Subgroup and approved by the Metadata Committee in fiscal year 2023. 

The purpose of these recommendations is to standardize serial holding and item records in the WRLC Alma Institution Zones, and to facilitate the discovery of print periodicals in the WRLC instances of Primo VE. 

Every effort should be made to adhere to the following recommendations for newly cataloged print periodicals. Legacy records should be corrected only as time and resources allow.

Recommendations for Item Records

  1. Item records for print periodicals should have enumeration and/or chronology information.

  2. Description of item records for periodicals should follow the guidelines specified in the WRLC Item Description Policies and Templates document. This uniformity ensures all schools use the same enumeration and chronology fields in the item record for the same pieces of information. 

  3. Item records should use one of the following item material types to describe periodicals : Issue, Serial, Journal, Book, or Bound issue. 

  4. Avoid using temporary locations for print periodicals. If items are in a temporary location, the holdings statement in the 866 field does not display in Primo VE ; instead, an ad-hoc holdings statement is created by Primo, which is not always accurate (for instance, the ad-hoc statement created by Primo will not display any gaps in holdings).

Recommendations for Holding Records

  1. Holding records for print periodicals should have one summary statement in an 866 field.

  2. It is recommended to not have more than one of each public 8XX field in the holding record. In Primo VE, the entirety of the holdings summary is not displayed automatically if there are repeating fields or subfields; only the first instance of each 8XX field and subfield is automatically displayed in Primo VE. 

Recommendations for Primo Configuration

  1. Primo VE should be configured to display the complete summary holdings in the Locations section; the default setting is to display a partial holdings summary. Information about this configuration can be found in the Configuring Additional Holdings Fields for Display in Primo VE Knowledge Center page.




Serial Holdings Subgroup Members


American University Amy Robertson; Matt Smith; Liam Toohey

George Mason University Rekha Pandya; Dorothee Schubel

George Washington University Dawn deVillasana; Qali Farah; Joyce Whitmore

Georgetown University Mark Winek

Washington Research Library Consortium Jackie Saavedra


Committee Chairs Amy Robertson; Joyce Whitmore

Resources - Metadata Policies

WRLC Network Zone Bibliographic Record Policies

Please direct any questions or comments about these policies to the WRLC Metadata Committee:  metadata@list.wrlc.org


BACKGROUND

The WRLC Metadata Committee was tasked to provide policies regarding a shared catalog in Alma integrated library system. Below shows the consortial topography for cataloging related functions in the Alma shared catalog environment. These policies have been revisited since going live in Alma.


The following policies govern mainly the bibliographic records in the shared catalog environment

(Network Zone (NZ)). Some of the policies will also have impacts on bibliographic and authority records in the Community and/or Institution Zone (CZ and IZ respectively) when applicable. These policies reflect the WRLC Principles for Working in the Alma Network Zone upon which WRLC member libraries have committed to adhere.


The WRLC Metadata Committee develops bibliographic principles, policies, and procedures to facilitate implementation of a shared library system. These provide a fundamental framework for the WRLC member libraries, as the creators, editors, maintainers, and users of this metadata, upon which we will operate.

Last revised: May 29, 2020

Policy Statements.

Authority control jobs in Alma

Policy status: Finalized

Functional Areas: Resource Management

Responsible Body: WRLC Metadata Committee


Policy Statement: Quality authority control facilitates access to information. Authority control is performed in the WRLC Network Zone via the Alma Link BIB Heading and the Preferred Term Correction jobs. The WRLC Consortial Network Zone Manager regularly reviews the results of the authority control jobs. Any manual changes needed for authority control will be announced by the NZ Manager in the Metadata Basecamp.


Functional ability: Alma, Primo

Last revised:  July 29, 2022


Bibliographic, holdings, and item data cleanup

Policy status: Finalized. 

Functional Areas: Resource Management

Responsible Body: WRLC Metadata Committee


Policy Statement: If resources permit, institutions should make an effort to address known data

problems. Significant changes to records, such as main entry or unnoticed title changes for serials, can be corrected after consultation with member libraries that have holdings attached via the message board of the WRLC Metadata Basecamp: https://3.basecamp.com/3574750/projects/10052002 


Functional ability: Alma, Primo

Last revised: March 29, 2019


Bibliographic Utilities

Policy status: Finalized.

Functional Areas: Resource Management

Responsible Body: WRLC Metadata Committee, Coordinated Collections Committee


Policy Statement: OCLC is the common bibliographic utility for WRLC member libraries. The OCLC record number provides a single match point that simplifies loading, maintenance and other technical service operations in the Alma shared catalog environment. Below lists some types of bibliographic records that are not required to contain an OCLC record number or to have holdings set in WorldCat; these records should not be in the NZ:


• Brief records for equipment, inventory, ordering, or ILL purposes

• Personal copies for course reserves

• Shipping list records for GovDoc, Marcive

• Host bibliographic records for Bound-withs

• Suppressed bibliographic records

• Vendor records other than OCLC


Functional ability: Alma, Primo

Last revised: October 26, 2018


Bound-withs

Policy status: Not finalized. Pending ExLibris Enhancement. 

Functional Areas: Resource Management

Responsible Body: WRLC Metadata Committee, Coordinated Collections Committee

Original Source: Ex Libris : Presentations and Documents Cal State: Bound-withs


Policy Statement: In Alma, each bound-with has a host bibliographic record in the IZ linked to

bibliographic records in the IZ and NZ for each title in the bound-with. It is recommended that the host bib record should be suppressed. Libraries may create collection-level records for bound-withs in OCLC with individual items in a contents note if required, then import the record into the NZ. Such records should not be linked to IZ/NZ records for individual titles in the bound-withs. Certain catalogers are working to develop the best way to handle bound-withs in Alma, so this policy statement may soon be revised.


Functional ability: Alma, Primo

Last revised: April 26, 2019


Copy-specific metadata

Policy status: Finalized.

Functional Areas: Resource Management

Responsible Body: WRLC Metadata Committee

Policy Statement:  Copy-specific metadata can be added in Alma in the following ways:

a)       In bibliographic records that are in the IZ and not linked to the NZ

b)      In bibliographic records that are in the NZ and linked to the IZ

c)       In IZ holdings or item records.

Copy-specific metadata should only be added to NZ bibliographic records if it would be of interest to library users outside of the institution.  If copy-specific metadata is added to bibliographic records in the NZ, it must be in the appropriate fields and it must be clear which institution the metadata applies to.  Please see the Formatting Copy-Specific Metadata page for more information on and examples of how to correctly format copy-specific metadata.

Functional ability: Alma

Last revised: April 28, 2020


Creating and managing local unique data

Policy status: Finalized.

Functional Areas: Resource Management, Acquisitions

Responsible Body: WRLC Metadata Committee, Special Collections Interest Group

Original Source: Introduction to Local Bibliographic Extensions

Local Extension Definition

Local field migration mapping

Cal State: Local Fields

Orbis Cascade: Local Fields


In general, data that applies only to a member library should be put into reserved Alma local MARC fields (e.g. 590, 9xx). The majority of these fields are defined by the entire consortium to contain similar data; some fields may be reserved for local optional use.


Some libraries may wish to make copy-specific information visible to the whole consortium in non-local notes or in other indexed fields, especially for rare materials. Libraries that choose to do this must make it clear to which library the copy-specific metadata applies. Please see the policy:  Copy-Specific Metadata.



Functional ability: Alma, Primo

WRLC Libraries Rationale: To protect local data from accidental deletion or overlay by another

institution, Alma provides the functionality for each institution to secure, manage, and display their local data through defined fields. Prior to migration, local legacy data for the WRLC institutions was mapped to the fields defined in WRLC Metadata Committee’s Final Mapping for Migration document.


Last revised: November 22, 2019

Deletion of NZ bibliographic records

Policy status: Finalized.
Functional Areas: Resource Management
Responsible Body: WRLC Metadata Committee

Policy Statement: Network Zone bibliographic records can be deleted from each Institution Zone either individually in the Metadata Editor, or through a batch process. Alma will automatically prevent the deletion of Network Zone records that have holdings in other institutions, or that are associated with boundwith titles via the 773 or 774 linking field.

Previous WRLC policy stated that when deleting Network Zone bibliographic records, you must first unlink the record from the NZ, delete the IZ-only copy, and then have the Consortial Network Zone Manager delete the remaining NZ records. This policy was put in place to prevent the accidental deletion of bound-with bibliographic records. With the May 2024 Alma release, a new feature was introduced that can prevent the deletion of related records. The Metadata Committee agreed to add this new configuration to our Network Zone on May 31, 2024. For more information on deletion prevention in the WRLC Network Zone, please see the Bibliographic Record Deletion - Related Records  page.  

Functional ability: Alma
Last revised: June 28, 2024 

Descriptive cataloging standards

Policy status: Finalized.

Functional Areas: Resource Management

Responsible Body: WRLC Metadata Committee, Coordinated Collections Committee


Policy Statement: Records in the NZ should be cataloged according to an established standard such as RDA, dcrm(b), dacs, etc. In general, records should be updated appropriately in OCLC before import. Records may be accepted into the NZ if they are cataloged according to earlier cataloging standards (e.g. AACR2).


Functional ability: Alma, Primo

Last revised: October 26, 2018

Duplicate NZ records

Policy status: Finalized.

Functional Areas: Resource Management

Responsible Body: WRLC Metadata Committee, Coordinated Collections Committee


Policy Statement: In general, there should be only one NZ record for each manifestation of a given work. Duplicate bib. records should be identified and resolved as time and resources allow. There may be exceptions for rare or special materials.  Questions about possible duplicate bib. records should be posted to the message board of the WRLC Metadata Basecamp: https://3.basecamp.com/3574750/projects/10052002 


Alma Functional ability: Alma, Primo

Last revised: November 22, 2019


Editing or making changes to NZ records

Policy status: Finalized.

Functional Areas: Resource Management

Responsible Body: WRLC Metadata Committee


Policy Statement: Please see the Principles for Working in WRLC’s Alma Network Zone, the Making Changes to WRLC Network Zone Bibliographic Records, and the Fields That can be Deleted in the Network Zone Without Consultation documents.  Any questions about editing or changing Network Zone bib. records should be posted to the message board of the WRLC Metadata Basecamp: https://3.basecamp.com/3574750/projects/10052002


Alma Functional ability:  Alma, Primo

Last revised: March 29, 2019


Identifier in $0 and/or $1

Policy status: Finalized.

Functional Areas: Resource Management

Responsible Body: WRLC Metadata Committee, Coordinated Collections Committee

Original Source: PCC URI FAQs (Feb 2018)


Policy Statement: When adding an identifier to an entity, it is recommended that the identifier be

recorded in $0 (authority data) and/or $1 (real world object) when available.

The preference is to record an HTTP URI over a text string URI.


Functional ability: Alma, Primo

Last revised: October 26, 2018


Language of cataloging

Policy status: Finalized.

Functional Areas: Resource Management

Responsible Body: WRLC Metadata Committee, Coordinated Collections Committee


Policy Statement: English is the language of cataloging at WRLC. Records with a cataloging language other than English are discouraged from being in the Network Zone; legacy records cataloged in a foreign language should be corrected as time and resources allow. 


Functional ability: Alma, Primo

Last revised: May 31, 2019


Local WRLC Subject Headings

Policy status: Finalized.

Functional Areas: Resource Management

Responsible Body: WRLC Metadata Committee, Reparative Cataloging Subgroup


Policy Statement: Local subject headings can be suggested by consortial staff; a Google form must be filled out. Once the form is submitted, the Reparative Cataloging Subgroup and the Metadata Committee follow a specific workflow to either approve or reject the subject heading. The local subject heading can either be a supplemental term or can replace a Library of Congress subject heading, as decided by the Reparative Cataloging Subgroup 


A local authority record is saved in the Network Zone for each local heading. Headings that are approved to replace LCSH are flipped to the local term by the daily Preferred Term Correction job. They are coded in the MARC record as LCSH (second indicator is 0). If the original LCSH contains subdivisions, the subdivisions are retained in the local heading. 




Supplemental headings are added to NZ bibliographic records based on the existence of specific Library of Congress subject headings in the original record. They are added via a normalization rule that runs automatically when a NZ record is saved in the Alma Metadata Editor. The normalization rule can be found in the Metadata Editor under Rules > Normalization > Shared > WRLC transform 650 to 650 subf 2 local subf 5 CAO. This rule can be used in Institution Zone configurations if a specific institution would like to add local WRLC headings to their own IZ records. 


The supplemental headings are coded in the MARC record with a second indicator of 7, a subfield 2 with a value of local, and a subfield 5 with a value of CAO (the OCLC code for WRLC). If the original LCSH contains subdivisions, the subdivisions will be added to the local heading. 




The full list of local headings can be found here :  Replacement and Supplemental Heading Tracking


Functional Ability: Alma, Primo

Last revised: July 28, 2023


MARC 588 field

Policy status: Finalized.

Functional Areas: Resource Management

Responsible Body: WRLC Metadata Committee


Policy Statement: For bibliographic records in the NZ, the MARC 588 can have either first indicators 0/1 or free text such as “Description based on” and “Latest issue consulted.” There is a Primo VE normalization rule that makes display of the 588 with indicators intelligible.


Functional ability: Alma, Primo

Last revised: October 30, 2020


Minimal level records

Policy status: Finalized.

Functional Areas: Resource Management

Responsible Body: WRLC Metadata Committee, Coordinated Collections Committee

Original Source: Cal State: Floor Bibliographic Standards

Orbis Cascade: Floor Bibliographic Standards


Policy Statement: Minimal level records are discouraged from being in the Network Zone. Member libraries are expected to meet quality requirements as agreed upon. Consult the Making Changes to WRLC Network Zone Bibliographic Records page to edit and review minimum level to core or full level records. Minimal or less-than-full records are allowed when the library lacks the necessary expertise, such as in language or format, to create or upgrade to core or full level records.


Functional ability: Alma, Primo

Last revised: May 29, 2020


Non-English subject headings

Policy status: Finalized.

Functional Areas: Resource Management

Responsible Body: WRLC Metadata Committee, Coordinated Collections Committee


Policy Statement: Access points should be in English and in Roman characters. Non-English and non-Latin scripts access points may be accepted into the NZ if present in the OCLC master record.


Functional ability: Alma, Primo

Last revised: October 26, 2018


Non-Latin (vernacular) scripts

Policy status: Finalized.

Functional Areas: Resource Management

Responsible Body: WRLC Metadata Committee, Coordinated Collections Committee


Policy Statement: Alma accepts and indexes non-Latin scripts (coded in UTF-8). Parallel descriptions in Roman and non-Latin scripts are accepted for bibliographic records. If vernacular data are not present in OCLC master, member libraries may choose to enhance the record with vernacular scripts in OCLC.


Functional ability: Alma, Primo

Last revised: October 26, 2018


Provider-neutral records

Policy status: Finalized.

Functional Areas: Resource Management

Responsible Body: WRLC Metadata Committee, Coordinated Collections Committee

Original Source:  PCC Provider-Neutral guidelines


Policy Statement: Provider-Neutral records are for electronic resources, print on demand

reproductions, and photocopies of textual materials. They are intended to eliminate a proliferation of records describing essentially the same content.  Member libraries will adhere to the PN records for the NZ and follow the PCC’s practices and the LC-PCC PS for RDA 1.11.  These do not apply to Community Zone records.


Functional ability: Alma, Primo

Last revised: October 26, 2018


Rare Book Cataloging

Policy status: Finalized.

Functional Areas: Resource Management

Responsible Body: Special Collections Interest Group, WRLC Metadata Committee


Policy Statement: 


Rare books, special collections, archival, or manuscript resources may be cataloged according to different national/international standards.  Examples include:  one of the Descriptive Cataloging for Rare Materials (DCRM) manuals, Resource Description & Access (RDA), and Describing Archives: A Content Standard (DACS).  Records may be accepted into the NZ if they are cataloged according to earlier cataloging standards (e.g. AACR2).  These resources sometimes warrant what appear to be duplicate bibliographic records in both the NZ and IZ, and this is left to cataloger’s judgement.  When in doubt about anything in bibliographic records for these kinds of resources, ask the applicable institution(s).  For guidance on copy-specific metadata (former owners, binding, etc.) please see the policy:  Copy-Specific Metadata.


Functional ability: Alma, Primo

Last revised: July 26, 2019


Record encoding

Policy status: Finalized.

Functional Areas: Resource Management

Responsible Body: WRLC Metadata Committee, Coordinated Collections Committee


Policy Statement: Character set in MARC records is to be set in unicode, UTF-8 level. Record

encoding level in NZ must be full or core level.


Functional ability: Alma,

Last revised: October 26, 2018


Record load profile

Policy status: Finalized.

Functional Areas: Resource Management

Responsible Body: WRLC Metadata Committee


Policy Statement: Record load profiles should generally only import to the Institution Zone; the Use Network Zone setting for each institution’s import profile should be set to No.


Import profiles can match to the Network Zone, but if a matching record is found the NZ record must be used (only local fields may be added), and if a matching record is not found the incoming record must be imported to the IZ only. To use this method, the following settings should be used: Use Network Zone: “Yes”, Upon Match: “Merge”, Merge method: “CONSORTIUM NZ AddLocalFields”, Upon No Match: “Import to IZ.”


Functional ability: Alma

Last revised: February 25, 2022


Records overlay

Policy status: Finalized.

Functional Areas: Resource Management

Responsible Body: WRLC Metadata Committee, Coordinated Collections Committee


Policy Statement: Do not use Alma’s Copy & Overlay feature, instead use Copy & Merge in the Metadata Editor. Use the merge rule created by WRLC: “Consortium IZ overlay all fields by local.” If merging two bib. records would result in changes that require consultation in the two documents listed below, post a message to the message board of the WRLC Metadata Basecamp: https://3.basecamp.com/3574750/projects/10052002

listing the institutions who have holdings in the subject line.


Please see: 

Fields That can be Deleted in the WRLC Network Zone Without Consultation

Making Changes to WRLC Network Zone Bibliographic Records


Functional ability: Alma

Last revised: December 13, 2019


Serials in print

Policy status: Finalized.

Functional Areas: Resource Management

Responsible Body: WRLC Metadata Committee, Coordinated Collections Committee

Original Source: CSR guidelines (Sep 2017)


Policy Statement: The institutional coverage of serials should be described in the holdings record or in local fields in the bibliographic record.


Functional ability: Alma, Primo

Last revised: May 31, 2019


Single versus separate records

Policy status: Finalized.

Functional Areas: Resource Management

Responsible Body: WRLC Metadata Committee, Coordinated Collections Committee


Policy Statement: One record per format in the Alma repository.  For legacy data, e.g. GovDoc materials, member libraries will make a concerted effort to resolve mul-ver records issue.


Functional ability: Alma, Primo

Last revised: October 26, 2018

Suppression of NZ bibliographic records for withdrawals

Policy status:  Not finalized. Pending revision of the WRLC SCS Project Final Report
Functional Areas: Resource Management
Responsible Body: WRLC Metadata Committee, Coordinated Collections Committee
Original Source: Orbis Cascade: Suppression for physical inventory
Cal State: Withdrawals
Cal State: Suppression of Records
WRLC SCS Project Final Report (on withdrawals)

Policy Statement: When WRLC used Voyager and Sierra as their ILS, it was policy for the schools participating in the WRLC Sustainable Collection Services (SCS) Project to suppress bibliographic and holdings records for items that were discarded in favor of a retention copy elsewhere.

Since WRLC’s migration to Alma, we now have the ability to view deleted record information in Alma Analytics; this policy is therefore no longer necessary.

The policy status will remain not finalized until the WRLC has revised the original SCS Project Final Report. That being said, bibliographic and holdings records can be deleted from Alma when an item is discarded for a retention copy elsewhere; the records no longer have to be suppressed. 


Functional ability: Alma, Primo
Last revised: November 17, 2023


Resources - Metadata Workflows and How-To's

Resources - Metadata Workflows and How-To's

Metadata in the WRLC Training Sessions 2022

Session 1 | What you need to know (WRLC Overview)

Presented by Jackie Saavedra, WRLC, on October 18, 2022

Session 2 | Meet Alma (Introduction to the Alma ILS)

Presented by Jen Froetschel, GW, on October 25, 2022

Session 3 | Using the Metadata Editor

Presented by Robert Bratton, GW Law, on November 1, 2022

Session 4 | Advanced Alma Tools

Presented by Matthew Bright, GW, on November 8, 2022

Resources - Metadata Workflows and How-To's

How to relink holdings records

There are two different ways to relink a holdings record; either through an Alma search or in the Metadata Editor.

Alma Search

  1. Search for the record either using a Physical Titles or Physical Holdings search in Almarelink.PNG
  2. Choose View to view the holdings record you wish to relinkrelink6.PNG
  3. Choose Relink at the top right-hand cornerrelink2.PNG
  4. From here, you will be taken to the Metadata Editor. Follow steps #3-8 under the Metadata Editor section of this page.

Metadata Editor

  1. Open the holdings record you wish to relink in the Metadata Editor.
  2. Choose Record Actions > Relink to a different recordrelink5.PNG
  3. A Relink Holdings page will appear on the right-hand side of the Metadata Editor. From here, you can search for the bibliographic record you would like the holdings record to be linked to. You can search in the Institution or Network Zone. Please note that you can search by OCLC number via the System Number field. You CANNOT search by MMS ID.relink3.PNG
  4. A list of matches will appear on the right-hand side of the Metadata Editor. Choose Relink to relink your holdings record to the new bibliographic record.relink4.PNG
Resources - Metadata Workflows and How-To's

How to link and unlink bibliographic records from the NZ

Linking bibliographic records to the NZ

  1. Open the bibliographic record in the Metadata Editor. If the record only exists in your Institution Zone, a house icon will appear under the title of the item.linkNZ1.PNG
  2. Choose Record Actions > Share with NetworklinkNZ2.PNG
  3. If there are no matches found in the Network Zone, the record will be linked to the NZ and be released from the Metadata Editor.
  4. If matches are found, a pop-up will appear giving you the option to view all matches in the NZ, or push the record to the NZ. It is best practice to choose Yes and view all matches in order to avoid duplication in the NZ. Matches are found using the Match Profile Configuration (for more information on WRLC's policy, see Match Profile in the Metadata Editor.)relinkNZ3.PNG
  5. A list of matches will appear in the Metadata Editor on the right-hand side. If you find an exact match (same OCLC number for example) for the item you are cataloging, choose the Link option. For more information on single match points in the WRLC Network Zone, see the WRLC policy on Bibliographic Utilities and Duplicate NZ Records. linkNZ3.PNG
  6. If you do NOT find an exact match from the list, choose Record Actions > Share with Network again, and this time select No when prompted to view relevant matches.
  7. Your record is now linked to the Network Zone, and an NZ icon will appear under the title of the item in the Metadata Editor.linkNZ4.PNG

Please note that when an IZ record is linked with a pre-existing NZ record, the NZ record metadata overlays the IZ record metadata; no merging occurs. The only metadata in the IZ record that merge into the NZ record are local extensions.

Unlinking bibliographic records from the NZ

  1. Open the NZ record in the Metadata Editor. If the record is linked to the Network Zone, an NZ icon will appear under the title of the item.linkNZ5.PNG
  2. Choose Record Actions > Copy to Catalog. linkNZ6.PNGThis will create two separate bibliographic records; one that is in your Institution Zone only, and one that is in the Network Zone. The NZ copy no longer has any affiliation with your IZ. Please follow WRLC policy to delete the remaining NZ record.
  3. Your record is now unlinked from the NZ. A house icon will appear under the title of the item, signifying it is in the IZ only.linkNZ7.PNG

Linking & unlinking in batch

Please note that when an IZ record is linked with a pre-existing NZ record, the NZ record metadata overlays the IZ record metadata; no merging occurs. The only metadata in the IZ record that merge into the NZ record are local extensions.

Unlinking records from the Network Zone creates two separate bibliographic records; one that is in your Institution Zone only, and one that is in the Network Zone. The NZ copy no longer has any affiliation with your IZ.  Please follow WRLC policy to delete the remaining NZ record.

Resources - Metadata Workflows and How-To's

How to create new bibliographic records in the Metadata Editor

1. Open the Metadata Editor.

2. Choose Records on the top left-hand corner, then choose New > Placement Options.

newbib1.PNG

3. Choose the location of new records (whether IZ-only or liked to the NZ). Then click Save; this setting will be saved until you change the setting again.

newbib2.PNG

4. Choose New > MARC21 Bibliographic > Books (Default)

newbib3.PNG

Please note that the IZ and NZ icons next to the Books (Default) templates does NOT signify the location of the new record; the icon only signifies which template you are using - either the book template saved in the IZ, or the book template saved in the NZ.

The MARC21 Bib Book template in the NZ (the one with the NZ icon) is the out-of-the-box template from Alma. If you would like to see more about creating record templates in Alma, see the Working with Record Templates page.

5. Edit the new record, then click Save.

Resources - Metadata Workflows and How-To's

How to merge bibliographic records

Alma provides the ability to merge two bibliographic records in the Metadata Editor. This is helpful when catalogers identify duplicate records.

For more information on duplicate records in the WRLC Network Zone, see the WRLC policy on Bibliographic Utilities and Duplicate NZ Records.

Please follow WRLC policy on editing NZ records when merging records linked to the Network Zone.

You can merge two bibliographic records only when BOTH records are Institution Zone records, or BOTH are Network Zone records. You CANNOT merge an Institution Zone bib record with a Network Zone bib record. In this scenario, it would be better to link the IZ record to the NZ record.

1. Search for the duplicate titles in Alma. Push the bibliographic records to the Metadata Editor.merge1.PNG

2. Open the Metadata Editor. Now both records are listed on the left-hand side.

3. First click on the primary record from the left-hand side. The record should now be open in the Metadata Editor.merge2.PNG

In this scenario, the primary record is the record with the LEAST COMPLETE metadata. For more information about primary and secondary records as they pertain to merging, please see the Knowledge Center page on Primary Records.

4. Then select the split-screen editor button, and open the secondary record. merge3.PNG

The secondary record should now be on the right-hand side of the screen, and the primary record should be on the left-hand side of the screen.

5. Choose Record Actions > Merge & Combinemerge5.PNG

6. In the pop-up window, choose the WRLC CONSORTIUM NZ / IZ Overlay all fields but local for Integration Profile, Import Profile, Combine and Merge Inventory merge routine. You can either Show Merge Preview, or go ahead with the merge by clicking OK.merge6.PNG

This specific merge routine replaces the primary record (the one with the least complete metadata) with the secondary record, save for a few fields. For more information on this merge routine, please see the WRLC Merge Rules page.

7. Both records have now been merged. All inventory (holdings and item records) has been combined and attached to the newly merged record.merge7.PNG

Resources - Metadata Workflows and How-To's

WRLC Local Authority Headings Workflows

The following are the workflows used by the WRLC Consortial Network Zone Manager to oversee, edit, and update the local authority records in the WRLC Network Zone environment.

Replacement Headings

  1. Create local authority record. Save as a Local LCSH authority record in the NZ (do not import records, the headings will not link to an imported authority record unless that authority record is opened and saved in the Metadata Editor).

  2. Create set of NZ records containing original LCSH

  3. Run the “Unlink Bib Records from Authority Records” job on the set. This is done so that the headings will be unlinked from the LCSH authority record.

  4. After 24 hours, check the results of the Preferred Term Correction job via the Authority Control Task List. All headings should have been linked to the local authority record and flipped.

  5. Follow instructions for CZ records (see appropriate section below)

  6. Edit the “WRLC Delete incorrect URIs for flipped Local Headings“ normalization rule to include the new headings.

  7. Follow instructions for changing incorrect URIs for local flipped headings (see appropriate section below).

Supplemental Headings

  1. Create local authority record. Save as a Local WRLC authority record in the NZ

  2. Add normalization rules to the WRLC transform 650 to 650 subf 2 local subf 5 CAO normalization rule

  3. Create set of NZ records containing original LCSH

  4. Run normalization rule on the set

  5. After 24 hours, check the results of the set to make sure the local headings are linked to their local authority records.

  6. Follow instructions for CZ records (see appropriate section below).

Community Zone Local Headings

  1. Write normalization rule with title “WRLC CZ [New Heading] Local LCSH”

  2. Create a logical set of all CZ records with the original LCSH

  3. Run the normalization rule on the set. Save this as a recurring job (to run every 2 months on the 15th)

  4. Consortial NZ Manager will review results of scheduled jobs every 2 months 

Change URIs for Replacement Headings

  1. Create a set of records with the new replacement heading(s).

  2. Combine the new set with the original set titled “WRLC Local Replacement Subject Headings.” Delete both of the non-combined sets, and give the combined set the same name as the original set

  3. Run the normalization rule “WRLC Delete incorrect URIs for flipped Local Headings“ on filtered set to delete incorrect URIs. Save this as a recurring job (to run every 2 months on the 16th)

  4. Consortial NZ Manager will review results of scheduled job every 2 months

Documentation

WRLC Local Subject Headings tracking spreadsheet : Replacement and Supplemental Heading Tracking

Testing document : Local Authority Records

Resources - Metadata Workflows and How-To's

Best practices for local extensions (local fields) in NZ-linked records

Local extensions are local fields that can be added to NZ-linked bibliographic records. These fields are marked by a house icon in Alma. 

local-extension-1.PNG

Specifically, you can enter local information in the MARC 21 77X/78X, 09X, 59X, 69X, and 9XX fields.

The fields only appear to your specific Institution Zone; they do not appear when other institutions are viewing the NZ record. 

Local extensions can be added to NZ-linked records either in the Metadata Editor, or in batch via a normalization rule, import profile, or MARCedit.

Adding local extensions in the Metadata Editor

After opening an NZ-linked record in the Metadata Editor, choose Editing actions > Add local extension to enter a local extension in the bibliographic record.

Although not visible in the Metadata Editor, please note that the $$9 local subfield is automatically created and stored in the cached record. This subfield will appear in the local extension when exporting the MARC record from Alma.

A local extension should NOT be added to a record using the Editing Actions > Add field function, and then adding a $$9 local to the field. This will result in a false "local" field that is actually viewable by all institutions.

Adding local extensions via normalization rule / import profile / MARCedit

Local extensions can be added in batch to NZ-linked records using a normalization rule, an import profile, or MARCedit as long as it follows these guidelines

Non-local fields (those without a $$9 local) CANNOT be added to NZ bibliographic records in batch in an Institution Zone by any method

Resources

Alma Knowledge Center > Adding Local Extensions to Bibliographic Records in the Network Zone

Alma Knowledge Center > Working with Normalization Rules

Duplicate NZ Records report

On the 2nd of every month, the WRLC Alma Network Zone creates an Analytics report listing all Network Zone bibliographic records that have duplicate OCLC numbers.

dup-nz-report.PNG

The WRLC Network Zone uses the OCLC number as our primary match point; all NZ records must have a unique OCLC number. As it says in the WRLC NZ policy Bibliographic Utilities,

OCLC is the common bibliographic utility for WRLC member libraries. The OCLC record number provides a single match point that simplifies loading, maintenance and other technical service operations in the Alma shared catalog environment.

It is therefore the responsibility of each of the WRLC institutions to review the report and edit the NZ records in this report for which they have holdings attached. Cleanup work can consist of merging both NZ records (this would require the approval of all institutions with holdings via Basecamp), or moving their holdings from one NZ record to the other. 

If you would like this report to be emailed to you each month, please send an email to servicedesk@wrlc.org to request access.