Go to National Library of Australia Home PageNational Library of Australia Online

SEARCH:

Networked Services Project
Request for Tender for NLA Networked Services

Chapter 4 - Project Capabilities Sought

4.1 National Bibliographic Utility

4.1.1 Overview

4.1.2 ABN and the New NBU System: Key Differentiators

4.1.3 Mapping to Configurations in Chapter 2

4.1.4 General Capabilities Sought

4.1.5 Uncommon Capabilities Sought

4.1.6 Specific Capabilities Sought

4.1.7 Questions

4.1.8 Links to Other Configurations

4.1 National Bibliographic Utility

4.1.1 Overview

The Library wishes to continue to support Australian libraries, and through them the Australian people, by ensuring that the following services are provided:

a) A source of cataloguing data, so that Customer Libraries can buy rather than create cataloguing data; the data should be high quality, adhere to international standards, and be inexpensive; the data source should provide a high hit rate so that libraries can receive the efficiency benefits of 'one stop shopping'
b) A source of location data, so that Customer Libraries and their users can tell which items are located in which Australian libraries; this data source will underpin interlibrary lending and document delivery in Australia.

The Library owns a database which contains both cataloguing and location data. The database is referred to as the National Bibliographic Database (NBD) and presently resides on the Australian Bibliographic Network (ABN). The NBD contains more than 12 million bibliographic records, 25 million holdings records and more than 1 million authority records. The logical subset of the NBD that consists of bibliographic records that have holdings attached is referred to as the National Union Catalogue. Further detail on ABN and the NBD can be found in the Appendices. The NBD is a critical component of the Library's strategy for supporting Australian libraries in the foreseeable future.

The Library has considered the issue of a distributed vs a centralised NBD. For the location information on the NBD, it is the Library's present view that the most practical solution is probably a centralised national database. For the data which does not have attached location information, the Library wishes to offer "apparent one-stop shopping" but has no prior preference for whether this is implemented through a distributed or centralised model. Tenderers who wish to offer decentralised solutions for some or all of the NBD should respond in detail to Question 4.1.7.1(a).

In addition to its services to Australian libraries, the Library has an obligation to provide Australian data as part of exchange agreements with overseas libraries and consortia.

The National Bibliographic Utility's (NBU) Contributing and Customer Libraries are very diverse. They include university, college and research libraries, and state, public and special libraries, with an enormous range of local library systems and local workflows. These Contributing and Customer Libraries are completely independent of the Library. There is no central funding body and no form of governance or contract that could ever, for example, require these Libraries to install a particular vendor's library system. (Nor would the Library ever seek this.) This diversity drives many of the requirements in Section 4.1 for a wide range of options, especially in relation to interfaces between the NBU and local systems.

4.1.2 ABN and the New NBU System: Key Differentiators

In seeking to replace the ABN software that presently supports the NBD, the Library wishes to deliver the key improvements listed below.

4.1.2.1 "Painless" Database Update

The process of contributing data to ABN requires many Contributing Libraries to adapt their local workflows to the needs of ABN, or to contribute by delayed and labour-intensive (for the Library) batch methods. The Tendered System will allow timely contribution of data as a minimal-effort by-product of local workflows. Improved facilities for holdings data will allow the NBD to reflect many holdings updates that are presently not reported.

4.1.2.2 Improved Database Quality

The ABN software offers only blunt tools for identifying duplicate records, identifying and retaining higher-quality data, identifying data that needs change and changing it, and encouraging contribution of higher quality data. Such tools as exist on ABN are also difficult to adapt to new data sources, new standards and new policies. The Tendered System will provide flexible, powerful, precise and efficient facilities to manage and improve data quality on the NBD.

4.1.2.3 Extension of "one-stop shopping"

The range of sources of bibliographic data available to Customer Libraries has expanded greatly. Customer Libraries, while wanting to take advantage of this wider range of sources, also wish to continue to receive the efficiency benefits of ABN-style one-stop shopping. The Library wishes to ensure that Customer Libraries' use of alternative data sources does not decrease their rate of contribution to the NBD. For these reasons the Tendered System will deliver "apparent one-stop shopping" through gateways and through related facilities that will support functions such as integrated billing (see Section 4.5) and data capture.

4.1.2.4 Reduced need for human intervention

A number of functions presently performed by Library staff, including data loading, duplicate resolution and delivery of cataloguing products to Customer Libraries, are labour intensive. The Tendered System will automate more of these processes, so NBU services can be delivered more quickly and efficiently.

4.1.3 Mapping to Configurations in Chapter 2

The capabilities described in this section relate to Configurations #1.1, #1.2 and #1.3.

4.1.4 General Capabilities Sought

4.1.4.1 Overview of general capabilities

The following general functions are sought:

a) Database building, maintenance and quality control (including data sampling validation, etc)

b) Cataloguing and holdings support

c) Authority control

d) Searching

e) Links with external databases

f) Output of cataloguing products

g) Creation and maintenance of Australian ISSN data

h) Activity logging and reports.

The cataloguing support is sought for creation of the NBD. Capabilities sought for cataloguing support for the Library's in-house catalogue are described in Section 4.6.

4.1.4.2 Cross-functional capabilities

General capabilities which apply to all the above functions include:

a) Provide support for the extended Roman character set as defined in the USMARC format or in a combination of ISO 646 (ASCII) and ISO 8859 (Extended Latin alphabet), including diacritics and special characters; preferably the ability to accept, input, store, display, search on, sort and output these characters

b) For non-Roman scripts, provide a minimum level of support that allows non-Roman data to be loaded, stored and output in MARC records ie passed through the system without corruption

c) For any scripts where display is not supported or in cases where the user's client software does not support a particular character set, the Tendered System should substitute appropriate text or symbol for the character (ie not display garbage)

d) Provide easy to user interfaces, suitable for novice and experienced users, with online help and tutorials

e) Accept files of user information, including passwords and authorisations, from the system selected to meet the functions described in Section 4.5 (Administrative Support System); or provide a user registration system that could act as the central registration system for all Configurations.

4.1.4.3 Overview of data contribution capabilities

The Library expects that the Tendered System will support data addition, change and deletion in at least four ways.

a) Direct, "apparently online" sessions, which will probably use the Tendered System's proprietary cataloguing functions. The Library expects that a significant minority of Contributing Libraries will wish to continue to contribute to the NBD directly rather than via local systems. The Library recognises that a proprietary cataloguing solution may be the most practical way to meet these libraries' requirements in the short term.

b) Through "upline loading", where Contributing Libraries select new, changed and deleted data from their local systems and transmit it by a store and forward process to the NBU.

c) Through the Union Catalogue Profile of Z39.50 Extended Service for Update, where data is transmitted to the NBU from the NBU's authorised cataloguing client, or from a Union Catalogue Profile compliant local system. (The latest text of the Union Catalogue Profile will be available in late March at:

http://www.nla.gov.au/2/NDIS/devproject.html) and through http://lcweb.loc.gov/z3950/agency/profiles/profiles.html

d) Through traditional batch loads of files from national and similar agencies, and of large files from Contributing Libraries.

The Library envisages the balance between these methods changing over time, with decreasing use of the NBU's proprietary cataloguing functions, and increasing use of upline loading and the Union Catalogue Profile. The Library will encourage increased use of the Union Catalogue Profile as the method that will best meet the Library's requirement for timely contribution of data as a minimal-effort by-product of local workflows.

The Library is unable, however, to predict the rate to which Contributing Libraries will adopt the new methods of contribution. It is also possible that the way in which other aspects of the NBU are implemented (eg detection of duplicate authority headings) may mean that some update paths prove to be better than others in particular circumstances. For these reasons, the Library requires the Tendered System to support all the above update paths, to allow the maximum feasible flexibility in methods of data contribution, and to allow Contributing Libraries the maximum feasible choice in their migration paths.

4.1.5 Uncommon Capabilities Sought

Tenderers should be aware that there are, in the Library's view, a number of differences between a national bibliographic utility and, for instance, a consortium library system, or a large multi-campus library system. The main such uncommon capabilities are listed below.

4.1.5.1 Support for a wide range of data sources

Many library systems load data from only one or two external sources. The NBU will, however, load or make accessible files from hundreds of different sources: at least 14 different national and similar agencies, and hundreds of Contributing Libraries whose data may not entirely conform to national standards. This drives a number of capabilities sought, including:

