Unit 9: Electronic resource management systems: vendors and functionalities

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.

Unit 8: Technological Protection Measures

For this week, we explored the various types of technological protection measures (TPM) present in licensed resources and how they may pertain to libraries. David Millman provides an introduction to authentication and authorization while Kristin Eschenfelder explores how TPM are being used in libraries, including what sort of implementations are most common in particular types of institutions. In general, libraries tend to use authentication systems to control access to materials. Authentication is the process that determines who the user is and pending that outcome, the user will or will not be granted access to the desired materials, which is part of the authorization process.

Libraries typically provide the publisher or vendor of a licensed resource with some kind of list of IP addresses, as well as those associated with a proxy server or virtual private network (VPN). Proxy servers and VPNs are used when patrons, such as enrolled students at UW – Madison, are attempting to access licensed resources from off campus. The authentication system sees the IP address or number as a proxy address, routes it through the proxy server, which is a UW – Madison IP address, and then onto the UW libraries server or the publisher server. If logging in through a VPN, the authentication system sees the off campus address as part of the UW network. So basically, the VPN adds the user to the network, as opposed to simply allowing access. When logging in to access the licensed resource, the system also looks for authorization rights.

In general on the UW – Madison campus, most users have the same rights, meaning that if they are authorized users (as defined in the license agreement), everyone may more or less view the same materials and resources. Authorization provides permission to use a particular resource, which is typically granted through an IP address range. It is through this range that permissions may be denied, as is the case with certain medical resources, for example. Furthermore, systems such as Shibboleth may be used to grant or deny access based on the users department and program. Such systems may be helpful for small libraries to ensure a good price on licensed resources by demonstrating that only a small number of users will be able to access the resource.

While most licensed resources necessitate authentication and authorization protocols, TPM tools may also be in place either through the resource itself or at the library. TPM tools are hardware and software systems that may facilitate limitation of access or the range of uses allowed to users as users could redistribute, alter and republish items from licensed resources. Essentially, since the language in license agreements may be vague or unclear, TPM may block uses that are not explicitly defined in the agreement. These TPMs may be in the form of soft or hard restrictions where soft restrictions are hardware or software configurations making it difficult for the authorized user to download, save, print, or copy/paste items from the resource. A savvy user usually finds work-arounds to these restrictions, but with hard restrictions, certain uses are prevented through hardware or software. Hard restrictions and TPMs should not be confused with Digital Rights Management (DRM) tools, although they are somewhat related, or at least similar.

Eschenfelder, in her three articles for this week, found that soft restrictions are quite common and include a warning, download limits, and “restriction by decomposition”. The most common hard restriction is the blocked copy and paste functionality, yet there are few examples of hard restrictions actually in use. The most common tools in libraries, museums and archives are authentication systems, specifically network-ID logins and IP address ranges. By limiting use through authentication, further restrictions may not be as necessary. In terms of use control, Eschenfelder and Agnew found that resolution limits and watermarking are quite common. However, some could argue that this may limit legitimate use of the resource. For example, what if an art student is studying a particular work of art or artist and the only online collection has poor resolution or a big watermark in the middle of the image? It may be difficult for that student to effectively analyze his or her topic. This begs the question of how should librarians proceed? If we continue to allow the publishers and vendors to dictate the type of TPM restrictions, what will they try next?