[OPEN-ILS-GENERAL] RE: Serials Management

[Stuart Miller]

I'd like to point out that while I would very much like to think prediction is no longer necessary, the fact is that nearly half of our active serial subscriptions are still print--and that's after cancelling print wherever we could for the electronic versions. We will be stuck for yet many more years with managing something like 20,000 print subscriptions. If anyone can figure out how we can maintain one key-stroke checkin and monitor claims WITHOUT prediction, we're all ears. I just don't think abandoning checkin and claiming for THAT many titles is possible--much as I would like to recommend it. That isn't to say we couldn't manage those print serials in some existing, proprietary stand-alone system and pull holdings data into a public interface, but I think this library (and other ARLs probably) would like to have usable serials control in an open source ILS. But given the cost of replicating prediction features (and who really wants to code that AGAIN?) and the fact that so many libraries CAN ditch prediction because the number of print subscriptions is so small anymore, I'm doubtful if ANY open source ILS is going to meet serials management needs like ours--unless of course the big libraries are willing to develop the needed functions. Such a thought gives me hives, but we might end up having no other choice. All the "choices" we have at the moment are most unappealing when it comes to serials.

Stuart Miller
Library Systems Analyst
University of Chicago

-----Original Message-----
From: open-ils-general-bounces at list.georgialibraries.org [mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of Dan Scott
Sent: Wednesday, September 10, 2008 9:27 PM
To: Evergreen Discussion Group
Subject: Re: [OPEN-ILS-GENERAL] SPAM: Serials Management and the Collaborative Itch

2008/9/8 Mark Leggott <mleggott at upei.ca>:
<snip>
> So, how about it? Would this work for other academic institutions looking to
> make the switch to Evergreen? What else would you need not currently in
> CUFTS? And please don't say predictive algorithms for pre-populating
> check-in records for print issues - those things don't work well in any ILS
> product and who needs them 2 years from now anyway?

I think this would be worthwhile integration. I'm not convinced that
everyone would be willing to throw out support for print issues, but
agree that it's a waning concern.

I had asked our electronic resources librarian to take a look at CUFTS
this summer, because I suspect it would solve a couple of our current
problems:
  * maintaining a list of e-resources by subject, which we currently
maintain manually
  * providing an a-z list, for which we currently subscribe to EBSCO
for the reason that they apparently provide better usage stats than
the SFX a-z list that we already pay for as part of our consortial SFX
install in Ontario
  * giving us decent e-resource management (subscription costs,
licensing information, etc) that we currently manage in a spreadsheet
today

I think the major barrier for us (Laurentian) is that we need a
multilingual interface, which CUFTS currently doesn't offer; our
university is officially bilingual and needs to support switching
between languages in both the public and staff interfaces.

As for the synchronization question, if both apps were playing in the
same database, one could use triggers and/or rules to automatically
and immediately propagate the data from CUFTS that would be meaningful
to Evergreen. The advantage to a tighter coupling is that you can use
a single reporting interface to generate reports across all of your
data.

On the other hand, back at Access 2007 Mike sketched out a small
vision of (trying to remember, here) federating different search
backends as OpenSRF search services: basically, wrap your
non-Evergreen search in an OpenSRF service with some means of
relevancy ranking across the various services -- ah, the joys of
federated search! That would seem to be a reasonable means of pulling
these services together. And now I'll step back and let Mike correct
my extremely fuzzy memory.

--
Dan Scott
Laurentian University