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:
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:
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.
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:
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
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:
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.
We've tried to change the names of the RS partners with more significative strings:
NILDE02a -> Biblioteca Scientifica e tecnologica RS
NILDE02b -> Biblioteca Scientifica e tecnologica RS - Sede di Pordenone
leaving the same codes:
and all goes smoothly on our tests.
We've tried to assign the same names to two different RS sharing partners (obviously with different codes as the two above):
and all goes smoothly on our tests.
We've created a RS partner with the name of a our library (RIZZI) and this partner makes only lending basing on the ISBN-ISSN of the material requested:
this should permit the bypassing of the normalization of the holding material
seen above.
In this configuration Nilde can refer to the 852$b content for picking the
exact RS partner.
Obviously -in this configuration- we need an RS partner "specular"
for each UNIUD Library that makes lending.
All goes smoothly on our tests.
We've created an RS partner called "Biblioteca Scientifica e tecnologica RS" that support both borrowing and lending with Bibliographic record ID type = ISBN_ISSN:
All goes smoothly on our tests.