minerva homepage

  About Minerva  
  Good practises  
  Competence centres  
  Digitisation guidelines  
  European and national rules on the Web Applications  

home  |  search  |  map  |  contact us  

Path: Home | Publications | Technical Guidelines | Table of contents | Introduction


Interoperability and service provision centres Working group

Technical Guidelines
for Digital Cultural Content Creation Programmes
Version 1.0: Revised 08 April 2004

This document has been developed on behalf of the Minerva Project by UKOLN, University of Bath, in association with MLA The Council for Museums, Libraries & Archives

cover of  handbook


Throughout Europe, internation­al, national, regional and local initiatives are investing signifi­cant public and private sector funding to enable access to a range of cultural heritage resources through digital chan­nels. The motivations and drivers for these initiatives may vary widely: they may encompass dif­ferent types of resources, address different audiences and aim to contribute to distinct social and economic objectives.

However, the various agencies sup­porting digitisation programmes typically share a common concern of seeking to maximise the value of their grant awards, by requiring that the content produced should be as widely useful, portable and durable as possible. These qualities are encapsulated within the notion that resources (and the mechanisms through which resources are accessed) should be ‘interoperable’.

The key to such ‘interoperability’ is to ensure consistency of approach to the creation, management and delivery of digital resources through the effective use of stan­dards, the rules and guidelines that codify good practice. Digitisation programmes already recognise the value of standards, and the adoption of a shared set of technical standards and guide­lines is often a first step in seeking to ensure conformity within a pro­gramme. This document seeks to provide some guidelines for the use of standards - primarily techni­cal standards. It is intended prima­rily as a resource for policy-makers, and for those implementing funding programmes for the cre­ation of digital cultural content.

1.1 The purpose of this document

It should be emphasised from the outset that it is not the intention of this document to impose a single prescriptive set of requirements to which all projects must conform. It would be impossible to create a single document that captured all the context-specific requirements of many different programmes, and it is recognised that differ­ent programmes will take differ­ent approaches to conformance with guidelines. Rather, this doc­ument seeks to identify those areas in which there is already commonality of approach and to provide a core around which context-specific requirements might be built. In this sense the scope and emphasis is similar to that of the EMII-DCF Data Capture Model, and indeed several of the recommendations in this docu­ment are based directly on those presented in that document.

As noted in that document, the usage of these guidelines can­not guarantee ‘interoperability’: the precise requirements for usefulness, portability and dura­bility of digital resources will vary from programme to pro­gramme, and the form in which standards are deployed by indi­vidual projects will reflect those requirements. Further, while the guidelines provided by this doc­ument are intended to be gen­erally applicable, each pro­gramme will operate within a context where projects are required to conform to the con­straints and standards deter­mined by many parties (institu­tional, programme-wide, sectoral, regional, national, inter­national). For example, public sector funded programmes may fall within the scope of stan­dards mandated by national governments, or it may be desir­able to share data with services themselves operating within a published standards framework.

Further, even within the lifetime of a programme, the technological environment changes and stan­dards evolve. Programmes should maintain awareness of all ongoing standards developments relevant to their operating context. It is important that programmes also provide additional support for projects in the form of an advisory service that can offer guidance on the interpretation and implementation of standards and guidelines, and that ensures that the recommendations in those standards and guidelines are updated to reflect significant developments.

1.2 The role of technical standards

The EMII-DCF Framework Report highlights the definition of a standard used by the British Standards Institution (BSI):

A standard is a published specification that establishes a common language, and contains a technical specification or other precise criteria and is designed to be used consistently, as a rule, a guideline, or a definition. Standards are applied to many materials, products, methods and services. They help to make life simpler, and increase the reliability and the effectiveness of many goods and services we use.

The appropriate use of standards in digitisation can deliver the con­sistency that makes interoperabili­ty possible. A high level of consis­tency across the digital resources made available by multiple providers means that a tool or service operating across those resources needs to handle only a limited number of clearly specified formats, interfaces and protocols. In contrast, an ever-increasing number of different formats and protocols would make such devel­opment complex, costly and at best unreliable, if not impossible. In addition, the process through which standards themselves are developed means that they cap­ture good practice based on past experience and enforce rigour in current practice.

Standards are often defined as either

  • de jure– formally recognized by a body responsible for setting and disseminating standards, developed usually through the common consent of a number of interested parties. An exam­ple is a standard such as the TCP/IP set of protocols, main­tained by the Internet Engineering Task Force (IETF)
  • de facto – not formally recog­nized by a standards body but nevertheless widely used, and recognized as a standard by its users. An example is a file for­mat used by a software product that has a dominant or large share of the market in a particu­lar area, such as the Adobe Portable Document Format (PDF).

A further consideration is the “open-ness” of a standard. This can refer to a number of charac­teristics of a standard, and the EMII-DCF Framework Report high­lights three aspects of primary interest to the user of a standard:

  • open access (to the standard itself and to documents pro­duced during its development)
  • open use (implementing the standard incurs no or little cost for IPR, through licensing, for example)
  • ongoing support driven by requirements of the user not the interests of the standard provider.

