Request for Tender

Digital Collection Management System

Frequently Asked Questions

This document lists frequently asked questions concerning the National Library's Request for Tender for a Digital Collection Management System. This information is based on questions asked during the Open Briefing Session held on 2 September but also includes answers to questions raised subsequently by potential tenderers. It also includes information already available to tenderers in the RFT documentation. It is provided for clarification purposes. For further enquiries please contact dsp@nla.gov.au.

1. What is the relationship between Group 11 outsourcing and this RFT?

Tenderers should note that the Library is included in Group 11 of the Commonwealth's "Whole of Government" outsourcing program. After acceptance of the System procured through this RFT by the Library, on-going infrastructure support for the System (ie the support for hardware and systems software, as distinct from applications software) may need to be novated or transferred to any service provider appointed through the outsourcing program. More information on outsourcing and its relationship to this Request for Tender is found in Chapter 2 in Section 2.5 and Chapter 3 in Section 3.1.1 of the RFT documentation.

2. What is the relationship between the Library's procurement of a Metadata Repository and Search System and this RFT?

The Library is currently evaluating products which will be used to provide online metadata search services, through a Metadata Repository and Search System Request for Quotation that was released in June 1999. These search services will be based on "resource discovery" metadata such as the Dublin Core. This metadata will be extracted from existing Library systems, the systems of partner organisations or gathered from documents on the web. Sources within the Library for such metadata will include Kinetica (National Bibliographic Database), the Library's Catalogue and the Object Management System configuration within the Digital Collection Management System. Metadata will be transferred from such systems to the Metadata Repository via standard formats such as USMARC or in XML.

The reasons that the Library has chosen to procure a separate Metadata Repository and Search System (MRSS) rather than use a configuration within the Digital Collection Management System (DCMS) for resource discovery services are:

  1. Metadata in the MRSS will come from many source systems and may refer to digital objects not held by the Library which are part of the collections of other cultural agencies.
  2. The Library wishes to clearly separate resource discovery from digital object management and delivery. There are/will be a number of resource discovery services based on Kinetica, the Library's Catalogue, the MRSS and external databases such as Informit Online that may all link to the DCMS to provide access to the Digital Objects themselves.

This relationship is shown diagrammatically in the logical systems architecture diagram in Chapter 1, Section 1.6 of the RFT documentation.

3. How will development of services based on the Metadata Repository and Search System be handled with respect to the implementation of the Digital Collection Management System? Do these systems need to use similar hardware and software?

The Metadata Repository and Search System and the Digital Collection Management System are quite independent systems. NLA will handle development of resource discovery services based on the Metadata Repository and Search System. Some metadata in the Metadata Repository and Search System may be sourced from Digital Collection Management System. The successful tenderer will be expected to be able to report metadata from the Digital Collection Management System in a standard format that can be imported into the Metadata Repository and Search System. This format will be agreed in discussions between NLA and the successful tenderer but is likely to be via an XML file with an agreed Document Type Definition (DTD). The only metadata that is potentially common to both systems is the "resource discovery" metadata which is a small subset of the metadata that will be stored in the Digital Collection Management System in the Object Management System configuration.

After implementation, users who discover the existence of a digital object by searching the metadata held in the Metadata Repository and Search System or other systems such as the Catalogue may navigate to the actual digital object via a link (URL) that points to the Digital Collection Management System.

As the interface between these systems is via metadata (text) files in a standard format such as XML or via URL links, there is no need for the platform, operating system or database software to be the same.

4. What types of sites are causing collecting problems in PANDORA?

The type of sites causing capture problems include those using programs or scripts on the client side written in Java or Javascript and dynamically generated sites where the content often is created "on the fly" out of a database management system. The Library understands that capturing such sites, especially very large database sites, is a difficult technical problem and may not be feasible or practical in all cases. But the Library is interested in solutions available in the marketplace for gathering web content and believes that significant improvements can be made over the current PANDORA system. For further information and technical issues relating to the PANDORA system, see Chapter 8 Section 8.4 and Appendix E in the RFT documentation.

It should also be noted that the market for a system that can be used to capture and archive web sites and electronic publications includes state libraries within Australia and national and state libraries overseas.

To help tenderers better understand the type of sites that have caused callecting problems for the PANDORA archive, the following list is supplied:

5. What does the Library expect from Tenderers in regard to Configuration 4?

Configuration 4 is the Rights Management and Access Control System. Tenderers must respond (even if to say their solution is "non-compliant" with respect to this configuration) to all system configurations and tenderers who provide a good solution for this configuration will obviously be advantaged. However, configuration 4 includes functionality that is believed to be difficult to obtain in the marketplace. Standards for rights management are not yet in place and are being developed at the present time. Therefore the Library may decide not to implement this configuration in its entire scope.

6. What is in scope with respect to the current Images 1 system?

Images 1 is a system based on digital images of items from the Library's Pictorial Collection. These images are scanned by an external contractor employed by the Library. The Images 1 system consists of an Access database for metadata that controls the digital capture workflow, images of low (thumbnail), medium and high resolution and a web based resource discovery/search system. The Access database and the digital images themselves are in scope with regard to the RFT. This data (and metadata) will need to be migrated into the Digital Collection Management System by the successful tenderer.

Please note that the scanning of Pictorial Collection items and the Images 1 resource discovery/search system are not within scope, although collection and item level metadata will need to be supplied from the DCMS to build a web-based resource discovery service for Images 1 using the Metadata Repository and Search System. The metadata will need to be supplied in a standard format using XML.

7. What is the Library's development philosophy? Is it realistic?

