[OPEN-ILS-GENERAL] What are your requirements for Evergreen?

[Dan Scott]

On 29/01/2008, Galen Charlton <galen.charlton at liblime.com> wrote:
> Hi,
>
> On 1/29/08, Dan Scott <denials at gmail.com> wrote:
> > An acquisitions system is a given for everyone, and we're currently
> > working on that in the acq-experiment branch, as documented in
> > http://open-ils.org/blog/?p=101 http://open-ils.org/blog/?p=108 and
> > http://open-ils.org/blog/?p=115, as well as in the wiki at
> > http://open-ils.org/dokuwiki/doku.php?id=scratchpad:acq_serials
> >
> > A serials module is also a base requirement for everyone. On top of
> > the acquisitions portion (subscription support, vs. basic one-time
> > purchases), at a basic level we need basic patterns (overlay calendars
> > with exceptions), a helpful check-in interface, and claiming.
>
> To suggest a requirement that is likely core to some, perhaps ideal to
> others, ERMS support would be useful, either in the form of ERM
> functions integrated with the acquisitions, serials, and reporting
> modules, or support for exchanging acquisitions and other information
> with a stand-alone ERMS, or both.

Hi Galen (and apologies to all for starting this thread and then
disappearing - I just gave a talk on Evergreen w/ slides to be
available from coffeecode.net any hour now - so I've been kind of
preoccupied):

Just to try to clarify ERMS support, are you talking about all 47
functional requirements in Appendix B of
http://www.diglib.org/pubs/dlf102/ or just some subset?

Exchanging acquisitions and other information with a stand-alone ERMS
should be quite possible, subject to building connectors for each
stand-alone ERMS (I'm guessing that no standards have emerged yet).

Given the pretty broad scope of the full set of requirements, now that
four years have gone by since the publication of that report, is there
some minimal subset that would be enough to satisfy the most common
use cases libraries have for an ERMS (say, enabling support to track
purchasing and renewals of the e-resource, along with storing rights
management information for display in an associated "info" page for a
given e-resource)?

Or would enabling easy integration of CUFTS2
(http://cufts2.lib.sfu.ca:8033/trac/CUFTS/ - sharing Perl/PostgreSQL
sensibilities with Evergreen) satisfy the bulk of the requirements,
while leaving open the possibility for sites to use other standalone
ERMs? The last time I tried installing CUFTS2 was over a year ago, but
I think Todd has worked out a number of the little bugs since then.

-- 
Dan Scott
Laurentian University