shared systems (consortia) omri gerson verde & sfx development director ex libris system seminar...

Shared Systems (Consortia)

Omri GersonVerde & SFX Development Director

Ex Libris System SeminarPotsdam, GermanyMay 13-16, 2007

Shared Systems (Consortia)2

Copyright Statement

All of the information and material inclusive of text, images, logos, product names is either the property of, or used with permission by Ex Libris Ltd. The information may not be distributed, modified, displayed, reproduced – in whole or in part – without the prior written permission of Ex Libris Ltd.

TRADEMARKS Ex Libris, the Ex Libris logo, ALEPH 500, SFX, SFXIT, MetaLib, DigiTool, Verde, Primo, Voyager, Journals Onsite, MetaSearch, MetaIndex and other Ex Libris products and services referenced herein are trademarks of Ex Libris, and may be registered in certain jurisdictions. All other product names, company names, marks and logos referenced may be trademarks of their respective owners.

DISCLAIMER The information contained in this document is compiled from various sources and provided on an "AS IS" basis for general information purposes only without any representations, conditions or warranties whether express or implied, including any implied warranties of satisfactory quality, completeness, accuracy or fitness for a particular purpose. Ex Libris, its subsidiaries and related corporations (the "Ex Libris Group") disclaim any and all liability for all use of this information, including losses, damages, claims or expenses any person may incur as a result of the use of this information, even if advised of the possibility of such loss or damage.

© Ex Libris Ltd., 2007


Session Topics

Which Functions are Shared?

Consortia Players - Roles and

Responsibilities

Central Catalog Model

Union Catalog Model

Shared System Model

E-Resources - Consortia in Verde & SFX

Discovery - Consortia in Primo & ML


Things to Remember

No two consortia are alikeNo model solves it allDifferent attitudes in different world regions (US, Europe, Asia, South America, Pacific)


Shared Functions

Central CatalogCentral OPACBack office

UsersCirculationVendorsAdministration

Hardware, software and maintenance


Consortia Players – Roles & ResponsibilitiesThe nature of the players determines whichmodels and functions can be realized

Example:Center that provides services to membersIndividuals that want to share some things

Who will host and manage the central functions?Do members use different versions of ALEPH or perhaps other systems as well?Willing to conform with central cataloging rules?Willing to share circulation statuses?

Any other combination…


Simple Multi ALEPH Model

A hosting model that allows totally separated libraries to exists on a singe serverSingle softwareMultiple and separate configurations

BIB RecordBIB Library

ADM RecordADM library





Not considered as a ‘real’ consortia model


Session Topics



Responsibilities


Union Catalog Model

Shared System Model





Prime goal is the central cataloging of BIB recordsShared bibliographic recordsDownload into local systemsBinding rules for central catalogingLocal systems receive corrections of locally owned recordsShared authorities



Holding and items are managed locally but replicated to the center Also serves as a central OPAC with the ability to show holdings, and allows jumping into the local systemsDepending on the model, the holdings in the center may range from full details of the item, to merely indicating the library has itMay be used as a database for central ILL systems



Exists in:GermanyAustriaMexicoBelgium (In implementation)China (under development)


Central Catalog – ALEPH Cluster

ReplicationReplication

Updates AUTExternaldata

Copy Cataloging

HOL

ADMADMADMADMADMADMHOL

ADMADMADMADMADMADMItems

ADMADMADMADMADMADMBIB

BIB

Updates

Local Local SystemsSystems

Central Central SystemSystem



Enables multiple servers (one per institution)Each institution controls its own BIB and ADM dataBibliographic and AUT records are cataloged centrally (Using ALEPH cataloging client)Holdings and items are entered locally ALEPH Cluster replication

Replication of BIB records: central -> localReplication of HOL records and items: local -> central Local systems use central AUT dataCentral Web-OPAC: Jump into the local OPAC

ALEPH Cluster - connection ALEPH <-> ALEPH via Z105 messaging



