For this week, we explored more reasons as to why electronic resource management (ERM) systems exist, the desired qualities and functions, and how libraries may acquire such systems. No problem, right? Well, as per usual, this is more complicated than one might imagine, depending on that person's imagination, of course. Both Maria Collins and Margaret Hogarth provide us with a nice introduction to ERM systems and the key players. With the growing number of electronic resources and the decrease of libraries purchasing on a title-by-title basis, librarians have found that they need some kind of a system to help keep track of when to start the license negotiations, be able to easily generate A-Z lists, and be able to integrate such functionalities, as well as others, into the Integrated Library System (ILS) or Public Access Management System (PAMS). In short, it is up to the library to make any system or authentication changes and implementations required in a license while the vendor do nothing, which is why we have ERMs.
So how did this come about and what do librarians desire in an ERM system? An effective ERM should have one “point of maintenance”, which most ILS are capable of, or programmed to handle and should streamline the workflow, including maintenance of spreadsheets and databases (license status, etc.). Many libraries created their own ERM systems starting in 1998 with open source systems, and eventually began to work in a more collaborative environment. In 2002, DLF ERMI began in order to look at “the functional requirements desired in an ERM, identify data elements and common definitions for consistency, provide potential XML schemas, and identify and support data standards” (Collins 184). The results of this work was published in a report in 2004, outlining the preferred standards, features, and design of an ERM, including data standards, vendor costs, and system migrations, including those listed above. Some of the preferred standards include EDItEUR, ONIX, SUSHI, and COUNTER. The final three are also mentioned in several Against the Grain articles on ERM systems as a positive example of increased cooperation between libraries, vendors, and publishers. Moreover, as mention by Hogarth, one of the primary concerns to librarians is the issue of standards.
As there are several choices when determining which ERM system to chose for you library, how do you chose? Many librarians want some kind of flexibility, with little manual data entry, good standards in naming conventions, limited staff training and time, interoperability, and a good link resolver. Another consideration is whether or not to use a third party or see if your ILS has an integrated ERM system, such as Ex Libre's VERDE. However, Collins warns against, or at least to be wary of, using the same vendor for both the ILS and ERM system as the library may end up with an under-supported system. If looking at a one size fits all type of system, make sure to know each vendor's track record on development. A one vendor system should have a knowledgeable title management database, link resolver, and A-to-Z listing services. For third party systems, such as Serials Solutions, how well will it integrate with the ILS? This is the primary concern. A third party system should be able to easily link and manage subscriptions, including aggregated resources. There are also subscription agents, such as EBSCO. These systems may be acceptable, but be careful if using another subscription agent or another A-to-Z listing service or link-resolving tools. If using open access or own system, the library must be able to sustain its own systems resources, but can tailor the ERM system to local needs.
All of the options will involve dedication staff and typically includes the need to enter data manually. For example, with EBSCO's system, one of the primary complaints from the Against the Grain articles is that it does not support or update non-EBSCO data efficiently. Serials Solutions 360 had difficulty mapping data to and from the link resolver and it was difficult to get the COUNTER data. Collins suggests that a library should conduct an internal and external needs assessment prior to making the final decision. Considerations should include the type of library, mission statement, size of library and collection, technological infrastructures, cost vs. need, existing tools and ILS, and interoperability. In short, what does you library need and how will the system resolve problems? Hogarth also provides a detailed look at various systems, including open source systems, as well as numerous bullet points of what to consider when choosing a system.
No comments:
Post a Comment