View
257
Download
0
Category
Tags:
Preview:
DESCRIPTION
primo
Citation preview
Customer Profile for Primo
September 2009
Confidential Information
The information herein is the property of Ex Libris Ltd. or its affiliates and any misuse or abuse will result in economic loss. DO NOT COPY UNLESS YOU HAVE BEEN GIVEN SPECIFIC WRITTEN AUTHORIZATION FROM EX LIBRIS LTD.
This document is provided for limited and restricted purposes in accordance with a binding contract with Ex Libris Ltd. or an affiliate. The information herein includes trade secrets and is confidential.
Disclaimer
The information in this document will be subject to periodic change and updating. Please confirm that you have the most current documentation. There are no warranties of any kind, express or implied, provided in this documentation, other than those expressly agreed upon in the applicable Ex Libris contract. This information is provided AS IS. Unless otherwise agreed, Ex Libris shall not be liable for any damages for use of this document, including, without limitation, consequential, punitive, indirect or direct damages.
Any references in this document to third-party material (including third-party Web sites) are provided for convenience only and do not in any manner serve as an endorsement of that third-party material or those Web sites. The third-party materials are not part of the materials for this Ex Libris product and Ex Libris has no liability for such materials.
Trademarks
"Ex Libris," the Ex Libris bridge , Primo, Aleph, Alephino, Voyager, SFX, MetaLib, Verde, DigiTool, Preservation, URM, Voyager, ENCompass, Endeavor eZConnect, WebVoyage, Citation Server, LinkFinder and LinkFinder Plus, and other marks are trademarks or registered trademarks of Ex Libris Ltd. or its affiliates.
The absence of a name or logo in this list does not constitute a waiver of any and all intellectual property rights that Ex Libris Ltd. or its affiliates have established in any of its products, features, or service names or logos.
Trademarks of various third-party products, which may include the following, are referenced in this documentation. Ex Libris does not claim any rights in these trademarks. Use of these marks does not imply endorsement by Ex Libris of these third-party products, or endorsement by these third parties of Ex Libris products.
Oracle is a registered trademark of Oracle Corporation.
UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Ltd.
Microsoft, the Microsoft logo, MS, MS-DOS, Microsoft PowerPoint, Visual Basic, Visual C++, Win32,
Microsoft Windows, the Windows logo, Microsoft Notepad, Microsoft Windows Explorer, Microsoft Internet Explorer, and Windows NT are registered trademarks and ActiveX is a trademark of the Microsoft Corporation in the United States and/or other countries.
Unicode and the Unicode logo are registered trademarks of Unicode, Inc.
Google is a registered trademark of Google, Inc.------------------------------------------------------------------------------------------------------------------------------------------
ii
Copyright Ex Libris Limited, 2008. All rights reserved.Documentation produced April 23Document version 2.3Web address: http://www.exlibrisgroup.com
iii
Table of Contents
Chapter 1About this Guide.............................................................................1
Organization of the Guide........................................................................1
Resources.................................................................................................2
PART 1 UNDERSTANDING PRIMO AND PRIMO IMPLEMENTATION.......................3
Chapter 1 Introduction to Primo Implementation...........................................3
Implementation Overview........................................................................4
Key Roles for Primo Implementation.......................................................6
Chapter 2 Introduction to Primo......................................................................8
Primo Administrative Definitions.............................................................8
Primo Components...................................................................................8
Chapter 3Primo Administrative Structure....................................................11
Chapter 4Primo Publishing Platform Configuration: Data Sources and Harvesting.....................................................................................14
Identifying Data Sources for Harvesting................................................14
Methods for Harvesting Data.................................................................17
Sample Data...........................................................................................18
Chapter 5Normalization................................................................................19
Structure of the PNX..............................................................................19
Customizing the Normalization..............................................................20
Publishing Pipes.....................................................................................22
iv
Chapter 6Front End Configuration................................................................23
Views......................................................................................................23
Tabs........................................................................................................24
Search Scopes........................................................................................24
Restricted Search Scopes.......................................................................26
Chapter 7Delivery Configuration...................................................................28
Delivery Categories..............................................................................28
Resource Availability..............................................................................29
Availability Statuses for Physical Items, Microfilm and Print Journals31Availability Statuses for Digital/Electronic Online Resources.............32Availability Statuses for Journals.........................................................32Availability Statuses for Remote Search Resources............................32Harvesting Fixed Availability Status....................................................33Real-Time Availability..........................................................................33
Restricted Delivery Scopes....................................................................35
GetIt! Delivery Links..............................................................................36
Delivery Link Configuration...................................................................37
Chapter 8Users and User Authentication.....................................................41
Staff Users..............................................................................................41
End Users...............................................................................................42
User Groups.........................................................................................42Defining User Groups...........................................................................42End User Authentication......................................................................43
PART 2 DEFINING CUSTOMER INFORMATION FOR PRIMO IMPLEMENTATION......44
Chapter 9Building Your Implementation Team............................................44
Chapter 10.............................................Configuring Institutions and Libraries46
Configuring Institutions.........................................................................46
Loading IPs from a Loader File............................................................51
Configuring Libraries.............................................................................51
v
Loading Libraries from a Loader File..................................................56
Chapter 11.................................................................Configuring Data Sources58
Identifying Data Sources........................................................................58
Specifying Harvesting Methods for Non-Ex Libris Data Sources..........60
Preparing Sample Data for Testing........................................................62
Chapter 12...............................................................Configuring Normalization64
Customizing Normalization Rules..........................................................64
Delivery and Scoping Section..............................................................65Facet Section........................................................................................65Display Section.....................................................................................78Links Section........................................................................................81Enrichment Section..............................................................................81Local fields...........................................................................................82
Chapter 13................................................................................Publishing Pipes85
Defining Pipes........................................................................................85
Availability Update Pipe.........................................................................86
Chapter 14................................................................Configuring the Front End88
Defining Search Scopes.........................................................................88
Defining Restricted Search Scopes........................................................89
Customizing Views.................................................................................91
Chapter 15.........................................................................Configuring Delivery94
Mapping Delivery Categories.................................................................94
Customizing Availability Status Indicator Text......................................95
Activating Real Time Availability Option................................................96
Defining Restricted Delivery Scopes......................................................97
Configuring Delivery Links.....................................................................98
vi
Delivery Link Configuration Examples.................................................100
Example 1 – Online Resource from ILS..............................................100Example 2 – Electronic Journal from SFX..........................................100Example 3 – Physical Item from ILS...................................................102Example 4 – Online Resources from Two Digital Repositories..........102
Chapter 16....................................Configuring Users and User Authentication104
Configuring Staff Users........................................................................104
Configuring End User Groups..............................................................106
Configuring the PDS.............................................................................106
Appendix A......................................OAI-PMH ListRecords and Header Format...................................................................................................112
Appendix B...............................PNX Structure Reference: Sections and Fields...................................................................................................117
Subfields in the PNX............................................................................117
The Control Section..............................................................................118
The Display Section..............................................................................119
The Links Section.................................................................................125
The Search Section..............................................................................127
The Facets Section...............................................................................129
The Sort Section...................................................................................132
The Duplicate Record Detection Section.............................................133
The FRBR Section................................................................................133
The Delivery and Scoping Section.......................................................133
The Ranking Section............................................................................134
The Enrichment Section.......................................................................135
The Additional Data Section.................................................................136
Appendix C..........................................................End-to-end Delivery Examples...................................................................................................138
Part One...............................................................................................138
Part Two...............................................................................................141
vii
Part Three............................................................................................142
viii
About this Guide
The Customer Profile for Primo enables you to prepare for the configuration of the Back Office by gathering the information that you will need during the actual configuration.
Organization of the Guide
The Customer Profile document is organized into two parts:
PART 1 - Understanding Primo and Primo Implementation – Each chapter within Part 1 includes an overview of the Primo components that are used for the specific implementations in the chapter.
PART 2 - Defining Customer Information for Primo Implementation – Each chapter within Part 2 includes the mapping tables that are used to fill the Primo information. In Primo version 1, these tables are consulted during the configuration of the Back Office. In future Primo versions, the mapping tables will be saved in the .csv format and loaded directly into Primo.
Appendix A and Appendix B contain supplemental information that can be referenced if necessary. Appendix C provides end-to-end examples for some of the Primo functionalities.
The following are conventions used throughout this guide:
Table 1: Conventions
Convention Description
Indicates the use of Ex Libris products.
Indicates a note or reminder to the user.
Indicates a reference from the overview chapter to the implementation chapter.
Indicates an example scenario of the Demo customer.
1
About this Guide Customer Profile for Primo
Resources
The following are other guides for the Primo system:
Primo Back Office Administration Guide
Primo Technical Guide
Primo Interoperability Guide
Primo System Administration Guide
Primo Hardware and Software Requirements Guide
Ex Libris Backup Package
2
PART 1 UNDERSTANDING PRIMO AND PRIMO IMPLEMENTATION
Chapter 1
Introduction to Primo Implementation
The purpose of this document is to assist both you and Ex Libris to successfully implement Primo in an efficient manner.
The sections that follow were designed to:
Introduce basic concepts regarding the Primo application and its configuration.
Allow you to map out elements of your institutions’ existing infrastructure to be used with the Primo installation.
Describe configuration options and examples, and guide you in making the decisions necessary for configuring your Primo installation.
After reading each section, use the corresponding appendix to provide information about configuration options you have chosen, and relevant parameters and settings. Although you may not be able to provide all the information required, the information that you do provide will serve as a basis for the Implementation Analysis session. During that session, the topics introduced in this guide will be further explained and discussed.
The configuration options you choose are not binding. Your Ex Libris project analyst will work with you to arrive at the best initial configuration to start your Primo implementation. After the initial configuration and test data load, you may decide in conjunction with your Ex Libris project analyst to make changes to the configuration before switching your Primo installation into production.
3
Chapter 6: ¡Error! Estilo no definido. Customer Profile for Primo
The Ex Libris staff is ready to assist and advise you in any way necessary.We hope you enjoy Primo!
Implementation Overview
Implementation always differs from customer to customer. In general, there are two elements that affect the complexity and duration of the implementation:
The type and number of data sources from which data will be harvested into Primo.
The type of Primo installation: single- or multi-institution installation. As a rule, more effort and resources are required for multi-institution implementations.
This guide will lead you through four basic implementation steps:
Definition of the Primo administrative structure, which includes defining Primo institutions and libraries. An institution is the main administrative unit in Primo. A library is a sub-unit to which every resource belongs.
Definition of the Primo Publishing Platform, which includes determining the data sources to be harvested by Primo and the data transformation from the source format to Primo normalized record. There are three categories of data sources that may be implemented with Primo. Each category requires a different level of customization for implementing the data transformation, and is treated differently in various sections of this document. The three categories of data sources are:
a. Data sources that originate from another Ex Libris product or from an ILS for which a data transformation template already exists.
Ex Libris products include the ALEPH ILS, Voyager (ILS), DigiTool, MetaLib KB, and SFX KB. A transformation template also exists for the UNICORN ILS (from Sirsi/Dynix). Check with your Ex Libris project analyst for a current list of available transformation templates for non-Ex Libris systems.
Existing transformation templates are used to define most elements of Primo’s normalized record. Minor configuration changes can be made to the template for a number of mandatory data elements.
b. Data sources which are based on Generic MARC, Generic Dublin Core, and/or Microsoft Excel or Microsoft Access.
For these data sources, generic templates are used following additional required customization.
4
Chapter 6: ¡Error! Estilo no definido. Customer Profile for Primo
c. Data sources that originate from non-MARC ILS systems and other databases that cannot be transformed based on existing transformation templates.
Configuration of the Front End. Implementation of the Front End includes configuring views, tabs and scopes for each institution. Primo’s Front End user interface is made up of views, while each view can contain tabs. The tabs enable the records to be divided into resource groups or types, by defining for each tab specific search scopes. The search scope groups records so that a search from a specific tab is restricted to only those records.
Implement Authorization and Delivery Policy. Configuration of the Authorization and Delivery Policy includes specifying the end user’s access restrictions that are used by different resources and delivery configuration.
Figure 1 describes Primo’s implementation and configuration flow.
5
Chapter 6: ¡Error! Estilo no definido. Customer Profile for Primo
Figure 1. Primo Configuration Flow
Key Roles for Primo Implementation
You will need to identify members of your staff to play key roles during the Primo implementation process. Following is a list of key roles along with the corresponding responsibilities required throughout the implementation, maintenance, and management of the Primo application.
Note: A single individual may fulfill one or more roles.
Project Management:
Coordinate between your Primo Implementation Team and Ex Libris staff.
6
Chapter 6: ¡Error! Estilo no definido. Customer Profile for Primo
Create a project plan, including a schedule for implementation tasks and milestones.
Manage the implementation tasks based on the project plan in order to meet the agreed-upon milestones.
Coordinate and/or manage training activities.
System Administration Management:
Provide hardware and software support during the installation stage.
Manage technical tasks such as system backups, monitoring, ongoing maintenance, fine-tuning, etc.
Data Management:
Assume ownership of the data management and configuration of the publishing platform.
Note: This role requires familiarity with the library’s data sources, data formats, and the users’ expectations of the library. This role also requires familiarity with web-based applications and knowledge of electronic resources.
Front End Management:
Customize the web-based user interface.
Customize look-and-feel of the views.
Interoperability Management:
Coordinate between all participating data source and delivery applications such as ILS, SFX, Digital Repositories, remote search application (MetaLib in version 1), Patron Delivery Services (application used for managing end user authentication), and others.
Note: This role requires familiarity with the library’s data sources, users, and the users’ expectations of the library. This role also requires familiarity with web-based applications and knowledge of electronic resources. This role can often be filled by the same person who fills the data management role.
Go to Chapter 9 on page 41 to list members of your implementation team and their role(s).
7
Chapter 2
Introduction to Primo
Primo provides users with a universal solution for the discovery and delivery of print and digital information sources, regardless of format and location. It offers advanced, high quality search results based on existing metadata. After identifying the desired materials (through discovery), Primo can facilitate the delivery of the physical item from the library or provide immediate access to digital copies.
Primo Administrative Definitions
Institution — An institution is the main administrative unit in Primo. An institution can contain one or more libraries and repositories.
Library — A library is a sub-unit to which every resource belongs. Every library must belong to a single institution.
End User — Every end user must belong to a single Primo institution.
Resource — A resource is represented within Primo by a Primo Normalized XML (PNX) record.
Primo Components
Primo is comprised of the following components:
Front End — The Primo Front End User Interface is made up of Views, which are the sole means for user interaction with Primo. Each institution can have its own fully customized view. Each view must have a default institution, which is used for end user authentication.
Every view can have one or more tabs. Defining tabs enables you to divide the Primo repository and records from remote resources into resource groups or types.
Within each tab, one or more search scopes can be defined. A search scope groups records so that a search can be restricted to only those records.
After discovery, Primo indicates the availability of the resource in the source system. Primo interacts with the source system to provide more information about the resource or to deliver the resource.
8
Chapter 6: ¡Error! Estilo no definido. Customer Profile for Primo
Search Engine — At the heart of the Primo system is the search engine. The search engine is based on Lucene technology and supports multiple slices to reduce retrieval time for very large data sets. Search functionality includes faceted navigation, ‘did you mean’, paging and sorting.
Publishing Platform — Primo includes a built-in Publishing Platform used to process raw data and to transform formatted raw data into high quality, indexed information that can be quickly and efficiently searched by the Primo search engine.
The processing of each data source is performed by Pipes that recognize various library source formats. This processing includes:
Intelligent harvesting of data. Library data can be harvested using FTP, file copy or Open Archives Initiative (OAI).
Normalization of the data to the Primo standard record format called PNX (Primo Normalized XML).
Primo can harvest and normalize any data in standard XML format using a mapping template. Currently, there are mapping templates for MARC, MAB and Dublin Core. Additional templates are planned for future development. Although the templates can be localized during the implementation process, Ex Libris recommends that you use the existing templates for initial implementation and consider customization only after you begin to use Primo.
Data enrichment based on pre-defined algorithms and external information.
Removal of duplicate records based on pre-defined algorithms.
Grouping of similar titles using a process called FRBRization.
Storage of PNX records in the Primo database.
The normalization mapping templates are configurable using the Primo Back Office.
Patron Directory Service (PDS) — Primo integrates with your existing authentication and user attributes delivery system. Authentication in Primo is handled via the Patron Directory Service (PDS) module. PDS is a web-based application that provides your institution with shared user authentication and single sign-on (SSO) capabilities for the Ex Libris suite of products, including Primo, DigiTool, MetaLib, and ALEPH.
Back Office — The Primo Back Office is a web-based user interface that enables configuration and monitoring of all Primo components. The Back Office is made up of configuration wizards that are based on Primo’s life cycle. This document refers to the relevant sections in the Primo Back Office.
9
Chapter 6: ¡Error! Estilo no definido. Customer Profile for Primo
Database — The Primo database is based on Oracle RDBMS and contains three primary types of content:
PNX (Primo Normalized XML) records and information contributed by users such as reviews and tags. The original source record can also be stored for reference purposes.
Monitoring information such as usage statistics and detailed information on searches.
Primo configuration information.
Once you have completed the forms in this document you will have determined:
The Primo administrative structure — Primo institutions and libraries to be defined for your Primo installation.
The Primo Publishing Platform settings — The data sources to be harvested by Primo, the transformation rules to be used for normalizing the data from its original format to Primo normalized record, and the publishing pipes settings.
The Front End settings — Configurations of the site’s web based interface, including views, tabs, and scopes.
Primo Authorization settings and delivery configuration settings — The delivery and access policies used for different delivery systems.
10
Chapter 3
Primo Administrative Structure
A single Primo installation can be used by a single institution or by several institutions (multi-institution) forming a consortium. Many consortia can form super-consortia.
The Primo institution is the main administrative unit in Primo. (If we compare the Primo institution to administrative units in other Ex Libris products, the Primo institution is similar in concept to the ALEPH500 ADMinistrative library, the Voyager Instance, the MetaLib institution, and an SFX instance.)
The institution is also the main delivery unit. A single Primo site may have multiple delivery systems and Primo must know to which delivery system to send the user. For example, Primo can send the user to a specific SFX instance or ILS server.
Every institution has a defined set of IP ranges. Users belong to a single Primo institution, which is derived from the user’s login via PDS. If the user has not signed in, Primo attempts to derive the institution from the user’s IP address. If this is not possible, Primo links the user to the delivery system of the default institution of the Primo view in use. Every view must have a default institution defined for this purpose.
The institution is a remote search unit. Primo runs remote searches via MetaLib. The sites’ MetaLib installation(s) may include multiple institutions – Primo must know which institution to use.
An institution can have multiple libraries and/or repositories within it. A Primo library is an institutional sub-unit to which every physical resource belongs. A resource is represented within Primo by the PNX record. Every library must belong to one institution.1
In a multi-institution site, you may want to consider defining a “central” institution if either of the following cases exists:
A view exists which belongs to all institutions or to the consortium’s central administration. Every view must be linked to a default institution, which could be one of the member institutions or a “central” institution.
1 The Primo library is similar in concept to the ALEPH500 sub library and Voyager Owning Library. A DigiTool repository is considered a library in Primo.
11
Chapter 6: ¡Error! Estilo no definido. Customer Profile for Primo
A data source exists which belongs to some or all of the institutions. In addition, data sources are linked to institutions, which could be one of the member institution or a “central” institution.
It should be emphasized that a “central” institution is not required functionally in these cases since the view and data source can be linked to a default institution. However, it may make the setup easier to follow.
Note: Users only belong to member institutions, not the “central” institution. Restricted search scopes and delivery scopes are defined only for member institutions since they are the user’s institutions.
Figure 2 shows an example of the Primo Administrative Structure:
Figure 2. Primo Administrative Structure
To configure the administrative structure for your Primo installation:
1. List the institutions to be defined for your installation. For each institution, you will need to:
Provide a unique code and display name (this is required for administrative purposes only and will not be displayed in the user interface).
Provide one or more key strings that can be derived from the source records data and can be used to identify the institution.
12
Chapter 6: ¡Error! Estilo no definido. Customer Profile for Primo
Specify the system and version used to store the source data, as well as the base URL and port used to access that system.
List the range of IP addresses that map to that institution. This enables Primo to assign a default institution to end users that have not signed in.
2. List the libraries to be defined for your installation. For each library, you will need to:
Specify to which institution the library belongs.
Provide a unique code and display name. The Library display name is used when displaying the availability and location information in the brief and full views of the records in the Front End.
Provide one or more key strings that can be derived from the source records data and can be used to identify the library.
Go to Chapter 10 on page 43 to provide information about the institutions and libraries in your installation.
13
Chapter 4
Primo Publishing Platform Configuration: Data Sources and Harvesting
The Primo database can include data from many different sources. For example, you may include bibliographic and holdings data from an ILS, digital and electronic resources from a digital repository, and searchable remote sources2.
Figure 3. Data Sources
Identifying Data Sources for Harvesting
During the Primo implementation, you must identify the existing and planned data sources in your institutions to be harvested by Primo. To provide effective discovery and delivery, Primo harvests data and transforms it into a common and enriched format. This common record is based on a format called Primo Normalized XML (PNX).
Since all records from the data sources are usually harvested and processed during the initial load, which can be very large, Ex Libris recommends that you use the copy harvesting transfer mode to save transfer time.
Following the initial migration, harvesting includes only new, updated, and deleted records.
2 Available using MetaLib only in version 1.
14
Chapter 6: ¡Error! Estilo no definido. Customer Profile for Primo
All of the information fields to be included in each PNX record should be found in a single record in the data source that can be identified by a unique and persistent identifier. Therefore, any information found in records that are related to the main record must be appended to the main record.
For example, when holdings information is stored in one or more records related to the main bibliographic record, you will need to append that holdings information onto the bibliographic record.
When data originates from an ALEPH ILS system, all relevant holdings and availability information is expanded into bibliographic records by a special program called expand_doc_bib_avail. Authority information is expanded using a special program called expand_doc_bib_aut_ref1. For more information on configuring ALEPH for integrating with Primo harvesting, refer to The ALEPH Publishing Mechanism document.
When data originates from Voyager ILS system, all relevant holdings and availability information appears in 949 fields. Authority information appears in 950/951 fields. For more information on configuring Voyager for integrating with Primo harvesting, refer to Voyager®Primo® Integration User’s Guide document.
When data originates from a non-Ex Libris ILS, embed information stored in related records into a local field, such as a 999 field, in the following format:
Table 2: Data Format for Non-ALEPH Data Sources
Data Format
Description
$$a Institution Code
$$b Library code
$$c Collection code
$$d Call number
$$e Number of items
$$f Number of unavailable items. Refer to Resource Availability on page 27 for the definition of unavailable
$$g Availability status. Refer to Resource Availability on page 27 for the definition of availability status
$$h Multi-volume flag – Y/N
$$i Number of loans
Note: If you are not able to extract information on the availability status, you can do one of two things. Determine what availability/location information you can extract and how to extract the information. Or,
15
Chapter 6: ¡Error! Estilo no definido. Customer Profile for Primo
determine whether the information can be derived in Primo, based on the combination of the library/collection or call number.
The structure of each data source record should conform to one of the following standard formats:
MARCXML (http://www.loc.gov/standards/marcxml/)
MARC exchange format (ISO 2709).
Dublin Core XML (http://dublincore.org/documents/dc-xml-guidelines/)
However, the record can include non-standard MARC or Dublin Core fields, for example, non-numeric codes for MARC.
Go to Identifying Data Sources on page 55 to provide information about data sources you plan to harvest with your Primo installation.
Methods for Harvesting Data
Primo supports several methods for harvesting data, including:
FTP — For more information, refer to FTP Harvesting on page 57.
Copy — For more information, refer to Copy Harvesting on page 58.
OAI-PMH — For more information, refer to OAI-PMH Harvesting on page 58.
If the data is being harvested from an Ex Libris system (ALEPH, Voyager, DigiTool, SFX), the standard harvesting methods are used as detailed in Table 3.
Table 3: Harvesting Methods Used for Ex Libris Systems
System Method
ALEPH and Voyager
Versions previous to version 18
Copy – used for initial harvesting
Copy or FTP – used for ongoing harvesting
DigiTool OAI-PMH
SFX Copy or FTP
MetaLib Copy or FTP
For each data source being harvested from a non-Ex Libris system, you need to specify the harvesting methods possible for that data source and whether the system allows extraction of updated records.
16
Chapter 6: ¡Error! Estilo no definido. Customer Profile for Primo
Go to Identifying Data Sources on page 55 to provide information about data sources to be harvested from non-Ex Libris systems.
Sample Data
During the implementation and configuration of Primo, the data normalization, data load and Front End must be configured and tested. Two sample data files in XML format should be prepared for each data source and placed in a separate folder for each data type.
Go to Preparing Sample Data for Testing on page 59 to provide locations of the sample files.
17
Chapter 5
Normalization
Primo enables a library to consolidate print collections, digital repositories and electronic resources. To provide effective discovery and delivery, Primo harvests data and transforms it into a common and enriched format. This common record is based on a format called Primo Normalized XML (PNX).
Structure of the PNX
The PNX is structured in sections, each serving a different purpose. Data may be duplicated, enabling robust flexibility for manipulating data to take advantage of Primo’s capabilities. PNX sections are detailed in the following table:
Table 4: PNX Sections
PNX Section Purpose
Control Formatted data for control purposes, including information about the source and status of the records.
Display Includes the data for brief and full record displays.
Links Contains relevant record links that are used to connect the record in Primo to an external resource.
Search Includes metadata and unstructured data that will be indexed for the search.
Facets Fields that serve as a basis for faceted browsing in the User Interface.
Sort Used to sort records in the User Interface.
De-duplication Includes data required to eliminate duplicate records.
FRBR Grouping Includes data required to group related records (FRBRization).
Delivery and Scoping
Includes information required to manage delivery and scoping for search.
Ranking Includes two boosters for ranking. The boosters can be added using an enrichment routine plug-in which may be based on number of copies or circulation statistics.
Enrichment Includes data required for the enrichment process.
Additional Data Contains data elements required for specific functions in Primo that
18
Chapter 6: ¡Error! Estilo no definido. Customer Profile for Primo
PNX Section Purpose
cannot be extracted from other sections of the PNX.
For detailed information about the structure of the PNX, refer to Appendix B – PNX Structure Reference: Sections and Fields on page 113.
Customizing the Normalization
As source data is imported from various data source remote systems, the incoming records are normalized based on a set of normalization rules. These rules define how the data from the source record is converted to the PNX format. Normalization rules for each data set are based on one of the pre-existing normalization mapping sets templates developed for various data formats.
Templates currently exist for the following formats:
MARC21
ALEPH MARC
ALEPH MAB
UNICORN MARC
Voyager MARC
SFX Knowledge Base
MetaLib Knowledge Base
DigiTool
Generic Dublin Core (DC)
19
Chapter 6: ¡Error! Estilo no definido. Customer Profile for Primo
Figure 4. Normalization of Source Data
To prepare a mapping set appropriate to your library, customization of the normalization rules may be required in certain PNX sections as outlined in the following table.
Table 5: PNX Sections Requiring Customization
PNX Section Fields to customize Description
Delivery and Scoping
Institution
Delivery Category
Restricted delivery scope
Fields that govern search, display and access to resources.
Facet Collection
Library
Codes for subdivisions of the entire resource database, used for grouping.
Display Resource Type
Library Level Availability
Describes the nature of the material and where it can be found.
Links LinktoHoldings
LinktoRequester
LinktoResource
Backlink
OpenURL
OpenURL_fulltext
Defines how to link to the external elements (ILS pages, open URL, etc.).
Search Search scope
Restricted Search Scope
Fields that govern the scopes.
20
Chapter 6: ¡Error! Estilo no definido. Customer Profile for Primo
Note: Other fields can also be customized. In addition, a number of local fields can be added to specific PNX sections where required. This subject should be discussed with an Ex Libris specialist during the Implementation Analysis session.
Go to Customizing Normalization Rules on page 61 to configure the normalization for your data sources.
Publishing Pipes
Harvesting source records and creating PNX records is managed by the Publishing Platform. The Publishing Platform supports scheduled and unattended harvesting and processing of various data formats, allowing interactive monitoring and control over the entire set of activities.
Within the Publishing Platform, PNX records are created by publishing pipes. Every data source has its own pipe. Each data source may have its own set of normalization rules, or several data sources may be linked to one set of normalization rules.
Go to Chapter 13 on page 81 to define the publishing pipes for your data sources.
21
Chapter 6
Front End Configuration
The Primo Front End User Interface is made up of Views, which are the sole means for user interaction with Primo. Every view can have one or more tabs. Defining tabs enables you to divide the Primo repository and records from remote resources into resource groups or types.
Within each tab one or more search scopes can be defined. A search scope groups records so that a search can be restricted to only those records.
Figure 5. Front End Configuration
Views
A view is a customized interface that enables you to define:
A different look-and-feel for different user groups. Every view can have its own logo, header, header links and more.
A different set of tabs and search scopes to be displayed for different user groups.
Each institution can have its own fully customized views. Views can be defined for individual institutions within a consortium or for all institutions within a consortium. However, each view must have a default institution, which is used by the delivery system URL incase user institution cannot be determined.
22
Chapter 6: ¡Error! Estilo no definido. Customer Profile for Primo
Every view can have a different list of search scopes as well as the default scope. For more information on scopes, refer to Search Scopes on page 23.
By default, Primo comes with two views:
View only including the reference data scope.
Basic default view to see your data after initial load.
Go to Customizing Views on page 87 to specify the views to be created for your installation.
Tabs
Every view can have one or more tabs. Defining tabs enables you to divide the Primo repository and records from remote resources (such as from MetaLib) into resource groups or types. Using tabs in Primo is similar to the use of links in Google to locate resources of different types such as images and maps.
Being that a primary advantage of Primo is to provide a unified search interface for all library resources, Primo is initially configured with a single tab. You are encouraged to consider carefully whether to implement a multi-tab configuration after your switch to production.
Search Scopes
A search scope groups records so that a search can be restricted to only those records. There are two types of search scopes: local and remote.
Local — Represents a subset of the Primo repository.3 The default local scope includes the entire Primo repository.
For many institutions, additional local scopes may not be necessary. For consortium installations, it may be advantageous for each institution to have a separate local scope that includes only the resources of that institution. In addition, a shared scope would include the resources of the entire repository.
Remote — Represents a subset of records from remote resources. A remote scope is based on MetaLib QuickSets, which are lists of remote resources that are preconfigured for specific user groups by librarians. Most installations will have one or more QuickSets to be added to a remote scope.
For example, a consortium with three institutions may have a different view for each institution, or it may decide to have four views: one per institution
3 A local search scope is similar to an ALEPH logical base.
23
Chapter 6: ¡Error! Estilo no definido. Customer Profile for Primo
and one shared view. For each institution, the default scope is the local scope set for the institution in addition to the shared scope – that is, a scope shared between institutions in the consortium – plus, a remote scope consisting of a list of MetaLib QuickSets.
For example, our consortium includes a North Campus, a South Campus, and a Lake Campus. Each is defined as an institution in Primo. The following views are defined:
North Campus View
South Campus View
Lake Campus Central View
Shared View (All Campuses View)
For each view, the following scopes are defined:
North Campus View:
North Campus Local scope
All Campuses Repository
Remote Scope (North Campus’ MetaLib quicksets)
South Campus View:
South Campus Local scope
All Campuses Repository
Remote Scope (South Campus’ MetaLib quicksets)
Lake Campus View:
Lake Campus local scope
All Campuses Repository
Remote Scope (Lake Campus’ MetaLib quicksets)
Shared View (All campuses View):
All Campuses Repository
Determine which local scopes you need by addressing the following questions:
1. If you are a consortium, do you want a separate view for each institution?
2. If so, which data sources do you want your users to search by default?
24
Chapter 6: ¡Error! Estilo no definido. Customer Profile for Primo
3. Do you want your users to search the entire Primo repository or to start by limiting their search to a particular subset of resources?
If you use MetaLib, consider which QuickSets should be defined as a remote scope for each view.
Go to Defining Search Scopes on page 84 to specify the search scopes to be created for your installation.
Restricted Search Scopes
Restricted search scopes restrict groups of records to specific users. Only users that are authorized to view the restricted records will be able to search and display them in Primo. For example, a restricted search scope of Manuscripts can be restricted for search and display to the group of Graduate Users only.4
Restrictions can be defined based on the following parameters:
The Institution parameter restricts access to resources for users belonging to specific institutions.
The User group parameter restricts access to resources based on user groups. One of the groups can be Non-Guest, meaning that the user need not belong to a specific group but is required to sign-in.
The On/Off campus parameter restricts access to resources based on whether the user is on-campus – that is, the user’s IP address is within the IP range of an institution – or off-campus.
Determine which restricted search scopes you need by addressing the following questions:
1. Do you have any records that can be searched by some users and denied to all others?
2. Do you have any criteria in the data source that will identify those records?
Go to Defining Restricted Search Scopes on page 85 to specify the restricted search scopes to be created for your installation.
4 A restricted search scope is similar to an ALEPH denied logical base.
25
Chapter 7
Delivery Configuration
Primo’s “Delivery” functionality includes:
Indicating the availability status of the resource found following a search.
Providing two delivery links:
GetIt URL – The best delivery option Primo can offer based on resource availability, delivery category, data source, and user details.
GetIt2 URL – Additional delivery options or extended services that can be offered based on the record.
The availability status of the resource is displayed in the following Primo interfaces:
The Brief results screen of the User Interface. Here the search results can also be filtered based on the availability status.
The Full display screen of the User Interface. As mentioned above, the GetIt delivery links are based on four elements: resource availability, delivery category, data source, and user details. The following sections describe the delivery category and resource availability concepts in more detail.
Delivery CategoriesA delivery category represents a type of resource. Delivery functionality and configuration depend on the delivery category. The following delivery categories are supported:
Physical item – Represents books, print journals, CDs, tapes, and all other physical items. The expected data source for physical items is the ILS catalog.
Microfilm – The expected data source for microfilm items is the ILS catalog.
SFX Resource – The expected data source for electronic journals is the ILS catalog and/or the SFX knowledgebase. Primo attempts to remove duplicate print and electronic journal records.
Online resource – Represents all digital or electronic resources except for journals. The expected data source for online resources is the institutions’ digital repositories. However, the ILS may also contain links to digital
26
Chapter 8: ¡Error! Estilo no definido. Customer Profile for Primo
resources. For online resources the system uses restricted delivery scopes to indicate access restriction. For more information, refer to Restricted Delivery Scopes on page 32 .
Remote search resource – Represents resources located using the remote search function via MetaLib.
For example, an article indexed in PubMed and located via MetaLib is considered a remote search resource.
MetaLib resource – Represents resources loaded from the MetaLib knowledgebase.
Primo determines the delivery category as follows:
For institutions using the MARC21 standard, an internal algorithm that creates delivery categories is used.
For data sources originating from DigiTool, SFX and MetaLib, a default value is used. For example, resources from MetaLib are tagged as remote search resources.
For institutions using the MARC21 standard as well as DigiTool, SFX, or MetaLib products, a delivery category field is calculated automatically with no need to be updated.
If the data source comes from an ILS utilizing a data standard other than MARC21 (such as MAB or UNIMARC) the delivery category field must be configured. In this case, you will need to create a mapping table as well as configure normalization rules. For more information, refer to Configuring Normalization on page 61.
If necessary, go to Mapping Delivery Categories on page 90 to map delivery categories for your data sources.
Resource Availability
Generally, for physical resources, availability indicates whether or not an item is in the library. For digital and electronic resources, availability indicates whether or not access to the resources is restricted.
27
Chapter 8: ¡Error! Estilo no definido. Customer Profile for Primo
Note: Primo does not control access to the resources – this is done by the source system. Primo indicates to the user whether or not access to the resource is restricted. Availability depends not only on the status of the resource but also on the authorization the user has regarding the resource.
Fixed availability status relates only to the resource, and is received from the data source. Calculated availability status is generated by Primo, and takes into account information about the user’s institution and resource availability.
Table 6 lists the possible fixed and calculated availability statuses for each delivery category.
Table 6: Availability Statuses Per Delivery Category
Delivery Category Fixed Statuses Calculated Statuses
Physical Items
Microfilm
Print Journals
Available
Check holdings
Unavailable
Does not exist in my institution (check holdings)
Does not exist in my institution (unavailable)
Check holdings
Available in my institution
Available in other institution*
Unavailable in all institutions*
Digital/Electronic Online Resource
MetaLib Resource
No restrictions
Restricted access
No restrictions
Restricted access
May be restricted
Remote Search Resources
Full text
No full text
* These calculated statuses are applicable in multi-institution environment only.
You can customize the text of the availability status that appears on the search results screen indicating the resource availability.
Go to Customizing Availability Status Indicator Text on page 91 to change the default availability status text for your installation.
Availability Statuses for Physical Items, Microfilm and Print JournalsFixed availability statuses are either sent by the source system or derived in Primo using data from the source system. The fixed availability statuses include:
28
Chapter 8: ¡Error! Estilo no definido. Customer Profile for Primo
Available — Indicates that the item is in the library; it is not checked out, on hold, or undergoing maintenance. This status does not consider whether the end user has authorization to check out the resource.
Unavailable — Indicates that the item is not available because it is checked out or undergoing maintenance.
Check holdings — Indicates that the status is unknown. This status may be used for multi-part resources, like journals, for which a detailed availability status is required. However, for filtering purposes, this status is equivalent to being Available.
Calculated availability status takes into account the user details (institution and user group) and resource availability. Possible statuses include:
Available in my institution — Indicates that the item is available in the user’s institution in one or more of the libraries.
Available in other institution —The status indicates that the item exists in the user’s institution but is currently not available. However, the item is available in another institution in the consortium. This is only relevant for a consortium where Primo is implemented as multi-institution environment.
Unavailable in all institutions —The status indicates that the item is not available in any institution in the consortium. This is only relevant for a consortium where Primo is implemented as multi-institution environment.
Does not exist in my institution — There are two possible statuses:
Does not exist in my institution: Unavailable – Indicates that the item does not exist in the user’s institution, and there is currently no other possible option to offer the user. Since the resource was found in the Primo repository, the assumption is that the item does exist in another institution.
Does not exist in my institution: Check holdings – Indicates that the item does exist in the user’s institution but detailed holdings should be checked.
Availability Statuses for Digital/Electronic Online ResourcesFixed availability statuses are sent by the source system and include:
No restrictions — Indicates that the item can be accessed by all users.
Restricted access — Indicates that there are some access restrictions.
29
Chapter 8: ¡Error! Estilo no definido. Customer Profile for Primo
Calculated availability status takes into account the user details (institution and user group), and restricted delivery scopes. For more information, refer to Restricted Delivery Scopes on page 32.
Possible calculated statuses include:
Not restricted — Indicates that the item can be accessed by the user.
Restricted access — Indicates that the user is not authorized to access the item.
May be restricted — Indicates that the user may be restricted, however Primo does not have enough information to determine for sure.
For example, when DigiTool is the data source system, access restrictions are calculated by Primo based on the restrictions indication, if any, within the source data. For this calculation Primo uses a mechanism called restricted delivery scope. For more information, refer to Restricted Delivery Scopes on page 32.
Note: If you do not want to display access indication in Primo and would like to rely on the source system to determine authorization, you can define the status of those items as not restricted. Primo will then always attempt to access the digital object, and the data source will reject the user if he/she is not authorized.
Availability Statuses for JournalsPrimo attempts to eliminate duplicate records for electronic and physical journals. In general, if an electronic version exists it is given priority unless it is not available to the user based on his home institution. In this case, the print journal will be given priority. This behavior is not configurable in the system.
Availability Statuses for Remote Search ResourcesThere is no fixed availability status for remote search resources. The SFX system chosen based on the user’s institution will be queried to determine if the user has access to the full-text service. Primo provides the user’s IP address and/or the PDS handle so that restriction thresholds in SFX can be checked.
Calculated availability statuses include:
Full-text – Indicates that the full-text service is available.
No full-text – Indicates that no full-text service is available.
30
Chapter 8: ¡Error! Estilo no definido. Customer Profile for Primo
Harvesting Fixed Availability StatusPrimo receives the fixed availability status of each resource from the data source system. When data originates from an ALEPH ILS system, Primo calculates the availability status at the library level for physical items, microfilms, and print journals. When data originates from a Voyager ILS system, Primo calculates the availability status at the collection level for physical items, microfilms, and print journals.
A resource is available when the total number of items minus the number of unavailable items is greater than zero. A resource is unavailable when the total number of items minus the number of unavailable items is less than or equal to zero.
ALEPH inserts either available, unavailable, or checkholdings into sub field $$e of the AVA field when information is expanded into bibliographic records.
Voyager inserts either available, unavailable, or checkholdings into sub field $$e of the 949 field.
For more information on harvesting data sources, refer to Identifying Data Sources for Harvesting on page 14. For more information on normalization of data sources, refer to Configuring Normalization on page 61.
When data originates from a system other than ALEPH/Voyager ILS, you should address the following questions:
1. Are you able to extract availability information on the copy or library level and integrate it into source records?
2. If so, availability status should be loaded into a locally defined field, for example a 999 field, in format detailed in Table 2, page 15.
Real-Time Availability “Real-time availability” (RTA) means that it is possible to get the availability statuses for physical items in “real time” from the source system. RTA can be established for the source systems that have API by means of which the availability statuses can be retrieved.
RTA is invoked only if the delivery category of the record is “Physical Item” or “Microform.” The program updates the Library Level Availability field (display/availibrary), which is the basis for all availability status displays in the Front End. If RTA fails for some reason, the system displays the availability status that is stored in the PNX.
Note: RTA assumes that the records already have the Library Level Availability field, which should be created by the publishing pipe.
31
Chapter 8: ¡Error! Estilo no definido. Customer Profile for Primo
Currently, Primo delivers an RTA program for ALEPH. Customers can write their own RTA program by using the Primo RTA plug-in. For more information, see the Primo API Guide.
To activate the RTA feature, use the following page to update the Real Time Availability mapping table:
Primo Home > Initial Configuration Wizards > Primo Configuration Wizard > Step 4: Front End Configuration Wizard > Step 2: Restrictions and Delivery Configuration Wizard > Step 6: Real Time Availability Configuration
For more information, see Activating Real Time Availability Option on page 92.
Go to Customizing Availability Status Indicator Text on page 91 to update the status indicator.
Restricted Delivery Scopes
For online resources and digital repositories, the indication of resource availability is calculated based on restricted delivery scope.
Figure 6. Restricted Delivery Scopes
32
Chapter 8: ¡Error! Estilo no definido. Customer Profile for Primo
Delivery restrictions are defined based on the following parameters:
Institution – Restricts delivery access to resources based on the user belonging to the specific institution.
User group – Restricts delivery access to resources based on user groups. One of the groups can be Non-Guest, meaning that the user need not belong to a specific group but is required to sign-in.
On/Off campus – Restricts delivery access to resources based on whether the user is on-campus – that is, the user’s IP address is within the IP range of an institution – or off-campus.
Additional restrictions – If there are more granular restrictions, for example access is permitted only to participants of a specific course, you can flag a resource as having "additional restrictions”. In this case, Primo cannot definitively determine whether the user can access the resource.
Determine which restricted delivery scopes you need by addressing the following questions:
1. Do you have any online resources that should be indicated as restricted for access?
2. If so, which users should have access and which should not?
3. Do you have any criteria in the data source that will identify those records?
For example, certain online resources in the library should be accessible only to Law Faculty members. There is a note option called “faculty use” that appears in sub-field $$z of 856 field of restricted on-line resources. Using the Normalization Rules Editor you can define that all resources that have 856$$z=”faculty use” should be assigned restricted delivery scope “FACULTY”. You can then define that only users that belong to “Law Faculty” end user group can access resources that belong to “FACULTY” scope. For more information on setting normalization rules, refer to Customizing Normalization Rules on page 61.
Go to Defining Restricted Delivery Scopes on page 93 to specify the restricted delivery scopes to be created for your installation.
GetIt! Delivery Links
Primo is not a delivery system. It interacts with the source systems to provide information about resource availability, and provides the end user with links to delivery systems. For example, Primo links to the ILS for placing requests and the digital repository for viewing digital resources.
33
Chapter 8: ¡Error! Estilo no definido. Customer Profile for Primo
GetIt! functionality provides two levels of links:
GetIt! URL – Represents the best delivery option Primo can offer.
GetIt!2 URL – Represents additional delivery options or extended services that can be offered.
If the GetIt! URL is not available, Primo attempts to invoke the GetIt!2 URL.
Both levels of links are configurable based on the delivery category, calculated availability status, and optionally, based on the data source. You can configure the following:
GetIt! display text – Represents the text which appears on the links to the available resources.
Figure 7. GetIt! Display Text
GetIt! and GetIt!2 URL links and text – Represent the links that appear on each tab indicating the delivery option.
To configure the GetIt! text and links, you must customize the default fields in the GetIt! mapping tables. You can customize the GetIt! mapping table by accessing the Front End Wizard in the Back Office.
34
Chapter 8: ¡Error! Estilo no definido. Customer Profile for Primo
Delivery Link Configuration
Behind every GetIt! link is a URL that is calculated by Primo in real time, recommending the best delivery option for getting the resource from the source system. The calculation is based on the calculated availability status, resource delivery category and optionally data source. You can configure which type of GetIt! link should be recommended based on the resource’s delivery category and availability status, and optionally, the resource’s data source.
Every type of GetIt! link has a corresponding field in the links section of the PNX record. The following linking fields are available:
OpenURL – Standard that provides the syntax for transporting bibliographic metadata and identifiers of objects between information services.
OpenURL_fulltext – OpenURL that is limited to the full-text service.
OpenURL_service – OpenURL that is limited to a service other then full-text
LinktoHoldings – Displays holdings and request options in the source system.
For consortium installations, the following links may be used:
LinktoHoldings_available – Link to holdings display and request options in the source system only if the item is available in the user’s institution.
LinktoHoldings_unavailable – Link to holdings display and request options in the source system even if the item is unavailable in the user’s institution.
LinktoHoldings_doesnotexist – Link to holdings display and request options in the source system even if item does not exist in user’s institution.
LinktoRequest – Link to a form or web page where a user can place a request.
Backlink – Link back to the original record in the source repository.
LinktoResource – Link to the resource itself; for example, to the full-text resource or to an image.
LinktoTOC – Link to the table of contents.
LinktoAbstract – Link to the abstract.
LinktoReview – Link to a review.
35
Chapter 8: ¡Error! Estilo no definido. Customer Profile for Primo
LinktoPrice – Link to a price.
LinktoFindingAid – Link to a finding aid.
LinktoUC – Link to a Union Catalog; for example, WorldCat.
Thumbnail – May be added from the Enrichment section of the Pipes Wizard in the Back Office.
AdditionalLink – Related to content link.
For every delivery category, calculated and availability status, and optionally data source, the link function should be defined as in the following examples.
Example 1:
Delivery Category Availability Status GetIt! URL GetIt!2URL
Physical Items, Microfilm and Print Journals
Available LinktoHoldings OpenURL
Unavailable LinktoRequester OpenURL
Note: The GetIt!2 option is not required. If there are no additional services to offer, GetIt!2 does not need to be defined.
In this example, the configuration is made for resources stored in ALEPH ILS:
1. For physical items available in the library, invoking the GetIt! link takes the user to the List of Holdings screen for this resource in ALEPH, where all information about its items and holdings display.
2. For physical items not available in the library, invoking the GetIt! link takes the user to the List of Holdings screen for this resource in ALEPH, where the user can put a hold request for the item.
If the same configuration is made for resources that are stored in a system other than ALEPH ILS, which uses separate screens for available and unavailable items, the GetIt! link takes the user to the relevant screen in the ILS, depending on whether the record is available or not.
Example 2:
Delivery Category
Availability Status GetIt! URL GetIt!2 URL
Online Resources
No restrictions LinktoResource OpenURL
Restricted access Backlink OpenURL
36
Chapter 8: ¡Error! Estilo no definido. Customer Profile for Primo
According to these definitions, when the user’s search result is an unrestricted online resource, invoking the link will take the user directly to the resource. If access to the resource is restricted, invoking the link will take the user back to the original record in the source repository where the user may find an explanation for the restriction. For example, the resource may be restricted only to users who sign-in.
Primo comes pre-configured with linking mechanisms that can be activated for different combinations of delivery category, availability status and data source. The default configuration can be customized where required.
When modifying the delivery configuration, you should consider for every combination of delivery category, availability status and optionally, data source, which linking mechanism should be activated. This mapping is customized using the normalization rules, discussed in Customizing Normalization Rules on page 61.
For additional examples, refer to Delivery Link Configuration Examples on page 96.
For a full scenario of how the link mechanisms work, refer to Appendix C – End-to-end Delivery Examples.
Determine changes needed in the default delivery link configuration by addressing the following questions:
For each data source, which delivery services can you offer users?
For each data source, what is the URL for these services?
Go to Configuring Delivery Links on page 94 to customize the pre-configured linking mechanism for your installation.
37
Chapter 8
Users and User Authentication
There are two types of Primo users:
Staff users – Members of your library staff or other employees of your institution who configure or maintain Primo using Back Office functions.
End users – Typically, library patrons or other types of users who search library resources using Primo’s Front End user interface.
Staff Users
Members of your library staff or other employees of your institution should be defined in Primo as staff users. Each staff user is assigned one or more authorization roles, depending on the actions that should be permitted to that user. The following table lists the available authorization roles and the corresponding actions permitted.
Table 7: Authorization Roles
Authorization Role Actions Permitted
Administration (Anna, Inma, Elías, Andrés, Isabel A.)
Perform all tasks using the Back Office user interface.
Data Management (Anna, Inma, Elías, Andrés, Isabel A.)
Manage and configure Data Sources and Pipes settings using the Pipes Wizard.
Front End Management (Anna, Inma, Elías, Andrés, Isabel A.)
Manage and configure delivery and user interface settings using the Front End Configuration Wizard.
Monitoring and Maintenance (Anna, Inma, Elías, Andrés, Isabel A.)
Monitor Primo status and schedule Primo tasks using the Monitoring Primo Status interface.
Reports (Anna, Inma, Elías, Andrés, Isabel A.)
View reports and statistics using the View Reports interface.
Go to Configuring Staff Users on page 100 to configure the list of staff users and their authorization types.
38
Chapter 8: ¡Error! Estilo no definido. Customer Profile for Primo
End Users
The list of valid end users is drawn from your institution’s existing authentication system. Refer to End User Authentication on page 40 for more information.
User GroupsYou may define user groups for end users. User groups are used for authorization purposes by defining search or delivery restrictions:
Restricted access to records using the search. For example, some records in an institutional repository should be accessible only to graduate students and faculty members.
Restricted access to a particular delivery option. For example, you may restrict access to an external library resource.
Defining User Groups
Determine which user groups you need by addressing the following questions:
1. Do you want to offer full access to all resources to all end users? If so, then you have no need to define user groups, and you may skip this section.
2. Do you have a need to restrict search on particular resources to only specific groups of users?
3. Do you have a need to restrict delivery access to particular online resources to specific groups of users?
4. Do you have a need to limit access – search or delivery – to particular resources only to users that are located on-campus?
5. Do you have a need to limit access to any resources according to institution, IP address, or user status (such as faculty and staff, graduate students, undergraduate students)?
You can specify user groups by mapping them to a certain user status or category.
Note: If you already use MetaLib in your institution, any user groups defined for MetaLib will also be used by Primo. If you have not yet defined user groups, define them using the User Group Wizard in the Authentication Wizard section of the Back Office. Refer to End User Authentication on page 40.
39
Chapter 8: ¡Error! Estilo no definido. Customer Profile for Primo
Go to Configuring End User Groups on page 102 to configure the list of end user groups.
End User AuthenticationPrimo integrates with your existing authentication and user attributes delivery system. Authentication in Primo is handled via the Patron Directory Service (PDS) module.
Every end user must be a member of a single Primo institution. Authentication is done via the institution that the end user is a member of. If the user signs in, the user’s institution is derived via the PDS. If the user does not sign in, Primo attempts to derive the user’s institution from the user’s IP address. If this is not possible, authentication is attempted via the default institution of the Primo view being used. Therefore, every Primo view must have a default institution defined.
PDS is a web application that provides your institution with shared user authentication and single sign-on (SSO) capabilities for the Ex Libris suite of products, including Primo, DigiTool, MetaLib, ALEPH, and Voyager. PDS can check whether a user attempting to access one Ex Libris system has already been authenticated to access another Ex Libris system. If so, PDS will log the user in without requesting a username and password. Similarly, a user logging out of one Ex Libris system can be automatically logged out of all Ex Libris systems that are working with the same PDS, as well as being logged out of the PDS itself (single sign-off).
Neither Primo nor PDS maintain a user database. PDS is configured to integrate with your institution’s local authentication server and user database, such as an LDAP directory service.
Note: The authentication server should be configured for each institution separately.
The following Ex Libris product versions also use PDS:
MetaLib (version 3 and higher)
DigiTool (version 3.0 and higher)
ALEPH (version 17.01 and higher) may be configured to use PDS
Voyager (version 6 and higher)
Go to Configuring the PDS on page 102 to configure the PDS.
40
PART 2DEFINING CUSTOMER INFORMATION
FOR PRIMO IMPLEMENTATION
Chapter 9
Building Your Implementation Team
List the members of your implementation team and their role in Form 1. Choose one or more roles by typing an "X" into the appropriate box. For information about roles, refer to Key Roles for Primo Implementation on page 6.
You will use the information filled in this form to guide you during the configuration of the Back Office.
41
Chapter 10: ¡Error! Estilo no definido. Customer Profile for Primo
Form 1: Implementation Team Members Form
42
Chapter 10
Configuring Institutions and Libraries
Use this appendix to provide information about the institutions and libraries in your Primo installation.
Note: Use the forms in this section to prepare the mapping tables for each of the institution(s) libraries. The information filled in the institution and library mapping tables is consulted during the configuration of the institutions and libraries in the Back Office. For more information, refer to the instructions in the Performing Initial Configuration chapter of the Primo Administrator Guide. In addition, it is possible to load the list of the institution’s libraries and IP’s directly into the database from a tab-delimited file.
For information about how institutions and libraries make up the administrative structure of your Primo installation, refer to Primo Administrative Structure on page 11.
To help you fill in your forms, please refer to the example of the demo customer which is analyzed here. The demo customer is a consortium of two universities – North University and South University. These universities both share the same ILS system (Aleph) and digital repository (DigiTool). Each university has its own remote resources system (MetaLib) and SFX instances.
You will use the information filled in the forms in this chapter during the configuration of the institutions and libraries in the Back Office. For configuration instructions, refer to Step 1: Defining Institutions in the Performing Initial Configuration chapter of the Primo Administrator Guide. To configure your institutions, access the following path in the Back Office:
Primo Home -> Initial Configuration Wizards -> Primo Configuration Wizard -> Step 1: Defining Institutions
Configuring Institutions
To configure the institutions in your installation:
1. List the institutions in Form 2. For each institution, fill in the following fields:
Key String(s) — List one or more strings that identify the institution in the data source records.
43
Chapter 10: ¡Error! Estilo no definido. Customer Profile for Primo
If your Primo installation is integrated with ALEPH ILS, the institution is usually identified by an Administrative library (ADM code) as it appears in subfield a of the AVA field.
If your Primo installation is integrated with Voyager ILS, the institution is usually identified by a Voyager Instance code as it appears in subfield a of the 949 field, which is specified in Voyager for the extract.
If the institution can be identified by more than one key string in the source data, separate each key string with a comma.
Institution Code — Assign a unique code for the institution that will identify it throughout the Primo system. The Institution Code can consist of up to 100 alphanumeric characters (uppercase letters only). Do not use any spaces or special characters.
Display Name — Enter the name of the institution, as it should display to the user. The display name can consist of up to 255 characters. The institution’s display name displays in various places in the Back Office, where different configuration options for different institutions are implemented. For example, views can be created for different institutions, so you will have to specify the institution of the view. The display name will not display in the Front End.
Example 1 – Demo Customer Institution Definitions
As described above, the demo customer has two universities: South and North. Each university is defined as an institution in Primo. Thus, our demo customer has North and SOUTH institutions.
Example 2 – Demo Customer Libraries Definitions
Each of the two universities has two libraries:
North University has the Law Library and the Main Library.
South University has the Education Library and the Science Library.
Each library is defined as a unit (sub-library) in ILS Aleph source data, with the following codes:
North University – NLAW and NMAIN
South University – SEDUC and SSCI
Therefore, the institutions that can be derived from the sub-library codes as they appear in the source data (AVA$$b field) are:
Source Key String(s) Institution Code Institution Display Name
NLAW, NMAIN NORTH North University
SEDUC, SSCI SOUTH South University
44
Chapter 10: ¡Error! Estilo no definido. Customer Profile for Primo
Form 2: Institution List Form
Source Key String(s) Institution Code Institution Display Name
UPV50 UPV Universidad Politécnica de Valencia
2. Specify IP address ranges mapping to each institution in Form 3. The IP address allows Primo to assign a default institution to end users that have not signed in. An institution may have more than one valid IP address range. For each range of IP addresses, fill in the following fields:
Institution Code — Enter the unique code assigned to the institution in Form 2.
IP Address Range — Enter the IP address ranges in the Start and End columns.
Note: With Primo 2.0 and later releases, it is possible to load the list of IP’s into the database from a loader file. For more information, see Loading IPs from a Loader File on page 47.
Note: If a "central" institution is defined, do not define IPs for the “central” institution because they will be defined per member institution and users should be linked to member institutions based on the IP.
Example 3 – IP Ranges Definitions for Demo Customer Institutions
We will define IP ranges for both North University (NORTH Primo institution) and South University (SOUTH Primo institution).
Institution Code
IP Address Range
Start End
NORTH 111.222.333
555.666.777
SOUTH 222.333.444
777.555.666
45
Chapter 10: ¡Error! Estilo no definido. Customer Profile for Primo
Form 3: Institution IP Address Mapping Form
3. Specify the delivery systems and versions used to link to the source data for delivery (GetIt!) purposes, as well as the base URL and port used to access those systems in Form 4.
Delivery System and Version — Enter the name of the system used at the institution as a data source, and the version of that system being used. Some examples are ALEPH version 18, DigiTool version 3, and MetaLib version 4.
Institution Code — Enter the unique code assigned to the institution in Form 2.
MetaLib Institution Code — Indicates to the system the MetaLib Institution to use during a remote search for this Institution
For a central institution, if the consortium has a central MetaLib institution, this institution can be used. Otherwise, a default MetaLib institution should be defined. This default institution is required for users that are not signed-in and are not within the IP range of any other institution.
SFX Instance Code — The code of the SFX instance used by the Institution
Base URL: Port — Enter the URL that is used to access the data source and the port. For example, 111.222.333:8991.
For a central institution, default URLs should be defined.
Example 4 – Delivery of the System of the Demo Customer Institutions
North University and South University share the same ILS system (Aleph) and Digital Repository (DigiTool). Each university has its own remote resource system (MetaLib) and SFX instances.
46
Chapter 10: ¡Error! Estilo no definido. Customer Profile for Primo
Delivery System and Version
Primo Institution Code
MetaLib Institution Code
SFX Instance Code
Delivery System Base URL
ALEPH ALL http://aleph-demo.exlibrisgroup.com:8992/F
DigiTool v.3 (Digital Repository)
ALL http://www.digi-tool.com:1801//webclient
MetaLib, v.4
NORTH NORTH http://metalib1-demo.exlibrisgroup.com?user_name=user&user_password=password*
SOUTH SOUTH http://metalib2-demo.exlibrisgroup.com?user_name=user&user_password=password*
SFX v.3 NORTH NORTH http://demo.exlibrisgroup.com:9003/demo1
SOUTH SOUTH http://demo.exlibrisgroup.com:9003/demo2
*The MetaLib base URL must include the MetaLib staff role, username, and password so that Primo can activate the MetaLib API.
Form 4: Institution Data Source Mapping Form
RegardingAleph and Aleph Test port: s we requested an encripted port (443) but it seems not to be working…
Loading IPs from a Loader FileWith Primo 2.0 and later releases, it is possible to load the list of IP’s into the database from a tab-delimited file. The Load IPs function exists in the following places in the Institution Wizard:
47
Chapter 10: ¡Error! Estilo no definido. Customer Profile for Primo
Institutions List — this type of load is intended for sites that want to load IPs from multiple institutions in a single Excel file.
Libraries List (of a specific institution) — this type of load is intended for sites that want to load the IPs of a single institution.
Note: To use IP loader, all text files must be UTF-8.
To create a tab delimited UTF file from an Excel sheet, perform the following steps:
1. Save the Excel sheet as Text (tab delimited).
2. Open the saved text file in Notepad and save as a Text document with UTF-8 encoding. Save the file under a different name.
Configuring Libraries
With Primo 2.0 and later releases, you can load a list of the institution’s libraries into the database from a tab-delimited file. For more information on creating a loader file, see The last three libraries correspond to 3 reading rooms.Is that correct? Why? on page 53.
To configure the libraries in your installation:
List the libraries in Form 5. For each library, fill in the following fields:
Institution Code – Unique code assigned to the institution in Form 2.
Key String(s) – List one or more strings which identify the library in the data source records. If ALEPH is being used as the data source, the library may be identified by sub-library code as it appears in subfield b of the AVA field. If Voyager is being used as the data source, the library may be identified by the Voyager Owning Library code as it appears in subfield b of the 949 field. If UNICORN is being used as the data source, the library may be identified by the codes that are in the subfield 1 and subfield m of the 999 field. If the library may be identified by more than one key string, all possible values should be in the same cell separated by commas. Also, it is possible for the source library code to be created from two or more strings by adding a space and they should be treated like a single value. For example:
ABC,XYZ – two source codes
ABC XYZ – single source code
Length: All source codes for the same Primo Library can be up to 255.
48
Chapter 10: ¡Error! Estilo no definido. Customer Profile for Primo
Primo Library Code – Assign a unique identifier for the library that will identify it throughout the Primo system. Maximum length is 255. Do not use any spaces or special characters.
Primo Library Display Name – Enter the name of the library, as it should be displayed to the user. The display name can be up to 255 char characters. The library display name will be displayed in the search results in Front End User Interface as part of availability and location information. This is the library name in the default language (en_US). Names in additional languages can be defined in the following columns. This column is mandatory. If you do use the English interface, the program will copy the Library name from col. 7 to col. 4 as the English name. If you only use a single language interface, you can fill in only this column since the English version is used as the default for all languages.
Col. 5 — Delete flag – if you want to delete the library enter “DEL” in this column.
Col. 6 — Language code of additional language 1.
Col. 7 — Library name in additional language 1.
Col. 8 — Language code of additional language 2.
Col. 9 — Library name in additional language 2.
Etc.
Example 5 – Identifying Libraries for Demo Customer Institutions
Let us recall our two universities and their libraries:
North University contains the Law Library and the Main Library.
South University contains the Education Library and the Science Library.
Each of these libraries is defined as a sub-library in ILS Aleph with the following codes:
North University – NLAW and NMAIN
South University – SEDUC and SSCI
The North University libraries that can be derived from the sub-library codes as they appear in the source data (AVA$$b field) are:
49
Chapter 10: ¡Error! Estilo no definido. Customer Profile for Primo
Institution Code
Key String(s)
Primo Library Code
Primo Library Display Name
NORTH NLAW NLAW North University Law Library
NORTH NMAIN NMAIN North University Main Library
The South University libraries that can be derived from the sub-library codes as they appear in the source data (AVA$$b field) are:
Institution Code
Key String(s)
Primo Library Code
Primo Library Display Name
SOUTH SEDUC SEDUC South University Education Library
SOUTH SSCI SSCI South University Science Library
50
Chapter 10: ¡Error! Estilo no definido. Customer Profile for Primo
Form 5: Library List Form part1
51
Chapter 10: ¡Error! Estilo no definido. Customer Profile for Primo
Form 6: Library List Form part2
52
Chapter 10: ¡Error! Estilo no definido. Customer Profile for Primo
Form 7: Library List Form part3
The last three libraries correspond to 3 reading rooms.Is that correct? Why?
Las tres salas de lectura no deben aparecer como sublibraries.
53
Chapter 10: ¡Error! Estilo no definido. Customer Profile for Primo
Loading Libraries from a Loader File
A loader file (as shown in Figure 8) is a tab-delimited file that allows you to load a list of the institution’s libraries into the database. After you have created the file, it can be loaded from the following pages in the Institutions Wizard:
Institutions List — this load is intended for sites that want to load libraries from multiple institutions in a single Excel file.
Libraries List (of a specific institution) — this load is intended for sites that want to load the libraries of a single institution.
Note: To use the Libraries loader, the text of all files must be UTF-8.
To create a tab-delimited UTF file from an Excel sheet do the following:
1. Save the Excel sheet as Text (tab delimited).
2. Open the saved text file in Notepad and save as a Text document with UTF-8 encoding. Save the file under a different name.
Figure 8 shows an example of a tab-delimited file.
NORTH NARCH,NARCC NARCH North Campus Archives fr_FR Name in French
NORTH NAR BB NARBB North Campus BBBBB fr_FR Name in French2
NORTH AINTE AINTE Internet fr_FR Internete
Figure 8. Example Tab-Delimited Loader File
54
Chapter 11
Configuring Data Sources
Use this appendix to:
Identify data sources to be harvested by Primo.
Specify harvesting methods for any non-Ex Libris data sources you have.
Prepare sample data to be used for testing.
You will use the information filled in the forms in this chapter during the configuration of the data sources in the Back Office. For configuration instructions, refer to Step 3: Pipe Configuration Wizard in the Performing Initial Configuration chapter of the Primo Administrator Guide. To configure your data sources, access the following path in the Back Office:Primo Home -> Initial Configuration Wizards -> Primo Configuration Wizard -> Step 3: Pipe Configuration Wizard -> Step 1: Data Sources Configuration
Identifying Data Sources
For more information, refer to Primo Publishing Platform Configuration: Data Sources and Harvesting on page 14.
List each existing and planned data source in your institutions to be harvested by Primo. For each data source, fill in the following fields:
Source ID – Assign a unique identifier for the data source. This may be a running number or meaningful name.
System and Version – Enter the name of the system to be harvested as a data source, and the version of that system being used. Some examples are: ALEPH version 18, DigiTool version 3, and MetaLib version 4.
Note: MetaLib and SFX Knowledge Bases can be harvested and loaded into Primo to be available as local resources. However, if a MetaLib or SFX Knowledge Base is added to an existing ALEPH database via MarcIT, then do not list the MetaLib or SFX Knowledge bases as separate sources. This data will be harvested along with the ALEPH data source.
System Type – Enter the data source system type, for example: ILS, Digital Repository, or Remote Search.
55
Chapter 11: ¡Error! Estilo no definido. Customer Profile for Primo
Format – Enter the standard format being used in the data source records. The choices are MARC21, MAB or Dublin Core.
Estimated Number of Records – Enter the estimated number of records to be harvested.
Institution Code – Enter the unique Institution Code to which this data source belongs. Use the same Institution Code you assigned in Form 2. If your Primo installation includes only one institution, then you do not need to fill in this column. Alternatively, if a few institutions share the same data source, the “CENTRAL” institution should be used here.
Planned Switch To Production (STP) – Data sources may be implemented in Primo immediately or added gradually over time. In this column, indicate whether the data source is planned for immediate production, or enter a target date for its switch to production.
Example 6 – Demo Customer Data Source
Both the North and South Universities will be harvesting their data from:
ILS system (Aleph)
Digital Repository (DigiTool).
Source ID
System and Version
System Type
Format Estimated Number of Records
Institution Code
Planned STP
1 ALEPH, v.18
ILS MARC21 5M Central 01.01.2007
2 DigiTool
Digital Repository
Dublin Core
500K Central 01.01.2007
56
Chapter 11: ¡Error! Estilo no definido. Customer Profile for Primo
Form 8: Data Sources
Specifying Harvesting Methods for Non-Ex Libris Data Sources
For each data source being harvested from a non-Ex Libris system, specify the harvesting methods possible for that data source and whether the system allows extraction of updated records in Form 9. For more information, refer to Methods for Harvesting Data on page 16.
Source ID – Enter the unique code for the data source you assigned in Form 8.
Harvesting Methods Possible – Specify which methods are possible for extracting data from the data source. The available harvesting methods are: FTP harvesting, Copy harvesting, and OAI-PMH harvesting.
FTP Harvesting. Primo can harvest files from a remote server via FTP. To do this Primo requires a valid IP address to the FTP server, a folder name where the source data is stored, username and password.
Every source data record should be extracted as a separate XML file structured using the OAI–PMH protocol ListRecords response format. All files should be added to a tar file and compressed using zip. Do not include more than 10 MG records in a single tar file (before compression)
It is recommended that you extract the files from your data source into a separate folder. Only when the records have been added to tar files and compressed using zip, should they be transferred to the FTP folder from which Primo will harvest the file.
57
Chapter 11: ¡Error! Estilo no definido. Customer Profile for Primo
The Publishing Platform harvests all files in the FTP folder with a server timestamp greater then the last harvesting date. File names should be unique. It is recommended that you add the timestamp to the file name. Optionally, the file can be deleted once it has been successfully harvested.
For more information on the format of the extracted files, refer to OAI-PMH ListRecords and Header Format on page 108.
Copy Harvesting. Primo can harvest files from the local Primo server. To do this Primo requires access the folder where the extracted source data files are stored. In all other respects the Copy workflow is the same as the FTP workflow. For more information, refer to FTP Harvesting on page 57.
OAI-PMH Harvesting. Primo may harvest the source data directly from systems that support OAI-PMH harvesting. Details about the OAI-PMH protocol can be found at http://www.openarchives.org/OAI/openarchivesprotocol.html.
Extraction of Updated Records Possible – Enter Y if the system allows extraction of updated records. If not, enter N.
Form 9: Harvesting Methods for Non-Ex Libris Data Sources
58
Chapter 11: ¡Error! Estilo no definido. Customer Profile for Primo
Preparing Sample Data for Testing
During the implementation and configuration of Primo, data normalization, data load and the Front End must be configured and tested. Three sample data files in XML format should be prepared for each data source and placed in a separate folder for each data type.
For example, sample data in the MARC21 format should be placed into a /marc folder, sample data from a digital repository into a /digital folder, etc.
The three sample files per data source should be structured as follows:
File #1: Sample of 100 records that will be used for testing aspects of the normalization rules and duplicate removal. The file should be prepared in advance to be reviewed and analyzed during the Implementation Analysis session held with an Ex Libris specialist.
File #2: Sample of 10,000-100,000 records that will be used for initial configuration, data load and testing. The size of the sample data file can be adjusted based on the full size of your data, but in general it should be around ten percent of the size of the full data.
File #3: Sample of 10 records that represent all of the system’s record types. This file will be used with the Test Utility, which is part of Normalization Rules wizard. The Test Utility allows testing of the Normalization Rules after they have been edited.
For brief information on extracting data from Ex Libris products, refer to the Primo Interoperability Guide.
For information on extracting data from ALEPH, refer to The ALEPH Publishing Mechanism.
For information on extracting data from Voyager, refer to Voyager® Primo® Integration User’s Guide.
For information on extracting data from DigiTool, refer to General Configuration Guide – Repository Replication and OAI.
For information on extracting local data from MetaLib, refer to section 10.1.2 in the MetaLib Resource Management Guide.
For information on extracting data from an SFX Knowledge Base, refer to section 3.4 in the Primo Interoperability Guide.
For each data source, specify the folder location where you placed the sample files that were prepared for testing.
Source ID – Enter the unique code for the data source you assigned in Form 8.
59
Chapter 11: ¡Error! Estilo no definido. Customer Profile for Primo
Folder Location – Enter the folder path where the sample files were placed.
Notes – Enter any notes regarding the sample files.
Form 10: Sample File Locations
For more information, refer to Sample Data on page 17.
For information on the OAI header, see Appendix A: OAI-PMH ListRecords and Header Format.
60
Chapter 12
Configuring Normalization
Customizing Normalization Rules
You will use the information filled in the forms in this chapter during the configuration of the normalization rules in the Back Office. For configuration instructions, refer to Step 3: Pipe Configuration Wizard in the Performing Initial Configuration chapter of the Primo Administrator Guide. To configure your normalization rules, access the following path in the Back Office:
Primo Home -> Initial Configuration Wizards -> Primo Configuration Wizard -> Step 3: Pipe Configuration Wizard - > Step 3: Normalization Rules Configuration
Mapping templates currently exist for the following formats:
MARC21
ALEPH MARC
ALEPH MAB
Voyager MARC
UNICORN MARC
SFX
MetaLib
DigiTool
Generic Dublin Core (DC)
Identify which template best fits your data set, duplicate the chosen template, assign a name to your normalization rule set and configure the mandatory fields as outlined in the following sections.
Example:
If your data originates from ALEPH ILS, use ALEPH MARC as your base template and create your own normalization rules set named, for example, “University A_MARC21”.
61
Chapter 12: ¡Error! Estilo no definido. Customer Profile for Primo
Delivery and Scoping SectionThe values defined in the Delivery and Scoping section are used to define scopes which govern searching, and to define delivery, such as who can access which resource.
Institution field – Specify the normalization rule for Institution field if it is different from the standard rule. The standard normalization rule for ALEPH takes the value of the $$a AVA field and translates it using the mapping institution table as defined in Form 2 on page 47, and puts the resulting value into the institution field. The standard normalization rule for Voyager takes the value of the $$a 949 field and translates it using the mapping institution table as defined in Form 2 on page 47, and puts the resulting value into the institution field.
Scope fields – Define the mapping between the scope codes and the value from the source data.
Indicate how the scopes defined in Chapter 14 can be mapped based on the source data. For Scope Code, Enter the Scope Code as defined in the forms in Chapter 14.
Form 11: Scope Definitions
Facet SectionThe Collection field — specifies the normalization rule for the Collection field. The Collection Facet is similar to the collection code in a typical ILS. The collection is the physical, digital, electronic, or logical group to which the resource belongs. The collection facet is a code, which will be translated to display text in the user interface.
The Library field— defines a separate facet just for physical libraries. If this facet is used, the collection facet will be used for other types of collections with the exception of libraries. This facet can be used by all sites, but it has some special features intended for multi-institution sites (it can be split into two facets: libraries from the user's institution and all other libraries).
62
Chapter 12: ¡Error! Estilo no definido. Customer Profile for Primo
Define the mapping between the Primo Collection/Library code and values from the source data.
Collection/Library Code — Assign a collection/library code consisting of 10 alphanumeric characters, all lower case, not including any spaces or special characters.
Key String(s) — Lists one or more strings that identify the collection/library facet in the data source records. If the collection/library may be identified by more than one key string, separate each key string with a comma.
Form 12: Collection Facet Code Mapping
Primo Collection Code Aleph Description Aleph Collection Key StringA Audiovisuales U A AC UD Acuicultura ACAD Fac. Admin. Empresas ADAF UD Análisis Formas AFAG ETSI Agronómica, M.N AGAI Aula Informática AIAL EPS Alcoy ALAM Aula Multimedia AMAN Animación. A. e Ind. ANAP Grupo Arq. Paralelas AP
APIÁrea Programas Internacionales AP
AR ETS Arquitectura ARAT ETSI Edificación ATAU UD C. Audiov. y Pub. AUAV Audiovisuales AVBA Fac. Bellas Artes BA
63
Chapter 12: ¡Error! Estilo no definido. Customer Profile for Primo
BD UD Biblio. y Docum. BDBBD Biblioteca Docente BD BE Grupo BET BEBQ UD Bioquímica y B.M. BQC Depósito CCA ETSI Caminos CACE CEGEA CECI CIEGS CICIHI IIAMA C-IHICL Agencia de Calidad CLCM UD C. Materiales CMCN UD Caminos y Aerop. CNCO UD Construcción COCP UD Composición CPCR Cátedra Cerámica CRCS UD T. Señal y Com. CSCSCT ETSI Caminos.Secret. C-SCTCT COTAD CTD Depósito D DA UD Derecho Admin. DADAD Despacho Adquisiciones DA DAGF Dep. Ing. Rural y A. D-AGFDBTC Dep. Biotecnología D-BTCDBVG Dep. Biologia Vegetal D-BVGDC UD Derecho Civil DCDCI Documentación Científica DC DCGF Dep. Ing. Cartograf. D-CGFDCIA Dep. Ciencia Animal D-CIADCMP Dep. Composición Ar. D-CMPDCOM Dep. Comunicaciones D-COMDCSA Dep. Costrucc. Arq. D-CSADCST Dep. Ing. Construc. D-CSTDDIB Dep. Dibujo D-DIBDEGA Dep. Expr. Graf. Arq D-EGADEGI Dep. Ing. Gráfica D-EGIDEIO Dep. Estadística D-EIODELN Dep. Electrónica D-ELNDELT Dep. Ing. Eléctrica D-ELTDESC Dep. Escultura D-ESCDFIS Dep. Física Aplicada D-FIS
64
Chapter 12: ¡Error! Estilo no definido. Customer Profile for Primo
DHIA Dep. Historia Arte D-HIADHMA Dep. Hidráulica D-HMADI UD Dibujo I DIDIN Despacho Informáticos DI DIDM Dep. Lingüística Ap. D-IDMDISA Dep. Ing. Sist. y A. D-ISADISC Dep. Inf. Sist. y C. D-ISCDL UD Der. Constitucion DLDL Depósito (L.Espera) DL DL Depósito (L.Espera) DL DM UD Derecho Mercantil DMDMAG Dep. Mecanización Agraria D-MAGDMAT Dep. Matemáticas D-MATDMCM Dep. Ing. Mecánica D-MCMDMES Dep. Estructuras D-MESDMOT Dep. Motores D-MOTDO UD Dibujo II DODOMP Dep. Org. Empresas D-OMPDPIN Dep. Pintura D-PINDPRI Dep. Proyectos Ing. D-PRIDPRO Dep. Proyectos Arq. D-PRODPRV Dep. Prod. Vegetal D-PRVDQIM Dep. Química D-QIMDQMN Dep. Quimica Nuclear D-QMNDR Dirección DRDRES Dep. Restauración D-RESDSIC Dep. Sis. Informatic D-SICDT UD Dibujo Técnico DTDTE Desp. Dir. Técnica DT DTAL Dep. Tec. Alimentos D-TALDTMD Dep. Termodinámica D-TMDDTRA Dep. Transportes D-TRADTRR Dep. Ing. Terreno D-TRRDTXP Dep. Ing. Textil D-TXPDURB Dep. Urbanística D-URBEC UD Estética y Comp. ECED UD Edafología EDEE Escola d'Estiu EEEFVP Unidad EFVP EFVPEG UD Ecología EG
65
Chapter 12: ¡Error! Estilo no definido. Customer Profile for Primo
GEA Grupo GEA EGEI ETSI Informática EIEL UD Electrotecnia ELEX Apoyo Lingüis. I+D+i EXF Fondo Antiguo FFCCC ES Infor Ap. Secret. F-CCCFG UD Fisiogenética FGFS UD Fisiología y B.V. FSGA EPS Gandía GAGC UD Geotecnia GCGD UD Geom. Descriptiva GDGE UD Geofísica GEGEN Colección general GENGF UD Geografia Física GFGG UD Geología GGGI CIGIP GIGN UD Genética GNGO Máster Campos Golf GOGT UD Geom. Des. y Top. GTHA UD Hª Arquit. 1 HAHD UD Hidráulica HDHG UD Hidrogeología HGHH UD Ing. Hidrá.e Hid. HHHI UD Hª del Arte HIHO Master Hospitales HOHQ UD Hª Arquit. 2 HQIB Ins.In. Bioingenieri IBIBH Inst. Bioingenieria IBHIBMC Inst. Biologia M.C.P I-BMCIC UD Ing. Cart. G. F. ICICMA Centro Medio Ambien. I-CMAID Informática CAD IDIDE Programa Ideas IDIE Area Interv. Edifici IEIIAM Inst. Agrof. Medit. I-IAMIISI ISIRYM I-ISIIITQ Inst. Tecnol. Quim. I-ITQIM UD Ing. Mécanica IMIN ETSI Industriales INIO INECO IO
66
Chapter 12: ¡Error! Estilo no definido. Customer Profile for Primo
IQ UD Ing. Química IQIS UD Ing. San. y Amb. ISITM Inst. Tec. Materiale ITMLA Lab. Automóviles LALE Centro de Lenguas LELI Laboratorio Idiomas LILM Inst. Ing. Alimentos LMLT Laboratorio Turismo LTM Mostrador MAA Armario A MAMA UD Tec. Medio Amb. MAMAR Mostrador Armario A MA MB UD Microbiología MBMD UD Ing. Medioambient MDME UD Mecan.T.Agraria MEMF Grupo Interd. MMF MFMFO Mesa de Formación MFMG UD Mejora Genética MGMH UD Máquinas Hidrául. MHMJ Museo del Juguete MJMN UD Montes MNMÑ Club Deportivo de Montaña MÑMP Master Desarrollo MPMT UD Ing. Materiales MTMV Agromuseu Vera MVNB UD Nutrición y Brom. NBNM Esp. Prof. E. Inmobi NMNU UD Ing. Nuclear NUO Mediateca O OH UD Obras Hidráulicas OHOI Oficina Internaciona OIOT Oficina Técnica OTP Segunda Planta PPA UD Producción Animal PAPG UD Petrolog. y Geoq. PGPI ETSI Diseño PIPR UD Procesos Fabric. PRPT Catalogación PT PU UD Puertos PUPY UD Proyectos PY
67
Chapter 12: ¡Error! Estilo no definido. Customer Profile for Primo
QT UD Int. Arquitectura QTRO Rincón de ocio ROS Sala S SE Sede Depto. SESIE SIE SIET Despacho Dirección T T1 Taller 1 T1T1A Taller 1 A T1-AT1AM Taller 1 AM T1-AMT1AO Taller 1 AO T1-AOT1AR Taller 1 AR T1-ART1CE Taller 1 CE T1-CET1DT Taller 1 DT T1-DTT1GV Taller 1 GV T1-GVT1H Taller 1 H T1-HT1IT Taller 1 IT T1-ITT1MG Taller 1 MG T1-MGT1ML Taller 1 ML T1-MLT1P Taller 1 P T1-PT1TA Taller 1 TA T1-TAT1TD Taller 1 TD T1-TDT1TE Taller 1 TE T1-TET1U Taller 1 U T1-UT2 Taller 2 T2T3 Taller 3 T3T4 Taller 4 T4T5 Taller 5 T5T6 Taller A T6TA UD Teoría Arquitect. TATD UD Termodinámica TDTE ETSI Telecomunic. TETF UD Transportes y F. TFTH Taller H THTL UD Ing. Telemática TLTM ITM TMTO ETSI Geodésica, C.T. TOTR UD Derecho Trabajo TRTSCT ETS G. Edif. Secret. T-SCTTT UD Termotecnia TTTV Radiotelevisión UPV TV
68
Chapter 12: ¡Error! Estilo no definido. Customer Profile for Primo
UO UD Urb. y Ord. Terr. UOVA CAV VAVAAP Área de Protocolo V-AAPVADE Fac. Adm. Emp. Sec. V-ADEVAEC V. Planificación e Innovación V-AECVAFU Aula FUNDESCO V-AFUVAIQ AINQUIVA V-AIQVALU Servicio de Alumnado V-ALUVASJ Servicio de Abogacía V-ASJVCAL ASIC V-CALVCAS Cat. Arq. Sostenible V-CASVCBM Centro Biomateriales V-CBMVCCD Centro Coop. Desarr. V-CCDVCCO Comisiones Obreras V-CCOVCDL Centro de Lenguas V-CDLVCDU Vicerrectorado de Deportes V-CDUVCEG Cent. Est. Gestion E V-CEGVCEQ Cent. Ecología Quim. V-CEQVCEX V. Centros en el Extranjero V-CEXVCFP CFP V-CFPVCIA CIA (Arquitectura) VCIAVCIV Centro Inv. Vehículo V-CIVVCLT Vicerrectorado de Cultura V-CLTVCOO Contratación y Obras V-COOVCSO Consejo Social V-CSOVCTT CTT V-CTTVCVR Centro Val. Riego V-CVRVD Vicerr.Deportes VDVDAL Deleg. Alumnos V-DALVDFU Defensor Com. Universitaria V-DFUVEEE V. Estudios y Conv. Europea V-EEEVFOU Forum UNESCO V-FOUVFPA Fondo de Patrimonio Artístico V-FPAVG CAV-EPSG VGVGCT ETSI Geo. Secretaría V-GCTVGER Gerencia V-GERVGIN Área Información UPV V-GINVGIP Centro Invest. GIP V-GIPVGRE Grupo GREA V-GREVIAD Ins. Ing. Alimentos V-IAD
69
Chapter 12: ¡Error! Estilo no definido. Customer Profile for Primo
VIAI Inst. Automática I. V-IAIVICE ICE V-ICEVICI ICITECH V-ICIVIDF Inst. Diseño Fabric. V-IDFVIIE Inst. Ing. Energétic V-IIEVIMM Inst. Matem. Multid. V-IMMVIMP Inst. U. Matem. Pura V-IMPVING INGENIO V-INGVIPE Inst. Pro Empresa V-IPEVIRP Inst. Restauración V-IRPVITA Inst. Tecnol. Agua V-ITAVITC Instituto ITACA V-ITCVMED Gabinete Médico V-MEDVMGP Master Dir. Ger. P. V-MGPVMIE Microscopia Electro. V-MIEVMJP Master Jard. y Pais. V-MJPVMLI Master Logística V-MLIVNTC C.T. Nanofotónica V-NTCVOVE Área Medio Ambiente V-OVEVPER Servicio de Recursos Humanos V-PERVPIE Proyecto PIE V-PIEVPRL Ser. Prev. Riesgos Laborales V-PRLVRRR Rectorado V-RRRVSAG ETSI Agron. Secret. V-SAGVSAQ ETS Arq. Secretaría V-SAQVSAY EPS Alcoy. Secret. V-SAYVSBA Fac. Bell. Art.Secre V-SBAVSCR Secretario General V-SCRVSGA EPS Gandia. Secret. V-SGAVSGR ETS Medio R. Secret. V-SGRVSIF ETSINF. Secret. V-SIFVSIN ETSI Ind. Secretaría V-SINVSIT ETSI Dis. Secretaría V-SITVSNL Normal. Lingüística V-SNLVSRD Servicio Radiaciones V-SRDVSRI Ser. Rel. Int.-ETSA V-SRIVTLC ETSI Teleco. Secret. V-TLCVUPA Vicerrectorado UPV Abierta V-UPAVVAL V. Estudios y Alumnado V-VALVVAS V. Asuntos Sociales V-VAS
70
Chapter 12: ¡Error! Estilo no definido. Customer Profile for Primo
VVEM Politica de Empleo V-VEMVVGE Vicegerencia V-VGEVVIA V. Intercambio Académico V-VIAVVIN V. Invest. Y Des. Tecnológico V-VINVVIP V. Iniciativas y Planificación V-VIPVVIS V. Planif. Calidad y Prospectiva V-VISVVOA V. Ordenación Académica V-VOAVVPD V. Personal Docente V-VPDVVPL Vicer. Promoción Lin V-VPLVVRI Dir. Rel. Inst. y Asuntos Sociales V-VRIVY CAV-EPSA VY
Form 13: Library Facet Code Mapping
Library Code Key String(s)B BK KR RN NT TP PM MI IA AY Y
71
Chapter 12: ¡Error! Estilo no definido. Customer Profile for Primo
G GH HQ QCIHI CIHIDAGF DAGFDBTC DBTCDCGF DCGFDCIA DCIADCMP DCMPDCOM DCOMDCSA DCSADCST DCSTDDIB DDIBDEAF DEAFDEGA DEGADEGI DEGIDEIO DEIODELN DELNDELT DELTDESC DESCDESP DESPDFIS DFISDHIA DHIADHMA DHMADIDM DIDMDISA DISADISC DISCDMAT DMATDMCM DMCMDMES DMESDMOT DMOTDOMP DOMPDPIN DPINDPRI DPRIDPRO DPRODPRV DPRVDQIM DQIMDQMN DQMNDRES DRESDSIC DSIC
72
Chapter 12: ¡Error! Estilo no definido. Customer Profile for Primo
DTAL DTALDTMD DTMDDTRA DTRADTRR DTRRDTXP DTXPDURB DURBIBMC IBMCICMA ICMAIIAM IIAMIISI IISIIITQ IITQVAFU VAFUVAIQ VAIQVAMV VAMVVCAL VCALVCAS VCASVCBM VCBMVCCD VCCDVCDL VCDLVCEG VCEGVCEQ VCEQVCFP VCFPVCIV VCIVVCTT VCTTVCVR VCVRVESC VESCVFGL VFGLVFOU VFOUVGIP VGIPVGRE VGREVIAD VIADVIAI VIAIVIBH VIBHVICE VICEVICI VICIVIDF VIDFVIIE VIIEVIMM VIMMVIMP VIMPVING VING
73
Chapter 12: ¡Error! Estilo no definido. Customer Profile for Primo
VIPE VIPEVIRP VIRPVITA VITAVITC VITCVITM VITMVMGP VMGPVMIE VMIEVMJP VMJPVMLI VMLIVNTC VNTCVOSC VOSCVOVE VOVEVSDT VSDTVSIE VSIEVSNL VSNLVSRD VSRD
Cuando hay una sola letra es una biblioteca. Cuando hay más es un departamento.
También, a nivel de nombres, si pone Bib. es una biblioteca. Hay alguna exceptión (Biblioteca, Centro…)
Display SectionThe Resource Type [El título de la faceta que se construye sobre este campo debería ser: Formato] field represents the main record format or type based on a master list of main record types. It is recommended to have a small number of types, numbering no more than around 10.
The Resource Type is the basis for determining the icon that will display next to the record in the brief/full results list. Every record must have a single Resource Type field. The default Resource Type list includes:
Book (book)
Journal (journal)
Article (article)
Text Resource (text_resource) — Assigned to all text resources that cannot be identified as a book, journal, or article.
Image (image)
74
Chapter 12: ¡Error! Estilo no definido. Customer Profile for Primo
Video (video)
Audio (audio)
Map (map)
Score (score)
Database (database) No visible
Website (website)
Electronic Resource (Eliminado)
Pendiente confirmer la opción “Electronic Resource”.
Other (other) — A catchall Resource Type for records that cannot be mapped to any other resource type.
Primo has a standard resource type mapping for data coming from the MARC21 format. This format is not customizable.
For data sources that use other formats, a mapping is required.
Form 14: Resource Type Mapping Form
Se entiende que los productos exlibris (SFX, metalib, Primo Central) tienen su correspondiente equivalencia. Aquí añado solo la de Riunet (Dspace)
Source id Source Data Field Source Resource Type PRIMO RESOURCE TYPE4 DC.TYPE annotation Text Resource4 DC.TYPE article Article4 DC.TYPE bachelorThesis Book4 DC.TYPE Book Book4 DC.TYPE bookPart Book
75
Chapter 12: ¡Error! Estilo no definido. Customer Profile for Primo
4 DC.TYPE Conference Object Text Resource4 DC.TYPE Conference Paper Article4 DC.TYPE conference Poster Text Resource4 DC.TYPE conference Proceedings Book4 DC.TYPE doctoral Thesis Book4 DC.TYPE Image Image4 DC.TYPE Learning Object Video4 DC.TYPE Map Map4 DC.TYPE masterThesis Book4 DC.TYPE News Article Text Resource4 DC.TYPE Objeto de aprendizaje Video4 DC.TYPE paper Article4 DC.TYPE Presentation Text Resource4 DC.TYPE report Text Resource4 DC.TYPE Technical Report Text Resource
Nueva faceta para formato a partir del $h con elementos seleccionados (Isabel tiene que pasar la lista)
Pedir E-book y e-journal como scopes
Pendiente cambios Elías.
Library Level Availability Field
The Library Level Availability field (also know as availlibrary in the Normalization Set Editor) includes resource availability information for each Primo library in addition to location information.
In the case where your installation uses ALEPH, the AVA field, extracted from ALEPH, should be mapped to the Library Level Availability field in Primo. In the case where your installation uses Voyager, the 949 field, extracted from Voyager, should be mapped to the Library Level Availability field in Primo.
The pre-configured mapping is described as follows:
Table 8. Pre-configure Mapping
ALEPH AVA / Voyager 949 Primo Library Level Availability field
$$a institution code $$I Institution code
$$b library code $$L Library code
76
Chapter 12: ¡Error! Estilo no definido. Customer Profile for Primo
$$c collection code $$1 Collection
$$d call number $$2 Call number
$$e number of items
(for the entire library, not only one location)
$$3 number of items
$$f number of unavailable items $$4 number of unavailable items
$$g availability status
(permitted values: available, unavailable, or check_holdings)
$$S availability status
(permitted values: available, unavailable or check_holdings)
$$h multi-volume flag (Y/N) $$5 multi-volume flag (Y/N).
$$i number of loans $$6 number of loans (for ranking purposes)
All installations using an ILS other then ALEPH or Voyager should consider the following:
Is it possible to extract availability information on the copy/library level and integrate it into the source records?
If so, insert the availability data into the local field (for example, the 999 field) in the following format:
$$a Institution code
$$b Library code
$$c Collection code
$$d Call number
$$e Number of items (for the entire library, not just one location)
$$f Number of unavailable loans
$$g Availability status (permitted values: available, unavailable or check_holdings)
$$h Multi-volume flag (Y/N)
$$i Number of loans
The data from this embedded local field should be mapped to the Primo avail_library field.
Links SectionRefer to Form 26 on page 95.
77
Chapter 12: ¡Error! Estilo no definido. Customer Profile for Primo
Enrichment SectionPrimo comes pre-configured with the following enrichment options. Review the table and specify which changes you would like to insert.
Form 15: Added Enrichment Options
Si supone traducir a términos los códigos de estas clasificaciones como no los utilizamos habría que desactivarlos. La única duda sería el DC
Ver si se puede poner el código de clasificación de la LC y a partir del código generar la portada de Google.
Local fieldsPrimo comes pre-configured with all the fields required for Primo to work. In rare cases, you may have to include additional data via local fields.
In addition to the standard PNX fields, you can define up to 50 local fields in the following PNX sections:
Display
Links
78
Chapter 12: ¡Error! Estilo no definido. Customer Profile for Primo
Search
Note: By default, the Number of local fields parameter on the Primo Home > Advanced Configuration > Search Engine Configurations page is set to 5 to limit the number local fields to search to increase system performance.
Enrichment
Facets
Note: Local field configuration is an advanced configuration that should be discussed with an Ex Libris Implementation Analyst during the Implementation Analysis session.
If you think you may have special types of data that may require additional fields, indicate this in the following table.
Form 16: Local Fields
Tabla de equivalencias para construir la faceta Tipo de documento
Primo_Faceta_Tipo_de_documento Riunet (Dspace) field DC.TYPE Aleph_field_TDOLiteratura LiteraturaLecturas niveladas Lecturas niveladasPartes de libros BookPart Obras antiguas Obras antiguasNormas tecnológicas NormasBases de datos Bases de datosTesis Doctoral Thesis TesisPublicaciones docentes Publicaciones docentesPelículas Películas
Catálogos exposiciones Catálogos de Exposiciones
Juegos JuegosPatentes PatentArtículos, etc. Article
79
Chapter 12: ¡Error! Estilo no definido. Customer Profile for Primo
Artículos, etc. contributiontoPeriodical Artículos, etc. JournalArticle Artículos, etc. OnlineJournalArticle Artículos, etc. Paper Ponencias, etc. conference Object Ponencias, etc. conference Item Ponencias, etc. Conference Proceeding Ponencias, etc. Conference Paper Ponencias, etc. Conference Poster Artículos, etc. Preprint Informes técnicos, etc. Working Paper Software Software Informes técnicos, etc. Technical Report Trabajos académicos (PFC) bachelorThesis Proyectos fin de carreraTrabajos académicos (PFC) masterThesis Polimedia Polimedias Publicaciones docentes Artículos docentes Laboratorios virtuales Laboratorios virtuales Multimedia Video Multimedia Animation Anotación (Otros) Annotation InCollection (Otros) InCollection Lecture (Otros) Lecture Multimedia Musical Score Multimedia Recording, musical Notas de prensa NewsArticle Plan or blueprint (Otros) Plan or blueprint Multimedia Presentation Multimedia (Otros) Recording, acoustical Multimedia (Otros) Recording, oral Artículos, etc. Review Multimedia Image Multimedia Image, 3D Otros OtherMonografías Conference Proceedings Monografías
80
Chapter 13
Publishing Pipes
You will use the information filled in the form in this chapter during the configuration of the pipes in the Back Office. For configuration instructions, refer to Step 3: Pipe Configuration Wizard in the Performing Initial Configuration chapter of the Primo Administrator Guide. To configure your pipes, access the following path in the Back Office:
Primo Home -> Initial Configuration Wizards -> Primo Configuration Wizard -> Step 3: Pipe Configuration Wizard -> Step 5: Pipes Configuration
Defining Pipes
Harvesting source records and creating PNX records is managed by the Publishing Platform. The Publishing Platform supports scheduled and unattended harvesting and processing of various data formats, allowing interactive monitoring and control over the entire set of activities.
Within the Publishing Platform, PNX records are created by publishing pipes. Every data source has its own pipe. Each data source may have its own set of normalization rules, or several data sources may be linked to one set of normalization rules.
Specify for each data source which set of normalization and enrichment rules should be used.
81
Chapter 13: ¡Error! Estilo no definido. Customer Profile for Primo
Form 17: Normalization Rule Sets Used
Availability Update Pipe
The availability status for physical items (available, unavailable, or check holdings) should be included in the record extracted from the data source. In other words, the availability status is loaded as part of the standard ILS pipe.
Note: If you choose to use the Real Time Availability (RTA) feature, which allows end users to get the availability statuses for physical items in “real time” from the source system, the records should have the Library Level Availability field, which should be created by the publishing pipe.
An ILS pipe generally runs no more than once or twice a day. Although the pipe can be run more often, frequent indexing and the required swapping of slices in the search engine can negatively affect performance.
To ensure that the status is up-to-date, you can define a special availability update pipe. This pipe is based on the standard pipe, but only includes records with a change in the availability status.
Even if you choose to use the Real Time Availability (RTA) feature, consider using the availability update pipe as well because of performance issue - some source system might not be able to bring availability information for all results in a good responsive time – in this case you might want to have brief view with the harvested availability information and full view with the real time availability.
The availability update pipe can run as frequently as once an hour. The records that are entered via this pipe are not indexed right away. However, since the Front End uses the availability status that is stored in the PNX record and not the PNX record stored in the indexes, this is irrelevant. These records will be indexed later with the regular pipe. There is one exception to
82
Chapter 13: ¡Error! Estilo no definido. Customer Profile for Primo
the records that are not indexed, which is the post-filter that is used by the availability status (the “Show only available items” filter). This filter is based on the indexed availability status, which means that the display name may be more up-to-date than the filter.
Consider whether you would like to implement an availability update pipe.
83
Chapter 14
Configuring the Front End
Use this appendix to:
Define search scopes.
Define restricted search scopes.
Customize views.
You will use the information filled in the form in this chapter during the configuration of the Front End. For configuration instructions, refer to Step 4: Front End Configuration Wizard in the Performing Initial Configuration chapter of the Primo Administrator Guide. To configure your restricted search scopes and views, access the following paths in the Back Office:
Primo Home -> Initial Configuration Wizards -> Primo Configuration Wizard -> Step 4: Front End Configuration Wizard -> Step 1: Define Restricted Search Scopes and Step 3: Views Wizard
Defining Search Scopes
For more information on local and remote search scopes, refer to Search Scopes on page 23.
Specify the search scopes that should be created for your installation in Form 18:
Scope Code – Assign a unique identifier to the scope. The Scope Code must consist of 100 alphanumeric characters, all lower case. Do not use any spaces or special characters.
Scope Name – Enter a name for the scope, consisting of up to 255 char characters.
Scope Source – Enter the name of the field in the source records on which the scope is based, for example, AVA field, sub field $b.
Description – Enter a description for the scope.
84
Chapter 14: ¡Error! Estilo no definido. Customer Profile for Primo
Example 7 – Defining Scopes for Demo Customer
Every institution should have two scopes:
Institution scope
ALL DATA scope
Scope Code
Scope Name Scope Source
Description
NORTH North University Scope
Institution
North University Repository
SOUTH South University Scope
Institution
South University Repository
ALL ALL DATA Institution
ALL CAMPUSES
Form 18: Search Scopes
Defining Restricted Search Scopes
For more information on restricted search scopes, refer to Restricted Search Scopes on page 25.
Note: For each set of restriction criteria, use only one restricted search scope even when the restricted records are from different data sources. Defining many restricted search scopes may negatively affect search response time.
85
Chapter 14: ¡Error! Estilo no definido. Customer Profile for Primo
Specify the restricted search scopes that should be created for your installation in Form 19:
Scope Code – Assign a unique identifier to the scope. The Scope Code must consist of 100 alphanumeric characters, all lower case. Do not use any spaces or special characters.
Scope Source – Enter the name of the field and a value in the source records on which the scope is based.
On/Off Campus – Enter whether the scope should restrict access to resources based on whether the user is on or off campus.
End User Group – If the scope should restrict resources to members of specific end user groups, enter the list of restricted user groups in this column. Use the User Group Name(s) assigned to the user groups in Form 28.
Example 8 – Defining Restricted Search Scopes for Demo Customer
There is a manuscript collection in Law library of North University that can be searched by either logged in or on-campus users only. The collection is identified by the source data (AVA$$cMANUS field).
Scope Code
Scope Source
Scope Description Institution Code
On/Off Campus
End User Group
NORTHLAW
AVA$$cMANUS
Restricted for search by either On Campus users or logged users only
NORTH ON Non Guest
Form 19: Restricted Search Scopes
86
Chapter 14: ¡Error! Estilo no definido. Customer Profile for Primo
Customizing Views
For more information, refer to Views on page 22.
To create customized views for each institution, the default view should be copied into a new base view. Customizations should be made to the new base view. New views can then be created by copying the customized base view, thereby inheriting customizations into the new views. From there, new views can be further customized.
Specify the views that should be created for your institution(s) in Form 20:
View Code – Assign a unique identifier to the new view, consisting up to 100 alphanumeric characters. Do not use any spaces or special characters.
View Name – Enter a name for the view, consisting up to 255 char characters.
Institution Code – Enter the unique Institution Code to which this view belongs. Use the same Institution Code you assigned in Form 2. If your Primo installation includes only one institution, then you do not need to fill in this column.
Tabs – We recommend local and remote tabs to differentiate between local and remote resources. Remote resources are accessed via MetaLib, where the response time is longer.
Scopes to be Included in the Tab – List the search scopes that should be available in the main tab of the view.
Example 9 – Configuring Views, Tabs, and Scopes for Demo Customer
For each of our Universities we’ll define a view with two tabs:
Local – includes local data scope and ALL Data scopes
Remote – includes the University’s MetaLib QuickSets
View Code
View Name Institution Code
Tabs Scopes to be Included in the Tab
NORTH North University View
NORTH Local North University Scope, ALL DATA
Remote MetaLib QuickSets of North University
SOUTH South University
SOUTH Local South University Scope, ALL DATA
87
Chapter 14: ¡Error! Estilo no definido. Customer Profile for Primo
View Remote MetaLib QuickSets of South University
Form 20: Customized Views
Specify the customizations that should be made to each view in Form 21:
View Code – Enter the unique View Code to which the customizations should be made. Use the same View Code you assigned in Form 20.
Logo – Enter the file name of logo.
Search Boxes – Enter the list of options that should appear in the search boxes for both the Basic and Advanced Searches.
Note: Refer to The Search Section on page 123, to choose from the search options specified in the Search section of the PNX record.
Full Display – Specify fields to appear in the Full results list.
Note: Refer to The Display Section on page 115, to choose from the display options specified in the Display section of the PNX record.
Brief Display – Specify fields and facets to appear in the Brief results list.
Note: Refer to The Facets Section on page 125 or to The Display Section on page 115, to choose from the display and/or facet options specified in the Display and Facet sections of the PNX record.
Notes – Enter any notes regarding the list of tiles.
88
Chapter 14: ¡Error! Estilo no definido. Customer Profile for Primo
Form 21: View Customizations
Note: Although you can start planning this form now, during the actual configuration in the Back Office you can continue with further View customizations.
Pendiente revision Brief Display
89
Chapter 15
Configuring Delivery
Use this appendix to:
Map delivery categories to your data source if your data source is a non-Ex Libris system or uses a standard other than MARC21.
Customize the availability text that appears on the search results screen indicating the resource availability.
Define Restricted Delivery Scopes.
Configure the GetIt! delivery links mechanism.
You will use the information filled in the forms in this chapter during the configuration of Primo’s delivery settings. For configuration instructions, refer to Step 4: Front End Configuration Wizard in the Performing Initial Configuration chapter of the Primo Administrator Guide. To configure your delivery settings, access the following path in the Back Office:
Primo Home -> Initial Configuration Wizards -> Primo Configuration Wizard -> Step 4: Front End Configuration Wizard -> Step 2: Delivery and Delivery Restrictions
Mapping Delivery Categories
For data sources using a non-MARC21 standard (such as MAB or UNIMARC) or data sources originating from non-Ex Libris systems, fill in the delivery categories mapping table. As described in Delivery Categories on page 26, delivery links are based on four elements: delivery category, resource availability, data source, and user details. The details filled in the mapping table are based on the delivery category and resource availability.
Data Source System – Specify the system from which the data source originates; for example, ILS, digital repository, digital archive, etc.
Delivery Category – Specify the type of resources that are stored in the data source; for example, physical items, microfilm, print journals, etc. For a list of delivery categories refer to Delivery Categories on page 26.
Notes – If more than one type of resource is stored in a single data source, specify how the mapping should be configured.
RIUNET (Dspace) (Resource ID = 4)
90
Chapter 15: ¡Error! Estilo no definido. Customer Profile for Primo
Form 22: Delivery Categories Mapping Table
When the mapping is complete, the Normalization set should be populated in the Delivery and Scoping section, Delivery Category field. For more information, refer to Configuring Normalization on page 61.
Customizing Availability Status Indicator Text
You can customize the text that appears on the search results screen indicating the resource availability. For more information, refer to Resource Availability on page 27.
Form 23: Availability Status Indicator Text for Single Institution Environment
91
Chapter 15: ¡Error! Estilo no definido. Customer Profile for Primo
Form 24: Availability Status Indicator Text for Multi-Institution Environment (No rellenar)
Activating Real Time Availability Option
If you choose to activate the Real Time Availability option, configure the Real-Time Availability mapping table using the following page:
Primo Home > Initial Configuration Wizards > Primo Configuration Wizard > Step 4: Front End Configuration Wizard > Step 2: Restrictions and Delivery Configuration Wizard > Step 6: Real Time Availability Configuration
If your source system is ALEPH, the table should be configured as following:
Source system — the system for which RTA is available. (ALEPH)
Institution — this column defines the mapping for the field/subfield which the RTA program should use to find a match for the Primo institution in the Library Level Availably that will be updated by the RTA program. (e.g. in the default set up for ALEPH it's a. It means the Institution is based on subfield a of the AVA field)
Library — this column defines the mapping for the field/subfield which the RTA program should use to find a match for the Primo library in the Library Level Availably that will be updated by the RTA program (e.g. in the default set up for ALEPH it's b. It means the Institution is based on subfield b of the AVA field)
Sub-location — this column defines the mapping for the field/subfield which the RTA program should use to find a match for the Primo sub location the Library Level Availably that will be updated by the RTA
92
Chapter 15: ¡Error! Estilo no definido. Customer Profile for Primo
program (e.g. in the default set up for ALEPH it's c. It means the Institution is based on subfield c of the AVA field)
Additional — any additional parameters required by the program. None are required for ALEPH.
Target — enter Y to activate the RTA program. The default is N
Description — free text descriptive note
Currently, Primo has an RTA program for ALEPH. If you want to write your own RTA program using the RTA plug-in, inform your ExLibris project manager and we will provide additional details.
2. In the Views Wizard, in the General Attributes page indicate whether and how Real time availability should be invoked - at the brief and full results level or only for the full results. The latter option has been added in case the available API is slow and/or can only be invoked for a single record at a time. If you want to suppress RTA for a specific view you can also indicate that there should be no RTA by checking the “None” option.
Defining Restricted Delivery Scopes
For more information on restricted delivery scopes, refer to Restricted Delivery Scopes on page 32.
Specify the restricted delivery scopes that should be created for your installation in Form 25:
Scope Code – Assign a unique identifier to the scope. The Scope Code must consist of 100 alphanumeric characters, all lower case. Do not use any spaces or special characters.
Data Source – Enter the Source ID for the data source. Use the Source ID entered in Form 8.
Source Description – Describe the type of records to be restricted and how they can be identified. This can consist of up to 255 char characters.
Institution Code – If the scope should restrict resources based on the user belonging to the institution(s), enter the Institution Codes in this column. Use the code assigned to the institution(s) in Form 2.
On/Off Campus – Enter whether the scope should restrict access to resources based on whether the user is on or off campus.
93
Chapter 15: ¡Error! Estilo no definido. Customer Profile for Primo
End User Group – If the scope should restrict resources to members of specific end user groups, enter the list of user groups in this column. Use the User Group Name(s) assigned to the user groups(s) in Form 28.
Additional Restrictions – Detail any other criteria to consider before allowing access to the resources.
Form 25: Restricted Delivery Scopes (Si utilizamos un tab para Metalib habría que definir scopes –quicksets- restringidos)
Configuring Delivery Links
The following is Primo’s default linking mechanism configuration. Make your desired changes to the configuration by editing the contents of the form. For more information about the behavior of delivery links, refer to Delivery Link Configuration on page 35. For more examples of how the link mechanisms work, refer to Delivery Link Configuration Examples on page 96. For end-to end delivery examples, refer to Appendix C – End-to-end Delivery Examples .
94
Chapter 15: ¡Error! Estilo no definido. Customer Profile for Primo
Form 26: Delivery Link Configuration (OK)
Delivery Category
Availability Status GetIt! URL GetIt!2 URL
Physical Items, Microfilm and Print Journals
Available (in user’s institution)
LinktoHoldings OpenURL
Available in other institution
LinktoRequester OpenURL
Unavailable (in all institutions)
LinktoRequester OpenURL
Check holdings – Does not exist in my institution:
Unavailable
Available
Check holdings
LinktoHoldings OpenURL
Online Resources
No restrictions LinktoResource OpenURL
Restricted access Backlink OpenURL
May be restricted LinktoResource OpenURL
Electronic Journals
No restrictions OpenURL_fulltext OpenURL
Restricted access OpenURL_fulltext OpenURL
May be restricted OpenURL_fulltext OpenURL
Remote Search Resources
Full-text OpenURL_fulltext OpenURL
No full-text OpenURL
MetaLib Resources
No restrictions LinktoResource OpenURL
Restricted access LinktoResource OpenURL
May be restricted LinktoResource OpenURL
95
Chapter 15: ¡Error! Estilo no definido. Customer Profile for Primo
Delivery Link Configuration Examples
Based on the configuration in Form 26 on page 95, following are examples of how GetIt! URLs are resolved.
Example 1 – Online Resource from ILSIn this example, we have a static link that cannot be re-calculated in real time.
Delivery configuration:
Delivery category of the record = online resource
Availability status = no restrictions
Based on this scenario the LinktoResource link field should be used.
The PNX links section/LinktoResource field should include the static URL, display text and optionally, the institution code. When normalization rules are created for this case, you need to specify from where in the source record the URL and display text should be extracted.
<linktorsrc>$$U<856_u>$$D<856_z>
In this case the URL will be taken from the data in the 856$$u field in the source record, and display text will be taken from the 856$$z field of the source reccord.
Example 2 – Electronic Journal from SFX
Delivery configuration:
Delivery category of the record = e-journal
Availability = not restricted
Based on this scenario the OpenURL_fulltext link field should be used.
In the PNX links section, using the OpenURL_fulltext function will force the link should be calculated in real time. Therefore, the template with the code OpenURL_fulltext should be used. The definition for the normalization should be as follows:
<openurlfullt>$$Topenurlfulltext
The openurl_fulltext template includes the following:
{{sfx_base}}sid:Primo:{{control/source_id}}&genre={{adddata/genre}}&aulast={{adddata/authorlast}}&aufirst={{adddata/authorfirst}}&issn={{adddata/issn}}&jtitle={{adddata/journal_title}}&atittle={{adddata/
96
Chapter 15: ¡Error! Estilo no definido. Customer Profile for Primo
article_title}}&date={{adddata/date}}&volume={{adddata.volume}}&issue={{adddata/issue}}&spage={{adddata/startpage}}&epage={{adddata.endpage}}
Relevant fields in the PNX that are referenced by the template:
From the Control section:
source_id=pubmed
From the Additional Data (adddata) section:
Genre article
article_title Induction of Cell Cycle Arrest and Apoptosis in HT-29 Human Colon Cancer Cells by the Dietary Compound Luteolin.
journal_title Am J Physiol Gastrointest Liver Physiol.
author_first D
author_last Lim
author_init Y
issn 1876-9081
date 2006
volume 25
issue 1
startpage 125
endpage 135
Resolution of the GetIt! URL:
Based on this configuration, the OpenURL_fulltext is selected as the appropriate link from the PNX. This field references the template called openurl_fulltext which is filled in using the SFX base_url of the user’s institution as well as fields from the PNX.
http://sfxserver.uni.com/sfxmenu? Primo:pubmed&genre=article&jtitle=Am J Physiol Gastrointest Liver Physiol&atitle= Induction of Cell Cycle Arrest and Apoptosis in HT-29 Human Colon Cancer Cells by the Dietary Compound Luteolin&aufirst=D&aulast=Lim&auinit=Y&issn=1876-9081&date=2006&volume=25&issue=1&spage=125&epage=135
Example 3 – Physical Item from ILS
Delivery configuration:
97
Chapter 15: ¡Error! Estilo no definido. Customer Profile for Primo
Delivery category = physical item
Availability = available
Based on this scenario, the LinktoHoldings link field should be used.
PNX links section:
Using the LinktoHoldings function forces the link to be calculated in real time for the appropriate record. Primo knows to which record in the source system it link to. For LinktoHoldings in the ALEPH ILS system the template aleph_holdings is used. The definitions for the normalization are as follows: <linktoholdings>$$T aleph_holdings
Template:
{{ils_base}}?func=item-global&doc_library={{control/original_sourceID}} &doc_number={{control/source_recordID}}
Relevant fields in the PNX referenced by the template:
From the Control section:
original_source_id usm01
source_recordID 000007895
Resolution of the GetIt!URL:
http://aleph-demo.exlibrisgroup.com:8992/F?item-global&doc_library=USM01&doc_number=000007895
Example 4 – Online Resources from Two Digital RepositoriesThis example involves online resources from a Music Archive and Video Archive.
Delivery configuration:
Delivery category = online resource
Availability= available
Based on this scenario LinktoResource link field should be used.
PNX links section:
Templates can be defined in order to link back to the source repositories. In this case the definitions for the normalization can be as follows:
For VIDEO archive:<linktorsrc>$$TlinktoresourceVIDEO
98
Chapter 15: ¡Error! Estilo no definido. Customer Profile for Primo
For MUSIC archive:<linktorsrc>$$TlinktoresourceMUSIC
Templates:
The templates will include the base_url code of every repository with relevant place holders for sourcerecordid identification.
99
Chapter 16
Configuring Users and User Authentication
Use this appendix to:
Configure staff users and their authorization types.
Configure end user groups.
Configure the PDS.
You will use the information filled in the forms in this chapter during the configuration of the users and user authentication in the Back Office. For configuration instructions, refer to Step 2: Authentication Configuration Wizard in the Performing Initial Configuration chapter of the Primo Administrator Guide. To configure your staff users and user group settings, access the following path in the Back Office:
Primo Home -> Initial Configuration Wizards -> Primo Configuration Wizard -> Step 2: Authentication Configuration Wizard -> Step 1: Manage Staff Users, Step 2: End User Configuration Wizard (PDS) and Step 3: Configure User Groups
Configuring Staff Users
For information about staff user authorization types, refer to Table 7 on page 38.
List each staff member and their contact information in the Staff Users Configuration Form. Assign one or more authorization types to each staff member by typing an "X" into the appropriate box.
100
Form 27: Staff Users Configuration Form
Chapter 16: ¡Error! Estilo no definido. Customer Profile for Primo
Configuring End User Groups
List each user group and their user category and data source restrictions in the End User Group Configuration Form. For information about end user groups, refer to Defining User Groups on page 39.
Form 28: End User Group Configuration Form (Sin restricciones)
User Group Name User Status or Category Data Source to be Restricted Access Restrictions
Configuring the PDS
Configuring the PDS integrates the Primo authentication system with your institution’s existing authentication system and provides single sign-on and sign-off (SSO) functionality. For information about end user authentication, refer to End User Authentication on page 40.
To configure the PDS, address the following questions and fill in the forms accordingly:
1. Would you like to enable SSO functionality between your different Ex Libris products? If yes, specify which products.
Form 29: Products included in SSO
2. For each institution, specify the authentication method and user attribute repository.
102
Chapter 16: ¡Error! Estilo no definido. Customer Profile for Primo
If users may be authenticated in more than one authentication database, explain your policy in the Notes column.
Example Case 1: Students are registered in LDAP and staff members are registered in ALEPH. In this case, PDS should first check the ALEPH database and then LDAP.
Example Case 2: Users are authenticated using LDAP, while user attributes are stored in ALEPH.
Form 30: Authentication Per Institution
* Possibilities include: ALEPH, MetaLib, DigiTool, LDAP, CGI-Hook iChain, Shibboleth, etc.
3. If you already have PDS installed and configured for any other Ex Libris product, please note that you have to check the PDS version in the products. In principle, you should always use the highest PDS version since it is backward compatible. So for example, if a site has PDS running on MetaLib 3.1 which has PDS 1.2 the site should switch to the Primo PDS since its version is higher.
To configure SSO between Exlibris products using PDS 1.3 and PDS 1.2, the shared PDS must be the higher version.
To know which PDS version is installed, use the Unix ver command to display the PDS version that is embedded in the Ex Libris product. You should copy the locally customized files found in the conf_table and html_forms directories from the PDS 1.2 environment to the PDS 1.3 environment.
If you already have PDS installed and configured for any other Ex Libris product and its PDS version is the same or higher than those in Primo, do the following:
Configure Primo’s PDS_HOST and PDS_PORT parameters to point to your existing PDS installation.
Configure Primo’s PDS_URL parameters to point to your existing PDS interface.
103
Chapter 16: ¡Error! Estilo no definido. Customer Profile for Primo
Depending on the Ex Libris product for which your PDS is currently configured, you may find the PDS_HOST and PDS_PORT parameters in the following table.
Product Name File
ALEPH aleph_start
MetaLib metalib_start
DigiTool dtl_start
4. Record the parameters in the following form.
Form 31: Attributes for Existing PDS Installation
5. If you do not already have PDS configured for any other Ex Libris product, you must configure it using the PDS Management Primo Interface.
Fill out the following forms, depending on the authentication system(s) in place at your institution(s).
If you use ALEPH, Voyager, MetaLib, or DigiTool for authentication, enter the appropriate information in Form 32.
104
Chapter 16: ¡Error! Estilo no definido. Customer Profile for Primo
Form 32: Parameters for ALEPH, MetaLib or DigiTool Authentication
If you use LDAP for authentication, enter the appropriate information in Forms 33 and 34.
Form 33: Parameters for LDAP Authentication
105
Chapter 16: ¡Error! Estilo no definido. Customer Profile for Primo
Form 34: User Attributes Mapping That Should Be Enabled
If you use CGI-Hook for authentication, enter the appropriate information in Forms 35 and 36.
Form 35: User Authentication for CGI-Hook
106
Chapter 16: ¡Error! Estilo no definido. Customer Profile for Primo
Form 36: User Attributes Mapping That Should Be Enabled
6. Supply log in (login name and password) information for the test user for every institution , that will be used by Ex Libris Staff in a variety of the tests
Institution Test User (login/password)
107
Appendix A
OAI-PMH ListRecords and Header Format
Details about the OAI-PMH protocol can be found at:http://www.openarchives.org/OAI/openarchivesprotocol.html.
Every record should include a header based on the OAI-PMH protocol with the following elements:
Unique identifier.
Status attribute if the record was deleted.
Timestamp. Although the OAI-PMH protocol calls for a timestamp, it is not required by Primo.
For example:
<header> <identifier>000000006</identifier></header>The header of a deleted record should look like this:<header status=”deleted”> <identifier>000000006<./identifier></header>
All records should be packaged using the ListRecords format.
For example:
<?xml version="1.0" encoding="utf-8" ?> <OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd"><ListRecords><record><header><identifier>000010116</identifier> </header><metadata><record xmlns="http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd"> <leader>00981pam^^2200349^a^4500</leader> <controlfield tag="FMT">BK</controlfield> <controlfield tag="LDR">00981pam^^2200349^a^4500</controlfield>
108
Appendix A: OAI-PMH ListRecords and Header Format Customer Profile for Primo
<controlfield tag="001">000010116-8</controlfield> <controlfield tag="005">20020418155342.1</controlfield> <controlfield tag="008">870129s1987^^^^nyu^^^^^^^^^^^00110^eng^^</controlfield> <datafield tag="010" ind1="" ind2=""> <subfield code="a">^^^87000934^//r882</subfield> </datafield><datafield tag="020" ind1="" ind2=""> <subfield code="a">0871131471</subfield> </datafield><datafield tag="035" ind1="0" ind2=""> <subfield code="a">(OCoLC)15197019</subfield> </datafield><datafield tag="040" ind1="" ind2=""> <subfield code="a">DLC</subfield> <subfield code="c">DLC</subfield> <subfield code="d">CLS</subfield> </datafield><datafield tag="050" ind1="0" ind2=""> <subfield code="a">TP248.6</subfield> <subfield code="b">.H35 1987</subfield> </datafield><datafield tag="082" ind1="0" ind2=""> <subfield code="a">615/.365</subfield> <subfield code="2">19</subfield> </datafield><datafield tag="100" ind1="1" ind2=""> <subfield code="a">Hall, Stephen S.</subfield> </datafield><datafield tag="245" ind1="1" ind2="0"> <subfield code="a">Invisible frontiers :</subfield> <subfield code="b">the race to synthesize a human gene /</subfield> <subfield code="c">Stephen S. Hall.</subfield> </datafield><datafield tag="250" ind1="" ind2=""> <subfield code="a">1st ed.</subfield> </datafield><datafield tag="260" ind1="0" ind2=""> <subfield code="a">New York :</subfield> <subfield code="b">Atlantic Monthly Press,</subfield> <subfield code="c">c1987.</subfield> </datafield><datafield tag="300" ind1="" ind2=""> <subfield code="a">xiv, 334 p. ;</subfield> <subfield code="c">24 cm.</subfield> </datafield><datafield tag="500" ind1="" ind2=""> <subfield code="a">"A Morgan Entrekin book."</subfield> </datafield><datafield tag="500" ind1="" ind2=""> <subfield code="a">Includes index.</subfield> </datafield>
109
Appendix A: OAI-PMH ListRecords and Header Format Customer Profile for Primo
<datafield tag="650" ind1="" ind2="0"> <subfield code="a">Genetic engineering.</subfield> </datafield><datafield tag="650" ind1="" ind2="0"> <subfield code="a">Recombinant DNA.</subfield> </datafield><datafield tag="650" ind1="" ind2="0"> <subfield code="a">Insulin</subfield> <subfield code="x">Synthesis.</subfield> </datafield><datafield tag="650" ind1="" ind2="0"> <subfield code="a">Biotechnology.</subfield> </datafield><datafield tag="650" ind1="" ind2="2"> <subfield code="a">Biotechnology.</subfield> </datafield><datafield tag="650" ind1="" ind2="2"> <subfield code="a">DNA, Recombinant.</subfield> </datafield><datafield tag="650" ind1="" ind2="2"> <subfield code="a">Genetic Engineering.</subfield> </datafield><datafield tag="650" ind1="" ind2="2"> <subfield code="a">Insulin.</subfield> </datafield></record> </metadata></record><record><header> <identifier>000021372</identifier> </header><metadata><record xmlns=" http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd "> <leader>00992cas^^2200337^a^4500</leader> <controlfield tag="FMT">SE</controlfield> <controlfield tag="LDR">00992cas^^2200337^a^4500</controlfield> <controlfield tag="001">000021372-1</controlfield> <controlfield tag="005">20020418155342.1</controlfield> <controlfield tag="008">910831c19919999enkbr^p^^^^^^^0^^^^0eng^d</controlfield> <datafield tag="010" ind1="" ind2=""> <subfield code="a">sn^91033422^</subfield> </datafield><datafield tag="016" ind1="7" ind2=""> <subfield code="a">9111470</subfield> <subfield code="2">DNLM</subfield> </datafield><datafield tag="016" ind1="7" ind2=""> <subfield code="a">SR0069808</subfield> <subfield code="2">DNLM</subfield>
110
Appendix A: OAI-PMH ListRecords and Header Format Customer Profile for Primo
</datafield><datafield tag="022" ind1="" ind2=""> <subfield code="a">0960-8966</subfield> </datafield><datafield tag="030" ind1="" ind2=""> <subfield code="a">NEDIEC</subfield> </datafield><datafield tag="035" ind1="0" ind2=""> <subfield code="a">(OCoLC)24318845</subfield> </datafield><datafield tag="040" ind1="" ind2=""> <subfield code="a">NLM</subfield> <subfield code="c">NLM</subfield> <subfield code="d">CAS</subfield> <subfield code="d">WAU</subfield> <subfield code="d">NLM</subfield> <subfield code="d">NSD</subfield> <subfield code="d">DLC</subfield> <subfield code="d">HUL</subfield> </datafield><datafield tag="042" ind1="" ind2=""> <subfield code="a">lcd</subfield> </datafield><datafield tag="245" ind1="0" ind2="0"> <subfield code="a">Neuromuscular disorders :</subfield> <subfield code="b">NMD.</subfield> </datafield><datafield tag="246" ind1="1" ind2="0"> <subfield code="a">NMD</subfield> </datafield><datafield tag="260" ind1="" ind2=""> <subfield code="a">Oxford ;</subfield> <subfield code="a">New York :</subfield> <subfield code="b">Pergamon Press,</subfield> <subfield code="c">c1991-</subfield> </datafield><datafield tag="300" ind1="" ind2=""> <subfield code="a">v. :</subfield> <subfield code="b">ill. ;</subfield> <subfield code="c">27 cm.</subfield> </datafield><datafield tag="310" ind1="" ind2=""> <subfield code="a">Bimonthly</subfield> </datafield><datafield tag="362" ind1="0" ind2=""> <subfield code="a">Vol. 1, no. 1-</subfield> </datafield><datafield tag="500" ind1="" ind2=""> <subfield code="a">Title from cover.</subfield> </datafield><datafield tag="510" ind1="1" ind2=""> <subfield code="a">Index medicus</subfield>
111
Appendix A: OAI-PMH ListRecords and Header Format Customer Profile for Primo
<subfield code="x">0019-3879</subfield> <subfield code="b">1991-</subfield> </datafield><datafield tag="530" ind1="" ind2=""> <subfield code="a">Also available in an electronic version.</subfield> </datafield><datafield tag="650" ind1="" ind2="2"> <subfield code="a">Neuromuscular Diseases</subfield> <subfield code="x">periodicals.</subfield> </datafield><datafield tag="655" ind1="" ind2="7"> <subfield code="a">Computer network resources.</subfield> <subfield code="2">local</subfield> </datafield><datafield tag="655" ind1="" ind2="7"> <subfield code="a">Electronic Journals.</subfield> <subfield code="2">mesh</subfield> </datafield><datafield tag="740" ind1="0" ind2=""> <subfield code="5">med</subfield> <subfield code="a">Neuromuscular disorders (Online)</subfield> </datafield></record></metadata></record></ListRecords></OAI-PMH
112
Appendix B
PNX Structure Reference: Sections and Fields
The PNX record is created and stored in XML format, using the UTF-8 character set.
The data in the PNX record is organized in sections; each section containing information for a specific purpose. In some cases, the data is duplicated to provide flexibility to the system when it is processing the data.
Each of the PNX sections contains various fields. Multiple and repeatable fields of the source record can be concatenated to one field in the PNX record (for example, in the Display section) or stored in separate fields within the PNX record (for example, in the Search and Facets sections).
Subfields in the PNX
Some fields in the PNX record have multiple values that are delimited by two dollar signs followed by a specific character or number (similar to MARC subfields). The following table lists the various subfield delimiter types used in the PNX record.
Table 9. Subfield Delimiter Types
Type Delimiter Description
Uppercase Alphabetic.
The character denotes the content and is persistent across PNX fields.
A Algorithm used for FRBR key type.
C Constant that displays before the field. The constant is translated via the Display Constants code table of the Front End subsystem.
D Text that displays instead of the field (for example, for URLS).
E Constant that displays instead of the field (for example, for URLS). The constant is translated via the Full Display Labels code table of the Front End subsystem.
113
Appendix B: PNX Structure Reference: Sections and Fields Customer Profile for Primo
Type Delimiter Description
I Institution code.
K Key for FRBR.
L Library code.
O Origin of the field used in Deduped records – the sourceid.
S Status.
T Template code.
U URL.
V Value of the field (to distinguish between the value of the field and the display text or constant).
Numeric. Indicates the order of the data elements.
Note: All text fields can be either a code or text. Primo first searches for a translation of the value in the codes table and, only if it does not find the translation, will Primo display the value.
The Control Section
The Control section includes formatted data used for control purposes. The following table lists the contents of the Control section.
Table 10 . Control Section Fields
Field Description
sourceid Source ID. Identifies the source repository in Primo. Every source repository has a configuration file in which the sourceid and other information about the source repository are recorded.
originalsourceid Original Source ID. Identifies the source repository in the source system. This is not necessarily the same as the source repository’s identifier in Primo. (for example, USM01).
sourcerecordid Source Record ID. Identifies the record in the source repository. For example, an ALEPH system number supplied in MARC21 tag 001. This ID must be unique and persistent within the source repository. The sourcerecordid is derived from the OAI header.
addsrcrecordid Additional Source Record ID. An additional ID of the source
114
Appendix B: PNX Structure Reference: Sections and Fields Customer Profile for Primo
Field Description
record.
recordid Record ID. The unique identifier of the record in the Primo repository. The sourceid and sourcerecordid are concatenated to create the recordid (for example, ALEPH system number + tag 001).
sourcetype Source Type. Not in use.
sourceformat Source Format. Identifies the original format of the source record, such as MARC21, Dublin Core, MAB2, etc.
sourcesystem Source System. Identifies the system used by the source repository, such as ALEPH, Voyager, MetaLib, SFX, DigiTool, etc.
recordtype Record Type. Not in use.
lastmodified Date Last Modified. Not in use.
The Display Section
The Display section includes data used in the brief and full display formats of the user interface.
The basis for the data elements used in the Display section is the Dublin Core element set. Dublin Core was selected as a metadata standard that is intended to support a broad range of purposes and resource types. In some cases, the names of the Dublin Core elements have been modified and a number of additional fields have been added. Note that some sources may not include all of the data elements. In other cases, it is necessary to map data to the most suitable element.
Note: Some formatting of the data for display is performed during the mapping process in order that this processing need not be performed online.
In addition to the fields listed in the following table, Primo sites can define up to five local display fields.
115
Appendix B: PNX Structure Reference: Sections and Fields Customer Profile for Primo
Table 11. Display Section Fields
Field Name Description
type Resource Type. Represents the main format of the record or the type, based on a master list of main record types. It is recommended to include only a minimum number of types (~10). Primo sites are able to modify this list so that it is suited to the content of its repository and its users. The type is used to determine which icon displays next to the record in the brief and full results list. Every record must have a single type field.
The default Resource Type list includes: book
journal
article
text_resource – for all text resources that cannot be identified as a book, journal, or article.
image
video
audio
map
score
database
website
other – a resource type for records that cannot be classified as any other resource type.
Example of source data:
MARC21 – mapping based on the leader position 6 and the 007 and 008 fields.
source Source Repository. The source repository from which the record was derived.
title Resource Title. The name given to a resource. The title can be created from a number of fields and subfields from the source record. Multiple occurrences are not concatenated.
Example of source data:
MARC21 – 245 subfields $$a and $$b.
116
Appendix B: PNX Structure Reference: Sections and Fields Customer Profile for Primo
Field Name Description
creator Content Creator. An entity responsible for creating the content of the resource. Multiple occurrences are concatenated with a semi-colon.
Example of source data:
MARC21 – 245 subfields $$c OR if 245 $$c is not present, 1XX, stripping subfield $$d, and stripping from subfield $$t to the end. It is possible to reverse the author’s last and first name (for example, Stephans, Mary to Mary Stephans) by using a special routine.
Note:The display form of the creator also serves as a hyperlink to search for additional records. It is important that all the strings in the display also be added to the creatorcontrib field in the Search section.
contributor Contributor. An entity responsible for making a contribution to the content of the resource. Multiple occurrences are concatenated with a semi-colon.
Example of source data:
MARC21 – 700/710/711 fields, stripping subfield $$d, and stripping from subfield $$t to the end. It is possible to reverse the author’s last and first name by using a special routine (for example, Stephans, Mary to Mary Stephans)
Note: The display form of the contributor also serves as a hyperlink to search for additional records. It is important that all the strings in the display also be added to the creatorcontrib field in the Search section.
description Description. Any information describing the content of the resource. This can be an abstract, contents notes, summary, etc. Multiple occurrences are not concatenated.
Example of source data:
MARC21 – 502, 505, 520 fields.
edition Resource Edition. The edition of the resource. This is one of the fields of the PNX record that is not derived from Dublin Core. Edition is a key element in grouping bibliographic records.
Example of source data:
MARC21 – 250 $a and $b.
117
Appendix B: PNX Structure Reference: Sections and Fields Customer Profile for Primo
Field Name Description
format Physical Format. The physical description, extent, or digital manifestation of the resource. Multiple occurrences are concatenated with a semi-colon.
Example of source data:
MARC21 – 300 and 340 fields. Can also be created from the control data in the leader and 008, 006 fields.
identifier Identifier. Any unique identifier of the record. Dublin Core defines this as an unambiguous reference to the resource within a given context. In the context of the PNX record, this is intended to be used for standard identifiers like ISBN and ISSN. Multiple occurrences are concatenated with a semi-colon.
Example of source data:
MARC21 – 020 $$a – prefix the value with ISBN:022 $$a – prefix the value with ISSN:
language Resource Language. The language of the resource. The language is stored in coded form (ISO 639-2) and is translated in the user interface. Multiple occurrences are concatenated with a semi-colon.
If the language is not in ISO 639-2 form, the normalization process attempts to convert it to this form. If this is not possible, the language is unknown (using the und code).
Example of source data:
MARC21 – 008/35-37; if blank, use 041 subfield $$a.
publisher Publisher. An entity responsible for making the resource available. Multiple occurrences are concatenated with a semi-colon.
Example of source data:
MARC21 – 260 subfields $a and $b.
creationdate Creation Date. The date or year when the resource was created or the year of publication and/or manufacture. Multiple occurrences are concatenated with a semi-colon.
Example of source data:
MARC21 – 008/07-10; 260 $$c.
118
Appendix B: PNX Structure Reference: Sections and Fields Customer Profile for Primo
Field Name Description
subject Subject. The topic of the content of the resource. Multiple occurrences are concatenated with a semi-colon.
Example of source data:
MARC21 – 6XX fields
Note: The display form of the subject also serves as a hyperlink to search for additional records. It is important that all the strings in the display also be added to the search index.
coverage Coverage. The extent or scope of the content of the resource.
relation Related Resource. A reference to a related resource. Multiple occurrences are not concatenated.
Example of source data:
MARC21 – 440, 830, 760-787 except for 773.
ispartof Parent Resource. A reference to a resource from which the resource is derived (for example, in an article from a journal – the journal is the source). Multiple occurrences are not concatenated. This type of relationship has been added as a specific relationship so it can be displayed as part of the brief results display.
Example of source data:
MARC21 – 773.
rights Rights. Information about the rights of the resource.
availlibrary Library Level Availability. Includes availability information per Primo library in addition to location information. The field is structured with subfields as follows:
$$I – institution code
$$L – library code
$$1 – sub-location
$$2 – call number
$$S – availability status: available, unavailable, check_holdings
$$3 – number of items
$$4 – number of unavailable items
$$5 – multi-volume flag: Y/N
$$6 – number of loans (for ranking purposes)
119
Appendix B: PNX Structure Reference: Sections and Fields Customer Profile for Primo
Field Name Description
availinstitution Availability Institution. Calculated automatically by Primo from all library level availability fields that belong to the institution using the following logic:
Primo merges the availability status from $$S for all availlibrary fields for the institution and creates the merged availability status as follows:
If one of the statuses is check_holdings, Primo sets the merged availability status to check_holdings.
If one of the statuses is available, Primo sets the merged availability status to available.
If neither of the above conditions exist, Primo sets the merged availability status to unavailable.
If an institution does not have an availability field, Primo creates a field with the availability status does_not_exist.
The availinstitution field is used at runtime to calculate the availability status for the brief results set.
availpnx Availability PNX. Calculated by Primo from all availinstitution fields from the Display section using the following logic:
Primo takes all availinstitution fields and merges the availability status from $$S as follows:
If one of the statuses is check_holdings or available, Primo sets availpnx to available.
If the above condition does not exist, Primo sets availpnx to unavailable.
This field is used in the user interface when filtering by availability.
userreview User Review. Review added by the end user.
userrank User Rank. Rank or score assigned by the end user for the resource.
120
Appendix B: PNX Structure Reference: Sections and Fields Customer Profile for Primo
The Links Section
The Links section contains links that can be used to create the GetIT! functionality and/or to create links in the record display (for example, a link to the Table of Contents). The Links section includes several fields, each of which represents a function in Primo.
The PNX Link field includes data based on the type of link:
Static – The Link field contains the URL. A static URL may require some attributes, including the institution to which it belongs and a display text. These are indicated by subfield delimiters ($$UURL$$DDisplay text$$IInstitution).
Calculated – Calculated URLs are created from a template that is defined in the Primo Back Office. The Link field contains URL template code, data for the template place-holders, and the institution (if several fields of the same type are added for different institutions).
The following table lists the fields in the Links section. In addition to these fields, Primo sites can define up to five local Links fields.
Table 12. Links Section Fields
Field Name Description
openurl Open URL. The open URL. In principle, this URL can be created by Primo for the metadata in the PNX.
openurlfullt Open URL Full Text. An open URL that is limited to the full-text service.
openurlservice Open URL Service. An open URL that is limited to a specific service other then the full-text service.
linktoholdings Link to Holdings. A link to the holdings display and request options in the source system.
For multi-institution sites, the following links can be used:
linktoholdings_avail – A link to the holdings display and request options in the source system if the item is available in the user’s institution.
linktoholdings_unavail – A link to the holdings display and request options in the source system if the item is unavailable in the user’s institution.
linktoholdings_notexist – A link to the holdings display and request options in the source system if the item does not exist in the user’s institution.
121
Appendix B: PNX Structure Reference: Sections and Fields Customer Profile for Primo
Field Name Description
linktorequest Link to Request. A link to a form or page on which a user can place a request.
backlink Back Link. A link back to the original record in the source repository.
linktorsrc Link to Resource. A link to the resource itself (for example, to the full-text or image).
linktotoc Link to Table of Contents. A link to the item’s Table of Contents.
linktoabstract Link to Abstract. A link to the item’s abstract.
linktoreview Link to Review. A link to the item’s review.
linktoprice Link to Price. A link to the item’s price.
Linktoextract Link to Extract. A link to an extract or first chapter of the item.
thumbnail Link to Thumbnail. A link to the item’s thumbnail.
linktofindingaid Link to Finding Aid. A link to a finding aid.
linktouc Link to Union Catalog. A link to a Union Catalog (for example, WorldCat).
additionallinks Additional Links. Additional links relevant to the resource.
122
Appendix B: PNX Structure Reference: Sections and Fields Customer Profile for Primo
The Search Section
The Search section includes the data (including metadata and full-text) being indexed during a search. The data is in several indexes to enable qualified searching – that is, to search for a specific index and/or enable ranking based on the field in which the query search terms were found.
Note: Repeatable fields of the source record are mapped to repeatable fields of the PNX record.
Table 13 describes the fields in the Search section. In addition to these fields, Primo sites can add up to five local index fields.
Table 13. Search Section Fields
Field Description
creatorcontrib Creator/Contributor. The normalized form of authors created for the facets.
Example of source data:
MARC21 – 1XX and 700/710/711 fields.
title Title. All main title related fields.
Examples of source data:
MARC21:
245 subfields $$a and $$b.
246 subfields $$a and $$b.
addtitle Additional title. Additional title fields.
Examples of source data:
MARC21:
440 subfield $$a.
830 subfield $$a.
description Description. Information describing the content of the resource. This includes abstract, contents notes, summary, etc.
Example of source data:
MARC21 – 502, 505, 520 fields.
subject Subject. The topic of the content of the resource.
Example of source data:
MARC21 – 6XX fields.
isbn ISBN. The ISBM of the item.
Example of source data:
MARC21 – 020.
123
Appendix B: PNX Structure Reference: Sections and Fields Customer Profile for Primo
Field Description
issn ISSN. The ISSM of the item.
Example of source data:
MARC21 – 022.
fulltext Full text. Words from the full-text that were added in the enrichment phase.
toc TOC. Words from the Table of Contents.
rsrctype Resource Type. The type field from the Display section.
creationdate CreationDate. The publication date.
usertag User Tag. End user tags.
recordtype RecordType. Not in use.
sourceid SourceID. Based on the sourceid field from the Control section. This may be required to filter out certain records and is an internal Primo index.
recordid RecordID. The recordid field from the control section, which is used to locate a specific record. This is an internal Primo index.
addsrcrecordid General. Words from the fields added to this field are added to the general word file – for example, publisher.
searchscope Search Scope. Used to create search scopes in Primo views. This field is copied to the scope field for indexing by the search engine.
ressearscope Restricted Search Scope. Used to limit discovery of certain PNX records to specific user groups. In order to limit discovery, the records should be assigned a restricted search scope. Access is enabled based on the restricted search scopes defined in a Back Office table. Access can be enabled based on institution, on-off campus, and user group. This field is copied to the scope field for indexing by the search engine.
scope Scope. Used to create search scopes and restricted search scopes. The values from the Search scope and Restricted search scope fields in the delivery section should be copied to the scope field.
pnxtype PNX Type. An internal Primo index that defines the type of PNX record.
matchid Match ID. The ID assigned to records following the duplicate detection process.
frbrid FRBR ID. The ID assigned to records following the FRBRization process.
124
Appendix B: PNX Structure Reference: Sections and Fields Customer Profile for Primo
The Facets Section
The Facets section is used to create faceted browsing in the user interface. The facets are intended to help the user refine the results list. A single record can have many types of facets, as well as multiple values for a single facet type. Sites can decide which facets they want to include in the user interface.
describes the fields in the Facets section. In addition to these fields, Primo sites can define up to two local Facet fields (lfc01 and lfc02). describes the fields in the Facets section. In addition to these fields, Primo sites can define up to two local Facet fields (lfc01 and lfc02).
Table 14. Facets Section Fields
Field Description
rsrctype Resource type. The nature or genre of the resource. This field is based on the rsrctype field in the Display section:
Book books.
Journal journals.
Article articles.
Text Resource text resources.
Image images.
Audio media.
Video media.
Score scores.
Map maps.
Database -> databases
Website -> websites
Other others.
language Language. The language of the resource. The language is stored in coded form (ISO 639-2) and translated in the user interface.
If the language is not coded, the normalization process attempts to convert it to coded form. If this is not possible, a language facet is not created.
Examples of source data:
MARC21 – 008/35-37; if blank, use 041 subfield $$a.
creatorcontrib Creator/Contributor. This facet attempts to normalize personal names so that the field contains the last name and the first letter of first name, since this is common in many databases.
Example of source data:
MARC21 – 100/110/111 and 700/710/711 fields.
125
Appendix B: PNX Structure Reference: Sections and Fields Customer Profile for Primo
Field Description
If the author is a person, the field contains the last name and the first letter of each of the first names:
The second and third characters of the tag are 00.
The first indicator is 1 (for example, 1001).
Use subfield $$a only.
The first name is each word after the comma.
If the author is a conference, the field contains only the conference name, and not particulars on time or place:
The second and third characters of the tag are 11 (for example, 711).
Use subfield $$a only.
In all other cases, the entire field is used.
topic Topic. The topic facet enables the display of topics (subjects) on three levels. Every level is separate by a hyphen with a 3-byte Unicode representation. In the user interface, only three levels are used.
Examples of source data:
MARC21 – 6XX (all fields which begin with the digit 6) fields:
First facet level (topic 1) is all data up to the first occurrence of subfield $$v, x, y, or z. Each subfield division (v, x, y, or z) constitutes the next level. The string is truncated after three levels.
genre Genre. The genre of the resource.
Examples of source data:
MARC21 – 655 and subfield v from all 6XX.
classificationlcc
classificationddc
classificationrvk
Classification LCC, DDC, and RVK. The classification facet can be used to create a subject browse list based on the main subject classes of the classification scheme. The classification code is translated into a description in the enrichment phase.
creationdate Creation Date. The creation date should be normalized to four digits. If it cannot be normalized, do not create the field.
Examples of source data:
MARC21 – 008/07-10; 260 $$c.
format Physical format. The physical format or file type.
Examples of source data:
MARC21 – Can be based on the 007 control field.
filesize File Size. The size of the file for digital objects.
126
Appendix B: PNX Structure Reference: Sections and Fields Customer Profile for Primo
Field Description
collection Collection. This is the collection (physical, digital, electronic, or logical) to which the resource belongs. The collection facet is a code that is translated in the user interface.
Examples of source data:
MARC21 – 852 $b $c
library Library facet. A facet for physical libraries which can be used instead of or in addition to the collection facet. The Library facet has a special (optional) feature intended for multi-institution sites. - it is possible to configure the facet so that it is split between libraries belonging to the user’s institution and libraries belonging to all other institutions.
prefilter Pre-filter. The search pre-filter that is available in the Primo user interface must be mapped as a facet. The default list of pre-filters is based on the Resource Type field in the display:
Book Books (books) (all_text)
Journal All text (all_text)
Article All text (all_text)
Text Resource All text (all_text)
Image Images (images)
Video Audio-Video (audio-video)
Audio Audio-Video (audio-video)
pnxdate PNX date. This is the date on which the PNX record was loaded into the Primo database. The PNX date is added automatically by the system.
The Sort Section
The fields in the Sort section can be used as the basis for sorting the results set. The following sort parameters are included in the Normalized Record.
Table 15. Sort Section Fields
Field Description
Creation Date The creation date should be normalized to four digits.
Example of source data:
MARC21 – 008/07-10; 260 $$c.
Popularity [not in use]
Number of times the item has been loaned.
127
Appendix B: PNX Structure Reference: Sections and Fields Customer Profile for Primo
Field Description
Title [not in use]
128
Appendix B: PNX Structure Reference: Sections and Fields Customer Profile for Primo
The Duplicate Record Detection Section
The fields in the Duplicate Record Detection Section include the data required to eliminate duplicate records. Duplicate records are normally derived from different repositories. A “de-duplication” vector is created for every record. Equivalent records are assigned the same MatchID.
The FRBR Section
The fields in the FRBR Section include the data required to group related records (FRBRization).
The Delivery and Scoping Section
The Delivery and Scoping section includes information that Primo requires to manage delivery and scoping for searches.
Primo is used to discover and deliver institutional resources. In principle, Primo provides delivery services by linking the user to other applications, for example the ILS for placing requests, the Digital repository for viewing digital objects. Access to such resources is controlled by the local application, not by Primo. However, Primo includes information concerning the availability of the item and attempts to provide a link to the best possible delivery option (the GetIt! function).
Table 16 describes the fields in the Delivery and Scoping section.
Table 16. Delivery and Scoping Section Fields
129
Appendix B: PNX Structure Reference: Sections and Fields Customer Profile for Primo
Field Description
institution Institution. The institution to which the resource belongs.
delcategory Delivery category. Delivery functions are configurable. The delivery categories are the resource categories for which delivery may function differently. The following are supported categories:
Physical item (all physical items except for journals and microfilms).
Print journal.
Microform.
Electronic (online) journal.
Online resources.
MetaLib KB resource – these are records from the MetaLib Knowledgebase.
Remote search resource – these are records retrieved via MetaLib.
resdelscope Restricted delivery scope. The restricted delivery scope is used to define access restrictions for online resources. The restrictions (based on institution, on/off campus, user group) are defined in a table in the Back Office. Lack of a restricted delivery scope field in the PNX indicates that there are no restrictions.
The Ranking Section
The Ranking section includes two booster fields that can be used to boost the ranking of the record.
Table 17 describes the fields that can be added to the Ranking section.
Table 17. Ranking Section Fields
Field Description
Booster1 Defaults to 1, indicating no boost. A plug-in enrichment routine can change this boost based on data in the Enrichment section.
Booster2 Additional booster field. Defaults to 1, indicating no boost. A plug-in enrichment routine can change this boost based on data in the Enrichment section.
130
Appendix B: PNX Structure Reference: Sections and Fields Customer Profile for Primo
The Enrichment Section
The Enrichment section includes data that is required by the enrichment process. The results of the enrichment process are not stored in this section, but rather in one of the following sections: Display, Search, Facets, or Links.
Table 18 describes the fields in the Enrichment section. In addition to the fields listed in the table, Primo sites can define up to five local enrichment fields.
Table 18. Enrichment Section Fields
Field Description
classificationlcc
classificationddc
classificationudc
classificationrvk
Classification. LCC/DDC/UDC/RVK. A classification code that is translated into descriptive text.
fulltext Full text. A link to full-text.
toc TOC. A link to a table of contents.
abstract Abstract. A link to an abstract.
review Review. A link to a review.
availability Availability. This field can include raw availability related data from the source for processing by an enrichment program.
rankfatherson Rank parent/child. This ranking field is relevant for records with a hierarchal relationship.
Example from MAB: Mapping based on leader pos. 23:
h father
u son
ranknocopies Rank number of copies. The number of copies.
rankdatefirstcopy Rank date first copy. The date of the first copy. This can be relevant for boosting ranking based on circulation date.
ranknoloans Rank number of loans. The number of loans.
131
Appendix B: PNX Structure Reference: Sections and Fields Customer Profile for Primo
The Additional Data Section
The Additional Data section contains data elements that are required for a number of functions in Primo that cannot be extracted from other sections of the PNX.
Table 19 lists the fields in the Additional Data section, mapping them to the equivalent data elements of the ContextObject of the OpenURL and RIS format for a reference management system.
Table 19. Additional Data Section Fields
Field Name ContextObject RIS
Author last aulast
Author first aufirst
Author initials auinit
Author first initial auinit1
Author middle initial auinitm
Author suffix ausuffix
Author au A1
Author au A1
Corporate author aucorp A1
Additional author A2
Series author A3
Book title btitle, title T1
Article title atitle T1
Journal title jtitle JF
Short title stitle JA
Additional title T2
Series title T3
Date date
RISDate Y1
Additional Date Y2
Volume volume VL
Issue issue IS
Part part
132
Appendix B: PNX Structure Reference: Sections and Fields Customer Profile for Primo
Field Name ContextObject RIS
Season ssn
Quarter quarter
Start page spage SP
End page epage EP
Pages pages
Article number artnum
ISSN issn SN
eISSN eissn SN
ISBN isbn SN
CODEN coden
SICI sici
Metadata format format
Genre genre
RISType Type
Notes N1
Abstract N2
City of Publication CP
Publisher PB
Miscellaneous1 M1
Miscellaneous2 M2
Miscellaneous3 M3
OCLC ID
Local fields 1-5 U1-5
133
Appendix C
End-to-end Delivery Examples
This section contains an end-to-end scenario of a delivery configuration.
Part One
Data is sent by source system, where the records’ availability and location information is specified at the library level.
From ALEPH: every extracted record includes an AVA field with the information about the record’s availability and location in the library:
datafield tag="AVA" ind1="" ind2=""> < subfield code="a">PRM50</subfield> < subfield code="b">NWILS</subfield> < subfield code="c">BUS</subfield> < subfield code="e">available</subfield> < subfield code="f">0</subfield> < subfield code="g">0</subfield> < subfield code="i">0</subfield> < /datafield>
From Voyager: every extracted record includes an 949 field with the information about the record’s availability and location on the collection level:
<datafield tag="949" ind1=" " ind2=" ">
<subfield code="a">primo1db</subfield>
<subfield code="b">Main Library</subfield>
<subfield code="c">Current Periodicals</subfield>
<subfield code="d">Z372 .M49</subfield>
<subfield code="e">available</subfield>
<subfield code="f">1</subfield>
<subfield code="g">0</subfield>
<subfield code="h">N</subfield>
<subfield code="i">0</subfield>
<subfield code="j">PER-CURR</subfield>
134
Appendix C: End-to-end Delivery Examples Customer Profile for Primo
</datafield>
Other source systems can send the availability and location information on either the library level or copy level. In case the availability and location information is extracted at the copy level (UNICORN), it will be normalized in Primo so that the information is grouped at the library level
<datafield tag="999" ind1="" ind2=""> <subfield code="a">ABC123</subfield> <subfield code="w">LC</subfield> <subfield code="c">1</subfield> <subfield code="i">3333333333333</subfield> <subfield code="d">4/30/2003</subfield> <subfield code="e">4/15/2003</subfield> <subfield code="l">STACKS</subfield> <subfield code="m">CENTRAL</subfield> <subfield code="n">4</subfield> <subfield code="r">Y</subfield> <subfield code="s">Y</subfield> <subfield code="t">BOOK</subfield> <subfield code="u">6/27/1985</subfield> <subfield code="o">.CIRCNOTE. This item circulates.</subfield> <subfield code="o">.CIRCFLAG. Y</subfield> <</datafield>
Primo maps the library level availability and location information into PNX field availlibrary (display section).
<availlibrary>$$INORTH$$LNWILS$$1BUS$$Savailable$$30$$40$$60</availlibrary>
Primo displays the library’s level of availability and location information in the Front End:
135
Appendix C: End-to-end Delivery Examples Customer Profile for Primo
Figure 9. Full View of the Record – Availability and Location Section
Figure 10. Check Availability and Location Tab of GetIt Window
Note: The library name is taken from ILS Library Names mapping table, which is automatically created when Libraries are defined in the Back Office using the Institutions and Libraries Wizard.
136
Appendix C: End-to-end Delivery Examples Customer Profile for Primo
Part Two
Primo uses library level availability and location information to calculate availability status at the institution level, when the user information, resource delivery category and data source are taken into account.
For example, if the record is a physical item that is now available in user’s library, the item’s status is calculated by Primo as “available_in_my_institution”. The display text is configured as “Available in your library”
Figure 11. Available in Your Library Appearing in the Display Text
If the record is an electronic online resource without any access restrictions, its status is calculated by Primo as “not_restricted”. The display text is configured as “Available online”
Figure 12. Available Online Appearing in the Display Text
If the record is an electronic online resource with at least one access restriction, its status is calculated by Primo as “restricted”. The display text is configured as “Restricted access”.
Figure 13. Restricted Access Appearing in the Display Text
137
Appendix C: End-to-end Delivery Examples Customer Profile for Primo
The calculated availability status is displayed in both the Brief and Full views of the Front End.
Part Three
Behind the GetIt link in both the Brief and Full views, there is a delivery option (URL) that retrieves the searched record in the best possible way. The delivery option used is configurable based on the record’s delivery category, calculated availability status, and data source.
In the Back Office, access the GetIt Link Configurations by accessing the following path:
Primo Home > Initial Configuration Wizards > Primo Configuration Wizard > Step 4: Front End Configuration Wizard > Step 2: Restrictions and Delivery Configuration Wizard > Step 2: GetIT! Configuration – Get It link Configuration section
You can define the link field in the PNX/links section to be activated for different combinations of the record’s delivery category, calculated availability status, and data sources.
Figure 14. Defining the Link Field Activation Settings
Figure 14 describes the following configurations:
The first row defines the settings for physical items available in the library. Invoking the GetIt! link activates the ‘linktoholdings’ link field in PNX/links section:<linktoholdings>$$Taleph_holdings</linktoholdings>
The “linktoholdings” field is configured to use the “aleph_holdings” template, which includes placeholders, such as the document number and library code that are calculated in the real time.
138
Appendix C: End-to-end Delivery Examples Customer Profile for Primo
The second row defines the settings for a non-restricted online electronic resource. Invoking the GetIt! link activates the ‘linktorsrc’ link field in PNX/links section:<linktorsrc>$$Uhttp://flora.huh.harvard.edu:8080/flora/flora_page.jsp?flora_id=1$$DOnline Version</linktorsrc>
The “linktosrc” field, which appears in the second row, is configured to include the static URL, display text, and optionally, the institution code. The extraction location of the URL and display text from the source record, is specified during the configuration of the normalization rules:<linktorsrc>$$U<856_u>>$$D<856_z>
In this case the URL is taken from the data in the 856$$u field of the source record, and the display text is taken from the 856$$z field of the source reccord.
The third row defines the settings for a restricted online electronic resource. Invoking the GetIt! link activates the ‘backlink’ link field in PNX/links section:<backlink>$$Taleph_backlink$$DThis item in ALEPH</backlink>
The “backlink” field, which appears in the third row, is configured to use the “aleph_backlink” template and display text.
The configuration of the templates is done in the Back Office by accessing the following path:
Primo Home > Initial Configuration Wizards > Primo Configuration Wizard >Step 4: Front End Configuration Wizard > Step 2: Delivery and Delivery Restrictions > Step 3: GetIT! Configuration – Templates section:
The “aleph_holdings” template, used in our example for physical items, is as follows:
{{ils_base}}?func=item-global&doc_library={{control/originalsourceid}}&doc_number ={{control/sourcerecordid}}&local_base={{control/originalsourceid}}
The data in the curly brackets are placeholders, which are calculated in the real-time.
{{ils_base}} – Contains the ILS URL as defined in the Institutions and Libraries Wizard or the Delivery Base URLs section of the Back Office.
139
Appendix C: End-to-end Delivery Examples Customer Profile for Primo
Figure 15. Defining the ILS URL in the Back Office
{{control/originalsourceid}} = Contains data from the PNX or control section about the originalsourceid field. In this case, the originalsourceid field contains prm01.
{{control/sourcerecordid}} = Contains data from the PNX or control section about the sourcerecordid field. In this case, the sourcerecordID field contains 000007895.
The resolution of the link is:http://aleph-demo.exlibrisgroup.com:8992/F?func=item-global&doc_library=PRM01&doc_number=000007895&local_base=PRM01
The “aleph_backlink” template, used in our example for restricted online resources, is as follows:
{{ils_base}}?func=direct&local_base={{control/originalsourceid}}&doc_number={{control/sourcerecordid}}
The data in the curly brackets are placeholders, which are calculated in the real time.
{{ils_base}} = Contains the ILS URL as defined in the Institutions and Libraries Wizard or the Delivery Base URLs section of the Back Office.
Figure 16. Defining the ILS URL in the Back Office
{{control/originalsourceid}} – Contains data from the PNX or control section about the originalsourceid field. In this case, the originalsourceid field contains prm01.
{{control/sourcerecordid}} – Contains data from the PNX or control section about the sourcerecordid field. In this case, the sourcerecordID field contains 001294631.
140
Appendix C: End-to-end Delivery Examples Customer Profile for Primo
The resolution of the link is:http://aleph-demo.exlibrisgroup.com:8992/F?func=direct&local_base=PRM01&doc_number=001294631
The following are example destinations according to the delivery settings:
For non-restricted online electronic resource, invoking the GetIt! link takes the user directly to the resource:
Figure 17. Non-restricted Online Resource
For restricted online electronic resource, invoking the GetIt! link takes the user back to the original record in the source repository, where the user may find an explanation for the restriction (see Figure 18). For example, the resource may be restricted only to users who sign-in.
141
Appendix C: End-to-end Delivery Examples Customer Profile for Primo
Figure 18. Restricted Online Resource Displaying Original Source Record
For physical items available in the library, invoking the GetIt! link takes the user to the List of Holdings screen for this resource in ALEPH, where all information about its items and holdings are displayed.
142
Appendix C: End-to-end Delivery Examples Customer Profile for Primo
Figure 19. Physical Available Items Displayed in List of Holdings Window
143
Recommended