1. Introduction 

Bibliography management software (BMS)[3]  is a group of programs designed to help users in compiling bibliographies and managing textual bibliographic records in one or more databases.

Originally, beginning of the eighties, these packages were specifically conceived to facilitate the task of writing papers with all their bibliographic citations. To switch from one style format (e.g. Chicago, Turabian, MLA, ANSI, APA, Vancouver, Nature ...) to another one should just be a matter of selection: hundreds of citation styles are there and more can be added by the user himself to fit the requirements for publishers, scholar societies and scientific journals.

Meantime they have evolved significantly, and now can be seen as a tool for completely managing textual -especially bibliographic- databases.

Not only do they take care of the output process: they also provide functions to import data derived from electronic sources and to intercept possible duplicates, to sort records, to search by means of Boolean operators, also remote databases over the Internet, and to edit data. Their object is not exclusively bound to bibliographic citations, but more generally to textual data. However, "bibliography" still remains their singularity.

Which are the main features that distinguish them from other textual database manager programs and why should one resort to this type of product rather than using a generic DBMS database management system?

  1. From the point of view of database structure, most of them (not all[1]) can be defined flat-file managers with a vertical structure like: Database -> Record -> Field (-> Subfields) -> Multiple values[2] .
    They are ready-to-use products with database definition already designed including reference types for different kind of documents: books, chapters, journal articles, patents, e-mail, dissertations, computer programs, web sites...
  2. Fields are of variable length, can have multiple values and bear specific attributes, i.e.: searching, sorting, editing via lookup lists, special formatting features for fields like authors, titles, pages, date, keywords ... It is common that fields attributes cannot be changed at will or moved to another field
  3. It is common that all the fields automatically have their content indexed and thus searchable; as a consequence, databases nowadays offer full free-text searching as a normal, often default, option.  Besides they offer more complex search interface: increasingly by means of superimposed windows -where one specifies fields and value seeked for- linked via Boolean operators. Less frequently they offer browsing lists and syntactically complex search queries (with parenthesis etc.)
  4. They offer filters to convert and import bibliographic data from external electronic sources such as: CD-ROM, Internet catalogues, local OPAC, web pages displaying references. Importing from the web tends to be direct, without downloading and converting data. Increasingly they embed or work in co-operation with Z39.50 search clients ready to import the retrieved data
  5. They have a very distinctive function: the so-called "manuscript/paper formatting" procedure. This process consists in inserting placeholders as references to database records into a document prepared by means of a word processor, in order to eventually have all the in-text citations and the final bibliography reference list automatically generated and formatted within the document
  6. They offer hundreds of output formats for citation styles fitting the requirements of publishers, scientific associations, scholar journals: Nature, APA, MLA, Vancouver, Index Medicus, Chicago, Turabian ... they can all be used to display and print data. Printing includes sorting records according to nested keys
  7. In general, their makers supply users with ready-made and ready-to-use objects, rather than with the tool to develop their own products. Thus, the language to design output styles and import filters tends to be limited -and efficient at the same time- by offering numerous sophisticated options already prepared and ready to be selected with the mouse. As a result of that, they are very easy-to-use packages, efficient within the boundaries that developers have pre-set and that the user cannot overcome by developing his own application, script, routine.

These are all features that one cannot usually find in generic and relational DBMS like dbase, Access, FileMaker, Paradox. Thereby users can develop new applications and build new objects by resorting to the design tools and the programming language provided with the DBMS. As users decide not to rely on specifically designed packages, but rather to adopt a generic, flexible and powerful tool, they must be expert and willing to struggle on their own -or relying on valuable help- to achieve similar functionalities. Not only will users have to define and build the database structure, along with input forms, output styles, searching, sorting, printing, import/export routines, but they will also have to ensure maintenance of their product for the future.

BMS have been conceived, developed, maintained and marketed especially for the individual -mostly the academic researcher- working with his own personal computer database and goals, and not for the library or information service, though they have been successfully used in those environments too.

They also still have very limited multimedia functionality (graphics, sound, animation are usually only available by means of the OLE -object link and embedding- technique or a similar one) nor are they made to handle and calculate numeric data.

Although their size limits -thanks also to current hardware and operating systems- only tend to increase (number and size of database, records, fields, number of filters and styles...), they do not have the capacity to host generic library catalogues.

These factors all contribute to sustain the "personal" nature of this kind of software.

Quite understandably, it has become inevitable for this kind of products to cope with the various challenges and options presented by the Internet, such as: publishing searchable databases on the web, looking into remote database thanks to the OpenUrl and Z39.50 protocols and finally to become entirely web based applications, where -like in ordinary webmail- nothing is installed or stored on the individual user's workstation and everything is managed at the producer's server level.

Librarians and information professionals would benefit from a closer glance at this kind of product as it is the most specific bibliographical computerized tool that their users might employ. Thanks to downloading and importing routines, these software packages play a role in facilitating information and data communication between local or remote catalogues and the end-user.

Francesco Dell'Orso
University of Perugia (Italy) francesco.dellorso@unipg.it



[1] This is not the case of Biblioscape, built on a relational database structure. Biblioscape is a complex and powerful "artifact" that, in its Professional edition, goes far beyond the boundaries of the BMS category. RefWorks also is far from being a 'table-free' application, being built upon a generic SQL-tables structure. Anyhow, to find documentation on the internal structure of these databases is uncommon and producers even seem reluctant to describe it.
[2] Subfields: seldom, nearly only as far as names are concerned: "Last name, first name, prefix-qualification". Multiple values: nearly only for names and keywords
[3] As for the name of this software family see also Name

Table of contents  | Index