WorkflowBIB records are always created centrally first, then copied manually (CTRL+N) to the local BIB BIB records are centrally available -> copy (CTRL+N) to the local BIB.Every BIB or AUT update is automatically replicated to the local systems.HOL and item records are only created locally, and updated with automatic replication to the central system.


UpdatesUpdates

External Data

BIB

Central BIB records contain Central BIB records contain local owner information local owner information (LOW-tag)(LOW-tag)

AUT

Copy Copy CatalogingCataloging


ADMADMADMADMADMADMAUT



Central Catalog – Local Owner Update


Central “LOW” creation and deletion triggers message to local systemCentral record update triggers message to local systemLocal system fetches messages Local system collects record (Z39.50)Interface:

VST server provides messagesWeb-OPAC: Jump into the local OPAC



WorkflowBIB and AUT records are cataloged centrally (Using ALEPH cataloging client) LOW tag is added/deleted manually -> triggers the creation of a message to the local system.Administrative data and holdings are only maintained locally. Local system collects BIB and AUT data based on message, using Z39.50 (automatic process).



Central Catalog – MEX Items

Updates AUTExternaldata

Copy Cataloging

MEX Items

ADMADMADMADMADMADMItems


BIB



ADMADMADMADMADMADMAUT


Central Catalogs – Examples

HBZ – Hochschulbibliothekszentrum des Landes Nordrhein-Westfalen, KölnALEPH-Web: http://okeanos-www.hbz-nrw.de/FData model: ALEPH Cluster + MEX-items

BVB – Bibliotheksverbund Bayern, MünchenAccessed via MetaLib: http://bvba2.bib-bvb.de/V?RN=680510815Data model: Local Owner Update

ACC – Österreichischer Bibliothekenverbund, Wien ALEPH-Web: http://meteor.bibvb.ac.at/FData model: ALEPH Cluster


Session Topics


Consortia Players - Roles and Responsibilities


Union Catalog Model

Shared System Model




Union Catalog Model

Prime goal is to give a central OPACUploading of bibliographic records from local systems

Virtual De-duplication

Local systems are independent in terms of cataloging rules

Separate authorities

No “feedback” from Union catalog to local systems


Union Catalog Model

Summary holding information is available in the Union catalog

Some level of circulation information available in the Center (just in time)

Central OPAC support jumping into the local systems

The popular Union View functionality is powered by Union Catalog


Union Catalog Architecture

Original Records

Indexing

Equivalency Table

OPAC

Merge

Library A Library B Library C

Merge(just in time)

De-duplication

Normalizing, loading and

indexing

Contributors


Union Catalog – Upload in Index

Stores records as distinct entities in the databaseRecords can be loaded from an external resource or cataloged using ALEPH Cataloging moduleRecords that originate from an external resource can hold an identifier of the external resource, allowing navigation to the external resourceIndices are created using the standard ALEPH indexing scheme


Union Catalog – Equivalency

Equivalence table is created mapping each record to its equivalent recordsThe equivalence relation is not necessarily transitiveThe equivalence relation can be recreated at any time, leaving the records intact


Union Catalog – Just in Time Merge

Result sets will be de-duplicated to contain only one record per group of equivalentsBrowse lists will de-duplicate their counters to count only one record per group of equivalentsUser View uses on-the-fly Merge to present a single record that is built from a group of equivalentsThe Merge algorithm can vary from user to user Bases can be defined to bypass de-duplication hence can serve as a library specific OPAC


Union Catalog - Virtual Approach Advantages

In all cases, the data of each record stays intact in the databaseEasy to establish library specific OPACUpdating a record is simple and done by unlinking it from the equivalence table by marking it as “New”. This breaks all existing connections in the groupSame goes for deleting a record.A new record is simply inserted as equivalent only to itself


