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

[Zachary Spalding]

I could use the addition of an ISO ILL so I could get my ILLiad users  
to interact directly with Evergreen when dealing with ILL requests.


Zachary Spalding

On Jan 29, 2008, at 9:11 PM, Dan Scott wrote:

> I would like to start a discussion thread on the following subject, as
> I believe it's incredibly important to the success of the project and
> I don't think we've had much discussion about it yet. Perhaps this
> discussion will also be able to feed into the Duke initiative to write
> a design requirements document for an academic library system.
>
> (Note that "Project Conifer" refers to the project to implement a
> consortial install of Evergreen for Laurentian University, McMaster
> University, and the University of Windsor.)
>
> "What are the base requirements that have to be in place before we, as
> an academic library, or consortium of academic libraries, can migrate
> to Evergreen?"
>
> I'll kick off the discussion by giving an overview of the basic parts
> of the library system (both functionality and "soft requirements" like
> docs and training) and my understanding of where things are. Please
> feel free to broaden beyond what I provide here, as I will undoubtedly
> forget or mangle some of these! I believe that the answers may differ
> for different institutions, of course.
>
> 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.
>
> Academic reserves are another base requirement for each site.
> Essentially, give the system the ability to associate one or more
> items with one or more courses (instructor, course name, course code)
> and, by doing so, temporarily override the physical location of the
> item. Longer term it would be nice to have integration with courseware
> (WebCT / Blackboard / Moodle / Sakai) so that the reserve items would
> automatically be displayed as part of the course list, and it would
> also be nice if Evergreen could integrate with the campus academic
> system to know what courses a student was registered in and display
> those courses & reserve lists from the catalogue.
>
> Internationalization (i18n). One facet of this (internationalization
> of addresses to allow Canadian / American / arbitrary address formats
> from around the world) affects everyone. BC has already been able to
> customize Evergreen to support Canadian addresses, so a basic level of
> support is there. However, Laurentian in particular requires pervasive
> bilingual support - which is one of the development pieces I'm
> actively working towards. We hope to have this completed in the next
> few weeks; after that, we simply need to send off the strings to
> translation and our needs will be met. The new acquisitions system is
> being built to be i18n-ready from the ground up.
>
> Circulation: Are there circulation requirements beyond what Evergreen
> already offers today?
>
> Cataloguing:
>   * We have added infrastructural support for being able to search
> multiple Z39.50 sources at once, which was one of the requirements
> voiced at the Conifer Acquisitions session.
>   * Equinox has stated a number of times that they would like to
> rewrite the existing cataloguing client knowing what they do now. If
> our staff do not like the current cataloguing client, it might be
> possible to use a third-party cataloguing client (OCLC Connexion
> Client, for example) instead.
>   * Authority control: there is some rudimentary authority control
> built into Evergreen today.
>   * Bulk import of MARC records and authority records: the current
> interface for bulk imports of MARC records is the command line, which
> is not particularly friendly when you face the need to import, say,
> 12,000 records for a new set of Springer e-books.
>
> Catalogue: Do we have requirements beyond surfacing new functionality
> like academic reserves, acquisition requests, etc in the catalogue?
>
> Reporting: The current reporting module is extremely powerful, but it
> comes with no standard report templates. With that power comes a
> certain amount of complexity (it is essentially a nice GUI wrapper
> around the relational schema of the database, so understanding
> relational databases helps a lot) that means that our best approach
> for moving forward will probably be to define what standard report
> templates we want out of the box, then assign someone or some people
> to create those templates.
>
> Documentation and training: There is currently not much in the way of
> official (staff and librarian-oriented) documentation available for
> Evergreen. I started an effort to write "The Book of Evergreen", but
> that faltered when I turned my attention towards more basic
> infrastructure.
>
> Data partitions: in a consortial environment, what is necessary in
> terms of separating one Library's data from another's yet? For
> example: should a Laurentian acquisitions person be able to see
> McMaster's acquisition accounts and individual funds?
>
> Migration of existing data: Apart from bib records / holdings / patron
> records / authority records and open transactions (for example, books
> that are currently checked out), what other data do we want to migrate
> - complete transaction records dating back as far as our existing
> systems allow? Or would we be satisfied just exporting a static set of
> statistics so that we can combine data from the live system with the
> statistics from the old system (for example: circ counts by barcode by
> year)? Either way, we will have to define what data we want to
> migrate, then figure out how to migrate that into the new system.
>
> -- 
> Dan Scott
> Laurentian University