As stated in Chapter 1, Section 1.7 of the RFT documentation, the Library would like to "buy not build" where-ever possible. The Library is looking for existing products that can be tailored to meet its needs. The Library understands that several products will be required to meet its needs, for example the Collecting System might be based on commercial web searching/gathering software, whereas the Object Management System may be based on a product that uses a commercial database management system. The Library understands that its requirements are unusual and acknowledges that systems integration work will be required to ensure that all components of the System operate effectively together. The Library does not want solutions that require the System to be built from scratch, based only on say an underlying database management system.

8. Are the Library's estimates of disk space requirements realistic?

On implementation of the System, the disk space requirements for data are quite small (~ 100 GB) and are based on migration of the existing PANDORA systems and the Images 1 management system. Future disk space requirements will depend on the ability to use the System for other types of digital objects such as sound recordings. Data storage space has been modelled based on assumptions that are given in Chapter 9 of the RFT documentation. These space requirements are based on raw data sizes. Vendors are asked to document their own assumptions about how the data will be stored. If compression techniques are proposed for some/all categories they should take into account that master copies of digital objects are stored in a way that they are easily accessible and results in no loss of information (some compression techniques include unacceptable loss of information during compression). Formats for digital objects will undoubtedly continue to develop and change and so space requirements should be seen as estimates only.

Tenderers should supply a System that has the ability to meet the implementation disk space requirements and grow along the lines outlined in Chapter 9. However, the Library reserves the right to not grow the System to its full 5 year capacity dependent upon financial and management constraints.

9. Does the Library have a preferred hardware platform, operating system or database mangement system? Will the Library use existing hardware for the Digital Collection Management System?

The Library believes that a hardware and software solution will be needed and that new hardware will be required to support the Digital Collection Management System. The System will need to be able to interface with existing Library systems, for example for transfer of metadata. The Library does not have a preferred platform, operating system or database mangement system. The Library believes that the functional requirements and available application solutions should drive the choice of hardware, operating system and database management system that are recommended by tenderers.

10. Since Images 1 and Pandora are on a Microsoft Access database, can you provide: (a) a copy of the file format/record layout; (b) a sample subset of both databases in order to prototype file upload to other databases?

The Library is unable to provide this data in a form that would be useful in time for potential tenderers to make use of it before tenders close. We can, however, provide the following additional information to help potential tenderers size and scope the data migration requirement. Data needing to be migrated to the Object Management System to support the new Permanent Digital Archive will be derived from five sources:

Data needing to be migrated to the Object Management System to support the new Pictorial Manager Sub-System will be derived from four sources:

The Library will take responsibility for extracting this data from the existing data sources, doing any required conversions and data cleanup, mapping the values to the entity-attribute combinations in the Logical Data Model and providing this data in a standard interchange format to be agreed with the successful vendor. The Library will also provide a full Data Dictionary for the Logical Data Model based on the ISO 11179 international standard for Information Technology - Specification and standardisation of data elements (1994). Work is already well-advanced on this task.

It will be the responsibility of the successful vendor to map the data to the internal storage format proposed for the Object Management System. Vendors should include in their proposals a task to review the data requirements with Library staff before data migration commences. This task should be identified in the project plan and the cost of the task itemised in Configuration Cost Schedule 5 - Data Migration.

11. We are either unable or unwilling to meet all the compliance terms of the contract and would appreciate your advice as to whether there is room to negotiate on several terms and conditions, or whether this disqualifies the tender?

The contract as supplied in the RFT documentation is a draft. Terms and conditions of the contract are subject to negotiation during the contract negotiation period that will occur at the end of Phase 2 of the evaluation of tenders as described in Section 2.4.2 of the RFT documentation.

12. As we were not involved in the Request For Information stage for various reasons, we are concerned that we may not be able to prepare a full and final bid to our own internal quality control standards by Monday 18th October 1999 at 2 pm.

An Information Paper regarding the Digital Services Project was released in December 1998. This paper has been available on the Library's web site since that date. The RFT was released on 23 August 1999 with eight (8) weeks for responses. The Library considers that this should be enough time to respond.

13. We have difficulty in translating the range of requirements into a deliverable design at bid phase. We have a proposed project methodology to clarify the accepted deliverables, time and costing. Would a fixed cost bid for Phase One - design stage and a contingent cost for Phase Two - completion be acceptable?

The Library would prefer a fixed cost bid for the entire project to enable it to better understand its financial commitment and to allow costs between bids to be effectively compared.

14. As we build the pricing model we wonder whether our proposed bid is within budget. If the total cost is over budget, would the library discuss scaling down components, removing requirements or would this result in automatic disqualification of the bid?

The Library is not willing to reveal its budget for this project. If the total cost of a bid is over the Library's budget, this will not lead to automatic disqualification of the bid. The Library reserves the right to scale down components or remove requirements to match a bid to its budget if necessary.

15. One area of cost is software licensing. Are we right in interpreting the number of licences as approximately 10 indexers or cataloguers internally and 250 concurrent users externally by December 2000?

The Library's estimates of concurrent users for each system configuration are given in Section 9.2 (Performance Requirements) of the RFT documentation. Our estimate of the peak load of concurrent users (indexers and cataloguers) for the Object Management System is based on the current maximum number of users of the Library's ILMS. Please use the figures in Section 9.2 to provide cost estimates in your bid. Please also indicate any volume-based licence cost increments or formuli and the basis of licencing so that the Library can consider the cost impact of any reduction in the number of concurrent users of the System.

About This Site | Copyright | Privacy | Accessibility | Site Map | Site Search | Content A-Z | Contact Us