Loading of external resource takes no longer than the load and index time as in ALEPHThe worst-case effect of update, insert or delete is that between the time that a record was updated, until the time the equivalency entries are (re)created, the group of equivalent records will appear as non-equivalentUptime during loading



Same uptime considerations also apply if the match algorithm is to be changedThe merge algorithm can be changed with absolutely no effect since it is executed “just in time”



Union Catalog - Match

First phase - pool selection

Minimizing the equivalency search to a certain number of candidates Usually done on a direct index such as ISBN, ISSN or LCCN, and there for relatively fastIf number of candidates exceeds a certain limit the record itself will be considered as the only candidate


Union Catalog - Match

Second phase – final match

Finding the equivalent records from the poolLook for matching fields and conflicting fieldsMatch adds a positive weight whereas conflicts add a negative weightTotal weight checked against a threshold


Union Catalog - Merge

A merged record display is built by taking the “basic” fields from the preferred record and adding other fields from each of its equivalent recordsThe preferred record is selected by assigning weights to all the equivalent records based on table-defined criteria, top weight winsThe merge program is also table-definedNo merged record actually exists in the database. This is a virtual display created upon request


Union Catalog - OPAC

Jump to original

View in union

Holdings


Union Catalogs – Examples

CDL – Melvyl, California Digital Library

ALEPH-Web: http://melvyl.cdlib.org/F

KOBV – Kooperativer Bibliotheksverbund Berlin-BrandenburgAccessed via MetaLib: http://se3.kobv.de/V?func=meta-1&portal=KOBV&institute=KOBV&mode=advanced


Session Topics



Responsibilities


Union Catalog Model

Shared System Model




Shared System Model

Also known as Multi ADM modelImplemented widely in North America but in many other regions as wellRuns on a single system (hardware and software)Single Service Pack and Upgrade


Shared System Model

Provide a comprehensive solution for the functionality required by shared systems including

Shared and non shared OPACs including local brandingShared and non shared user filesResource sharingAutonomous administration (items, acquisitions, serials etc…)

Relatively centralized approach. Requires parties to conform to various consortia standardsOptimizes TCO


Shared System Architecture

BIB

Local Patrons

Budget

Acq

Circ

Items

ADM

AUT HOL

Global Patrons

Staff

Vendors

Local Patrons

Budget

Acq

Circ

Items

ADM

Local Patrons

Budget

Acq

Circ

Items

ADM

Library A Library B Library C

Center

Central Administratio

n


ADM Library 1

Shared System – Single BIB per title

BIB Library

BIB Record

ADM Library 2 ADM Library 3

ADM Record ADM Record ADM Record


ADM Library 1

Shared System – Multiple BIBs per Title

BIB Library

BIB Record

ADM Library 2 ADM Library 3

ADM Record ADM Record ADM Record

BIB RecordBIB Record

Union View


Shared System Model – Union View

Union view is based on Union Catalog architectureNo loading required. Works on the original bibliographic recordsNo need to jump into local OPAC – merging is also done for itemsVirtual host approach can be used to realize library based OPAC with library branding


Shared System Model


Shared System Model - Shared Patrons

a single patron file, in which the patrons of a specific institution are relevant only for the single institution (not shared), or relevant for all other institutions (shared)Privileges for each patron can be defined from the specific to the general, from a particular sublibrary, through the institution, to the consortium/shared systemThe system uses the item’s library to find the best-match patron privileges record (using tab_sublibrary definitions)


Shared System Model - Shared Patrons

Practical problems:Patron identifiers must be uniquePatron identifiers from separate sources must be the same, in order to identify the same person (though the system can work with a person having 2 separate identities)Patron privacy requires that patron view will be allowed or denied to staff users depending on different criteria


Shared Patrons Database Design

The global patron records (Z303, Z304, Z308, Z353) are resident in the system-level usr_library. The local patron records (Z305), which set the patron’s circulation privileges in the sublibraries of a single institution (ADM environment), are resident in each ADM library.


Shared Patrons Database Design