Taking the scenario above, since the specifications of the formats, interfaces and protocols used by resource providers are openly available, multiple developers can develop similar tools and services and dependency on a single tool or platform can be avoided.

Generally, the formal processes associated with the development of de jurestandards are regarded as ensuring that such standards are genuinely “open”. In these guidelines, preference is given to open standards, but in some cases industry or de facto standards are also considered.

1.3 The benefits of deploying standards

Important areas for consideration include:

  • Interoperability. It is important that content can be accessed seamlessly by users, across projects and across different funding pro­grammes. It should be possible to discover and interact with content in consistent ways, to use content easily without specialist tools, and to manage it effectively.
  • Accessibility. It is important that materials are as accessible as possible and are made publicly available using open standards and non-proprietary formats. If material is to be a widely useful resource it will be necessary to consider support for multiple lan­guage communities and ensure accessibility for citizens with a range of disabilities.
  • Preservation. It is important to secure the long-term future of materials, so that the benefit of the investment is maximised, and the cultural record is maintained in its historical continuity and media diversity.
  • Security. In a network age it is important that the identity of content and projects (and, where required, of users) is established; that intellectual property rights and privacy are protected; and that the integrity and authenticity of resources can be determined.

Failure to address these areas effectively may have serious con­sequences, resulting in the waste of resources by different parties:

  • Users -the citizen, the learner, the child. They will waste time and effort as they cannot read­ily find or use what is most appropriate to their needs, because it is not described ade­quately, or it is delivered in a particular way, or it requires specialist tools to exploit, or it was not captured in a usable form.
  • Information providers and managers. Their investment may be redundant and wasted as their resources fail to release their value in use, as their products reach a part only of the relevant audience, as they invest in non-standard or out­moded practices.
  • Funding agencies. They have to pay for redundant, frag­mented effort, for the unnec­essary repetition of learning processes, for projects that operate less efficiently than they should and deploy tech­niques that are less than opti-mal, for content that fails to meet user needs or does not meet market requirements.
  • Creators, authors. Their legacy to the future may be lost.

1.4 The life cycle approach

This structure of this document reflects a ‘life cycle’ approach to the digitisation process, and (with some modifications) parallels the structure of the Good Practice Handbook developed within Work Package 6 of the Minerva project.

The document is divided into the following main sections, each reflecting a stage in that life cycle. In practice, there are relationships and dependencies between activi­ties within these different stages and indeed some of the stages may not be strictly sequential.

  1. Preparationfordigitisation
  2. Handling of originals
  3. The digitisationprocess
  4. Storage and preservation of the digital master material
  5. Metadatacapture
  6. Publication
  7. Disclosure
  8. Reuse and re-purposing
  9. Intellectualproperty and copyright

1.5 Requirementlevels

The approaches taken to confor­mance to standards and guide­lines vary between programmes, along a spectrum from encourag­ing the adoption of good prac­tice to mandating conformance to standards as a condition of grant award. Typically the stan­dards and guidelines adopted by programmes encompass differ­ent levels of requirement, and it is possible to distinguish between:

  • Requirements: Standards that are widely accepted and already in current use. Projectsmustimplementstandardsthat are identifiedasrequirements.
  • Guidance that represents good practice but for which there may be reasons not to treat it as an absolute requirement, for exam­ple, because those standards are still in development. Projects should maintain and demon­strate awareness of these standards and their potential applica­tions.

The distinction between require­ments and guidance is typically made within the context of a par­ticular programme and the inten­tion here is to provide a founda­tion document for use within many different programmes.

Within the context of the stan­dards and guidelines for a specific programme, however, the authors of guidelines for the use of techni­cal standards should distinguish clearly between requirements (if any) and guidance.

Further, in standards documents, the key words ‘must, should and may’ when printed in bold text are used to convey precise meanings about requirement levels:

  • Must: This word indicates absolute technical requirement with which all projects must comply.
  • Should: This word indicates that there may be valid reasons not to treat this point of guid­ance as an absolute requirement, but the full implications need to be understood and the case care­fully weighed before it is disre­garded. ‘Should’ has been used in conjunction with technical stan­dards that are likely to become widely implemented during the lifetime of the project but cur­rently are still gaining wide­spread use.
  • May: This word indicates that the topic deserves attention, but projects are not bound by this advice. ‘May’ has therefore been used to refer to standards that are currently still being devel­oped.

This vocabulary is based on termi­nology used in Internet Engineering Task Force (IETF) doc­umentation. Those key words are used in the remainder of this document. Within the context of the stan­dards and guidelines for a specif­ic programme, the authors should adapt the requirement levels specified in this document to those of their own contexts; authors should make appropriate use of these key word conven­tions to convey this.

IETF RFC 2119 Key words for use in RFCs to Indicate Requirement Levels



Copyright Minerva Project 2005-07, last revision 2005-07-05, edited by Minerva Editorial Board.
URL: www.minervaeurope.org/publications/technicalguidelines/introduction.htm