Nicole
Hennig <hennig@mit.edu> <www.hennigweb.com>
Web
Manager, MIT Libraries
Abstract: The MIT Libraries provide access to databases and electronic journals via the online catalog and the web. The Vera database was created in order to improve public access to a growing number of resources listed on web pages and also to help the staff more easily maintain these pages. Details of the database, called "Vera" (Virtual Electronic Resource Access), are described, including field definitions and how the database is used by both staff and public. The development of the database helped to improve access and made it easier to maintain a growing number of resources. It has also led to many further questions and discussions among the staff of the MIT Libraries about the scope of the OPAC and how tools like Vera should be related to it.
Keywords: database, electronic journals, web interface
Nicole Hennig <hennig@mit.edu> is Web Manager at the MIT Libraries. The author would like to thank Wayne Jones for providing information about serials cataloging practices and for reading drafts of this article.
This article is copyright © Nicole Hennig and is available on the web: http://www.hennigweb.com/publications/vera.html.
Like so many academic libraries, the MIT Libraries provide access to both licensed and freely available e-journals and databases via an online catalog and via pages on a web site. The catalog access is part of a well-established practice whereby cataloging departments create bibliographic records for items which the library owns or licenses, and adds those records to an integrated library system whose design and search mechanisms have been purchased from a commercial vendor. The web access is romething much newer: a way of providing quick access to full-text content of thousands of titles, by listing them on web pages, backed by a home-grown database.
The MIT Libraries' web access to its e-journals and databases did not always have the look and functionality which it does now. The current system, which we call Vera,[1] is the product of nine months of work by the Libraries' Web Manager and the Web Advisory Group in consultation with a wide range of staff throughout the Libraries. [2] Before Vera, the Libraries' lists of electronic resources were simple web pages generated by Perl scripts. Our staff called this tool the "list-builder." Here is a sample from a web listing of e-journals:
Figure
1
CAPTION: Web page produced by the "list-builder"
The pages themselves were simple alphabetical lists. E-journals were listed by title only and databases were listed by subject and title on separate pages. The program used to build these pages (accessed through a web form) was slow and frustrating to use because every time a staff member made a single change to any one title, he or she would have to first remember which pages contained that title, and then make the program rebuild all the pages that contained it. In some cases it could take ten minutes or more to change one URL. In addition, the program would fail to build the pages completely from time to time, and no one on our staff was able to completely solve this problem, so we had to run the program again to get a complete set of updated pages.
In March of 1999 we conducted some usability tests [3] of our web site, including some of these pages. In addition to giving users specific tasks and asking them to think out loud while navigating the site, we included a brief survey. One of our main findings from the survey was that many of our users considered our lists of databases and e-journals to be the most valuable and useful content on our web site. At the same time, our usability test findings showed us that these pages were difficult to find and difficult to use.
In order to find a solution to both the public interface problems and our staff maintenance problems, we decided that this system of generating pages needed to be replaced, and that a database-backed web site was the way to go. After exploring various options, we chose FileMaker Pro as the database software. We did this for several reasons: MIT has a site license for the software and there is expertise and experience on the staff in using it. FileMaker also has built-in web capability and it is easy for non-programming staff to maintain in the long run. We did not want to end up with a system that only a chosen few understood, as had happened previously.
From both the public view and the staff view, Vera has developed into something much more than the simple improvement to the public interface which we originally envisioned. Our staff now use it to track licenses, to manage URLs, and to interact with our proxy server - among many other functions, which are discussed below - but the main focus has always been on designing a better interface and access for our users.
Vera is not meant as a substitute for our online catalog, but rather as a complement to it. All of our e-journals and most of our databases are also cataloged in the OPAC. There are some things Vera does better than our current catalog (called Barton), and vice versa. Some comparisons are below:
| Vera: Web Database | Barton: OPAC |
| broad subject access to e-resources (approximately 65 subjects) | specific subject access (Library of Congress Subject Headings) |
| highly configurable screen design (allowing us to create simple, user-friendly layouts) | screen design configurable within certain limits, based on our OPAC software |
| brief descriptions of each database | brief descriptions available for some databases (in the full record view) |
| simple lists of titles with their coverage dates, making it easier to scan the list and select the appropriate title | must view the full record to see dates and publishers |
| icons showing off-campus availability, classes offered, donors, additional licensing information, and help screens | no indication of whether the resource is available off-campus |
| dynamic URLs (see below); easy to update groups of URLs automatically, depending on various conditions in the database | usually only one URL, sometimes two; must view the full record to see it; each URL must be updated one at a time |
| license management fields | no license management information |
| lacks integration with print versions of journals | print and electronic versions are well integrated and often are found next to each other in the same search results set |
| includes a small number of cross-references | many more cross-references and access points for each title |
| lack of authority control [4] | authority control |
In the sections below, there are more details about how Vera works, how it looks, and how and why we made certain decisions about its design. We will demonstrate not so much how to build a FileMaker Pro database, but the rationale and logic which could go into using any database program to build a web-based e-resource listing.
The Vera database is used to create the public web pages where users access the more than 200 databases and 2,800 e-journals (as of May 2001) to which the MIT Libraries have access. Strictly speaking, the letters of the name stand for Virtual Electronic Resource Access, but that is really just a convenient retro-fitted expansion. Giving the database a name (just as we named our OPAC) has proven very useful both for publicizing it and for instructing our users on what it is. "Vera" is often the way users refer to it at the reference desk when they have questions.
The process of inventing a new system gave us the opportunity to include features that we wish were included in our OPAC. We began with the users' needs, added our staff's needs (for maintaining licensing information), and worked up to designing a system, rather than trying to make an existing system more user-friendly.
The home page of Vera looks like this:
Figure
2
CAPTION: Vera's home page
This page illustrates some of the organizational and design decisions we made. After looking at examples of how other libraries designed their web listings of electronic resources, we noticed that some provided access to databases and e-journals on entirely different sets of pages. We decided, instead, to provide users with "one-stop shopping" for both databases and e-journals. This is partly because we feel that in many cases the distinction between the two is irrelevant and unknown to users, and partly because the distinction between the two is shifting in the publishing world. [5] The fact that users don't understand what is meant by "databases" or "e-journals" was confirmed in some usability tests we did. [6] This screen gives users the option to limit their search to databases or to e-journals, but the default is to search both, since most users will use the default settings.
Titles in Vera can be found by the following methods:
The categorization of e-journals by subject is a major change from our former simple listing. In our previous set of web pages, e-journals were accessible only by a very long alphabetical list - only databases were categorized by subject. A question often asked by users was, "what e-journals are available for computer science (or any broad subject)?" That's not an easy question to answer using the OPAC, which uses only very specific LC subject headings. Vera solves this by adding broad subject categories for listing e-journals and databases.
To create our list of subjects we started with a list of about forty topics that we were using for databases. We analyzed them, reworded some, and ended up with about sixty-five subjects which are used in the current version of Vera. This was done by reference and collection librarians who had a good sense of what our users were looking for. Our goal was to keep them broad (e.g., Physics) but to have fairly specific subjects when the needs of the MIT users demanded them (e.g., Chemical Engineering, Civil Engineering, Electrical Engineering, Mechanical Engineering, Nuclear Engineering, Ocean Engineering).
The Vera subjects are a flat alphabetical list, with no hierarchies. Any title in Vera may be listed under any number of appropriate subjects. This is the first screen of the result set for the search of databases under the subject "Aeronautics/Astronautics":
Figure 3
CAPTION: Subject results
screen for databases
The results screen includes:
In addition to the specific results, there are also cross-reference links to e-journals on the same subject, a link to "General databases," and a link to the Libraries' list of web pages called "subject guides" compiled by our subject selectors. The subject guides, for example, often contain links to additional resources which are not listed in Vera. [7]
The subject results screen for e-journals is the same, except without the descriptions. We use a different color stripe across the top of the results table for e-journals as a visual cue to users that they are viewing a different type of results set.
Figure
4
CAPTION: E-journal subject results screen
Browsing by title yields the same form of results as does searching by subject, except that the description is omitted. This is because we wanted to provide the quickest way in to a title for users who already know what they are looking for. We are assuming that if a user is familiar with a particular resource enough to search for a specific title, then he or she doesn't need to see the description every time.
Typical results from a title search of databases are as follows:
Figure 5
CAPTION: Title browse
screen for databases
Following are some of the other main features of the Vera web interface:
Figure 7
CAPTION: Key to icons
Other features in Vera include a "Frequently Asked Questions" page, a dynamically updated counter displaying the number of titles Vera contains, a "new titles" link to resources added in several time periods from the past two weeks to the past six months, and a "new" icon which automatically appears next to each title for two weeks after its creation date. We have also included a link to information about the "Jake" project in order to help our users find titles that are "hidden" within database packages. [10]
For maintaining the database, the staff access Vera via one of two methods: through FileMaker Pro on the network, or through web screens designed for administrative purposes. Since we have one staff person who handles most of the data entry (our Digital Resources Acquisitions Librarian), we use FileMaker on the network for the majority of the staff work. This allows us to take full advantage of all the database features, such as global find and replace, without having to program it all into a web interface.
We have another small group of staff, called "Vera Contacts," who do some additional data entry. This group is made up of six people who represent our larger group of about thirty subject selectors. For this group we've created a web interface for data entry. Through their "Vera contact" the subject selectors may add and remove existing Vera titles from their subject lists, change or enhance the database descriptions written by our Digital Resources Acquisitions Librarian, and enter new titles that are "free & unlicensed." We chose six people to represent the selectors so that there would be fewer people to train in consistent methods of data entry.
Below is an example of the staff web interface used by our Vera Contacts for adding and removing titles from subject lists in Vera.
Figure 8
CAPTION: Vera staff web interface - adding and removing subjects
Below is an example of the main screen used by our Digital Resources Acquisitions Librarian for data entry within FileMaker Pro.
Figure
9
CAPTION: Vera staff interface in FileMaker Pro
We had many discussions on what the scope of the Vera database should be and finally agreed that free and unlicensed titles should be included (rather than segregating them on other pages just because they are free), but also agreed that we would be very selective and include only the most important free titles for each subject (decisions are left up to each subject selector). We did this to avoid making it hard to find our licensed resources in the middle of extremely long lists of free titles. [11]
We also continue to maintain a set of web pages we call "subject guides" (http://libraries.mit.edu/subjects/). These are the usual bibliographies or "pathfinders" of web sites and other materials that most libraries offer. They are a place where selectors can list many additional free, unlicensed resources that we don't list in Vera. This is a "working decision" that we will revisit at some point in the future, but so far our sense is that the decision was a good one. Here is a diagram representing the scope of Vera and its relationship to the "subject pages" and our OPAC (Barton):
Figure
10
CAPTION: Scope of Vera
As you can see from the diagram, most of the titles in Vera are also cataloged in our OPAC. In fact, every individual e-journal (in a non-aggregator package) is cataloged in our OPAC under its individual title, but there are catalog records for only those packages which we think have a distinctive enough name that might be known to a user and therefore a means by which he or she might search for titles. For example, there are records for JSTOR and the ACM Digital Library, but none for the "American Chemical Society Publications" (Vera includes records for all individual titles and all packages).
Individual journal titles from aggregator databases such as ProQuest Direct and Lexis-Nexis are not listed separately in either our OPAC or in Vera, since their content changes so frequently. (We point to the Jake project to help users find these titles, as mentioned above). Free and unlicensed titles are cataloged in the OPAC only if the selector has made a specific request for the cataloging. Like so many libraries, we are struggling with what the true scope of our OPAC should be, especially now that we have another tool (Vera) that serves as a primary entry point for our users of electronic resources.
A question that we are considering is, why are we doing double entry into two databases (Vera and our OPAC) for most of our electronic resources? The current situation is the result of migrating from simple lists of our titles on web pages, to a complex database for handling them. We are still looking at ways to save work and one step we have taken is to import the e-journal coverage dates from our OPAC into Vera monthly. However, it's not easy to do this for all the information, because we have different rules for when and how we list a title in the OPAC versus Vera. For example, sometimes the cataloging rules and CONSER standards demand two or more records for titles which are more conveniently listed under just one title (and one ID number) in Vera. And sometimes the opposite is true: there are two records in Vera for a single, authoritative record in the OPAC. In either of these cases, it is not possible to import the coverage dates from the e-journal record into Vera because there is no one-to-one match on the Vera ID numbers. Instead, we add the coverage dates manually, just as we do for all the databases.
So far, the advantages of having a custom database that integrates licensing information with titles and the web display have made it worthwhile to enter items in two databases. The extreme flexibility of Vera allows us to do things not possible in our catalog records, such as allowing us to respond quickly to our users' need for which information is displayed and how it should be displayed. It is also very useful to have the data entry of the item happen at the time of ordering it, so that as soon as the license is settled, we can give our users access (since there is no physical item to be received). We are in the process of migrating to a new system for our OPAC (GEAC to Ex Libris) and we hope that our new implementation will be much more flexible than the old. So the future of Vera and its relationship to our OPAC remains under discussion.
The web interface of Vera for the public looks simple, but it is backed by a relational database containing a wealth of additional information which is used and managed by several Libraries' staff members. The database contains four files:
The following diagram illustrates the various relationships among the files.
Figure
11
CAPTION: Database structure
In order to come up with the fields we use in Vera, we began by looking at the Dublin Core metadata elements (http://dublincore.org/documents/dces/). This was useful especially for the concepts of "format" and "type." There were many more specific things we wanted to track, and so we added many additional fields.
Each of the fields used in the Vera records for e-resources is described below:
Title: Text field. Used for entering the title of the resource. We generally use the form of the title that users know, which is sometimes a little different than the title that gets entered in our OPAC according to strict cataloging rules.
Title note: Text field. A place to enter additional title information that we would like to appear on the public web screens after the title. For example: "Be sure to log off by pressing the 'exit' button on the bar at the top left of the screen. Our license allows only a few simultaneous users."
"Dynamic URL management": This is a phrase we use to describe the interaction of the next few fields described below.
URL native: Text field. The original URL given to us by the vendor. Does not display on public web screens, but is used in calculations described below.
URL alternate: Text field. An alternate URL that we use in some cases instead of the native URL. This is used for items that are password-protected and go through a special script on our end. Does not display on public web screens, but is used in calculations described below. For example: http://libsys.mit.edu/dbs/linkit?econlit.
URL proxy: Global field. This is a string that we must put in front of the URL in order to send the user through our proxy server (for off-campus access). [12] It looks like this: http://libproxy.mit.edu:8000/login?url=. It does not display on public web screens, but is used in calculations described below.
URL calculated: Calculation field. Checks to see if the URL alternate field mentioned above has something in it. If so, it gets entered here for use by another calculation (see URL result). If the URL alternate field is empty, the URL native field contents gets entered here for use by the next calculation (URL result). Does not display on public web screens, but is used in calculations described below.
URL result: Calculation field. This field checks five other fields described below. If conditions are right, then it appends the contents of the URL proxy field to the front of the URL in the URL calculated field.
The logic is this (fields mentioned here are fully described later in this article):
if SystemOK = "yes" and ProxyUp = "yes" and Access_Remote = "yes" and Licensed = "yes" and Access_Control = "IP Address" then append the contents of the "URL proxy" field to the front of the URL in "URL calculated."
Otherwise, it copies the contents of the "URL calculated" field. This is an example of a URL result:
http://libproxy.mit.edu:8000/login?url=http://gateway.ovid.com/ ovidweb.cgi?T=JSD=wastPAGE=main
In plain English, that means that if our system is OK (meaning our systems person has configured it for that title), and our proxy server is up and running normally, and remote access is allowed in our contract with the vendor, and it's a licensed title (rather than a free, unlicensed title), and access is controlled by IP address rather than by password, then we want our proxy server URL string to be appended to the beginning of the URL.
This is the only field of the five URL fields that displays to the user, and even then we don't show the actual long, complex URL. Instead we hyperlink the title to go to that URL when clicked.
We call this set of five URL fields and the five additional fields involved in the logic behind them "dynamic URL management." The great thing about it is that it allows us to easily change the URL or a whole group of URLs as needed. For example, if our proxy server is malfunctioning, we can set the global "proxy up" field to "no" and then instantly all the URLs that previously had the proxy string appended to them, will no longer have it, thereby allowing us not to interrupt access for our users who are on campus, while we troubleshoot the proxy problem.
Or, for another example, if we have recently negotiated with a vendor to allow off-campus access, but haven't configured the proxy server for it yet, our Digital Resources Acquisitions Librarian can set the "remote access OK" field to yes. The "system OK" will remain on "no" by default until our Systems Librarian has had a chance to configure it. Then he sets "system OK" to "yes" and the URL changes automatically.
Publisher, interface, and vendor: "Publisher" describes the publisher of the information, "Interface" describes the name of the interface, and "Vendor" describes who we purchase it from. In some cases one, two, or all three of these are the same, and in some cases they are different. For example, for Journal of Health Politics, Policy and Law, Duke University Press is the publisher, Project Muse is the interface, and Johns Hopkins University Press is the vendor. Vendor is for our internal use and does not display on the public web screens.
The public web screens are set up so that the contents of the interface field displays, unless there is no named interface, in which case the publisher displays. Interface is a selection menu, and we add an "interface" name to this menu each time we get a new group of records from one provider that use the same web search interface.
In designing this, we wanted to be able to decide on a case by case basis whether to show the publisher or the interface to the public - this allows us to do that, while still keeping all the detailed information in the database behind the scenes for our own use.
On the public web screens, we call this concept "Provider." It appears under each title on all the results screens, and also the contents of the Interface field is used to make a menu for the user to select from on our "provider" search screen.
Figure 12
CAPTION: Provider
search selection menu
Format: Text menu containing four choices: web, CD-ROM, client software needed (SciFinder Scholar, for example, requires users to download and install software on their PC or Mac), local software (Datastream, for example, is available only on certain PCs in one of our libraries).
Type: Text menu containing four choices: database, e-journal, e-book, other. Only database and e-journal are used currently. When we built the database we had several discussions about which types we should include and considered long lists of types, such as "indexes & abstracts," "directories," "e-books." We then realized that we would need to spend time deciding which category some things belong to, since the boundaries are changing. We also realized from our usability testing that users don't make these kinds of distinctions. If they do make distinctions, they are not the same ones we as librarians think of. So we decided to keep it simple and just use the broadest division, "databases" and "e-journals."
Even with just those two categories, we will from time to time list an item as both a database and an e-journal, when a subject selector feels it is very important for users to see it in both lists. Usually this happens when for a large package of e-journals, such as "ScienceDirect (Elsevier)," we are listing each e-journal individually (under e-journals) and also making a listing for the package as a whole (once under databases and once under e-journals). We do this only if we have access to all or almost all of the titles in the package and if the product provides a search across issues.
For packages of e-books, we list only the package as a whole in Vera (such as Books24x7), not each book title in it. A package of e-books is listed as a database. We don't use the e-books designation in this menu at this time, since we aren't listing them as individual titles.
Access control: Text menu containing three choices: IP address, password, or none. This is used to indicate how the vendor controls access to the title. Free and unlicensed titles are listed of course, as "none." The choice in this field is used by the URL calculation fields mentioned above.
Includes full text: A check box. If checked, the phrase, "includes full text" appears on the web screens. We've consciously chosen the word "includes" so as to accurately describe those resources in which parts but not all are full text.
Broken resource: A check box. If checked, an icon appears after the title. This helps users see that this is a known problem with the title. Clicking on the icon links to a page where we describe the status of these problems (http://nic.mit.edu/3down/; scroll down to the "library services" section).
Coverage dates: A free-text field (not a date field). For e-journals we import the dates from our catalog, using a script that adds the word "present" to open date ranges, such as:
v.29:no.1 (1996) - present
We added the word "present" to open date ranges, since we've had many reports from our reference staff that when users are looking at a record from our OPAC, they don't understand that a hyphen with nothing after it (e.g., "1990- ") means "to the present." For databases, we manually enter a range of years (e.g., "1990 - present") or a more complete description of the particular situation, such as:
Anthropological Literature Index:
late 19th century - present; articles 2 or more pages long in English & other European languages
Access exclusions: Checkboxes with two choices: Lincoln Lab, and Haystack Observatory. In some cases, our negotiated licenses prohibit access for these two off-site MIT departments. If checked, the phrase "except Lincoln Lab" or "except Haystack" will appear after "licensed for MIT" on the web screens. This helps users from those departments see at a glance which titles are not available to them (a feature we never had in our old system).
Total databases and Total e-journals: Calculation fields. Calculates the total number of databases and e-journals, excluding "see-references" and "hide = yes" records. Appears on the Vera home page so users can see the latest count of how many titles are in the database.
Figure 13
CAPTION:
Total count of titles on public web screens
See-reference: Text field, a checkbox. If checked, indicates that this record is a duplicate of another record using an alternative form of the title. Allows us to display an item under alternate titles. This is sometimes used also to display an item as both a database and an e-journal.
Hide: Text field, radio buttons, "yes" or "no." If "yes," hides record from public view. By default, new records have this checked until our staff person finishes entering all the information.
Who supports: Text field, a menu. Resources are supported centrally by our Digital Resources unit, or supported locally by individual library units (in the case of some freely available titles). The menu allows selection of one of these choices.
MIT Location: Text field, checkboxes. This is used when a product requires the user to be on-campus in one or more of our libraries (CD-ROMs and local software). It's a list of each library with a check box in front of it. This is an example of what appears on the web:
CD-ROM
Dewey Library
on-site access only
Author: Text field. This field is not yet used. At the time of creating Vera we defined it with the idea that in the future we might want to list items that have a personal author, such as an electronic book.
Licensed notes: Text field. This field is used by our Digital Resources Acquisitions Librarian. It does not display publicly. It's a text field for general notes.
Description: Text field. A brief description for each database (we don't write them for e-journals) is written by our Digital Resources Acquisitions Librarian. This can be modified later by a subject selector, through the staff web interface.
Subject: Text selection menu. A menu containing our list of about sixty-five broad subjects. This is a FileMaker "portal" to the RS-items file which contains a record for each instance of a title being assigned to a subject. We assign as many subjects as apply.
Alt description: Text field. A subject selector may choose to have an alternate description, different from the standard one, associated with the title as it is listed under his or her subject. For example, Lexis-Nexis has a slightly different description when it's listed under Law than when it's listed under Business & Management.
Vera ID number: Number field. Automatically generated unique ID number.
Created on: Date field. Auto-generated creation date of the record.
Date modified: Date field. Auto-generated modification date of the record.
Classes offered: Text field. A URL for information about classes offered on how to use the resource. The icon will appear on the web and link to this URL.
License: Text field. A URL for additional licensing information. The icon will appear on the web and link to this URL. For example, the fact that SciFinder Scholar limits downloads to 5,000 records appears in this field.
Donor thanks: Text field. A URL for a page thanking the donor of a particular title. The icon will appear on the web and link to this URL.
Search help: Text field. A URL for help pages created by our staff, or sometimes by a vendor. The icon will appear on the web and link to this URL.
PO number: Alpha-numeric field. The purchase order number and a link to another FileMaker database we use to manage purchase information.
Contract renewal: Date field. The date the contract comes up for renewal.
Payment: Text field. Used by the Digital Resources Acquisitions Librarian to record additional information about payments.
IP range: Text field. The range of IP addresses on our campus to which the resource is available. Many vendors use this method to control access to the products.
Distance ed: Menu selection: yes or no. Does the vendor allow the resource to be used for distance education purposes? Used to generate reports for our staff on the web.
ILL: Menu selection: yes or no. Does the vendor allow the resource to be used to supply interlibrary loans? Used to generate reports for our staff on the web.
Authorized user definition: Text field. Used for special descriptions of authorized users if we have not been able to negotiate our standard MIT definition.
Restrictions: Text field. Used to describe restrictions on interlibrary loan and other restrictions, such as simultaneous user limits.
Scanned license URL: Text field. A URL for a link to the PDF version of the license contract. Used by our Digital Resources Acquisitions Librarian (not for public use).
Contract scanned: Date field. Date the contract was scanned into a PDF file.
Contract filed: Date field. Date the contract is filed in our paper files.
Usage statistics: Text field. Information on how to obtain the usage statistics for the resource. Used in a report for staff.
Tech phone: Text field. Vendor phone numbers to call for technical help. Used to generate reports for our staff on the web.
Contact info: Text field. Used for additional contact information, such as names of tech support staff at the vendor site, alternate phone numbers, etc. Used to generate reports for our staff on the web.
Get URL: A "shortcut" URL that we've created for each database. (described above). For example: http://libraries.mit.edu/get/ulrichs. This field is used to generate a report that contains the ".htaccess" file for uploading to our main web server (not the FileMaker server). It lists all the shortcut URLs and which full URLs they should point to.
A big advantage of using a database to track all of this information is that we can easily create many different reports for staff use. Our Digital Resources Acquisitions Librarian, Systems Librarian, and Web Manager use the following reports available within the FileMaker database (not on the web):
We also provide several reports through the web for our staff. A few are listed below:
Of course, with FileMaker it is very easy to generate any other kind of custom reports as needed.
We use two Windows NT servers to run the Vera database. Since FileMaker Pro is a database, a web server, and a CGI all rolled into one, we need no additional server software. We use FileMaker Pro version 4.1. Vera was built before version 5 was available.
One server runs the live copy and one the "working copy" of the database. Our staff connect to the working copy to make changes and updates, while the public connects to the live copy. Every night we run a script to copy the working copy over the live copy and make additional backups to another server. The advantage to this is that we can use the working copy as a testing ground for new web screens, and also that public use won't be interrupted if there are any technical problems due to staff errors. This means that any changes we make during the day don't show up until the next day. For those few changes we want to make to the live copy (such as indicating a "broken" resource), we will from time-to-time also connect to the live copy.
The original idea was that Vera would simply be an improved public Web interface for the MIT Libraries' electronic journals and databases, but it has grown into something much more than that. It is also a working database which members of the staff use to track license agreements and to easily manage changes to large groups of titles. Vera has a flexibility which our catalog does not have, and its ease of use and simplicity are characteristics which we might want to implement in our catalogs in the future. For example, our users appreciate the broad subject access which Vera provides, and staff appreciate the time which is saved by such features as the global find and replace.
The process of creating our own database for managing our e-resources led to a number of larger discussions and learning processes.
1. "Vera: Virtual Electronic Resource Access," http://libraries.mit.edu/vera.
2. The Web Advisory Group of the MIT Libraries is made of up four members of the library staff and chaired by the Web Manager. The group is responsible for developing and recommending policies and standards and for coordinating the overall organization and presentation of networked resources and services. For more information, see http://macfadden.mit.edu:9500/webgroup/. The Web Advisory Group at the time Vera was being planned was made up of Pat Flanagan, Stephanie Hartman, Wayne Jones, Marlene Manoff, and Nicole Hennig. The original Vera planning team was made up of Ellen Duranceau, Pat Flanagan, Nicole Hennig, and Joan Kolias.
3. For complete results of these usability tests, see: http://macfadden.mit.edu:9500/webgroup/usability/results/index.html
4.For a full discussion of the value of authority control for web resources generally, see: Barbara Tillett, "Authority Control on the Web," in Bicentennial Conference on Bibliographic Control for the New Millennium: Confronting the Challenges of Networked Information and the Web, http://lcweb.loc.gov/catdir/bibcontrol/tillett.html.
5. We use the term "e-journal" to mean an electronic version of a printed journal as well as a journal available only on the web, where the primary search interface is by specific volume, issue, and table of contents. We use the term "database" to mean searchable collections of "e-journals" and monographic e-resources, such as Lexis-Nexis or Dow Jones Interactive, where the primary search interface is a search across many hundreds or thousands of different titles. We also use the "database" category in Vera as a place to put anything that is not an "e-journal": simple web pages, links to other library catalogs, etc.
This perspective is similar to what is happening in the cataloging world, in which databases and other e-resources do not fit into the traditional monograph or serial categories, and so will be better accommodated in the proposed integrating category, all under the broad rubric of continuing resources. For more information, see: Jean Hirons, Revising AACR2 to Accommodate Seriality: Report to the Joint Steering Committee for Revision of AACR, http://www.nlc-bnc.ca/jsc/ser-rep0.html.
6. In addition to the usability tests mentioned in note 3, we did some informal tests of the Vera web screens before we rolled them out. More than one user, when asked to find a specific e-journal, clicked on "databases" instead of "e-journals."
7. We use the subject guides as a place to list many additional free resources. These guides contain links back to their appropriate subject list in Vera as well. For a sample subject guide, see: http://libraries.mit.edu/barker/Subjects/EECS/index.html.
8. There are a few exceptions, which we also note on the screens. Some of our licensed resources to do not allow access for certain related MIT labs or centers: Lincoln Labs, the Haystack Observatory, and the Woods Hole Oceanographic Institute.
9. Many databases require a few sentences to explain the coverage dates. For example:
Morningstar Principia Pro Plus for Mutual Funds
For data, generally 1970 (or fund inception date) - present; for commentary, 1993 - present
10. Jake is a project hosted by the Cushing/Whitney Medical Library at the Yale University School of Medicine. It helps the user determine which research database indexes or contains the full text of a particular journal. For more information about "Jake" see: http://jake.med.yale.edu/docs/about.html and http://www.openly.com/jake/.
11. For Vera's scope statement, see: http://macfadden.mit.edu:9500/webgroup/vera/scope.html.
12. Our proxy server is called "Ezproxy" and is available from Useful Utilities at http://www.UsefulUtilities.com/.
13. In particular, several staff members contributed in the following ways: Joan Kolias (Information Technology Librarian for Collection Services) urged us to begin with Du"lin Core. Ellen Duranceau (Digital Resources Acquisitions Librarian) came up with ideas for most of the licensing information fields (and more). Pat Flanagan (Reference Coordinator) contributed much of the users' point of view in the early stages. Wayne Jones (Head, Serials Cataloging Section) and Christine Moulen (Library Systems Manager) contributed in coordinating the importing of e-journal coverage dates from our OPAC. The idea for how we are managing URLs came from Eric Celeste, our Assistant Director for Technology Planning and Administration. And the members of our Web Advisory Group (Darcy Duke, Pat Flanagan, Stephanie Hartman, Nicole Hennig, Wayne Jones, and Marlene Manoff) contributed much in the way of user interface decisions.
14. See the web site of the Bicentennial Conference on Bibliographic Control for the New Millennium for many interesting papers on these and related issues: http://lcweb.loc.gov/catdir/bibcontrol/.
