All about DOLLeR: Managing Electronic Resources at the UIC Library
Note: This is a preprint version of the article published in Serials Review, Vol. 30, No. 3. (2004), pp. 194-205. Readers are advised to use the published version, available on paper, and also online through Elsevier's ScienceDirect (with proper permissions).
Mircea Stefancu is Electronic
Services Librarian at UIC. Address: Science Library, 845 W Taylor Street, Chicago,
IL 60607. Phone: 312-413-3529. Email: mircea@uic.edu.
Alex Bloss is Acquisitions Librarian at the
UIC. Address: Daley Library, 801 S Morgan Street, Chicago, IL 60608. Phone:
312-996-2706. Email: abloss@uic.edu.
Jay Lambrecht is Interim Associate University
Librarian at UIC. Address: Daley Library, 801 S Morgan Street, Chicago, IL 60608.
Phone: 312-996-2716. Email: jaylamb@uic.edu.
Abstract
Introduction
Looking around
In the beginning there was …the Green Sheet
Green Sheets go paperless
DOLLeR emerges
DOLLeR’s functional structure
DOLLeR’s tables
DOLLeR’s interface
a. The FileMaker Pro interface
b. The Web interface
Communication is the key: DOLLeR’s email gateway
DOLLER reports
Security in DOLLeR
Looking ahead
Acknowledgements
Annex 1
References
Abstract: DOLLeR (Database Of Library Licensed Electronic Resources) is a relational database developed at the University of Illinois at Chicago Library as the management tool for their electronic resource subscriptions and the associated licensing activity. The history of the development of DOLLeR is presented, along with detailed discussions of the most important aspects of the database functionality. The paper focuses on those features that contribute to make DOLLeR an efficient management tool, such as its simple and robust functional structure, its tables, its user-friendly interface (having the same looks and feel in both the FileMaker Pro and the Web environments), its email gateway allowing easy communication among authorized users, its capabilities of generating a variety of reports, and last but not least its security mechanisms.
When back in the mid-nineties electronic resources were just starting to appear, many libraries didn’t even know they were soon to be facing a new challenge: how to deal with this new breed of resource which was like no other type of material they were used to handling. At first, since nobody was quite sure of how to treat these new, elusive creatures, the electronic resources would only get web locations, added to the bibliographic records of their paper counterparts, and would mostly land on the libraries’ web sites as ever longer pages of alphabetically or otherwise ordered hyperlinks. With their umbilical cords severed, and without any real library technical services support, electronic resources lingered for a while through the vastness of the Net, waiting for their strength to build up through sheer numbers. This eventually happened. And at that point, it became apparent that something had to be done, or the legitimate library control over this increasingly significant type of resource would be lost.
As it happens with most endeavors at the University of Illinois at Chicago Library, it all started with a meeting where the problem was defined. A paper-based version of the tool was created, improved over the time and used for about six years. It was known as the green sheet, because of the color of the paper used. An electronic version of this initial management tool followed. However, being considered not enough of an upgrade from the paper version, it was never used. Then a new management tool came into play, in the form of a relational database, supplemented with a combination of useful extra features including a password protected web interface, seamless access to electronic versions of the license agreements from inside each record, a web email gateway for convenient online communication among the different participants in the e-resources managing process, and flexible reporting capabilities. After more meetings, consultations, and necessary back and forth, the new database was adopted as the UIC Library’s new electronic resources management tool, and simply named Database Of Library Licensed Electronic Resources, a.k.a. DOLLeR*.
* Special thanks to our colleague Deb Blecic, bibliographer for the Life and Health Sciences, who came up with this cool name.
The literature has relatively little to say about successful attempts from the part of individual libraries to develop in-house systems aimed at managing their electronic resources and the licensing aspects involved, but as one would expect, given the diversity in the configurations of the local technological means, expertise, and needs, the existing systems show a great variety in scope and complexity. Among the examples of projects similar to DOLLeR developed at various North-American university libraries are:
- VERA (Virtual Electronic Resource Access), a system developed at the MIT
Libraries in 2001 to provide their patrons with better access to the electronic
resources (licensed or not) to which the library offers access; the system is
backed by a relational database built in FileMaker Pro, and has an user friendly
web interface. 1
- ERTS (Electronic Resources Tracking System), built at the Tri-College Consortium
(Bryn Mawr, Haverford, and Swarthmore colleges) in 2002, to handle data on license
restrictions, authentication means, technical contacts, and statistical availability;
FileMaker Pro was used as a development environment; ERTS is accessible to the
technical services and to the public at all three colleges, on their intranet.
2
- HERMES (Hopkins Electronic Resource Management System), developed at the Johns
Hopkins University Libraries in 2002 as a tool for selection, purchase and management
of their electronic resources (including licensing); HERMES is web-based and
has a public interface for searching and accessing all e-resources at JHU; Microsoft
SQL Server was used for the back-end database, and Macromedia’s ColdFusion as
middleware platform. 3
More local e-resource management systems are introduced on the excellent site maintained by Adam Chandler from Cornell University, and Tim Jewell from the University of Washington at http://www.library.cornell.edu/cts/elicensestudy/. 4
In the beginning there was …the Green Sheet
During 1996, a number of UIC Library departments began to wrestle with the problem of how to manage the selection, purchasing, cataloging, management, and payment for electronic resources. It was readily apparent that the traditional routines were not suitable for these new products.
After sitting through a long and inconclusive Steering Committee meeting in 1997 on where responsibility should lie for the various activities related to electronic service procurement, Alex Bloss, the Acquisitions Librarian at UIC Library, drafted a paper showing the various departments involved in the process, a proposed sequence of handoffs for any proposed product, and a checklist of some required activities. This paper came to about one page in length.
The sequence of handoffs differed significantly from the "traditional" process at UIC. Such processing now required review and approval by the University's Legal Department and the University Librarian and also needed the involvement of the Library Systems Office as well as the regular participants in the selection and acquisition processes. The traditional process for print materials followed the sequence:
Bloss met with people in the library Business Office, Cataloging, Collections Development, and the Systems Office regarding the steps they needed to follow. It became apparent that the new process for electronic products was much more complex. At first, the process was as follows:
After revising the draft process, which now came to two pages, Bloss presented it to the library’s Steering Committee and gained their approval to implement the process. It was recommended that this checklist be put on green paper so as to make it stand out among all of the piles of papers that accumulate on peoples' desks. Thus came the Green Sheet.
As work with the green sheet started, it became apparent that it could be improved by the addition of selection criteria, which would help Collections and Systems staff to decide whether the product met the library’s needs. A task force was created to identify these criteria. This group developed the Master List of Preferred Practices and recommended its review before approval of a license agreement. This list was added to the Green Sheet, which grew to three pages.
As electronic products began to appear in the Library's online catalog, we realized that these products needed to be added to the separate list of electronic products being maintained by the Reference Department on the library's home page. Also, as an ever larger number of separate interfaces and search engines were being made available, we saw that training materials for them needed to be written. Finally, as the number and significance of the electronic products increased, it became useful to announce them to the university community. Thus, more steps were added to the process. The Reference Department and the Electronic Resources Quadrant were added to the Green Sheet so the product could be added to the appropriate lists, integrated into bibliographic instruction classes, and otherwise be promoted to the users. The Green Sheet was now four pages in length, and by May 2000, had reached its final form.
Fig.1. Green sheet workflow.
Around the beginning of 2000, after the Green Sheet had been in use for a while, it became apparent that some electronic products had ceased, or vendors had changed, or were being de-selected by Collections Development. In many cases, these products were now being offered by consortia, which had different licensing requirements. A means of backing these products out of the Green Sheet process was necessary. Thus, Alex created the Red Sheet. (Green for go, Red for stop…)
The Red Sheet touched all of the bases, except for Legal Counsel, that the Green Sheet did. It required the documentation of the reason for cancellation, notification of vendors and other interested parties, editing or closure of bibliographic records and hiding from public view, closure of purchase orders, and removal of appropriate web listing and training materials.
These processes have been used until the creation of DOLLeR, in 2003.
DOLLeR started as a process of upgrading an existing management tool that, for some of its users, began to function outside certain limits of acceptability. Its predecessor, the green sheet, was basically a very complex form of card catalog and a sign-off sheet at the same time. It was built around the idea that, when several people are going to contribute with different pieces of information to the same, unique record, having something physical (and easy to spot on your desk, such as a colored sheet in a pile of generally white paper) to move around would both help keeping the sequence straight, for the completeness of the form, and prompt the busy contributors to deal with it—and, hopefully, do so in a timely manner.
Although most of the users of the green sheets seemed in general satisfied with the tool, as he was the last contributor in line, Mircea Stefancu would have problems at times trying to identify certain pieces of information that he needed in order to do his part. He was working in the Acquisitions Department at the time, and his job in relation with the green sheets was to create invoice records and post payments for each new subscription in the library system (NOTIS at first, then Voyager with 2001). Occasionally, information regarding the accounts used to pay certain invoices would be missing from the copy of the invoices that would get to him directly from the library Business Office, and sometimes ahead of the actual green sheet, which would come from the Cataloging Department after passing through two more offices. Or he would get a green sheet but not the corresponding copy of the invoice, as the process of payment through the University’s Office of Business Administration had its own path and pace, independent from that of the green sheets, which would circulate only within the library, from one department to another. So he would find it pretty difficult to keep track of the various phases in which, and possible places where, the information about a given electronic resource could be along the pretty lengthy and nonlinear path toward its two final resting places—in the office of the head of the Collections Development Department, and, as a copy, in the file cabinets of the sitting chair of the Electronic Resources Quadrant. All that complicated dance had to be seasoned with pieces of information to be found on the green sheet itself, such as the guideline used for the payment, and the number of the corresponding bibliographic record in the library catalog, or pieces of information to be found only on the copy of the invoice, such as the fund the money had to be taken from. On the other hand, all payments wouldn’t be treated the same way, depending on the different funds used, and other factors. At almost any point in time, Stefancu’s desk would host several piles of documents (both invoices and green sheets) adorned with yellow stickers reminding him what operation and type of processing was necessary for each of them, as time came.
For Stefancu, it was becoming obvious that following an elusive piece of paper (even if agreeably colored) was not all that easy as it seemed when the green sheet system had been put in place. To be sure, the system had real virtues; however, it not only solved problems, but also created them. For instance, because there was more than one place where different threads of actions would originate, and the time cycle required for a green sheet to be completed was pretty lengthy and hardly uniform, people in some departments started creating local databases for their use and ease of work, which made for duplication of information and inconsistency of data held in different places. At times, having to address urgent issues and trying to expedite the process, Stefancu would be at a loss trying to determine on whose desk a green sheet was. The reality to which the green sheet system was trying to bring some order by moving around a unique (?) piece of paper holding such a composite package of information, simply proved to had become too complex to continue to be handled that way.
As Stefancu had already created a number of web-accessible small databases for daily statistics collection by staff in the acquisitions department, it occurred to him that having all the information gathered on different generations of green sheets and in several different file cabinets converted to an electronic format and kept in just one place would greatly improve both the safety and the speed of the process. That would also come with other specific advantages that paper-less databases have over their paper-based homologues. So he started working on a replacement for the paper-based system.
In the summer of 2002, he came up with an electronic version of the green sheet, backed up by a four-table relational database. This database had a user interface that pretty much emulated the looks and feel of its paper counterpart, but also had a number of modifications—some required, and others allowed by the new medium—like navigation buttons, portals for displaying related information from other records, a communication mechanism that used an email web gateway accessible from the main interface as an equivalent to moving the green sheet from one desk to another, and other such useful features. Maintaining a strong resemblance with the paper green sheet had been one of Stefancu’s concerns, as he wanted the users of the new database to experience an as smooth as possible transition from the old system. Since he already had some experience with using FileMaker Pro, choosing this software package as the development environment seemed the natural thing to do.
Stefancu also created a number of presentation documents for the new product, including an overview of the database, screenshots from all screens, and explanations of all the functional elements, and sent them to all the users of the green sheets. Also, he made his creation available for live demos on his desk computer, as not everybody had copies of the software installed on their own machines. However, given the difficulties associated with this kind of arrangement, the feedback was neither quick to come, nor overwhelming in the number of responses...
Eventually, the answer did come, as Jay Lambrecht, the Interim Associate University Librarian, took the lead in the debate initiated around the new management tool. Lambrecht had been looking for some time into viable alternatives for the green sheets, and had a pretty clear idea about what this future tool should be and do. Although he was interested in the idea of replacing the paper-based system, upon checking the documentation sent by Stefancu he decided that a mere electronic green sheet was not the real solution. So he came up with a more ambitious project, aiming at replacing not only the support of the green sheets, but the green sheet system altogether as the library’s electronic resources management tool.
What Lambrecht put in Stefancu’s bag in September 2002 was an outline of his vision of the new tool. Here it is, as per the email he sent out to the green sheets users in response to Stefancu’s proposal for an electronic green sheet:
…I envision a database of information regarding our electronic
subscriptions that includes much more than the printed green sheet. (It would
[be] so different, by the way, that I think we need a new name.) To get the
discussion started, let me share my vision of what an e-resources database should
include. The basic idea is to build a database that acts something like Voyager:
-- good bibliographic information for access
-- up-to-date holdings data
-- a "call number" (URL, proxy URL, etc.)
-- order and payment information (including history)
-- vendor information
-- "circulation" information (access to use statistics)
In addition, there are some unique aspects of e-resources that should be accommodated:
-- licenses must be negotiated and maintained
-- contacts must be listed and updated
-- with no physical object to move around, a workflow must be established
With these purposes in mind, I've created the outline below. Note that in some
places I've added SerialsSolutions as a source; another goal of this project
must be to use data we already possess to provide as many "details" as possible
without requiring us to re-key them.
I'd be happy if you and others copied on this note would comment on my outline
-- what is necessary but not listed, what is listed but not necessary, and ideas
for better organization. Your work gives us a very good start, and it's time
to move it forward.
DESCRIPTION
Title (source: SerialsSolutions)
Variant titles (acronyms, earlier or later titles, etc.)
ISSN (source: SerialsSolutions)
HOLDINGS
E-holdings (source: SerialsSolutions)
Nature of content (buttons for: article only, TOC)
Print holdings (source: SerialsSolutions)
Voyager record number (source: UIC staff)
SOURCE
Publisher
Vendor (if different from publisher, e.g. Ovid)
Access provider (if different from vendor, e.g. CIC)
Provider account number
Contacts
Sales/License
Name, phone, fax, e-mail, address
Technical support
Name, phone, fax, e-mail, address
Former vendor/Access provider
Contacts
Name, phone, fax, e-mail, address
Reason for and date of change
USE
Vendor URL
Proxy URL
IP addresses
ILLoan restrictions
E-reserve restrictions
Link to use statistics
UIC STAFF ACTIONS
Creation date of record (system supplied)
Current action (buttons for: new, renew, modify) and date
Renewal or modification deadline
Subscription term
Selector
Cost
Payment history
Print subscription requirement (buttons for: yes, no)
Number of simultaneous users
License date
License reviewed and signed date
Link to license text
Problem reports
Archiving plans
CHECKLIST
Update e-resources spreadsheet (Schwartz)
Notify public services (Lambrecht)
Update library homepage
Catalog (Zhao)
Pay (Bloss)
Create MHLD (Acquisitions)
The implementation solution Stefancu came up with for this conceptual frame was, as expected, a relational database. To build it, he again used FileMaker Pro. Work for the new database was started in version 5 of the software, but version 6 was used through the rest of DOLLeR development.
Looking at the list of requirements above, one can easily see that some of the requirements came straight from the green sheet, as the core information, like that about the resources and their providers, is central for such a tool. In the same time, aside from broadening the scope and functionality of the green sheet, the list includes new features that could not had been achieved in a paper environment, such as simultaneous access by several users to the same, diversely customized data, instant historical dimension to data spanning over extended intervals, points of access to information belonging to other databases, easy updating of the fast changing information.
As the electronic version of the green sheet was not to be taken into consideration, Stefancu started his work on the new database (which didn’t get its name until later in the development process) using solely Lambrecht’s outline. Exception was made only for the email gateway idea, which he saved for reuse in DOLLeR.
Designing a relational database basically means defining a number of tables, one for each category of objects to deal with, to hold distinct pieces of information relative to those categories. DOLLeR’s table structure actually reflects a common reality in today’s world of electronic resources. Descriptively speaking, the story is about a Provider who, according to a set of terms spelled out in a License, grants access to a Resource, and a Subscription is signed with some User to that effect. From the user’s (the Library’s) perspective, that translates into signing a Subscription for a given Resource with a Provider, based on the terms of a License. From the database design point of view, there are four main categories (entities, in database language) involved here, and for each of them a table was created in the database: Provider, License, Resource, and Subscription. A fifth table was created though, to hold the information provided by SerialsSolutions, a commercial service that keeps track of, and periodically updates, all changes in the full-text e-journals names, holdings, and access status (linking) for subscribing libraries; this data, delivered by SerialsSolutions every other month, was to be used as both an important time saver for data entry activity, and an authority file for the Provider and Resource tables.
Considering that:
DOLLeR’s five tables would be linked together as in figure 2, where the arrows represent one-to-many relationships
Fig.2. DOLLeR E-R diagram
The reality is nevertheless a little more complex than that, and the short list of possible variations from the above simplified model could read like: a Provider can actually use the same License for several Resources, or use different Licenses for a given Resource from one year to another; each year, for a given Resource, a new subscription can be signed with the same, or with a different Provider; a subscription can be based on the last year’s License provisions, or on a modified, or completely new License. Nevertheless, the database has been built according to the model above, and its use so far proved to have the flexibility necessary for accommodating such occurrences in a day-by-day electronic resources management situation.
The following information about the tables that make up DOLLeR is accurate as of the moment of this writing, but it is not final by any means. DOLLeR is under constant development, and although the main traits of the database have been set at the time of its creation, small changes or even new features are being added as its users or developer perceive new areas of improvement. This activity may affect the number of fields (which in itself is no indicator of the performance of the database), and /or the interface layout (for instance, a new field may be added, or an existing one removed or relocated). The current version of DOLLeR is 1.05.
The PROVIDER table includes 96 fields, the most important of them originating in different sections of Lambrecht’s list, such as: the provider’s type (publisher, vendor, aggregator, consortium), name, alternative name, FEIN, different account numbers, sales and technical support contact information; the URL, account and password for the use statistics; the library’s customer number with the provider; and of course notes. The remaining, and most numerous, fields are “functional.” These are required to ensure the functionality and the “depth” of the database. (See Annex 1 for a list of the data fields included in the Provider table.)
The LICENSE table includes 33 fields, some of them covering basic identification information, others allowing users to track back activities related to licensing, and yet others detailing important aspects governing the use of the electronic resources. (See Annex 1 for a list of the data fields included in the License table.) An important requirement on Lambrecht’s list was the capability of viewing online the actual text of the license. This feature was therefore included from the very beginning in the design of DOLLeR, so that electronic (scanned) versions of the licenses could be attached to each record.
The RESOURCE table includes 23 fields, most of which are part of the bibliographic description of any electronic resource. (For consistency in the treatment of the records, a resource in DOLLeR was defined as any package, or single title for which an individual subscription has to be signed, regardless of whether it does, or does not involve an invoice or a signed license agreement; having both packages and single titles as main entries in this table was considered an acceptable compromise, mostly because it reflects a reality providers create and libraries cannot avoid…) A few “functional” fields were also defined. (See Annex 1 for a list of the data fields included in the Resource table.)
The SUBSCRIPTION table, the most important and complex table of the database, includes 112 fields. Some of these fields describe strictly the terms of the subscription, such as the subscription interval, type (new, renewal, modification), status (active, superseded, cancelled, pending), number of simultaneous users, e-contents. Others relate to the money aspects and the invoicing activity carried out by the Business Office of the library. There are also fields in this table that are used to generate reports, or to add various functional features to the database. (See Annex 1 for a list of the data fields included in the Subscription table.)
The SERIALSSOLUTION JOURNALS table is the simplest one, and it is meant to hold the data pertaining to the individual titles bound together in different vendors’ packages; this data, conveniently processed and converted to the FileMaker Pro file format, is drawn from the spreadsheet that SerialsSolutions sends to the Library every other month and includes updates to the library’s list of e-journals. Eleven fields are defined for this table, among which are: the journal title, ISSN for the electronic version, start and end date of full-text coverage, provider, resource (package) name, and URL. The rest of the fields are “functional.” (See Annex 1 for a list of the data fields included in the SerialsSolutions Journals table.)
User interaction with DOLLeR is possible either via the FileMaker Pro environment, or via the Web. Having web access was one of the main requirements for this database, due to the relatively large number of its users with high level of authorization access, and the relatively high costs associated with multiple individual points of access in the FileMaker Pro native environment.
a. The FileMaker Pro interface. Given the new set, more complex of requirements included in Lambrecht’s outline, trying to keep the green sheet appearance ceased to seem an important element; as a matter of fact, it was not even an option anymore. However, what Stefancu had in mind when he started working on the DOLLeR interface was the imperative of making it as intuitive and easy to use as possible. Achieving consistency in the treatment of the layout of the various types of screens, and at the same time making use of shape and color patterns as visual guidance elements proved to best support this design goal.
Fig.3. The FileMaker Pro interface; the Subscription main screen
Here are some of the rules he observed while designing the 39 screens that make DOLLeR’s user interface:
Fig.4. The FileMaker Pro interface; the Help screen
The database has a front page that offers access to any of the five constitutive tables, based on the user’s level of access authorization.
b. The web interface. DOLLeR started its web career with a look that was completely different from what its FileMaker Pro environment users would see. The initial web interface was intended uniquely as a means for the general user to search the database. As opposed to its first avatar, and as a result of a new set of administrative requirements, which imposed that users with high level of access privileges interact with the database over the web, DOLLeR’s current web interface is basically the same interface used in the FileMaker Pro environment.
Fig.5. The Web interface; the Subscription main screen
However, it is slightly different in that the original features are not all active, due to current software version constraints, which impose certain limits on the size of the scripts that can be successfully used to obtain the same functionality on both the FileMaker Pro and the Web interfaces. Even so, the main operations that are usually performed in a database, like creation, deletion, editing of records, and, of course, searching can be successfully done over the web.
Reports with nicely tailored layouts for printing, which as a rule require more complex scripts, are not available directly through the web interface at this time.
The preferred web browser for DOLLeR is Internet Explorer, as Netscape Navigator cannot handle some of the functional features FileMaker Pro has to offer. This can hardly be a limitation though, as IE is freely available to anyone and is largely used in the library world.
Communication is the key: DOLLeR’s email gateway
A unique feature in DOLLeR is its web email gateway. This is basically a web form invoked from inside DOLLeR, that allows all users with editing privileges in the database to easily communicate among them, so that changes or additions could be immediately and easily announced to the DOLLeR community.
Fig.6. The Web email gateway
The email gateway is accessible from the Subscription record, as this is where the most contributions would occur. At the heart of this feature is the acknowledged need for all participants in the electronic resources management to be instantly made aware of the activity happening in DOLLeR. This awareness is perceived as an important management efficiency factor, since the life of an electronic resource is so dynamic and good timing here can make a difference in the quality of the library services as a whole. Desired information can be copied from DOLLeR and directly pasted into a reserved text area of the form. Another text area is available for comments. In order to precisely target their audience, the users of the gateway can choose the receivers of each of their messages by simply checking corresponding check boxes. These emails are easy to spot even in a busy email inbox as their subject line always reads: “>>> DOLLeR: from [sender name].” Being web-based, this communication system is independent oof the email software used by individual users.
Due to FileMaker Pro flexibility and to DOLLeR design, where virtually every data field is, or can be, indexed, the number of possible reports DOLLeR users can generate is technically limited only by the existing data itself. However, a number of “canned” reports are available through the FileMaker Pro interface with just a click of a mouse. Among these, and for obvious reasons, reports listing the subscriptions due for renewal over the next 90, 30 and 7 days are probably the most significant ones.
The web interface on the other hand, as already suggested, is currently not capable of generating exactly the same ready-to-print reports available in the FileMaker Pro environment. However, various types of subscription reports can be printed through the web interface using a number of predefined searches that include as criteria:
Fig.7. The web reports search page
Aslo, as DOLLeR allows various combinations of search criteria, informative reports, resulting from more complex searches, can be viewed online. While these are not suited for printing, they can be displayed on the screen using up to four simultaneous sort criteria.
Two are the main reasons why security is taken seriously in DOLLeR. First, data integrity is a real concern in an environment where relatively many users have the right to add/change data, be it full records or smaller pieces of information. However, due to their specific types of interaction with DOLLeR, no individual user is supposed to enter/alter data in every single field in the database; not every user is expected to create and/or delete records; most users are supposed to provide information in only a limited number of fields; there are users that are not supposed to contribute with any information at all. This somehow eases the pressure on each individual user, but creates a rather complicated security problem. The second reason for having a good security system in place is that not all data in DOLLeR is for the general user’s eye. Certain data, such as information regarding the various library accounts, passwords for providers’ user statistics web sites, or some license details, is not to be made available to the general public.
To address these concerns, strict security mechanisms and rules had to be implemented, and it is fortunate that FileMaker Pro offers the right solutions to such issues. Simply stated, passwords regulate all activity in DOLLeR. In order to protect data integrity, several user groups have been defined, each with a different password and carefully tailored access rights, ranging from access to selected screens and individual fields for viewing or editing purposes only, to creation/deletion of records. Similarly, in order to protect sensitive data, access to certain screens or fields has been blocked for certain group/password combinations. The result of this pretty intricate map of access privileges is a safe DOLLeR environment.
As DOLLeR users get more and more accustomed to its imbedded rules and with its interface, they necessarily find areas that ask, or allow, for enhancements. Responding to their strive for a better working experience is the main way the database gets improved. Everything that the users feel they would like to see in DOLLeR in terms of data availability, reporting capabilities, or general functionality, is taken into consideration, as well as their concerns about the esthetics of the database. However, there are aspects of the e-resources management process that, while partially transparent to the users, tend to be more difficult to accommodate.
An example of such situation is created by the variety of sources for the primary data entered into DOLLeR. Since preliminary information, which constitutes the basis for many new records in DOLLeR, comes usually from vendors, and can be quite different from that ultimately provided by the publishers, achieving a good degree of consistency in naming the electronic resources can be a challenge, making the necessary authority file, aimed at lining-up all such possible variations, seem like a perpetually moving target. That, combined with keeping several web lists of electronic resources inconsistently using various historical names for the same resources (in principle, as the packages’ instability is notorious!) proved to be the main problem in the behind-the-scenes processes required by DOLLeR. A fast, automated, reliable way of converting all name variations, as well as (re-)assigning the individual journal titles to the right package(s) is still to be found.
Currently, the UIC Library has subscriptions for over 12,000 individual electronic journals and databases coming in every imaginable combination, from individual titles, to publisher collections, to aggregator packages, with all possible (and seldom convenient) overlaps, intervals of coverage, and degrees of access. And this complex heritage keeps only increasing, and so do its associated problems. To the extent that it is nowadays possible to foresee the future, the fast advancements in the IT field will probably soon offer solutions to the current problems that electronic resources management systems face, either as fixes to the tools presently used, or as completely new products, suited to handle realities that databases like DOLLeR may not even get to be contemporary with…
Special thanks to: Debbie Blecic, John Cullars, Daniel Enoch, Joan Fiscella, Julie Hurd, Nancy John, Bob Malinowsky, Linda Naru, Carol Scherrer, Renee Schwartz, Ellen Starkman, Steve Wiberley, and Lisa Zhao who, in different phases of the development of DOLLeR, have contributed with great suggestions, constructive criticism and various technical hints; some of their expertise, experience and keen sense of observation is incorporated in DOLLeR.
Annex 1. Data fields in DOLLeR's tables
1. “VERA: Virtual Electronic Resource Access.” http://libraries.mit.edu/vera
(12 March 2004)
2. Norm Medeiros et al. “Managing Administrative Metadata. The
Tri-College Consortium’s Electronic Resources Tracking System (ERTS). Library
Resources and Technical Services 47, no.1 (January 2003): 28-35.
3. “HERMES - Hopkins Electronic Resources Management System.”
http://hermes.mse.jhu.edu:8008/hermesdocs/
(12 March 2004)
4. Adam Chandler and Tim Jewell. “A Web Hub for Developing Administrative
Metadata for Electronic Resource Management.” Updated 2003-02-26. http://www.library.cornell.edu/cts/elicensestudy/
(12 March 2004)