a) Facilities to allow NBD Managers to set parameters for new data sources without programmer intervention
b) Facilities to allow NBD Managers to change data at load time through a precise, powerful and flexible data conversion facility.

4.1.5.2 Support for "painless" data contribution

The need for timely contribution of data as a minimal-effort by-product of local workflows, as mentioned earlier in this Section, drives a number of capabilities sought that could be described as uncommon. These include compliance with the Z39.50 Extended Service Update Union Catalogue Profile, which, to the Library's knowledge, has not yet been implemented in any library software.

4.1.5.3 Flexibility to deal with changes in the data environment

Changes in the NBU's environment need to be reflected in the data. As a utility serving a nation, and accepting data from many other nations, the NBU has a very wide catchment in which such environmental change can occur. Libraries whose holdings are recorded on the NBD merge, split and cease to exist. New MARC data elements are defined and others made obsolete. Subject headings are merged, split and cancelled; since many libraries use the NBD as a subject authority, these changes need to be reflected promptly. Because of this dynamic environment, NBD Managers need sophisticated search capabilities to identify groups of records needing change, and global change facilities that can handle hundreds or thousands of records.

4.1.5.4 One record per item policy

Customer Libraries give a high priority to minimising the number of duplicate records on the NBD. A duplicate record is a record describing the same item as another record; duplicate records rarely consist of entirely identical text and often do not share any control numbers such as ISBNs, LC numbers etc. In managing the NBD on the Tendered System, the Library would prefer to continue the ABN policy of one bibliographic record per item.

There is extensive overlap in the files that will be loaded to the NBU. Records describing the same item often arrive several times from the one source (approximately two thirds of records that arrive in a weekly file of LC records, for instance, are intended to replace previously-issued LC records); they also often arrive several times from different sources. To prevent massive duplication of data, the Library seeks a duplicate detection and resolution facility that is unusually sophisticated and can be continually adjusted.

The functions related to the range of data sources (4.1.5.1) and one-record-per-item together underpin the "one stop shopping" concept which provides Customer Libraries with considerable efficiencies when searching the NBD for ILL locations and copy cataloguing.

4.1.5.5 Importance of holdings

The holdings data is the most valuable and unique data on the NBD. It is also the most volatile and least standardised. As 'privately owned' data on a public database, it requires special security so that one library cannot change the holdings data contributed by another library. As a key factor in the selection of cataloguing products, it requires unusual searching facilities (eg the ability to select all records whose holdings have been changed by particular library since a given date, excluding the effect of holdings changes by other libraries).

4.1.5.6 Extent of human reviewing

The capabilities sought for human reviewing go well beyond that which would be required by, for instance, cataloguing supervisors reviewing their staff's work. Human reviewing is a bottleneck that often delays file loads from ABN Contributing Libraries for several months, and is a major factor in decisions not to load to some files. The need for some form of review of incoming data will increase as more data is contributed by ftp and the Union Catalogue Profile of Z39.50 Extended Service for Update.

The Library wishes to deal with these problems in a numbers of ways, including greater automation of judgements on record quality, duplicate detection logic that minimises the number of cases requiring human review, improved data conversion facilities that reduce the need for manual intervention, file sampling facilities, and facilities that allow reviewers to compare and manipulate several records at once.

4.1.5.7 Output of cataloguing products to a wide range of Customer Libraries

The NBU will supply data to hundreds of Customer Libraries, and thus seeks a wide range of options for selection, format and delivery of records. In this the NBU differs from many library systems which rarely output MARC records to external systems, or only output them to one or two external systems.

4.1.5.8 Need to help prevent duplicates in Customer Libraries' local systems

Customer Libraries often acquire 'refresher files' from the NBD ie they acquire a record describing the same item on several different occasions. Between the occasions, the record may have been replaced on the NBD or merged with other records, and may no longer have, for instance, the LC number or ISBN that is in the record on the Customer Library's local system that it is intended to replace. The Customer Library's local system needs some way to relate the older record on their local system to the newer version that arrives from the NBD, so that the newer version will not be loaded as a duplicate.

The Library wishes to continue to help Customer Libraries prevent duplicates on their local systems by providing an 'immutable' control number or some equivalent facility, eg a control number that survives all merges and replaces, and records all previous 'immutable" numbers where one record has replaced several others.

4.1.5.9 Expectations driven by previous enhancements

The Library has made in-house enhancements to the WLN software that supports ABN. The Library recognises that functions equivalent to in-house enhancements are an area where compromise is likely to be needed. One particular enhancement, however, has proved very popular with Customer Libraries, and the provision of equivalent functionality is thus a high priority. It is the 'Downline Loading' enhancement. The three features of Downline Loading that are most valuable to Customer Libraries are:

a) Automatic record selection; records can be selected as a result of holdings additions and changes; there is no need for the Customer Library to enter a particular command to trigger transmission
b) Loading of the selected records into the Customer Libraries' local system without human intervention by staff at the Customer Library
c) Virtually instant delivery into the Customer's local system.

A particular difficulty that Tenderers are likely to face in providing an equivalent function to ABN-style downline loading is to provide it in a way that is easy for local systems to avoid local human intervention and transfer each record instantly to the local system. During implementation, liaison between the Tenderer and local system vendors may be needed.

The uptake of Z39.50 clients by Customer Libraries is expected gradually to replace the need for downline loading software; the Library seeks a Tendered System that can provide downline loading in the short to medium term.

4.1.5.10 Activity monitoring

The capabilities sought by the Library for managing the NBU as a business differentiate it from many other large library systems. These capabilities go beyond what could be described as 'normal' requirements for management information and statistics. They include the ability to track many application-level activities against Contributing and Customer Libraries in an auditable way. Although the Library is moving towards subscription based charging (see Section 4.5), detailed activity monitoring is still sought to allow the Library's business managers to compare subscription levels with actual activity, and to allow particular activities to be billed, or to attract credits, if required.

4.1.5.11 Effect of a distributed NBD on the above "uncommon" capabilities

The Library is open to proposals from Tenderers under which the NBD would have a distributed architecture - ranging from separate logical files on the NBU server(s) to physically separate files at different sites. Under such an architecture the Library would wish to continue to provide apparent one-stop-shopping and apparent one-record-per-item, and there would thus be a need for equivalents of many of the capabilities described above. Duplicate detection would need to occur on the fly instead of at load time, as would data conversion to bring data to the standards required by Customer Libraries.

4.1.6 Specific Capabilities Sought

The specific capabilities listed are not intended to be an exhaustive list of required functionality. They are designed to be illustrative of the range of functionality desired by the Library, and include capabilities which may be unusual in the library services marketplace. The Library does not expect that Tenderers will necessarily be able to provide all the functionality listed. However, the selection process will include detailed evaluation of the extent to which Tenderers are able to provide the capabilities listed.

4.1.6.1 Variety of data contribution methods

a) Allow bibliographic, holdings and authority data to be added, changed and deleted online.
b) Support "Upline loading" ie accept and load, preferably without human intervention, data that is transmitted by a store and forward process from an external system.
c) Allow files to be loaded from electronic media including diskettes, tapes and cartridges.
d) Provide full compliance with the Union Cataloguing Profile of Z39.50 Extended Services Update as a target, accepting new, changed and deleted bibliographic, holdings and authority data through this profile.

In the lists of capabilities that follow, capabilities that are common to some or all of the above data contribution methods (eg sampling, validation) are listed first.

4.1.6.2 Sampling and testing

Background

The ability to sample incoming data is needed for two main reasons:

  • To allow NBD Managers to monitor the quality of data that is contributed regularly by Contributing Libraries
  • To assist NBD Managers when they are analysing the data structure and content of new files.

Capabilities

a) Allow NBD Managers to sample data that arrives through all data contribution methods: upline loading, batch, online and Union Cataloguing Profile

b) Allow NBD Managers to produce reports on files that are being considered for loading eg indicating the number of occurrences of a particular sub-field.

c) Allow NBD Managers to specify and vary sampling parameters including the type of record, the user or group of users who supplied the data and the class of document.

d) Allow NBD Managers to load a file in test or simulation mode.

4.1.6.3 Validation and processing rules

a) Validate incoming data from all data contribution methods against USMARC bibliographic and authority formats, and other national MARC formats where appropriate, and against validation rules including requirements to contain mandatory data elements.

b) Allow an NBD Manager to override selected validations, such as edit masks for specified fields.

