|
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
|
|
Introduction
Throughout Europe, international, national, regional and local initiatives are investing significant public and private sector funding to enable access to a range of cultural heritage resources through digital channels. The motivations and drivers for these initiatives may vary widely: they may encompass different types of resources, address different audiences and aim to contribute to distinct social and economic objectives.
However, the various agencies supporting 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 standards, 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 guidelines is often a first step in seeking to ensure conformity within a programme. This document seeks to provide some guidelines for the use of standards - primarily technical standards. It is intended primarily as a resource for policy-makers, and for those implementing funding programmes for the creation 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 different programmes will take different approaches to conformance with guidelines. Rather, this document 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 document are based directly on those presented in that document.
As noted in that document, the usage of these guidelines cannot guarantee ‘interoperability’: the precise requirements for usefulness, portability and durability of digital resources will vary from programme to programme, and the form in which standards are deployed by individual projects will reflect those requirements. Further, while the guidelines provided by this document are intended to be generally applicable, each programme will operate within a context where projects are required to conform to the constraints and standards determined by many parties (institutional, programme-wide, sectoral, regional, national, international). For example, public sector funded programmes may fall within the scope of standards mandated by national governments, or it may be desirable 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 standards 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 consistency that makes interoperability possible. A high level of consistency 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 development complex, costly and at best unreliable, if not impossible. In addition, the process through which standards themselves are developed means that they capture 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 example is a standard such as the TCP/IP set of protocols, maintained by the Internet Engineering Task Force (IETF)
- de facto – not formally recognized by a standards body but nevertheless widely used, and recognized as a standard by its users. An example is a file format used by a software product that has a dominant or large share of the market in a particular 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 characteristics of a standard, and the EMII-DCF Framework Report highlights three aspects of primary interest to the user of a standard:
- open access (to the standard itself and to documents produced 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 programmes. 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 language 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 consequences, 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 readily find or use what is most appropriate to their needs, because it is not described adequately, 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 outmoded practices.
- Funding agencies. They have to pay for redundant, fragmented effort, for the unnecessary repetition of learning processes, for projects that operate less efficiently than they should and deploy techniques 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 activities within these different stages and indeed some of the stages may not be strictly sequential.
- Preparationfordigitisation
- Handling of originals
- The digitisationprocess
- Storage and preservation of the digital master material
- Metadatacapture
- Publication
- Disclosure
- Reuse and re-purposing
- Intellectualproperty and copyright
1.5 Requirementlevels
The approaches taken to conformance to standards and guidelines vary between programmes, along a spectrum from encouraging the adoption of good practice to mandating conformance to standards as a condition of grant award. Typically the standards and guidelines adopted by programmes encompass different 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 example, because those standards are still in development. Projects should maintain and demonstrate awareness of these standards and their potential applications.
The distinction between requirements and guidance is typically made within the context of a particular programme and the intention here is to provide a foundation document for use within many different programmes.
Within the context of the standards and guidelines for a specific programme, however, the authors of guidelines for the use of technical 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 guidance as an absolute requirement, but the full implications need to be understood and the case carefully weighed before it is disregarded. ‘Should’ has been used in conjunction with technical standards that are likely to become widely implemented during the lifetime of the project but currently are still gaining widespread 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 developed.
This vocabulary is based on terminology used in Internet Engineering Task Force (IETF) documentation. Those key words are used in the remainder of this document. Within the context of the standards and guidelines for a specific 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 conventions to convey this.
IETF RFC 2119 Key words for use in RFCs to Indicate Requirement Levels
http://www.ietf.org/
|
|