There can be a Z305 “ALEPH” record resident in the usr_library. It is used as fallback if an ADM record is not found. It is required for Direct Consortial Borrowing (PDQ).


Patrons – Shared / Non-shared

Patron sharing or non-sharing can be defined per ADM.Shared patrons:

Option for resource sharing through PDQ (Direct Consortial Borrowing)Requires unique identifiers across all institutionsRequires the same identifier across all institutions in order to maintain a single record per patron, otherwise a single person will have multiple recordsPatrons can be denied/allowed privileges per library, at the level of the institution


Non-shared patronsIf the library does not participate in the shared environment, the ADM library code is included as part of the patron key which makes it uniqueThe patron only displays when an operator is authorized for and connected to the same libraryResource sharing can only be done through ILL

Patrons – Shared / Non-shared


Patrons – Shared

Shared patrons have a single set of global records, used in common by all the institutions that are using the shared patronsAt any one time, they have a single address and are assigned a single default ILL Unit


Patrons – Non-shared

There are two reasons for using a non-shared patron setup:

Patron data should be viewed only by staff in the specific institution for which they are registered (e.g. Police Academy)There is no desire for any cross consortia circulation activities

Non-shared patrons have separate global records for each institution in which they are registered


Patrons – Non-shared

The patron must choose the login library when logging in to the WEB OPAC The library can be defaulted on the specific library’s brand OPAC, and the patron will not be required to chooseWhen using the Circulation module, the staff user is connected to a particular ADM library, and therefore the system will know which patron record should be usedNon-shared users do not participate in PDQ


Patrons – Patron List

The patron list in the Circulation module is filtered according to the connected library

If the connected library uses shared patrons, all the shared patrons are listedIf the library is set to non-shared patrons, only the patrons relevant to the non-shared library are listed


Patrons – Patron Display and Update

Within the shared patron option, view and update of the global patron records can be limited. This limitation is optionalThe simplest limit is that the patron must be specifically registered in the library (i.e. has a patron local record), in order for the operator to view or update the patron recordsThis can be limited further to allow update only in the HOME institution of the patron


Shared System Model - PDQ

PDQ stand for Patron Direct QueueAvailable from ALEPH version 18.01Available only in a shared system model


PDQ - Functional Objectives

1. To allow patrons to loan and return items belonging to any library, without having to register in every library.

Unknown Patron


PDQ - Functional Objectives

2. To allow patrons to loan and return a specific item anywhere, without having to register everywhere


PDQ - Prerequisites

The participating libraries have defined their patrons as sharedUniqueness of patron ID across the participating institutions is assumed.Unique item barcodes across all participating librariesCross-institution agreements on patron statuses


Shared System Model - Configuration

Some sites are controlled centrally and want simple, central update proceduresSome sites are decentralized, and are concerned about controlling the configuration updateSupports two-level configuration:

central configurationinstitution-specific overrides


Configuration – Two Level Approach

Case study – tab100

ADM library

tab100

ADM library

tab100

ADM library

tab100

alephe

tab100


ADM library

tab100

ADM library

tab100

ADM library

tab100

alephe

tab100 SUB-LIBRARY-DIVISION=N



ADM library

tab100 CHECK-ORDER-BUDGET=N

ADM library

tab100

ADM library

tab100

alephe

tab100 CHECK-ORDER-BUDGET=Y




Other configuration files that support the Two Level approach

Web OPAC html pagesPrint formsGUI menusOthers – Via path_convert



Existing ProblemIn most cases there is no support for a single file, but only for the whole directoryEx Libris is looking into developing a more granular Two Level configuration approach


Configuration – Examples – Web OPAC

Current situation offers two solutions:Base extension is used to enable local filesThese local files are in the general directory, and therefore do not have update controlFor update control, the entire www_f directory can be locally placed in the ADM library. The directory location is identified through www_server.confHowever, all the files must be in the local www_f


Configuration – Examples – Web OPAC

