On 29/01/2008, Galen Charlton <[EMAIL PROTECTED]> wrote: > Hi, > > On 1/29/08, Dan Scott <[EMAIL PROTECTED]> 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
