1. WHY SHOULD I CARE ABOUT (PRIMO) NORM RULES?

2. WHAT NORMALIZATION RULES DO Content display in Primo Primo functionality Troubleshooting

3. 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.  PNX: Primo Normalized XML record.  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.  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.

4. 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.

5. 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.

6. 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. :-(

7. 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.

8. 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 lds30 – lds 39  Local search fields lsr30 – lsr 39  If we want a MARC field to be “Clickable” in Primo, we add it to both the Display:lds3[X] and the Search:lsr3[X] fields by creating the appropriate norm rules. The numbers have to match!

9. 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. SalesForce cases are sometimes necessary as well.

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

11. 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”.

12. 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.

13. 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.

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

15. THE SUPER SLEUTH: TROUBLESHOOTING  So the Display:lds10 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:lds10 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]!

16. THE SUPER SLEUTH: TROUBLESHOOTING  By comparison, let’s look at the rule for Display:lds06  All of the Display:lds06 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.

17. THE SUPER SLEUTH: TROUBLESHOOTING  At this point, we realize that the norm rules for Display:lds10 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:lds10.  Request link: https://docs.google.com/forms/d/1e6vA- Bs0yO2_JvqXJmJrMDBWklfesub2AjmpvP6Ie6I/viewformhttps://docs.google.com/forms/d/1e6vA- Bs0yO2_JvqXJmJrMDBWklfesub2AjmpvP6Ie6I/viewform  NRWG site: https://docs.orbiscascade.org/silsdocs/functional%20areas/discovery/ normalization_rules_wg/ https://docs.orbiscascade.org/silsdocs/functional%20areas/discovery/ normalization_rules_wg/

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

19. 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.

20. 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%20o(){window.open(location.href+'&showPnx=true',"PNX%20Record")};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/S4h4qwAmhttp://screencast.com/t/S4h4qwAm

21. 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.

22. 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.

23. THANK YOU!!