c) Allow records accepted via upline loading and the Union Cataloguing Profile to be given a processing priority (ie load one file before loading another file), depending on the source of the data.

4.1.6.4 Conversion of incoming data

For each Contributing Library or agency that supplies data to the NBD, through upline loading, batch loading or the Union Catalogue profile, allow:

a) NBD Managers to specify which data should be loaded by:

i. MARC tag
ii. MARC sub-field
iii. MARC field indicator

b) NBD Managers to set and vary mapping of data in bibliographic, authority and holdings records; including "Convert all 976 fields to 035 0"; "Convert the contents of 984 $a according to a table eg 2001 to ANL"; "Convert New Hebrides to Vanuatu when it occurs in the following fields and sub-fields...'; 'Map contents of 010 to 001 if 001 not already present", and "delete all 500 fields containing the word binding"

c) NBD Managers to specify and execute other data massaging including:

i. add characters to the beginning or end of the incoming data element
ii. replace the first occurrence of a string of characters with another string
iii. truncate a data element to a specified length

d) NBD Managers to set parameters to move data from bibliographic to holdings records, eg to move legacy data of interest only to specific libraries (Called 'institution specific data' on ABN) to Library specified fields

e) Allow NBD Managers to convert a file in test or simulation mode.

4.1.6.5 Duplicate resolution; matching and merging

Background

A duplicate is a record that describes the same item as another record. The two records in a duplicate pair rarely consist entirely of identical text. Duplicate records may arrive through online cataloguing, Z39.50 Cataloguing Profile, upline loading and batch loads.

In addition to preventing duplicates, the matching process will also play an important role in ensuring that new holdings data contributed to the NBD via upline loading, batch loads or the Union Catalogue Profile is linked to the correct bibliographic records.

A possible method of providing these capabilities is listed in the Appendix D. The Library does not wish to discourage, however, solutions which provide the capabilities in different ways, eg by tolerating duplicates on the database but resolving them at online-display time and when cataloguing products are output. Tenderers wishing to propose alternative solutions should provide detailed answers to the question Describe how the Tendered System would detect and resolve duplicates in the Questions Section of this RFT.

Capabilities

For records arriving through any NBU method of data contribution:

a) Detect duplicates, flagging doubtful cases for review by NBD Managers or, where the duplicate has been created during a cataloguing session, for review by the Contributing Library

b) Provide an efficient and effective facility for human review of duplicates

c) Provide a duplicate detection and resolution facility that:

i. ensures that a record with holdings attached is never incorrectly replaced
ii. ensures that holdings from an incoming record are never attached to the wrong bibliographic record
iii. provides a high level of reliability for other decisions ie decisions involving addition or rejection of records
iv. minimises the number of doubtful cases flagged for human review (though it is recognised there is a trade-off between reliability and number of cases flagged for review.)
v. allows NBD Managers to set parameters specific to each data source and type of data (eg different parameters for LC MARC records and a file from a Contributing Library, and different parameters for serials and monographs) and to change these parameters easily without programmer intervention
vi. allows the quality of a pair of duplicates to be assessed, on criteria such as record source and encoding level, so that the higher quality record can be retained
vii. allows duplicate records to be merged, retaining some data from each record according to parameters set by NBD Managers, including parameters based on MARC field, indicator and subfields.

4.1.6.6 Batch data loading

a) Load the following data into the NBD:

Source
Format
ABN
USMARC bibliographic with extensions
Library of Congress
USMARC bibliographic
OCLC
OCLC extension of USMARC bibliographic
RLIN
RLIN extension of USMARC bibliographic
National Lib of Canada
USMARC bibliographic
National Lib of Singapore
USMARC
British Library
USMARC bibliographic
USGPO
USMARC bibliographic
National Lib of NZ
USMARC bibliographic with extensions
National Lib of Medicine
NLM extension of USMARC bibliographic
Contributed data from Australian libraries
USMARC bibliographic with extensions,
AUSMARC bibliographic with extensions
National Diet Library (Japan)
USMARC bibliographic
National CJK Service
USMARC bibliographic with extensions
Blackwells
USMARC + 970 field
LC
USMARC authority format
National Lib of Malaysia
USMARC with extensions
National Lib of Indonesia
Format not yet known
National Lib of Vietnam
ASCII
National Lib of Korea (South)
KORMARC
Future unspecified sources:
SGML
Tab delimited
Comma delimited
LC Holdings format

b) Load the following data into separate files that can be used for reference:

i. Library of Congress Name Authorities (LCNA)
ii. Library of Congress Subject Headings (LCSH)
iii. National Library of Medicine Subject Headings (MeSH)
iv. Other subject specific thesauri eg the Aboriginal Thesaurus

c) Accept both spanned and unspanned MARC data.

4.1.6.7 Quality control and human reviewing

Background

The Library is seeking a range of functions that will support NBD Managers in their task of ensuring that the quality of data on the NBD is maintained and improved. Automated quality control will include sampling functions, validation functions, conversion functions, and duplicate detection functions (described in other parts of the National Bibliographic Utility Section). This section focuses on the desired facilities for human reviewing, and also describes desired functionality for automated reports on record quality that may be passed to the billing system for allocation of credits based on record quality.

Capabilities

a) Allow a cataloguer, whether contributing online or trough the Union Cataloguing Profile, to flag a record so that it comes to the attention of an NBD reviewer.

b) Provide online facilities enabling NBD Managers to review records flagged by cataloguers, flagged by data loading processes or flagged by the duplicate detection process.

c) Enable the work of specified users, groups of users, Contributing Libraries or work in specified categories to be assigned to different NBD Managers for online review.

d) Where records have been flagged for review as potential duplicates, allow NBD Managers to compare the records easily, eg through providing an 'overlay' display that shows a composite record with the differences highlighted. Allow NBD Managers to call up the full display of any of the potentially duplicate records with a minimum of keystrokes.

e) Provide reports monitoring the quality of data input by a user or group of users, in a format that can be imported into the Administrative Support System (Section 4.5).

4.1.6.8 Global changes

a) Accept and process global change transactions initiated online and through the Z39.50 Union Catalogue Profile.

b) Limit the global change facility to authorised users, and provide checks, warnings and audit trails.

c) Allow NBD Managers to apply a global change to the entire NBD or to any subset of it that can be selected through the NBD search functions. The global change facility should be available for bibliographic, authority and holdings data.

d) Allow NBD Managers to specify that the value should be changed wherever it occurs in the record; or only in specified fields, fields with specific MARC indicators, sub-fields and character positions within fixed length fields.

e) Apply the NBU's validation rules to global changes.

4.1.6.9 Cataloguing

a) Allow a cataloguer to add, change and delete bibliographic, authority and holdings data.

b) Support the creation of bibliographic and authority data in USMARC format.

c) Provide efficient cataloguing work screens; provide a screen editor, with good text processing facilities.

d) Suppress prompts for fields which occur infrequently but allow these prompts to be called up easily and data inserted as required.

e) Allow a cataloguer to save partly-completed work, whether it is the creation of a new record or the update of an existing one, and resume it later; in such cases the partly-completed work should not be added to the NBD.

f) Validate new and changed cataloguing.

g) Store in each bibliographic, holding and authority record:

i. the date of creation and/or latest update
ii. the record source (eg the Contributing Library identifier)
iii. the source (eg the Contributing Library identifier) of the latest update.

h) Allow input of references (eg URLs in 856 fields) to external objects that are stored on the NBD or on NSP storage devices, or are accessible via World Wide Web, Gopher or ftp protocols on an external system. Support the use of these references as 'clickable links'.

i) Allow use of an existing bibliographic, holdings or authority record as a basis for the creation of a new record (eg to create a record for the "3rd edition, 1996" from a copy of the record for the "2nd edition, 1993").

j) Allow data identified on external systems via gateways to be copied to the NBD as well as to a Customer Library's local system or, at the cataloguer's choice, to be imported into an NBD work form to be updated or to form the basis of a new record.

k) Allow concurrent searching and cataloguing sessions, with the ability to cut and paste retrieved data from one window to another.

l) Allow a cataloguer to transfer without re-keying an authority heading on the NBD into a bibliographic record.

m) Allow cataloguers to search cataloguing tools such as LCNA and the Dewey Decimal Classification, and to incorporate data from search results into their work screens.

n) Inform cataloguers if they use a heading that is an unpreferred form, or not already used on the NBD.

