WHY SHOULD I CARE ABOUT PRIMO NORM RULES

WHY SHOULD I CARE ABOUT (PRIMO) NORM RULES?

WHAT NORMALIZATION RULES DO • Content display in Primo • Primo functionality • Troubleshooting

THE METADATA DYNAMO: GETTING DATA TO THE FRONT END What data displays in Primo is controlled by normalization rules. Normalization rules “translate” MARC and Alma fields into PNX fields. If a MARC field isn’t included in the normalization rules for a specific PNX section: field, then Primo can’t use the data in that MARC field for that purpose. PNX: Primo Normalized XML record. For example, if we want users to be able to search for AND see the MARC 600 subject field, there has to be a norm rule adding the 600 field to BOTH the Display: subject and the Search: subject sections of the PNX. Alliance context: Different cataloging practices across the Alliance mean that sometimes institutions have conflicting desires when it comes to displayed fields. The Installation-level nature of norm rules results in the need to coordinate norm rule changes across all 37 institutions.

THE METADATA DYNAMO: GETTING DATA TO THE FRONT END The bibliographic data that appears in the “Display” section of the PNX record is what shows to users in the Primo front end “Details” tab.

THE METADATA DYNAMO: GETTING DATA TO THE FRONT END The “Display” section of the PNX record also determines the data users see in the brief results list.

