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

[Bidd, Donald]

can someone tell me how to get off this list...thanks

-----Message d'origine-----
De : open-ils-general-bounces at list.georgialibraries.org [mailto:open-ils-general-bounces at list.georgialibraries.org]De la part de Chennakeshava,B
Envoyé : 31 janvier 2008 02:02
À : open-ils-general at list.georgialibraries.org
Objet : Re: [OPEN-ILS-GENERAL] What are your requirements for Evergreen?


what are the software reuired to evergreen installation for PC, kindly inform me.
 
Chennakeshava B.

 
On 1/31/08, Adams, Ken < KAdams at mt.gov> wrote: 

As for the ILL module - along with ISO-ILL for communicating with OCLC, an NCIP Responder would be useful.
 
Ken Adams
Montana Shared Catalog Director
kadams at mt.gov

  _____  

From: open-ils-general-bounces at list.georgialibraries.org [mailto: open-ils-general-bounces at list.georgialibraries.org] On Behalf Of Deb Bergeron
Sent: Wednesday, January 30, 2008 4:27 PM
To: open-ils-general at list.georgialibraries.org
Subject: Re: [OPEN-ILS-GENERAL] What are your requirements for Evergreen?

 
Ok Dan--thanks for bringing the conversation over here!

You mentioned several modules.  One important module is the OPAC.   Here we need both one for patrons and one for librarians.  I've mentioned before that it's always a balancing act that includes the 'necessary' information for most librarians with those of the faculty and student patrons.  I realize there are several OS OPAC models out there, and perhaps one or more of these could be integrated.  Oh, and by the way, make sure that all the information can be viewed and downloaded to not only a computer, but any hand-held device.

Someone mentioned an ILL module--thank you!  We need a resource sharing module that will accomodate not only resource sharing within a consortial setting, but within a larger environment as well (i.e. the state, country, world--why are we not thinking like Google?!).  This module must have the ability to 'talk to' the ILS and update the database in real-time without human interaction.  And, could you make this module modular so we can use it with any ILS?  

So, based on the previous postings, we'd have:

Cataloging 
Acquisitions
Serials
Circulation
OPAC
ILL
Reports/Stats
ERM

After building the base modules, let's think outside the box and include all the wizbang stuff students want (most of this is already available via ENCORE,  Endeca, and other products.)

Reviews
Tagging
Chat--including voip 
IM 
Faceting

Functionality not in an ILS (at least not that I've seen):

Add the ability to customize and add functionality similar to Google and Firefox.
Throw in some social networking capability or allow it to be added on in a modular fashion--again over several devices.

Now I'm going to go think about this some more.


Deb





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.



  


-- 


Deb Bergeron <mailto:bergeron at macalester.edu>  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 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.georgialibraries.org/pipermail/open-ils-general/attachments/20080131/2663a926/attachment-0001.html