o) Prevent a cataloguer from deleting a bibliographic record if holdings data is still linked to it.

p) Allow the bibliographic creation or update process to trigger "downline loading" ie the transfer of the new or updated data to an external system in real time.

4.1.6.10 Holdings

Background

Holdings records describe where documents are held in Australia, including documents held in electronic collections. Holdings statements generally include a call number and often a local system number, and may include notes about retention, referral etc. For serials, the holdings statement usually contains a summary of the volumes and years a Customer Library holds. The holdings data stored on the NBD will be summary holdings. There is no need to store volatile copy specific information such as whether a copy is on loan, or whether a particular issue of a serial has been received.

This section outlines the specific capabilities sought for creating and maintaining holdings on the system. The should provide facilities for intake of holdings through all update methods. Some Contributing Libraries will prefer to contribute information about all their holdings as a by-product of updating their local systems. Others will add new holdings to the NBD at the same time as they contribute new bibliographic records to the system and/or obtain copies of bibliographic records for their local systems. A third group might add holdings when obtaining copies of bibliographic records for their own systems, then change the bibliographic records locally and upload the holdings, together with the changed bibliographic records, to the NBD.

Contributing Libraries will need on occasion to delete or update holdings details to match significant changes to their own collections - eg, when they no longer have any copies of an item or have ceased to subscribe to a serial. In addition, Contributing Libraries may add new holdings to the NBD at the point of ordering the item or at a pre-cataloguing stage and may wish to amend the holdings details after the item has been fully processed. While many cataloguers will update existing holdings directly on the NBD, an increasing number of cataloguers will make these changes as a by-product of updating their own systems.

Capabilities related to the output of holdings data to Customer Libraries in MARC records are described in Section 4.1.6.15.

Capabilities

a) Allow addition, change, deletion and transfer of holdings, through online sessions, upline loading, batch loads and the Union Catalogue Profile.

b) Support the intake of holdings data created on external systems when the Contributing Library has supplied a unique control number or combination of fields that identify the NBD bibliographic record to which the holdings should be attached. This will involve full use of the matching functions described in Section 4.1.6.5 Duplicate resolution; matching and merging.

c) Support the conversion of holdings data created on external systems to the NBD internal format when supplied:

i. in an additional field in a brief or full bibliographic record in the USMARC format for bibliographic data
ii. in the USMARC format for holdings data, or
iii. in a delimited ASCII format consisting of the location, call number and one or more potential unique identifiers.

d) Limit the ability to create, change or delete the holdings data related to a particular Contributing Library to the staff of that Contributing Library and NBD Managers.

e) Allow new holdings data to be linked directly to a bibliographic record that:

i. has been identified through the NBD search functions, or
ii. is being created or updated online.

f) When a staff member of a Contributing Library adds holdings online, notify them if there are existing holdings for their library attached to that bibliographic record, and allow the staff member to either proceed with or abandon the activity.

g) Provide an option for adding holdings information automatically to new records. For example, if no holdings data is present, automatically add the Contributing Library identifier and the text 'held'.

h) Provide an option allowing holdings added to a bibliographic record to be automatically copied to other bibliographic records, eg items in a series.

i) Allow NBD Managers to edit existing holdings data, eg to insert a prefix in front of the call number of all holdings for a location meeting specified criteria.

j) Allow NBD Managers to merge all the holdings of one location with those of another, or groups of holdings records meeting specified criteria.

k) Allow global changes to be made on holdings.

l) Allow the holdings creation or update process to trigger "downline loading" ie the transfer of the new or updated data to an external system in real time.

m) Allow the deletion of holdings data by a Contributing Library to trigger downline loading of a record with a Delete status to that library.

4.1.6.11 Authority Control

Background

The Library wishes to retain and extend the Australianised nature of its present name and subject authority data, but also wishes to load LCNA, LCSH and other thesauri as separate files.

The present ABN authority file will be loaded to the new system. This will form the main authority file of the new system and will be the file that will be used for any automatic checking of newly input headings, automatic mapping of newly loaded headings etc, that the Tendered System provides. Pure LCNA, LCSH and other authority files stored separately will be used as cataloguers' reference tools, from which cataloguers may copy headings into the main authority file, and may also be used as an alternative source of headings in cataloguing products.

Capabilities

a) Allow authority data to be created, changed or deleted, through online sessions, upline loading, batch loads and the Union Catalogue Profile.

b) Allow cataloguers to flag for human review new, changed or deleted authority records, and to attach messages to them.

c) Validate new and changed authority records.

d) Provide lists and statistical reports of new authority records created in a given time period by a specified user or group of users or offline source.

e) Allow global changes on authority data.

f) Allow NBD Managers to merge and split authority records (eg, to replace the authority heading "War games -- Computer games" with the heading "Computer war games").

g) Prevent an authority record from being deleted if it is still linked to a bibliographic record.

h) When bibliographic data is loaded, use the NBD authority file to provide automatic mapping of non-preferred forms to preferred forms.

i) Load various thesauri of controlled terms including LCNA, LCSH, MeSH, as separate files to the NBD, to be used for reference. Allow cataloguers to copy data from these files into NBD records.

j) Allow NBD Managers to create, modify or delete data in Cataloguing Tools, such as LCSH and Country of Publication codes.

k) Allow the duplicate detection, matching and merging functions described in Section 4.1.6.5 to be applied to incoming files of authority data, with parameters specific to authority data.

l) Enable new formats (eg non standard MARC formats or tagged and delimited or comma delimited formats) to be defined to support the offline intake of authority data in other formats.

4.1.6.12 Searching

Background

The NBD search facilities will be used for varying purposes:

a) by End-Users seeking location and bibliographic information

b) by cataloguers in Customer Libraries seeking particular bibliographic and authority records, ILL staff seeking location information, and reference staff

c) by staff in Customer Libraries and NBD Managers selecting records for output in MARC format

d) by NBD Managers surveying data quality and frequency of particular data elements etc, and selecting records for global change.

Capabilities

a) Provide the following displays, and allow searchers to move easily between them:

  1. i. short and long displays of a record
ii. MARC format and other displays of a record
iii. a bibliographic record and its associated holdings data
iv. a bibliographic record and its associated authority headings
v. a bibliographic or holdings record and its associated documents, eg by following a URL in the bibliographic record or in the holdings data to a display of the associated document.

b) Generate display constants eg 'Continued by:' for particular fields and MARC indicators.

c) Provide options for the order in which holdings are displayed, including an option to display them in alphabetic order by Australian NUC symbol.

d) Allow a searcher to:

i. Input a search
ii. Browse lists of headings and indexed terms
iii. Combine search terms using Boolean and other operators
iv. Truncate search terms
v. Use proximity searching
vi. Use proximity searching with positional operators eg 'Department' within two words of 'Transport'
vii. Limit searches, including limiting to items held by "my library" or a group of libraries
viii. Include mathematical search criteria (greater than, within range etc) on numeric fields
ix. Save search strategies and search results
x. Search on specified MARC fields, fields with particular indicators, sub-fields and codes, and perform Boolean, truncation, proximity, limiting and saving operations on the searches eg "find all records that lack an 020 field but contain an 'x' sub-field in a 4xx field'
xi. Search on the contents of holdings statements, including full and truncated call numbers, strings of data within call numbers, and masks, to allow retrieval of records for global changes of holdings
xii. Retrieve records with short titles, excluding records with longer titles that include the same words
xiii. Optionally view only "my library's" or "my group of libraries" holdings statements on retrieved records.

e) Allow any set of records retrieved by the search facility to be passed to the global change facility and to the output of MARC records facility.

f) Allow searchers to search external databases through Z39.50; allow Z39.50 broadcast searching.

g) Allow a user to click on a an electronic address (eg a URL) that appears in a record and to be automatically connected to the appropriate document.

4.1.6.13 Links Within the NBD

a) Allow holdings data to be linked to particular bibliographic records.

b) Allow headings used in bibliographic records to be linked to authority records.

c) Allow authority headings to be linked to bibliographic records.

d) Support the following links among authority records, where "support" includes ability to search on data and retrieve linked data, and provision of a results screen that displays the logical relationships of linked data without repeating the data:

i. broader term
ii. narrower term
iii. preferred term
iv. unpreferred term
v. related term (see also)
vi. equivalent terms in different thesauri.

