Home » Articles posted by Roland Samieske

Author Archives: Roland Samieske

Help!

Problem? Check out the OLS Knowledge Base or open a ticket by emailing support@cuny-ols.libanswers.com.

Primo: Palgrave Connect

The CUNY-wide licensed ebook titles of the Palgrave Connect collection are now active in SFX and can be discovered in Primo.

In SFX, 6,491 portfolios are active for all of CUNY in the PALGRAVE_CONNECT_EBOOKS_COMPLETE target.

Impact of Primo on SFX

A few weeks ago, we (OLS staff) discussed ways in which the impact of Primo on other systems and environments could be illustrated.

A good place to start with is SFX, since it’s so heavily involved in creating fulltext links in Primo. So one way to measure Primo’s impact on SFX is to count the number of OpenURLs generated by Primo (either through “View Online”, or through the menu under “Other Options”) and compare them to other providers/generators of OpenURLs.

In FY 14/15, the top 5 providers were Primo, bX, Ebsco, Google, and Gale (For the remaining providers, the numbers drop significantly). Here’s a table with the number of OpenURLs generated each month by each provider:

                bX	Ebsco	Gale	Google	Primo	Other
July-14	        3052	14185	6990	6847	308	9672
August-14	1147	7512	1571	5821	859	12186
September-14	4477	25903	3289	10940	19302	25912
October-14	10651	44538	8009	16150	63698	35567
November-14	12934	49530	11050	17189	97932	25718
December-14	9506	31664	7530	15206	86557	19483
January-15	2583	9595	2030	6925	22495	12034
February-15	6194	24143	3317	9526	49877	17518
March-15	12127	41397	7257	15032	96998	24205
April-15	11756	40696	8220	14330	103400	23534
May-15	        10033	33960	7951	13107	99598	18721
June-15	        3494	14075	1955	7026	28637	11702
TOTAL OpenURLs: 1538333

I thought the best way to show the behavior over time is to use an area chart, because it shows how values (# of requests) change over time for different categories (OpenURL “generators”):

impact1

Since it’s implementation at the end of August 2014, Primo has quickly taken over a large share of the OpenURLs resolved by SFX, at a small expense to the other providers, but not by much. It actually looks as if the percentage of requests for the other main providers has remained relatively stable

The same chart in absolute numbers looks like this:

impact2

So it looks as if Primo has taken over a large share of the OpenURL requests, but not so much by taking them “away” from other providers but by simply increasing the number of OpenURLs.

The total number of SFX requests for FY13/14 was about 1.1 million (1,107,169). In the past FY, this increased by almost 40% to 1.5 million (1,538,333). And of these, 670K (669661) came from Primo.

Observations:

  1. In FY 14/15, Primo was responsible for over 40% of OpenURL requests, i.e. SFX menus
  2. It reached this number very quickly, within about 2 months of going live
  3. It simply increased the number of requests, and did not diminish the contribution of other vendors
  4. Given the impact on SFX, the impact on e-resource usage (search sessions, etc.) should be significant as well

EZproxy and SIP: Update

This is an update on the recent trouble with the OLS-managed EZproxy servers. As far as we can tell, this was mostly an issue with the Queens College EZproxy instance. That particular instance sees the most usage of all our EZproxy servers.

We solved the problem by adding an additional authentication step that’s invisible to the user. It executes a script that validates the user’s barcode against the Aleph X-Server API.

So if a user’s barcode is at first rejected because the connection exceeds the SIP license limit, the second step is executed and the user has a “second chance” to authenticate.

We have examined our EZproxy log files to make sure that this is not an issue any longer.

Note that the most common problems with authentication are still:

  1. The user’s barcode is not registered in Aleph, so the user must visit the circulation desk.
  2. There’s a typo in the barcode (too many or not enough digits), or a different ID is used, or a search string is entered.
  3. The user has a fine of $5.00 or more.
  4. The user has a manual block.

If you encounter a barcode that doesn’t authenticate and you can’t figure out why, don’t hesitate to open a work order with the CUNY Service Desk.

Recent troubles with centrally-managed EZproxy servers

If you have a centrally-hosted EZproxy instance, you may have noticed an uptick in the number of users reporting authentication problems. This is due to our exceeding our SIP* license limit thanks to the increased use of e-resources (most likely stemming from OneSearch). We are looking into requesting a new SIP2 license from Ex Libris.

Because self-checkout also relies on SIP2, libraries with automated checkout machines may notice more users reporting problems with their barcodes there, too.

While we wait for the new license from the vendor, users experiencing problems with their barcodes should wait a few minutes before trying to re-connect to the database or checkout a book using a self-checkout station.


* The SIP server is used to query the Aleph patron file with the barcode.

GVRL e-books activated in SFX

I just received KBART reports for all our schools for Gale’s Virtual Reference Library. The activation in SFX just completed and here are the numbers of entries for which the dataloader script found a match, by institute (location):

  • 57: 2,230
  • BB: 2,639
  • BC: 2,289
  • BM: 2,487
  • BX: 2,284
  • CC: 2,264
  • CL: 2,264
  • GC: 2,264
  • GJ: 2,264
  • HC: 2,285
  • HO: 2.332
  • JJ: 2,284
  • KB: 2,384
  • LE: 2,275
  • LG: 2,431
  • ME: 2,365
  • NC: 2,230
  • NY: 2,507
  • QB: 2,395
  • QC: 2,266
  • SI: 2,460
  • YC: 2,266

In addition I learned that the titles from Scribner Writers Online and Twayne’s Authors Online [XLS] were also included in the KBART report and they are also part of the GALEGROUP_DB_VIRTUAL_REFERENCE_LIBRARY target. So any of the title we license from these two collections would have been activated as well.

While these titles are active in SFX now, they won’t be updated in OneSearch until new Google Scholar holdings are created. I will take care of this by Friday.

Thanks,
Roland

Archive

October 2024
M T W T F S S
 123456
78910111213
14151617181920
21222324252627
28293031