(Go-live and beyond) Best practices for repository* import profiles

Legend: not started IN PROGRESS STALLED decided

Recommendation

*Screenshots below will be updated by 6/11/2021

RMFG has created one generic NZ repository import profile to be used as a template for campus repository record imports. Import profiles for other functional areas (New Orders, Digital Collections, etc.) should follow guidelines from those functional areas, if any. Campuses should also always keep UC-wide best practices in mind. The screenshots below highlight best practices for each tab and areas that are up to each campus and may change depending on what the purpose of the profile is. Note that after go-live, import profiles should always be tested in a sandbox before being used in our production environment. In addition, campuses are encouraged to ask questions through their RMFG representative, on SILS Slack channels, or on the UC Alma Google Group.

*In the Alma context, “repository import profiles” are used to load bibliographic records and in some cases create inventory associated with those bibliographic records:

Open

Summary best practices:

• Normalization

  • Use “allUC Normalization #1”

  • RMFG is still developing normalization rules, this page (and others) will be updated as needed

• Merge

  • Use “allUC merge rule #1”

  • RMFG is still developing merge rules, this page (and others) will be updated as needed

• Naming conventions

  • (Go-live and beyond) Naming conventions for shared rules, import profiles, and sets in the NZ  

• Match method

  • Use unique “OCLC identifier match method”

• Set management tags: leave “suppress” unchecked

• Do not check “Allow bibliographic record deletion”

Profile details:

• Use Network Zone: this will always be set to “Yes” if using a template copied from the NZ; there is no way to change it. If records are meant to be IZ-only campuses will have to build their own profiles or copy from the CZ.

• Profile name: if the profile is shared in the NZ and meant for the entire system, it should start with “allUC,” if the profile is shared in the NZ but is campus specific, it should start with campus initials. IZ-only profiles should follow local campus naming conventions.

• “Originating system” is up to each campus/situation.

• Import protocol is up to each campus/situation.

• Physical source format is up to each campus/situation.

• Encoding format is up to each campus/situation but ideally UTF-8.

• Source format is up to each campus/situation.

• Status must be set to “active” for the profile to be used.

• File name patterns are up to each campus/situation.

• Target format is generally MARC21.

Open

Normalization & Validation:

• Filter out the data using: is up to each campus/situation but there are shared indication rules available in the NZ if desired.

• Correct the data using: campuses are strongly encouraged to use “allUC [name]’ since this matches the normalization used in the WorldCat Daily Updates. Campuses can do more granular normalization but should be aware that any records with OCLC numbers are subject to the update process and some fields may be re-added to the records.

• Handle invalid data using: this is situational but also not likely to need adjusting.

• Import local extensions: is situational but probably a good idea

•  

Match Profile

• Match by Serial/Non Serial: is up to each campus/situation but if records have OCLC numbers should probably use the OCLC method to reduce multi-matches.

Match actions 

• Handling method: should be set to automatic; setting to manual will pause the import job until multi-matches are manually resolved

• Upon match: this is somewhat up to each campus/situation. If the records are meant to replace existing NZ records then choose “merge,” otherwise use “do not import” or “use existing” as needed.

• Merge method: if merge is selected then use “all UC [name].

• Leave “allow record deletion” unchecked. 

• “Do not merge/override with a lower brief version” should be checked. 

• Community Zone record handling: this is situational. If you want to re-link portfolios from the CZ to the imported ILS bibs, select that option. If not, skip the records.

• Automatic Multi-Match Handling: this is situational but in most cases probably want to skip matches for CZ bibs.

• No match: this is situational but outside of bibs created for order purposes, if the records do not have OCLC numbers they should not be added to the NZ during import.

Match actions:

• If you select “do not import” under Match actions AND under “no match,” the import profile can be run to generate reports and to generate files in specific categories based on what the profile is set up to do.

Automatic Multi-match Handling:

• Disregard matches for CZ linked records is situational.

• Disregard invalid/canceled system control number identifiers is situational.

  • Checking this off will ignore multi-matches during import.

Handling Record redirection:

• Note that this section will only appear in IZ-only import profiles. 

    Everything in this section is situational since it should not be able to impact NZ records but RMFG encourages campuses to be cautious about using “delete” in import profiles.

Set management tags: this is situational but see best practices for setting OCLC holdings.

Inventory: 

The entire inventory tab is situational. Campuses should consider creating individual import profiles for different formats and resource types.

Reasoning

RMFG opted to provide 1 import profile for use as a template along with some guidance around the various options that campuses can use. The group decided against trying to provide multiple profiles that would need to be maintained given that repository import profiles have a wide range of uses with different nuances. RMFG encourages campuses to continue asking the FGs and one another for guidance in developing profiles for specific scenarios.

Action Log