Interoperability Across Digital Library Programmes? We Must Have QA!
[ Home Page - Surveys - Documents - Presentations - Search ]
Brian Kelly, UKOLN, University of Bath, BATH, UK, BA2 7AY
B.Kelly@ukoln.ac.uk
Abstract Digital library programmes often seek to provide interoperability through use of open standards. In practice, however, deployment of open standards in a compliant manner is not necessarily easy. The author argues that a strict checking regime would be inappropriate in many circumstances. The author proposes deployment of quality assurance (QA) principles which provide documented policies on the standards and best practices to be implemented and systematic procedures for measuring compliance with these policies. The paper describes the work of the QA Focus project which has developed a QA methodology to support JISC's digital library programmes. A summary of the application of the methodology to support selection of standards and the deployment of deliverables into service is given. The author argues that similar approaches are needed if we are to provide interoperability across digital library programmes.
The need for open standards in order to provide interoperable digital library services is widely acknowledged. In addition to use of open standards there is also a need to make use of agreed best practices in the provision of digital library services.
Although such principles are widely accepted in the digital library community, in practice appropriate standards and best practices are not always used. This can happen for a number of reasons, some of which are legitimate (immaturity of open standards, a lack of tools, etc.) However a failure to use appropriate solutions may be due to inertia on the part of the developer, a failure to understand the need for open standards, a failure to appreciate appropriate architectures for open standards, lack of agreement on a definition of 'open standards' or a mistaken impression that open standards are being used. There is therefore a need to provide a model which seeks to exploit the potential of open standards, but is capable of addressing the challenges this can provide in a flexible manner.
This paper reviews the quality assurance methodology and support materials developed by the JISC-funded QA Focus project which aims to ensure that JISC's digital library programmes are functional, widely accessible, interoperable and can be deployed easily into a service environment. Particular emphasis is given to the application of the quality assurance framework in the selection of standards and the deployment of project deliverables into a service environment.
NOF-digitise is a digital library programme in the UK supported by public funding of about £50 million. The programme funds universities, museums, libraries, etc. to digitise materials from their collections and archives in order to make this cultural heritage available online.
Although organisations with proven expertise in digitisation work were funded, a number had little experience of large-scale digitisation activities. The programme provided a valuable opportunity for public sector bodies to enhance their expertise in this area; expertise which would be valuable in supporting in-house development activities.
The importance of open standards was emphasised from the start. It was a requirement that the projects addressed the need for potential reuse of the resources. In order to support over 150 projects the NOF-digi Technical Advisory Service (NOF-TAS) [1] was established. Early activities of NOF-TAS included producing the NOF-digi Technical Standards and Guidelines document [2] and organising workshops to support the projects. This was complemented by an email support list and a series of FAQs.
NOF-TAS was not responsible for monitoring projects' compliance with the standards. This work was carried out by BECTa. NOF-TAS worked with BECTa in developing a self-assessment reporting procedure. A reporting template was used to allow projects to report on compliance with standards. Projects were expected to document areas in which they were failing to make use of appropriate open standards. It was recognised that there were areas in which open standards would be difficult to implement: e.g. areas in which the standards were immature, with limited availability of authoring tools and poor support for viewers. For example in the area of synchronised multimedia the preferred open standard is SMIL (Synchronized Multimedia Integration Language); however this format is not yet ready for mainstream use. The proprietary alternative many projects preferred was Flash.
In response to such challenges the reporting procedure required projects to document:
It was permissible, for example, to develop an interactive game using Flash; however it would not be permitted to produce an entire Web site in Flash or use Flash to provide site navigation or to use it simply because of availability of in-house expertise in the format. The process is described in a NOF-TAS FAQ [3].
Although the work of NOF-TAS was highly appreciated by the projects and the funders the support model used by the service did have limitations:
QA Focus has been funded by the JISC to support JISC's digital library programmes. QA Focus began its work in January 2002 with funding initially for two years (subsequently extended by 7 months). QA Focus, along with NOF-TAS, is provided by UKOLN and the AHDS (Arts and Humanities Data Service). However QA Focus takes a different approach to NOF-TAS. Rather than providing technical support directly to projects QA Focus has developed a quality assurance methodology to be deployed by the projects themselves. This approach is based on self-assessment; unlike the NOF-digi programme no compliance checking is provided by third parties. The quality assurance methodology is described in section 5.
The QA framework is complemented by its support materials consisting of briefing documents and case studies, together with an online 'toolkit'. Over 60 briefing documents are available which provide focussed advice in various technical areas. The documents provide advice on why particular standards are needed, the advantages and disadvantages of various implementation approaches, common problems and approaches for ensuring compliance with standards or best practices.
The case studies are written by projects themselves. They help in community-building by allowing projects to share implementation experiences. In order to avoid projects using the case studies as a publicity vehicle a template is provided which requires authors to give a brief description of their project, the problem being addressed in the document, the solution used and problems experienced or lessons learnt.
Other important areas which have been addressed include the selection of standards for use by projects and the deployment of project deliverables into service. These areas are summarised in sections 5 and 6.
In addition a series of online toolkits have been developed which provide interactive self-assessment of use of appropriate standards and best practices and a series of surveys of Web sites has been carried out using a variety of testing tools.
Further information on these resources and on the QA Focus project is available from the QA Focus Web site [4].
At the core of the work of the QA Focus project is its quality assurance (QA) methodology. The work is based on well-established QA principles. We feel that in order to provide functional, widely accessible and interoperable deliverables projects need to document their technical policies and implement systematic procedures which ensure that the policies are being implemented correctly. We acknowledge that projects often have limited resources and are subject to tight timescales, so we have developed a lightweight QA methodology.
An example of a technical policy is illustrated below.
Web Access
Standards: XHTML 1.0
Exceptions: Resources derived from MS Office applications may not comply with HTML standards due to the limitations of Microsoft's conversion program.
Implementation Architecture: The Web site uses PHP scripts for processing metadata, navigational bars, etc. PHP template files will comply with XHTML 1.0. Content fragments will be edited with an XHTML-aware authoring tool.
Compliance Checking: When pages are created or updated the author is responsible for running the ,validate tool to ensure XHTML compliance. A batch check of the Web site will be carried out quarterly. W3C's Web Log Analysis tool will run monthly to detect the most widely accessed pages which are non-compliant.
Audit Trails: Reports of the Web Log Analysis tool and the batch audits will be kept.
Addressing Non-Compliance: Page authors are responsible for ensuring their pages are compliant.
Responsibilities: The project manager is responsible for enforcing this policy.
Fig. 1. Example Of A Technical Policy Statement
This policy, together with related policies on CSS standards and link checking, have been implemented for the QA Focus Web site. As can be seen such policies need not be onerous to develop. As well as documenting the standards to be used, the implementation architecture is also described. This will help ensure that an appropriate architecture is used. The compliance checking regime is documented and, in recognition of real-world complexities, details of permitted exceptions are given.
It should be noted that we have implemented a ightweight technique to simplify compliance checking procedures. In particular appending ,validate to the end of any URL on the UKOLN Web site will run the W3C validation program on the page. Similarly appending ,cssvalidate will run a CSS validator, appending ,rvalidate will validate the current pages and pages beneath it, appending ,checklink will run a link checker on the page and appending ,rchecklink will run a link checker on the page and pages beneath it. This simple interface to a range of testing services can be implemented using a simple update to a Web server's configuration file as described at [5].
Although the merits of open standards are widely acknowledged deployment of open standards is not always easy. There will be times when open standards are immature, with limited availability of authoring tools and viewers, or open standards fail to reach critical mass. Even in areas in which open standards are mature we do not always see open standards being used correctly: for example many Web sites are not compliant with the HTML standard. A more complete review of the difficulties experienced in using open standards within digital library programmes is given in [6].
In light of such issues there is a need for a methodology for selecting standards. It would clearly be inappropriate to abandon a commitment to the philosophy of open standards, and yet more forceful mandating of use of and compliance with open standards may well prove counter-productive. The approach taken by QA Focus is the use of a checklist for the section of standards. We have developed a checklist which illustrates the range of factors which should be considered when initially selecting the standards to be used within a project, as illustrated below.
| Area | Issues |
| Ownership | Is standard owned by a recognised open standards body? |
| Development process | Is there a community process for developing the standard? |
| Availability | Has the proprietary standard has been published? |
| Viewers | Are viewers (a) available for free, (b) available as open source and (c) available on multiple platforms? |
| Authoring tools | Are authoring tools (a) available for free, (b) available as open source and (c) available on multiple platforms? |
| Fitness for purposes | Is the standard appropriate for the purpose envisaged? |
| Resource issues | What are the resource implications in using the standard? |
| Complexity | How complex is the standard? |
| Interoperability | How interoperable is the standard? |
| Service deployment | How easy will it be to deploy the deliverable into service? |
| Preservation | Is the standard suitable for long term preservation? |
| Approaches to migration | What approaches can be taken to migrating to more appropriate standards in the future? |
| Measuring compliance | What approaches can be taken to measuring compliance? |
We envisage that projects would complete a checklist and use this to aid the discussions of the standards to be deployed. A record of the issues and decisions made should be kept, which could require approval by an external body but, in other cases, may be documented in project reports without the need for external approval.
Many project deliverables will be expected to be deployed into service. However an easy transition into service cannot always be guaranteed for a number of reasons:
We recommend that projects should provide information about the technical environment, identify potential service environments and have an understanding of issues of concern to services. Projects should make their QA policies available to potential service providers in order to help address possible concerns and facilitate the deployment of project deliverables.
This paper has argued that in order to enhance the interoperability of digital library projects there is a need to deploy quality assurance. QA Focus has developed a pragmatic lightweight QA framework which acknowledges the resource and deployment pressures faced by projects.
We feel the approaches described in this paper will be of interest to other digital library programmes. We welcome the opportunity to explore possibilities of working with other digital library programmes. To support this we are exploring the possibilities of making our resources available with a Creative Commons licence [7].
Acknowledgements: The author would like to acknowledge the contributions made by members of the QA Focus team (Marieke Guy and Amanda Closier, UKOLN and Hamish James and Gareth Knight, AHDS), by Karla Youngs and Ed Bremner, ILRT in the early days of the project and to the JISC for funding this work
[ Home Page - Surveys - Documents - Presentations - Search ]
Web page by Brian Kelly of UKOLN.
Last Modified 6-February-2008
Email comments to webmaster@ukoln.ac.uk