e) Support the following links between bibliographic records, where "support" includes ability to search on data and retrieve linked data, provision of a results screen that displays the logical relationships of linked data without repeating the data:

i. support links to different versions of a work
ii. support links between a whole document and its parts
iii. support links between documents based on the same work
iv. support links between related serially issued documents.

4.1.6.14 Links with external databases

a) Fully comply with Z39.50 Version 3 as both origin and target.

(More specific Z39.50 capabilities are included in the following sections: Variety of Data Contribution Methods; Global Change; Holdings; Authority Control; Searching; Output of Cataloguing Products; Activity Monitoring and Reports; and in Section 4.2 Cataloguing Client.)

4.1.6.15 Output of cataloguing products

a) Deliver bibliographic, holdings and authority data to Customer Libraries on request.

b) Allow Customer Libraries to request and receive MARC records through Z39.50.

c) Allow Customer Libraries to use the full range of NBD search functions to select records to be delivered.

d) Allow Customer Libraries to request delivery of individual records, and to select files of records for delivery.

e) Allow Customer Libraries to place standing orders so that records selected by specified criteria are automatically delivered to the Customer Library at specified intervals, including 'deliver every Friday by ftp all the serial records to which libraries x and y have added or changed holdings since the previous Friday'.

f) Allow Customer Libraries to cancel or postpone the delivery scheduled for a particular date ie vary the standing order, and to specify an expiry date for the standing order service.

g) Provide an equivalent to the "ABN immutable" function ie a means of storing in a record a list of the unique numbers of all records that have been replaced by that record.

h) Allow Customer Libraries to enter a local control number into a record in a way that allows them to receive that local control number if they order that record from the NBD, but that prevents their control number being received by other Customer Libraries that happen to order the same record. This is needed to provide an alternative method to "immutables" for matching NBD-derived records within local systems.

i) Provide Customer Libraries with a range of options for selecting records to be delivered, eg output results of last search, request only authority records updated sine the Customer Library's last run.

j) Provide Customer Libraries with a range of options for format of records, eg ASCII, untagged, specified fields.

k) As one format option, support the output of bibliographic and holdings data in the format currently output from ABN, using 984 fields for holdings, to minimise the changes that Customer Libraries will need to make to receive MARC records from the new NBU.

l) Provide Customer Libraries with a range of options for delivery methods, eg FTP, magnetic media.

4.1.6.16 Creation and maintenance of Australian ISSN/Publisher data

Background

The Library is seeking to replace its software, presently a customisation of its ILMS, which is used to assign ISSNs on request to new Australian serial titles as they are published and to register these ISSNs with the international ISSN database. This function is currently managed by the Australian ISSN Agency located in the National Library of Australia. As part of the process, databases of Australian serial titles (presently in USMARC, 35,000 titles growing at 2,500 titles per year) and of Australian publishers are maintained. See also Section 4.6.4.4.

Capabilities

Allow Library staff to:

a) Allocate International Standard Serial Numbers from a sequence of numbers provided by the International ISSN Agency, checking first that a particular title has not already been allocated an ISSN and checking that the ISSN assigned is valid

b) Maintain a record for each serial title allocated an ISSN, ensuring the record is upgraded to record full publication details once the title has been published, and that changes are recorded in a timely manner

c) Obtain reports of titles allocated an ISSN which have not yet been published

d) Obtain reports of titles and ISSNs associated with a specified publisher

e) Maintain a list of Australian publisher addresses and contact names

f) Register Australian serial titles and ISSNs with the International ISSN Agency database and notify the Agency of any changes and deletions, through conversion of records to the ISDS MARC format, or through output of records to a file to be converted to ISDS MARC by the Library's in-house conversion program

g) Register Australian publisher addresses and contact names with the international ISSN database and notify the agency of changes and deletions.

4.1.6.17 Activity Monitoring and Reports

Background

Reports will be used for export to the Administrative Support System and for general management information purposes. The capabilities sought by the Library for detailed transaction information to allow billing and crediting of Customer Libraries are complex.

Capabilities

a) Report on the number and type of application-level activities by each Customer Library.

b) Report on the output to each Customer Library, including number of records displayed and number of bibliographic and authority delivered to each Customer Library as cataloguing products.

c) Report on the access to third party Z39.50 servers by NBD users, in a format that could be imported by the billing system that is accepted as part of Configuration #5.

d) Report on the numbers of new and changed bibliographic, holdings and authority records contributed by each Customer Library, through each and all data contribution methods.

e) Report on the quality of new and changed bibliographic, holdings and authority records contributed by each Customer Library, through each and all data contribution methods.

4.1.7 Questions

4.1.7.1 General

a) If you wish to propose a solution that would involve some or all of the NBD being distributed across servers external to the Library, or any other solution involving distribution of the NBD, please outline your strategy.

b) If you are tendering for Configuration #1.3 (Outsourced), describe the services you are proposing to provide eg file loading, duplicate reviewing, Help Desk. Outline the service level agreements you would offer.

c) If the Tendered System could also meet the capabilities foreshadowed for separate stages of the NSP, particularly the Hosted Databases, Citation Data Creation and Interlibrary Loan and Document Delivery functions, please describe how this would be implemented, and provide indicative costings.

d) The Library's preference is for users of the National Bibliographic Utility and of the National ILL Utility, and eventually of the other stages of the NSP, to be registered once, in a way that would allow their passwords, authorisations, groupings etc to be set up in a single session, and would allow, for example, a user to use the same password to search the NBD and the Hosted Databases. The Library will, however, consider proposals that require registration of NBD users to be done within the NBU. If your Tendered System has facilities for user registration, please describe them.

e) What online session information does the Tendered System provide, eg elapsed time of this user's session, number of commands issued in this session?

f) Are users automatically signed off after a period of inactivity? If so, can the period be set, and by whom?

g) To what extent is the online help provided by the Tendered System context sensitive? Provide an example of context-sensitive help.

h) Will the Tendered System allow NBD Managers to create and edit help screens? If so, please describe this facility.

i) Does the Tendered System have a facility to broadcast news? If so please describe.

j) What local software and hardware is required to enable the Extended Latin (ISO 8859) characters to be displayed on a user's device?

k) List the character sets a cataloguer may use, and describe how cataloguers may input codes for any characters that cannot be directly input or displayed by the Tendered System.

l) Describe the support, if any, offered by the Tendered System for Chinese, Japanese, Korean and other non-Roman characters.

m) Do you have a plan and schedule for support for Unicode? If so please describe the plan and schedule, and what you mean by "support".

n) List the record-length and field-length limits for bibliographic, authority and holdings data. For each, show the limit for storage, online display, and output in MARC format. Describe any options for increasing these limits.

o) Does the Tendered System require modification to support the USMARC integrated format? If so, describe what support is provided. For example, does the Tendered System support retrieval of records for non-print materials catalogued in the serials format, and vice versa?

p) Although the NBD focuses on shareable data, support for non-shareable or 'institution specific' data has some advantages in attracting data contribution. Support for non-shareable data can range from inclusion of such data within a Contributing Library's holdings data to provision of library-specific views of bibliographic records. Describe any support the Tendered System provides for non-shareable data, including any support for its inclusion in and exclusion from cataloguing products.

q) Is all data in the system able to be created, maintained and deleted during an online session? If not please describe the circumstances under which this cannot be done.

r) Are there any circumstances when a change to an indexed field would not be reflected as an index update? Or a change to a field used to generate reports would not be reflected in the report? (For example if a cataloguer issued change transactions while a global change process involving the same data was still running). If so please describe the circumstances.

s) How is data on the Tendered System backed up?

t) Describe any facilities the Tendered System has for archiving bibliographic, holdings and authority data.

u) Describe your company's involvement, if any, in the Z39.50 Implementors' Group, and your strategies for future developments related to Z39.50.

v) Please describe your experience in customising the Tendered System for individual institutions or consortia.

4.1.7.2 Sampling and testing

Describe the Tendered System's facilities for sampling data that:

a) has been added online during a particular period

b) is awaiting offline loading

has been loaded offline and is now on the database.

4.1.7.3 Validation and processing rules

a) What validation does the Tendered System perform on bibliographic, authority and holdings data? What differences, if any, are there between validation performed on data that would be added via the Tendered System's proprietary cataloguing functions and data that would be upline or batch loaded, or added via the Z39.50 Union Catalogue Profile?