THE MAGIC MAKER: FRONT END FUNCTIONALITY How Primo uses bibliographic data is also controlled by normalization rules. Major functions get their own PNX sections: Search Facets Prefilters Links Browse Other functions, like lateral links (clickable subjects and authors) work via a combination of PNX sections. Once again, if the norm rules for a specific functional section don’t include a MARC field, the data in that field won’t be available for that function. : -(

THE MAGIC MAKER: FRONT END FUNCTIONALITY Data that the norm rules put into the Facets section of the PNX create the post-search facets you see on the left side of your brief results display. Each dynamic facet in the front end is populated with the values in the applicable PNX fields of ALL of your top 200 search results. Static facets show a predefined list of values – where a record fits in depends on what value(s) the norm rules write to that field of its PNX.

THE MAGIC MAKER: FRONT END FUNCTIONALITY Lateral links (clickable authors, subjects, etc. ) are also controlled by norm rules, but work a little differently than facets. Lateral links are controlled by a specific range of Display and Search PNX fields: Local display fields 30 – lds 39 Local search fields lsr 30 – lsr 39 If we want a MARC field to be “Clickable” in Primo, we add it to both the Display: lds 3[X] and the Search: lsr 3[X] fields by creating the appropriate norm rules. The numbers have to match!

THE SUPER SLEUTH: TROUBLESHOOTING Once you understand how norm rules drive content and functionality, you can use that knowledge to troubleshoot a wide range of metadata problems in the Primo front end. The general process is to trace the metadata backwards from the Primo front end to its source in the MARC bibliographic (or Alma) record: Identify problematic data or function, as well as exemplar records. Use the PNX bookmarklet to examine the PNX for the problem records. Determine the section and field of the PNX involved in the problem. Examine the norm rules for that section and field. Examine the MARC and/or Alma fields the norm rules take their data from. Data problems can often be corrected on a record-by-record basis in OCLC. Functional problems often take some more digging through code and mapping tables and Ex Libris documentation. Sales. Force cases are sometimes necessary as well.

THE SUPER SLEUTH: TROUBLESHOOTING Example (Data problem): Why does this print book show in Primo as an e. Book? Example: NZ MMS ID: 99143230840001451 IZ MMS ID: 9980547730001453 OCLC: 37132430 PNX shows: Display: type of “book”, which is for e. Books. Display: format consistent with a print book. Need to check Display: type norm rules!

THE SUPER SLEUTH: TROUBLESHOOTING Norm rule 2 shows the following process for setting Display: type to “book”: If The MARC LDR does not evaluate to “SE” under the “Validate FMT equals” routine, LDR/06=a and LDR/07=b, i, or s And the 008/23 byte is coded “o” (online), Then the LDR/06 is fed to the 008_type_online mapping table, Which sets the Display: type to “book” if the LDR/06 is “a” or “t”.

THE SUPER SLEUTH: TROUBLESHOOTING A quick check of the OCLC record shows that the master record is, in fact, coded as an “online” resource in the 008/23 byte. At this point, a cataloger should review the record and determine whether to change the coding or move the physical holdings to a new bibliographic record in OCLC.

THE SUPER SLEUTH: TROUBLESHOOTING Example (Function problem): Why do some local fields display to other libraries? Example record: NZ MMS ID: 9992921100001451 IZ MMS ID: 9980431200001453 OCLC: 429495 “Northwest Collection (WWU) is a 960 note that was added by WWU, but is visible in UW’s Primo.

THE SUPER SLEUTH: TROUBLESHOOTING A check of the PNX shows the offending metadata in the Display: lds 10 field. Note that the data in the Display: lds 06 field did NOT display in UW’s Primo. What’s the difference? A search for “Display of Local Fields” in the Primo OLH reveals. . .

THE SUPER SLEUTH: TROUBLESHOOTING So the Display: lds 10 field should be getting a $IWWU after that local title added entry. But maybe it is, and there’s a bug – so let’s check the norm rules. Display: lds 10 rule 4 controls the addition of the 960: Note that the only transformation strips some special characters from the end of the field. There’s nothing here about $$I[INST]!

THE SUPER SLEUTH: TROUBLESHOOTING By comparison, let’s look at the rule for Display: lds 06 All of the Display: lds 06 rules contain a transformation that adds the needed $$I[INST] so that institutions that didn’t add the note won’t see it in Primo.

THE SUPER SLEUTH: TROUBLESHOOTING At this point, we realize that the norm rules for Display: lds 10 are missing the transformation that would fix the non-local display issue. Next step: File a request with the Discovery & Delivery’s Norm Rules Team to add the $$I[INST] transformation to the norm rules for PNX field Display: lds 10. Request link: https: //docs. google. com/forms/d/1 e 6 v. ABs 0 y. O 2_Jvq. XJm. Jr. MDBWklfesub 2 Ajmpv. P 6 Ie 6 I/viewform NRWG site: https: //docs. orbiscascade. org/silsdocs/functional%20 areas/discovery/normaliz ation_rules_wg/

NORMALIZATION RULE BASICS • Where to look at norm rules • How to navigate the norm rule sets • What you’ll see

WHERE TO LOOK IN THE PBO Go to Advanced Configuration Full Normalization Rule Configuration. OR Using the drop-down menus, go to Local Data Normalization Sets. Once you reach the list of norm rule sets, click “View” next to the entry for the “ALLIANCE_ALMA_CP” set.

NAVIGATING THE NORM RULE SET The norm rule set is arranged by PNX section and field. PNX: Primo Normalized XML record PNX bookmarklet: javascript: function%20 o(){window. open(location. href+'&show. Pnx=true', "PNX%20 Record")}; o() To see the norm rule that affects a specific field from the PNX record: Change the drop-down to the desired PNX section. Scroll to the field you’re interested in. Click “View”. Example: Display Type – Video: http: //screencast. com/t/S 4 h 4 qw. Am

WHAT YOU’LL SEE Example: Search – Creation Date As you can see, these aren’t your average if/then statements! Rule 1: Takes the 4 -character substring starting at 008 position 7, adds it to the PNX field. Rule 2: Takes the 4 -character substring starting at 008 position 11, adds it. Rule 3: Adds the 260 $$c to the PNX field. Rule 4: Adds the 264 $$c to the PNX field.

WHAT YOU’LL SEE, CONTINUED Order (sometimes) matters. If a PNX field is not repeatable (e. g. , Display – Type), then the first rule that applies to a record is the one that wins. If a PNX field is repeatable, or is set up to merge multiple values into one field, then all rules that apply to the record are used. Transformations are used to format your data before they’re written to the PNX In our prior example, the Format Year transformation takes the first four characters of the string and replaces any non-digit characters with a zero. Transformation documentation is available in the OLH on the “Transformation Routines” page of the Technical Guide. Full details on norm rule logic are available in the OLH in the “Using Normalization Rules Sets” section of the Back Office Guide.

THANK YOU!!