Videre til indhold | Videre til menunavigation

Mine værktøjer

Du er her: Forside / Om biblioteket / Udbud / Delivery and maintenance of a metadata repository for digital preservation

Delivery and maintenance of a metadata repository for digital preservation

Published 2 July 2016, updated 11 August 2016


The Tender for public procurement of

Delivery and maintenance of a metadata repository for digital preservation

Download tender conditions and contract draft as zip files:

Questions regarding this tender shall be submitted by email to Questions and answers will be published on this page as described in the Tender conditions.

Questions and answers



1. We have not found any mentioning of the amount of current and future users of the system. Could you please specify the various user groups and their roles (if beyond your classification stated in Appendix 2A, section 5.2) and the amount of users per user group.

As stated in Appendix 2A, section 5.2 we expect to have four groups of users of the system.

We expect that about 3-7 IT Operations Specialists will need training.

We expect that about 5-12 Software Developers will need training.

We expect that about 10-20 Curators will need training.

Statsbiblioteket's staff will train Third party users individually according to their needs.

When the new System is implemented we expect to have around 50 users in total.

2. We did not see any explicit request to include services for the migration of existing metadata to the new system. Do we assume right, that this work will be done by the Statsbiblioteket themselves?

Yes, migration is expected to be performed by Statsbiblioteket. Knowledge of how to perform this is expected to be obtained during the Pilot Phase.

3. Intellectual Entities:

  • What exactly is your concept? Do you follow the PREMIS definition?
  • Could you please share a real world example?

We follow the PREMIS definition: "An Intellectual Entity is a distinct intellectual or artistic creation that is considered relevant to a designated community in the context of digital preservation".

To that end, in our current system we bundle one or more Metadata Objects as one Intellectual Entity.

For real world examples, in the newspaper collection described in Appendix 2A, section 2.5.1, we have two different definitions of an Intellectual Entity aimed at two different designated communities.

  • One is defined as each newspaper page being an Intellectual Entity. This is used for our discovery platform at For that we bundle the related objects for Newspaper Page (including MODS, MIX, ALTO and ACCESS), Newspaper Edition (including MODS and PREMIS) and Newspaper Title (including MODS and PREMIS) to describe the Intellectual Entity.
  • The other is defined as each newspaper edition being an Intellectual Entity. In that representation we bundle theNewspaper Edition (including MODS and PREMIS) and Newspaper Title (including MODS and PREMIS) together withall Newspaper Page objects of this edition (including MODS, MIX, ALTO and ACCESS) to describe the Intellectual Entity.

4. Metadata Export: You describe: When exporting metadata of Intellectual Entities, changes since last export will be listed.

  • Does this mean, that you currently collect the copies of every export (access copies)?
  • If so, for how long?
  • Is there a housekeeping process?

Metadata for Intellectual Entities is exported from our system on a regular basis. Other external systems may keep the exported copies indefinitely. Housekeeping is entirely up to the other external systems.

An Intellectual Entity should be considered changed if it has been updated or deleted.

One use case we had in mind when writing the requirement was export of metadata to our discovery platform. Our discovery platform has a local cache of metadata and a search index on top of it. The cache is harvested incrementally, which is why we need only Intellectual Entities changed since last harvest. The only context needed to do incremental harvesting is the timestamp of the last exported metadata.

We use the term access copies for derived copies of one or more Data Files, possibly using metadata from our metadata repository to generate those derived files. Our current solution has access copies of Data Files in a separate store, which is not stored into the discovery platform's cache. Generating access copies is a separate process to metadata export. See also Appendix 2A, sections 2.2.6 and 4.1.6.

5. Metadata Rules: You are talking about rules of Metadata for Intellectual Entities.

  • What kind of rules?
  • Could you please share a real world example?

The rules mentioned in Appendix 2A, section 2.2.7, refer to grouping/bundling of Metadata Objects per export target and not metadata rules. An example is two different targets for harvesting audio. This would include different rules for harvesting single tracks or whole albums. See also the answer to question # 3 about Intellectual Entities.

6. Structure of Metadata: You are describing Metadata Records and Metadata Objects.

Is our assumption correct?:

  1. Metadata Record --> one data element
  2. Metadata Object --> 1..n Metadata Record(s)

A Metadata Record can contain multiple data elements, i.e. a MODS record that contains both titleInfo, language, name etc.

A Metadata Object may be a combination of several Metadata Records. For instance a combination of a MIX record, an ALTO record and a MODS record.

7. Appendix 2, Requirement #18: selection of object for spot checks...

Do you mean just to take a  look into the detailed data of a query of metadata or an inspection of the bit repository object?

We want to use the selection of objects in order to perform actions available in the system including, but not limited to, inspecting both metadata and data, performing fixity checks, test migrations etc.

8. Appendix 2, Requirement #57:

What do you mean by an "emulation" of a file?

Emulation is part of Statsbiblioteket's preservation strategy and is performed on collections, if migration is not an option. Emulation refers to imitating the original computer environment to be able to display data correctly.

9. Can we answer Appendix 2B in a Word document and not in an Excel (using the same format)? This will enable us to easily add images and structured text. It will also ease the writing / review process (using “Track Changes”).

Appendix 2B must be answered in Excel, but it is ok to refer to an appendix in the In-depth Description field.

10. Appendix 2, Requirement 88 - the Supplier must provide a training plan describing in detail the contents and schedule of IT Operations Specialists training, as well as the training material provided. Do you want a list of the training material – or copies of all the actual material?

A list describing the training material will be sufficient for the tender.

This will also apply to Appendix 2, Requirements 90 and 92.
11. What’s the difference between Appendix 2, Requirement #74 – “It should be possible to provide limited API access to metadata for Third-Party Users. Describe the options for a limited public API” and Requirement #78 – “The System should provide fine-grained authentication and authorisation for Third-Party Users for API access to metadata”? These two requirements are related, but Appendix 2, Requirement 74 is intended to describe the API, while Appendix 2, Requirement 78 is intended to describe the options on how to control access to the API.
12. Will an archiving solution in the cloud be relevant? As stated in Appendix 2, Requirement 62, the system must be installed and hosted in-house at Statsbiblioteket.
13. I don’t seem to have a ESPD.  Was one included with the other documents? The ESPD is included as Appendix 2 in the Tender conditions and appendices. Completion of the ESPD is done here: and must be downloaded and attached in the updated version.
14. Please confirm if you are happy for us to quote subscription pricing, or whether you had intended to look for a perpetual licence?  Assuming you opt for subscription pricing, please advise how we should complete Appendix 3.

Subscription pricing as well as perpetual licencing is ok. Bear in mind that the tender is evaluated on the cost for the Contracts duration of 4 years when chosing your pricing.

If the subscription pricing is the only cost, just fill out the table section: "Maintenance and ongoing license fee for the first four years (Appendix 4, 5 and 7)". Other costs in connection with procurement of the software must be stated in the table section "Procurement of Software (Appendix 4)".

We must be able to evaluate the total cost of procuring the software for the whole Contract period of 4 years.
15. In Appendix 1 it is slightly unclear of what we need to deliver as part of our tender response and what needs to be provided after contract. We assume that we are providing a high level project plan at this stage and a more detailed plan of the Clarification and Pilot stage will be delivered at the start of the project. We would in the tender response like an overall timetable for the project. The detailed plan of the Clarification Phase can be delivered with the tender response or must be delivered immediately after signing the Contract. The detailed plan for the Pilot Phase is to be delivered after the Clarification Phase.