Nilde and Alma

 

In this document I'll try to fix the procedures for the implementation of the Alma-Nilde data exchange.
It's still in beta: so please if you found something wrong/imprecise mail to fabiano.petrone@uniud.it.

The implementations/questions to ask to Exlibris and Nilde IT are highlighted in red and are regarding:

For the exchange of the data between Alma and Nilde you should configure several things:

 

  1. RS partners that "represents" the workflow between your alma RS desks
  2. a new patron identifier that allows Nilde to "know" the patron interested to a borrowing operation
  3. add "in bulk" (via normalization rules) some data to your holdings that allows Nilde to make the correct lending operations


 

Configuring the email for Nilde user lookup identifier

This new identifier will permit to Nilde (in "Nilde Utenti" configuration) the identification of Alma patrons that needs a borrowing service:
it permits the bypass of the Nilde patron validation procedure (otherwise manually requested to the personnel of the Alma University)

You should ask Exlibris to add a proper new user ID for you: you've not the privileges to do so.
You can take my ticket n° 00449162 as an example for your own ticket.
Everyway my configuration is:

  1. code = NILDE_MAIL
  2. description = translation = email for Nilde user lookup
  3. default value = NOT checked
  4. uniqueness across istitution

 

In our case, the content of the identifier is the same of the student email field and you can add it via a syncronization job adding some program line to your syncronization scripts.
In my case (I use PERL) the lines are the following:

here $Campi[0] -the first element of the array @Campi- is the patron institutional email.

At the end of the work, we've our new ID type ready:


Configuring RS partners

The Nilde RS partners should make a "photograph" of your DD workflow as displayed on your primo ILL/DD form.
As you can see from the following screenshot, you can have several combinations of libraries (usually, but not exclusively, of RS type) to which you can ask for
a) a DD and for
b)a pickup location of DD material.
You can imagine these combinations like "ordered couples" (a,b) where a and b are Alma libraries, usually (but not exclusively) of RS type:

At every (Library, Pickup/delivery location) permitted combination of your form should correspond a (Default library owner, Default pickup library)on a given RS partner.
So if your form permits -say- five of these combinations, you'll need the creation of five different Nilde RS partners with five different (Default library owner, Default pickup library) configurations.
Let's configure for example a partner taht we'll call NILDE02b.
Go to the partners configuration in Alma:

Let's add NILDE02b:

 

here is the genearl information tab:

obviously yours may vary (I.E. the name can be different from the Code ID) but is mandatory that:


The other important place to configure is the Parametes tab:

here the user identifier type used by this patron should be the email for Nilde user lookup configured in the previous step and here is the place on which you should configure the desired (Default library owner, Default pickup library) combination.
That's all: you can save your Nilde RS partner.


Result of a borrowing test
We've tested a borrowing to a real patron and these are the screenshots of the data received by Alma.
The first one:

here you can find:

The Library owner (first element of the (Default library owner, Default pickup library)couple) is not here because is "impicit" in the choose of the Alma library on which we are working:

 

The request status is highlighted in red, as we feel that the value "Created borrowing request" is wrong.
As this step happens only on the end of the Alma-Nilde iteration workflow ( NCIP AcceptItem) a value of "Request Completed" would be better.

Other things that should be noted are the poor contents:

but you should consider that:

1) Exlibris will implement these contents on the feb 2018 Alma version
2) all the data needed is everyway available in Nilde (where you will make all the DD work)

 

What are the consequences for the patron?

At the moment our patrons uses the well-known ILL-DD form in Primo


This form is poorly customizable, but now you can control the (Library, Pickup/delivery location) combination working on the RS_library parameter on the patron record:

If you select from the list a RS library called -say- MY_RS_LIB, only the combinations (MY_RS_LIB, Pickup/delivery location) will be permitted to the patron: the first element of the couple is fixed and only the second may vary (if Alma is configured so).
With the Resource sharing library field left void, the patron can choose all the possible combinations (aKa he can choose every permitted library/pickup combinations for his DD).

On The scenario opened by the new RS partners configuration requested by Nilde all change.

  1. A patron that needs a borrowing service should NOT use the Primo ILL/DD form but should subscribe/login to the Nilde environment
  2. At the first login he should choose a RS partner to use and this partner "fix" the (Default library owner, Default pickup library) combination preferred by the patron
  3. This choose is thinked to be maintained as long as possible: a change is theoretically possible, but it's made directly by the Nilde team.
  4. In the Nilde environment, the configuration of the RS_library parameter in the user record is completely NOT influential on the Nilde side: here only the initial RS partner choice counts.

