Dan,
Are you or someone capturing these suggestions somewhere, such as a
table in a wiki or spreadsheet? If not, I'm willing to do it. It would
be helpful to have a list somewhere that can be updated as more
suggestions come in for different modules, public libraries, academic,
and/or consortial applications.
Deb
Dan Scott wrote:
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.
--
Deb Bergeron <mailto:[EMAIL PROTECTED]> System Admin: User Support
CLIC Consortium <http://clic.edu>
1619 Dayton Avenue, Suite 204A
Saint Paul, MN 55104
O:*651.644.3878* C:*651.487.7609* F:651.644.6258