Required development: All Web OPAC files will be in the general directoryExceptional files will be located in a local www_f directory


Configuration - Two Level Approach Enhancements

Requires investigation and brainstorming with sites to identify the most relevant tables Possibly, some tables will be inherited in their entirety, whereas others might be broken down to section levelIt should not be required that the table be present at local or global level


Session Topics



Responsibilities


Union Catalog Model

Shared System Model




Consortia

Why consortia models are so complicated in ALEPH?Why are there so many different models in ALEPH?


Library back officeALEPH, DigiTool,

Verde

Library back officeALEPH, DigiTool,

Verde

Library back officeVendor X

Primo

Resource Discovery

Delivery System

SFX+

Request

Publishing

ILL

Electronic Provider

Global Library Environment


Verde & SFX Consortia Model

The current presentation deals only with the most common model. Other models exist but will not be discussedBasic building block is an instance (resembles an ADM)Secondary building block is an institute (resembles a sublibrary or branch)A single central instance exist in a consortia modelCentral instance is buying and activating for local instances (consortia members)


Verde & SFX Consortia Model

A1 A2 A3

Institutes

Instance A

C1 C2 C3

Instance B

C1 C2 C3

Instance C

A B C

Central Instance


Verde & SFX Consortia Model – Main Functions

VerdeSearching and navigation Statistics

SFXTwo tier link resolution – Add local services first, and then add central servicesLocal A-Z list is an Aggregation of local and central active journals


Verde & SFX Consortia Model – Main Functions

For example, an OpenURL from a patron of institute C1 will resolve active journals in the following order

Journals active for institute C1 in Instance C Journals active for ALL in Instance CJournals active for institute C in Central Instance (meaning Central Instance has activated for member instance C)Journals active for ALL in Central Instance (meaning Central Instance has activated for all member instances)


MetaLib Consortia

Institution is the basic building block in MetaLibEach library is typically represented by an institutionA Patron is always logged into a specific institutionInstitutions have their own IRDsInstitution may share a consortia wide definition, or have their own definition, in each of the following:

UIPDSSFXProxy server


MetaLib Consortia

All institutions share the Server, Database and related maintenance (i.e. backups, cleanups etc…)Institutions share the administrative interface though different staff users are entitled to update a single institution, or groups of institutions (including ALL)This accommodates centralized versus de-centralized consortia in terms of their admin workflows


Primo Consortia – Building Blocks

Primo Consortia is more enhanced than MetaLibAs in MetaLib, institution is also the basic building block in PrimoThere are additional 2 concepts that help form the consortia structure:

ScopeView


Primo Consortia - Institutions

Each library is typically represented by an institutionA Patron is always logged into a specific institutionInstitution determines the SFX, ALEPH and MetaLib systems that power Primo’s services for a specific patron (link Resolution, remote search, hold request etc…)


Primo Consortia - Scopes

Unlike MetaLib, Primo aggregates records from different libraries and other sourcesA scope is a subset of records in PrimoA scope can be based on

Physical criteria, e.g. all items from library ALogical criteria, e.g. all records with material type books

A scope is also used to form a group of remote search resource (like quick-sets in MetaLib)


Primo Consortia - Views

A View in Primo is a UI customization including branding and look and feelA view is determined by the URL (virtual host)A View serves a specific library or a group of librariesA view can define different search tabs, e.g. per material type or Local vs. Remote SearchA View defines the default scope and a list of available scopes (pre tab)


Session Review

Who are the consortia players and what is shared?


Union Catalog Model

Shared System Model

Global Library Environment

E-Resource - Consortia in Verde & SFX

Discovery - Consortia in Primo & MetaLib

Thank You!

shared systems (consortia) omri gerson verde & sfx development director ex libris system seminar...

Documents

real consortia model

trademarks ex libris

trademarks of ex libris

consortia players roles

ex libris logo

ex libris group

ex libris products

central functions