Another potential issue: the Primo form is now used for ILL and for DD.
This particular combination is -i.e.- exclusively used for ILL:

Nilde doesn't support ILL yet: so the form should be revised (for permitting ONLY the ILL requests) or substituted (i.e. by a Plone form, etc.)

 

Normalization of the holdings of paper material

On the lending side, Nilde reads the material owned by Alma via Z3950 queries.
So in Alma you must configure your Z3950 server and offer your Bibliographic records enriched with your holdings.
here you can find instructions to do so.
For the lending request, Nilde must understand:

  1. where (inside the Alma libraries) is the desired document
  2. what library should act as RS owner & RS pickup location

Let's examine these 2 points.
The output of an Alma Z3950 server is usually something like:

852 8 $b RIZZI $c RIZZP $h 637 Per 004

This holding output should be enriched with various new content using the normalization rules (here you can find instuctions and examples)

1. where (inside the Alma libraries) is the desired document
The standard behaviour of Nilde is reading the content of the 852$b content (the Alma library code): if this matches with the code of a library registered in Nilde, the the document retrieved via Z3950 is marked as available for the lending request.
This custom behaviour requests a one-to-one corrispondence between the codes of the Alma libraries that can lend documents and the code of the libraries that are registered in Nilde for a given institution.
But usually happens that an institution registers in Nilde with an unique name a bunch of libraries of the "same argument":.
I. e. "Science library" (let's assume Nilde code: RIZZI) as a placeholder for the Alma code RIZZI library (i.e. the Science library - Udine campus) and the Alma code PORDE library (i.e. the Science library - Pordenone campus).
In one word: the Nilde code: RIZZI should be related to both the Alma codes RIZZI and PORDE.
If this doesn't happens, a z3950 search excludes all the items with 852$b=PORDE.
A workaround for this issue is an holding enrichment of the interested records. that puts a new code in 852$x (Nonpublic note, Repeteable) or in 852$z (Public note, Repeteable).
This code should then be reported to the NILDE team and will became the new Nilde code for identifiyng both the campuses.
Let's make an example:

852 8 $b RIZZI $c RIZZP $h 637 Per 004 $x BIB2

852 8 $b PORDE $c PORDEP $h 637 Per 008 $x BIB2

In this manner the value of $x (BIB2) as a Nilde code will identify both RIZZI and PORDE as "campuses" of the same "library" (BIB2: here the "" commas means that BIB2 is not a real Alma library! but only a placeholder useful for Nilde).

2. what library should act as RS owner & RS pickup location
This information is "encoded" iside the configuration of the RS partner, so you should embed also this info in your Z3950 holding output.
here is a enrichment example:

852 8 $b RIZZI $c RIZZP $h 637 Per 004 $x NILDE02

here the RS partner code is passed as a content of a 852$x field.


Note that this field is repetable, so you can enrich your record of two different istances of the same subfield.
One will contain the eventual placeholder for a "bunch" of Alma libraries, the other the RS partner:

852 8 $b RIZZI $c RIZZP $h 637 Per 004 $x BIB2 $x NILDE02

Obviously also in this case you should use the holding enrichment procedure via normalization rules

 

E-journals problem

On the lendings side, the Z3950 output of an E-journal present a key problem: the 852 field is absent, as an e-journal is seen in Alma as not "connected" to a particular library with a particular location.
sadly also the enrichment of the holding record is here strongly discouraged, because:

  1. usually these BIB+HOL records are records from the CZ (and so, if possible, they should not be modified)
  2. the content of an E-collection is continuously in development: new titles appears/disappears, and so the set to which to apply the holding enrichment procedure is never "well delimited"

Done these problems, here is the advice of Oren Farkas (Exlibris):

For electronic you can also determine the NILDE should send each time to a random partner in order to balance the load.
The point is that since as Fabiano said, Udine does not purchase electronic material per library there is no library to send to NILDE in this case.

An alternative solution could be redirecting the E-journals lending requests to an unique RS Desk (Call its code UNIUD -both in Nilde and in Alma- for example).
For discovering the e-journals inside our Z3950 database Nilde can search a match with the contents of the Library of congress RDAmedia:

https://www.loc.gov/standards/valuelist/rdamedia.html

The typical Z3950 output for an Alma E-journal should be in fact like this:

337 $a computer $b c $2 rdamedia

if a query matches this output (in its entirety or for one/more key subfield/s) Nilde should direct the lending request to the UNIUD RS desk.

 

Tests done with CNR

 

Nilde configuration