[Evergreen-general] Novelist and record harvesting - API vs. holdings uploads

[Lindsay Stratton]

I think we should be looking very seriously at Evergreen's APIs and
improving the documentation, functionality, performance, etc. More vendors
and services are moving to APIs, not just for holdings, but user and
transaction data as well. Speaking personally, I run holdings uploads for
Novelist and Syndetics (which also now offers API uploads but not for
Evergreen) and would love to shift them over to an API method. We also use
a discovery layer where user data conections needs some improvement. And we
have libraries interested in analytics platforms that would also benefit
hugely from API connections.

Lindsay

*Lindsay Stratton*
*Systems Librarian*
Westchester Library System
570 Taxter Rd., 4th Floor
Elmsford, NY 10523
lstratton at wlsmail.org


On Tue, Jun 6, 2023 at 6:15 PM Dan Moore via Evergreen-general <
evergreen-general at list.evergreen-ils.org> wrote:

> Heyo all,
>
>
>
> Our collections group is looking to tweak our Novelist implementation to
> make use of On The Shelf functionality, info here:
> https://connect.ebsco.com/s/article/Setting-up-On-The-Shelf?language=en_US
>
>
>
> There’s a curious (if not perhaps a little rude) note at the bottom of the
> page that states: “There is an Evergreen API that supports automatic
> harvesting of your collection. However, we were unable to obtain a complete
> harvest for any customers during the testing of this functionality, as
> Evergreen’s Web Services API was not built for such a wide-scale
> application. We discourage Evergreen customers from utilizing this feature
> for collection harvesting.”
>
>
>
> Additionally, on their KB page for the feature (
> https://eis1.my.site.com/ebsco/s/article/ILS-Export-for-NoveList-Products-and-Features?language=en_US),
> we can see some handy older screenshots of what I presume to be the old
> non-browser client. Combining that with the statement above about “during
> the testing of this functionality,” I’m presuming this was tested with
> EBSCO/Novelist at some point but that there hasn’t been an update to it
> since the browser client rolled out.
>
>
>
> There’s a slew of questions about this in my mind… the first being if
> what’s written here is accurate about the Evergreen API method of
> harvesting collection information not being robust enough (which generates
> an immediate follow up – what would make it robust enough?). But I’m also
> curious about the collective wisdom of the community about these
> strategies. We’re moving toward a Lean-based purchasing model wherein
> selectors will have a daily cap of titles to order so as not to create a
> wave for shipping/receiving folks to drudge through later. Real-time
> availability of holdings information would be a huge boon in supporting
> both Lean purchasing strategies AND maximizing Novelists’ effectiveness for
> reader’s advisory. However, if uploading holdings records is just the best
> way of doing it due to the performance of the API as-is or the time/money
> needed to extend it, then we’ll go that route instead – whatever delivers
> the best, most accurate information to patrons.
>
>
>
> Thoughts?
>
>
>
> All the best,
>
>
>
> Dan Moore
>
> Integrated Library System Administrator
>
> King County Library System
>
> Service Center, Issaquah
>
> (425) 369-3413
>
> dtmoore at kcls.org
>
> <https://kcls.org/>
>
>
>
> ------------------------------
> King County Library System is subject to the Washington State Public
> Records Act (RCW 42.56). Senders and receivers of KCLS email should presume
> that this email and any attachments are subject to public release upon
> request and to state record retention requirements, unless otherwise
> exempted.
> ------------------------------
>
> _______________________________________________
> Evergreen-general mailing list
> Evergreen-general at list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-general/attachments/20230607/84a09bb4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 31517 bytes
Desc: not available
URL: <http://list.evergreen-ils.org/pipermail/evergreen-general/attachments/20230607/84a09bb4/attachment-0001.jpg>