b) Describe how NBD Managers could set validation rules for incoming bibliographic, authority and holdings data. Can NBD Managers change the validation rules and actions, without the involvement of programmers or the Tenderer's staff? If so describe the steps involved, and describe what the NBD Managers may not change.

c) Do the data validation processes of the Tendered System allow a data element to be validated against the following criteria:

i. mandatory/optional
ii. repeatable/non-repeatable
iii. numeric/alphabetic
iv. conforming to an input mask specified by an NBD Manager
v. fixed length/variable
vi. only acceptable if containing particular content
vii. if containing a particular content, to be converted to a different content
viii. if empty, to be given a default value?

d) Does the Tendered System perform a Modulus 11 check on ISBNs entered online and received in batch files?

e) Does the Tendered System allow data validation rules to be set for different data types, including the following:

i. different rules for USMARC and other MARC formats
ii. different rules for monograph and serial records
iii. different rules for map and film records
iv. different rules for MARC and non-MARC data?

f) What actions does the Tendered System make when invalid data is found, online and in batch loads? Please give examples of different types of actions, eg non-acceptance of data, flagging for review, warnings.

g) Describe your view of the relationship between validation performed by the NBU server and validation that would be performed by the NBU-authorised Cataloguing Client. How would the Tendered System help ensure that validation rules applied by the NBU Server and the Cataloguing Client were consistent? How would the Tendered System balance this need for consistency with the need to perform validation efficiently and with minimum duplication of validation processes on the NBU Server and the Cataloguing Client?

4.1.7.4 Conversion of incoming data

a) How does the Tendered System support conversion of incoming data? Describe any circumstances in which the Library would be required to arrange pre-conversion of the data.

b) How does the Tendered System support the creation of new or amended conversion facilities to enable the conversion of new data files? To what extent would intervention by the Tenderer's own staff be required?

c) Please give examples of some of the data conversion and mapping that has been performed at data load time by installations of the Tendered System.

4.1.7.5 Duplicate resolution; matching and merging

a) Describe how the Tendered System would detect and resolve duplicates ie, how it would decide whether a record described the same item as other record(s). Include a full list of the MARC fields and sub-fields used in comparing the records.

b) Describe any particular capabilities that the Tendered System offers in relation to serial duplicates, to minimise, for instance, cases where successive title records were incorrectly reported as duplicates.

c) Is the Tendered System's duplicate detection and resolution facility available for all Tendered data contribution methods, including online contribution? Please describe any differences between the duplicate processing that would be applied to the various data contribution methods.

d) How does the Tendered System indicate the reliability of the software's decision that two records are duplicates?

e) What actions does the Tendered System take when:

i. A record is identified as a definite duplicate
ii. A record is identified as a possible duplicate

f) Can NBD Managers specify changes to the data elements to be used in duplicate detection (eg 'stop including date of publication and start including edition statement') and change the rules and actions without the involvement of programmers or the Tenderer's own staff? If so describe the steps involved, and describe what the NBD Managers may not change.

g) If the Tendered System allows duplicate records to be merged, how does it do this? What options would be available to NBD Managers to set rules for merging?

h) If the Tendered System permits duplicate records, how does it assist the user to recognise the duplicates?

4.1.7.6 Batch data loading

a) Describe any restrictions on the addition of new databases (eg LCNA) to the Tendered System.

b) Describe any restrictions on the definition of new types of data into the Tendered System, eg non-MARC data, image data.

c) Given the variety of sources of data for the NBD, it seems unlikely that any Tendered System will already have load tables for all of them. The Library's preference is for NBD Managers to be able to establish and edit load tables themselves, without the need for intervention from programmers or from Tenderer's specialised staff. Describe the process by which new formats would be defined for loading to the system. Please indicate the extent to which the loading of new data sources would be under the control of NBD Managers.

d) What, if any, charges are involved for the following:

i. loading data from a new source to an existing database, eg loading Malaysian MARC to the NBD?
ii. establishment of a new database, eg LCNA, or a register of manuscript collections?
iii. changes to the data load rules?
iv. regeneration of a database's indexes?

e) Under what, if any, circumstances would you recommend that a file be loaded during off-peak use of the system?

f) How much time would normally elapse between the loading of a record and the complete indexing of that record? Describe any circumstances in which partial indexing (eg indexing of control numbers only) would occur.

g) How many bibliographic records per hour would the Tendered System normally load where (a) all records in the file were new ie adds, and (b) records in the file were updates ie some adds, some changes and some deletions? Under what conditions would these load rates slow down?

4.1.7.7 Quality control and human reviewing

a) Describe how a cataloguer at a Contributing Library could flag a record, and attach a message to it, so that it came to the attention of an NBD reviewer. If the cataloguer wished to flag records as possible duplicates for the attention of NBD Managers, describe how that would work.

b) If NBD Managers attach messages to reviewed bibliographic and authority records and 'return' them to a cataloguer at a Contributing Library, describe how this is done.

c) Describe how files of records awaiting review are presented, including the fullness of the record displays and the order of records within the file. Describe how NBD Managers could move through and sample a file selected for review (eg skipping to a record part way through the file).

d) What online commands are available to an NBD Manager who is reviewing a file of records?

e) Which, if any, of the following actions can be performed by an NBD Manager after reviewing possible duplicates:

i. add the incoming record to the database as a new record
ii. reject the incoming record, but load any holdings data that is attached to it to the existing record
iii. replace an existing record with the incoming record
iv. pass the pair of records to an automated quality check process
v. merge the records, eg retain the existing record but add MeSH headings from the incoming record to it?

f) If the Tendered System allows NBD Managers to compare more than one database record with an incoming record, describe the steps involved.

g) If the Tendered System allows NBD Managers to call up a database record that has not been reported by the duplicate detection software, and include it in the duplicate removal process, describe the steps involved.

h) What reports on the quality of incoming records are provided? What parameters can be set for measurement of the quality of incoming records? Does the Tendered System assign incoming records a weight in terms of completeness (based on which attributes are included), and accuracy (based on the number of invalid data conditions) and adherence to standards (based on factors such as having all headings linked to verified headings)?

4.1.7.8 Global changes

a) Describe the global change facility of the Tendered System. Provide an example of a complex global change that can be performed on the Tendered System.

b) List examples of any cases where the Tendered System does not allow data to be subjected to global change.

c) Describe the information and warnings provided before a global change is finalised eg notification of the number of records that would be changed, display of at least some examples of the effect of the change, simulations.

d) Does the Tendered System allow global changes to be reversed, and if so how? Under what circumstances could a global change not be reversed?

e) Does the Tendered System allow NBD Managers to:

i. change MARC tags and sub-fields eg field 047 to 048, sub-field z in field 019 to sub-field x
ii. specify that the change will be case dependent
iii. perform more than one change to be specified for a group of records at a single time?

f) How does the Tendered System ensure good performance when massive global changes to searchable data elements (eg a change to a major Contributing Library's NUC symbol in the holdings data) are performed?

4.1.7.9 Cataloguing

a) Please provide screen prints, or a demonstration diskette, or a telnet address of a demonstration system, or equivalent, so that the Library's evaluators may view some typical online work forms that a cataloguer would use to input new bibliographic, holdings and authority records. This should include examples of variant types of work forms eg if different work forms are available for serials, music, non-Roman script etc.

b) To what extent are these work forms customisable:

i. system-wide by NBD managers
ii. to individual preferences by cataloguers?

c) To what extent can the work forms be set by NBD Managers to contain default data, such as a default of 'm' in Leader 06 if a work form for computer files is used?

d) To what extent could cataloguers set default values for particular data elements? Could they save the defaults across sessions? Could they set defaults for a particular session eg set the contents of a series field?

e) Describe how cataloguers would input less-common fields ie, fields that are not normally displayed on the work form.

f) Describe how a cataloguer would input diacritics and special characters.

g) How much time would normally elapse between a cataloguer completing the input, change or deletion of a record and:

i. the availability (or deletion) of the data in displays for other system users
ii. the completion of indexing or re-indexing of the record?

h) What, if any, cataloguing tools could the Tendered System mount, such as the USMARC place and language codes, Library of Congress Name authorities, and the Dewey Decimal Classification Scheme. Describe any cut and paste or similar facilities that could be used to transfer data from a cataloguing tool to the record that a cataloguer is working on.

i) Does the Tendered System spell check cataloguing? If so can it be turned off and by whom?

