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

[Chennakeshava,B]

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 inhttp://open-ils.org/blog/?p=101 http://open-ils.org/blog/?p=108 andhttp://open-ils.org/blog/?p=115, as well as in the wiki athttp://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 <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/e560e895/attachment.html