j) Describe how a cataloguer could transfer a single record from an external system to the NBD. Would this process be limited to external systems that supported Z39.50?

k) Does the Tendered System allow cataloguers to view search results from multiple databases, for example to compare MARC displays of the same record on the NBD and another database? If so please describe.

l) If a cataloguing session is terminated abnormally, how much work could the cataloguer lose?

m) Does the Tendered System support non-MARC cataloguing? If so describe.

4.1.7.10 Holdings

a) Please provide screen prints, or a demonstration diskette, or a telnet address of a demonstration system, or equivalent, so that the Library's evaluators may view some typical work forms used for the input, change and deletion of holdings data on the Tendered System.

b) How does the Tendered System prevent staff members from one Contributing Library changing or deleting the holdings data input by another library?

c) If the Tendered System supports transfer of attached holdings from one bibliographic record to another, describe the steps involved.

d) If the Tendered System allows Contributing Libraries to code incoming holdings details as requests to delete an existing holding if a match is found, describe how this works.

e) If the Tendered System finds, when batch-loading holdings data, that holdings for the Contributing Library already exist attached to a matching bibliographic record, what processing options are available? For instance, would NBD Managers be able to specify for a particular file of holdings data that the incoming holdings should replace the existing holdings, or be added to them, or be rejected?

f) In relation to requirement 4.1.6.10 (h) to copy holdings to other bibliographic records, cataloguers may wish to use this facility for large sets such as microform collections. Are there any limits to the number of records involved? Could cataloguers copy holdings to any retrieved subset of the NBD?

4.1.7.11 Authority Control

a) Does the Tendered System allow authority files to be stored separately, unlinked to the bibliographic database?

b) Does the Tendered System allow authority records to exist without any linked bibliographic records? If so describe how NBD Managers could delete such authority records, if they wished to (eg through global deletion).

c) Does the Tendered System allow cataloguers to record that an authority record has been checked or "verified"? If so, how is the information that the record has been verified used by the Tendered System? Can it, for example, be used so that a Customer Library ordering authority records can exclude unverified records?

d) How would the Tendered System support an environment where the primary authority file was an Australian authority file, based on LCSH/LCNA but with some Australian preferred forms and references? In your description of any such support please cover: workscreens, matching of incoming authority records, and selection and output of authority records to Customer Libraries.

e) Does the Tendered System provide an option for a cataloguer to transmit a failed search on the NBD authority file to LCNA or LCSH, without rekeying the search? If so please describe.

f) What does the Tendered System do if an incoming file contains an authority record for a term which exists as an unpreferred term in the database? If the Tendered System allows unpreferred terms to be mapped to preferred terms automatically at load time, how does the system report on occurrences of incoming unpreferred terms?

4.1.7.12 Searching

a) Are search menus offered? List any commands that searchers would need to learn.

b) If the Tendered System provides different search capabilities for general staff in Customer Libraries and NBD Managers, please describe the differences.

c) How does the Tendered System offer assistance to a searcher whose search has retrieved no records?

d) How does the Tendered System offer assistance to a user whose search has retrieved a large number of records?

e) Please provide screen prints, or a demonstration diskette, or a telnet address of a demonstration system, or equivalent, so that the Library's evaluators may view the following screens from implementations of the Tendered System:

i. search menus (not necessarily all search menus, a sample of 2 or 3 is sufficient)
ii. results of a search retrieving a single bibliographic record
iii. results of a search that retrieved over 5 bibliographic records
iv. a 'long display' of a bibliographic record
v. a display of holdings data
vi. a MARC format display of a bibliographic record and an authority record
vii. a typical help screen.

f) Describe the ways in which these screen displays can be varied by NBD Managers, and by individual users for their own sessions.

g) How can a searcher move through displays that are greater than one screen length (eg scroll, issue a 'next screen' command)?

h) Which data elements (eg title, series, notes) are searchable as a phrase match (eg "gone with the" retrieves "Gone with the wind")?

i) Which data elements are searchable using keywords (eg 'wind gone' retrieves 'Gone with the wind')?

j) List the types of data elements that can be searched in the following searches, and describe any limits on the number or content of indexes that would be provided by the Tendered System for:

i. phrase searches
ii. short title searches
iii. keyword searches, and
iv. a searches that limits a previous search.

k) If the Tendered System offers keyword searching across the entire record, proximity searching, and exact match searching on diacritics, special characters and upper/lower case, describe how these functions are supported in database management terms. Are special indexes created to support these searches?

l) Do any of the following types of searches have typically slower response times than other searches; if so please quantify the slowness:

i. Boolean searches
ii. searches containing particular Boolean operators
iii. keyword searches, including keyword searches across the entire record
iv. cross-database searches
v. limiting searches
vi. truncated searches
vii. proximity searches
viii. range searches
ix. searches for exact matches on diacritics, special characters, punctuation and upper/lower case.

m) Are the following types of terms searchable on the Tendered System:

i. single alphabetic characters
ii short words?

n) How does the Tendered System support searching on words that include diacritics, special characters, punctuation and upper case and lower case characters? Please indicate which of the following example searches can be performed on the Tendered System:

i. eleve retrieves both eleve and élève
ii. oeuvre retrieves both oeuvre and oeuvre
iii. cant retrieves both cant and can't
iv. c retrieves c and C and C+ and C++
v. act retrieves both act and A.C.T.
vi. cant retrieves cant but not can't
vii. C+ retrieves C+ but not C or C++
viii. A.C.T. retrieves A.C.T. but not ACT or act
ix. thé retrieves thé but not the.

o) Describe how the Tendered System ensures reliable retrieval by ISBNs, ISSNs and ISMNs, despite the presence or absence of hyphens within these numbers, and upper case and lower case Xs.

p) Could the Library specify that there be no stopwords in its implementation of the Tendered System? If so, what in your view would be the disadvantages of having no stopwords?

q) Please provide your recommended stopwords list, if one exists.

r) Does the Tendered System allow case-sensitive definition of stopwords?

s) Describe, with examples, how proximity searching works on the Tendered System. Include a description of options for positional proximity eg find 'Department' preceding, and within two words of, 'Transport'.

t) Describe how the following types of truncation searching works on the Tendered System:

i. right hand truncation eg metamorph#
ii. left hand truncation eg #ethylene
iii. wild character searching eg wom#n

u) Are search terms automatically truncated in any circumstances?

v) Describe the Boolean search functions of the Tendered System. Which Boolean operators are supported? Describe any limits or problems likely to be encountered by searchers using Boolean searching eg longer response times, limits to the number of search terms that may be entered.

w) Does the Tendered System allow searchers to reference previous searches, and to combine previous searches using all the Boolean operators supported by the Tendered System?

x) In what order are search results sorted? Can users choose the order in which search results are sorted? If so, what sort-order options are available? What parameters related to sort order can be set by the manager of the Tendered System? Is relevance ranking supported? If so on what criteria is relevance calculated?

y) If the Tendered System supports apparently simultaneous searches across multiple external databases, describe how this works. What is your recommended maximum number of databases in an apparently simultaneous search?

z) If the Tendered System allows cataloguers to set scripts for sequential searches eg 'for bibliographic records, search the NBD first; if no hits search RLIN: if no hits search OCLC...', describe how this works.

aa) What is the most common complaint made by present users of the Tendered System about the searching functions?

4.1.7.13 Links within the NBD

a) Describe how holdings data is linked to bibliographic data in the Tendered System.

b) Describe how headings in bibliographic records are linked to authority headings, and vice versa. When a cataloguer changes an authority heading that is linked to, for example, many thousands of bibliographic records, how much time would typically elapse before all the linked bibliographic records were updated? Would these changes in the bibliographic records result in each bibliographic record's date-of-latest-update being changed?

c) Does the tendered software support links between data dealing with the same intellectual work (eg a textual work that appears on CD-ROM, microform and paper); and between bibliographically different but related works (eg different editions of a work, the film of a book, or a conference paper and the published conference proceedings)? If so describe how the links are made, stored and used.

d) Does the Tendered System support links between bibliographic records, table of contents data, abstracts, and full document data? If so describe how the links are made, stored and used.

e) Does the Tendered System support links between former and later serial titles? If so describe how the links are made, stored and used.

f) What link rules and validation does the Tendered System use? eg a rule preventing the deletion of an authority record if a bibliographic record is still linked to it, a rule preventing removal of a bibliographic record if a holdings record is still linked to it.

4.1.7.14 Links with external databases

a) Describe how the Tendered System would:

i. allow a searcher to search the NBD and then forward a search that had not retrieved the required records to an external target or targets
ii. allow a searcher to navigate from holdings to shelf-status details on an external target
iii. allow a cataloguer to import data identified on external systems into a work form to be updated
iv. allow a cataloguer to copy data identified on external systems as the basis of a new record.

b) Describe how the Tendered System could ensure that, when a cataloguer searches an external database via the NBD and retrieves copy cataloguing from that external database, a copy of the cataloguing record is added to the NBD?

c) Which version of Z39.50 does the Tendered System support? Which of the Z39.50 extended services does the Tendered System support?

d) Which versions of Z39.50 can the Tendered System communicate with? How much work is involved in setting parameters to allow the Tendered System to search other Z39.50 compliant databases?

e) Does the Tendered System support Z39.50 "broadcast searching" If so describe how it works. If records for the same item are retrieved from multiple systems, how are these duplicates resolved?

f) Describe the differences, if any, in search effectiveness between searches performed on the NBU using the Tendered System's native search software, and searches performed on the NBU through Z39.50.

g) What in your view are the limitations, if any, of using Z39.50 to access other databases from the Tendered System?

4.1.7.15 Output of cataloguing products

a) Does the Tendered System allow data to be output in a different format to that in which it was provided eg a record provided in USMARC format may be output in a tagged and delimited ASCII format; a user might wish to request an APAIS record to be output in USMARC format for loading into a local library system; bibliographic data provided by a publisher in SGML format may be enhanced on the system by cataloguers at a later stage and output in USMARC format?

b) What options are available for a Customer Library to specify that alternative views of NBD data should be delivered in cataloguing products? eg

i. a choice of Pin Yin Romanisation or Wade-Giles Romanisation
ii. a choice of Australian views of authority headings or pure LCSH views
iii. a choice of thesaurus eg include LCSH and MeSH headings in bibliographic records output, or MeSH only.

c) Describe how Customer Libraries can browse NBD records that they have selected for output. How can they move through a file of selected records (skip 'n' records etc.)?

d) Can a Customer Library view potential charges for an output request before delivery? If so, describe how the Tendered System's facility for output of cataloguing products facility would access charging information and apply it to a particular output request.

e) Describe how a Customer Library would place a standing order for cataloguing products. Can the Tendered System accept Persistent and Periodic Queries (as defined by Z39.50 Extended Services)? If so, describe the extent to which these could be used to manage orders for cataloguing products, including standing orders.

f) Some Customer Libraries wish to be alerted when a bibliographic record to which they have attached holdings undergoes a substantial upgrade, or wish to have such upgraded records included automatically in their next delivery of MARC records. Describe how the Tendered System could meet this need.

g) Although the Library wishes to allow users to search the NBD through Z39.50, the Library wishes to be able to control the distribution of MARC records from the NBD ie to monitor for billing purposes, or possibly to restrict to authorised users, the extraction of MARC records from the NBD through Z39.50 search and present functions. How would the Tendered System meet this requirement?

h) Are all the options available for output of bibliographic records also available for authority records? Describe any differences.

i) If the Tendered System also supports citation data, could this be output as products for Customer Libraries? What would be the options for its selection, formatting and delivery? Customer Libraries may wish to place standing orders such as 'As APAIS citation data is loaded for each issue of journal x (which my library holds) include that citation data in my next delivery of cataloguing product data'. How would the Tendered System meet that type of requirement?

4.1.7.16 Creation and maintenance of Australian ISSN data

a) How would the Tendered System support the creation and maintenance of ISSNs for Australian serials?

b) If you wish to recommend any alternative solution, under which for instance ISSN creation would be performed on an external system that interfaced with the Tendered System, please describe it.

4.1.7.17 Activity logging and reports

a) What reports does the Tendered System provide? To what extent can they be customised? How would a user order customised reports?

b) Could the Tendered System report the number of bibliographic records created by a Contributing Library that were detected as duplicates at load time? (Such a facility could be used to prevent credits being awarded for duplicate records). If so please describe.

c) There is a trend for Contributing Libraries to outsource some of their cataloguing. Describe any reports that the Tendered System could produce that would allow a Contributing Library to track cataloguing performed on the NBD by an outsourcing agency separately from the cataloguing that may have been performed on the NBD by the Contributing Library's own staff.

4.1.7.18 General technical questions

a) In addition to the above questions, Tenderers are required to answer all questions in Sections 5.10.1-5.10.13, as applicable to this configuration.

4.1.8 Links to Other Configurations

a) The National Bibliographic Utility will be required to link to the National ILL Utility (Configuration #4), the Administrative Support System (Configuration #5), and the Integrated Library Management System (Configuration #6). In later stages of the Networked Services Project it will be required to link to an Interlibrary Loan and Document Delivery System, a Database Hosting System, and a Digital Object System. The Library places a high priority on the Tenderer's conformance to standards, and willingness to work with other system providers, to ensure that these links will function well. Tenderers should explain how they would implement the links between the NBU and the Configurations and stages listed above.

b) When all Stages of the NSP are complete, the Library wishes to deliver to users the maximum practical integration, from the users' point of view, of the following processes:

i. Identification of a required article, on the Database Hosting System
ii. Identification of the bibliographic description and location of the library material that contains the required article, on the National Bibliographic Database
iii. Initiation of the request for that article
  1. iv. Receipt of the article, as paper or electronic copy.

Describe the features of the Tendered System that would support this.

4.1.8.1 Links with the Cataloguing Client

As set out in this Section and the Cataloguing Client Section, the Library requires the NBU to comply as a target of the Union Catalogue Profile of the Z39.50 Extended Service for Update, and requires a Cataloguing Client to comply as an origin of the Union Catalogue Profile of the Z39.50 Extended Service for Update. If the Tendered System does not meet these requirements, please describe any plans and schedule you have to meet them, and the extent of integration you can offer in the meantime.

If you envisage any other method of implementing standard interfaces between cataloguing clients and the NBU, please describe them.

4.1.8.2 Links with the National ILL Utility

a) Users of the National Bibliographic Utility will, having found on the NBD the bibliographic and location data for an item they want, want to copy that data into a request form on the National ILL Utility. Describe how the Tendered System would support this link.

b) Users of the National ILL Utility, who have created an ILL request on the National ILL Utility will want to copy location data from the NBD into that request. Describe how the Tendered System would support this link

4.1.8.3 Links with the Administrative Support System

a) The Library's preference is for users of the National Bibliographic Utility and of the National ILL Utility, and eventually of the other stages of the NSP, to be registered once, in a way that would allow their passwords, authorisations, groupings etc to be set up in a single session, and would allow, for example, a user to use the same password to search the NBD and the Hosted Databases. This could involve acceptance by the National Bibliographic Utility system of user registration data created on a separate system ie on systems tendered as Configuration #5. Alternatively it could involve using the user registration and billing facilities of the National Bibliographic Utility as a central user facility for all other configurations. Describe the best solution you could offer to meet this linking requirement.

b) Reports of transactions made on the National Bibliographic Utility will need to be output in a form that could be used to produce invoices, probably by passing the reports to the Administrative Support System (ie to the system accepted as Configuration #5). The types of reports sought are listed under "Reports". Describe the features of the Tendered System which would help ensure that its activity reports would be acceptable by an external billing system.

4.1.8.4 Links with the Database Hosting System

a) When the Database Hosting System is implemented, its users will, having identified, for example, the citation to a particular journal article of interest, want to find out which Australian libraries hold that journal, and then initiate a request for the article. One method of meeting this requirement would be for the National Bibliographic Utility System to receive from the Database Hosting System inquiry transactions that quote an ISSN or other data elements such as title and publisher name and the Database Hosting System to accept a response containing the bibliographic and holdings data for that ISSN etc. Other methods could involve mirroring the NBD on the Database Hosting System, or implementing the Database Hosting System as part of the NBU. Describe your recommended method, and describe how it would be implemented.

b) Users of the Database Hosting System and the National Bibliographic Utility will sometimes wish to point a search at both the NBD and some or all of the hosted databases. Describe how the Tendered System would support this link.


Return to Start or Continue to Chapter 4-2
About This Site | Copyright | Privacy | Accessibility | Site Map | Site Search | Content A-Z | Contact Us