• Register
• Key Dates
• Schedule
• Local Info

April 11-14, 2007
San Francisco, California

Addressing The Limitations Of Open Standards

Background

The importance of open standards for those involved in the development of widely accessible and interoperable services in the cultural heritage sector is generally accepted. Open standards are on the whole regarded very positively by public sector organisations. Why, then, isn’t use of open standards ubiquitous?

It could be argued that the reason is a lack of understanding of the benefits of open standards, or just inertia, with developers continuing to make use of proprietary solutions they have expertise in. Such a belief suggests that greater use of open standards requires a mixture of the carrot (greater promotion of the benefits) and the stick (mandating use of open standards and penalties for non-compliance).

In reality, however, the authors feel that there is general understanding of the benefits of open standards in the cultural heritage sector. We also feel that, although there will be occasions when mandating the use of open standards is needed, there are dangers with this approach. Potentially this could result in services being developed which fail to be successfully deployed because the open standards are too costly to deploy, are immature, fail to deliver the services the user community expects, or have become out-dated, due either to developments elsewhere or to changes in user expectations.

There have been many examples of IT development projects in the public sector where  the costs have escalated and the services have failed to live up to their expectations. An inflexible top-down approach to development methodologies, such as a formal commitment to a set of standards, may be one reason for such problems. There is therefore a need to ensure that sufficient flexibility is provided in the selection and use of open standards to avoid such mistakes being repeated.

Open Standards

Definition of Open Standards

In a paper on open standards it is important to have a clear definition of the meaning of the term. In practice, however, it can be difficult to reach an agreed definition. Rather than attempting to produce a formal definition, the following list of the characteristics of open standards is given:

• The development of open standards is the responsibility of a trusted neutral organisation.
• The responsibility for the ongoing maintenance and development of open standards is taken by a trusted neutral organisation.
• Involvement in the development of open standards is open to all.
• There are no discriminatory barriers to use of open standards.
• Access to open standards is available to all, without any financial barriers.

However, such characteristics do not necessarily apply to all organisations with a responsibility for open standards. For example, within organisations such as W3C (the World Wide Web Consortium), discussions on areas in which standardisation will occur are decided by member organisations who have paid the required membership fee. Similarly, the initial discussions and agreements on the preferred approaches to  standardisation work may be determined by such member organisations. Also, standards produced by organisations such as the BSI (British Standards Institution) are not necessarily available free-of-charge.

Why Use Open Standards?

Open standards are important in the development of networked services for several reasons. They aim to:

• Support interoperability: Interoperability is often critical to those creating digital services. There will be a need to ensure that services and data can be used not only within a correct environment, but also across other digital services and across other application areas. A prime purpose of open standards is to provide such interoperability.
• Maximise access: Cultural heritage services normally seek to maximise access to their resources and services. Ideally, access will not be limited by constraints such as the device used by the end user; their physical location; their location on the network, etc.; or personal factors such as disabilities.
• Provide application- and device-independence: The dangers of lock-in to particular applications or hardware platforms are widely acknowledged.
• Ensure architectural integrity: Unlike proprietary solutions, for which the development and intended usage is likely to be constrained by commercial and competitive factors, open standards which are developed within a wider context can help to ensure architectural integrity across a wide range of scenarios.
• Provide long-term access to resources and services: Long term access to scholarly resources and cultural heritage resources is of particular importance for public sector organisations.

The authors of this paper feel that an understanding of such benefits is widely accepted within the development community. What, therefore, are the barriers to an implementation of a vision based on this approach?

The Complexities of Open Standards

The reality is that despite the widespread acceptance of the importance of open standards and the feeling among some that use of open standards should be mandatory in the development of networked services in practice, many organisations fail to implement open standards in their provision of access to digital resources. This may be due to several factors:

• Disagreements Over The Meaning: There are many complex issues involved when selecting and encouraging use of open standards. First, there are disagreements over the definition of open standards. For example Java, Flash and PDF are considered by some to be open standards, although they are, in fact, owned by Sun, Macromedia and Adobe, respectively, who, despite documenting the formats and perhaps having open processes for the evolution of the formats, still have the rights to change the licence conditions governing their use (perhaps due to changes in the business environment, company takeovers, etc.) Similarly, there are questions regarding the governance of apparent open standards, with the control of RSS 1.0 and RSS 2.0 providing an interesting example; this lightweight but powerful syndication format for Web context has a complex history plagued by disagreements over governance and the roadmap for future developments.
• Difficulties In Mandating And Enforcing Compliance: There are also issues with the mandating of open standards. For example: What exactly does ‘must’ mean? When told you must comply with HTML standards, a developer working on a project might first ask, ‘What if I don’t?’ Then what if nobody does? They might also ask, ‘What if I use PDF instead of HTML?’ There is a need to clarify the meaning of must and for an understandable, realistic and reasonable compliance regime.
• Failure In The Market Place: It also needs to be recognised that open standards do not always succeed in gaining acceptance in the market place: they are often regarded as too complex to be deployed, and the user community may be content to use existing closed solutions and reluctant to make the investment needed to make changes to existing working practices.
• Failure To Satisfy User Needs And Expectations: There is a danger that a development approach may over-emphasise the importance of open standards to the detriment of the end user and the end user’s needs and expectations. It is often tempting to look only at the benefits of open standards for the developer or the provider of a service. We can see the temptation to develop a service based on a rich standard which can address a wide variety of use case scenarios. The danger would be that the end user rejects the service in preference to a simpler one.

Despite such reservations, in reality many IT development programmes are successful. The success may be based on the deployment of agreed-upon and well-defined open standards. However in other cases, development work may adopt a more pragmatic approach, making use of mature open standards but having a more flexible approach to newer standards when there has been no time to reflect on the strengths and weaknesses and the experiences gained in their use.

Lessons Learnt Through Use Of Open Standards

Experiences In The UK

The Joint Information Systems Committee (JISC) (http://www.jisc.ac.uk/), that provides leadership in the innovative use of Information and Communications Technology to support education and research in the UK, has traditionally based its funding of development programmes around the use of open standards. Technical development for  ISC’s eLib programme, launched in 1996, was based on a standards document (eLib, 1996). The document formed the basis of a revised standards document produced to support JISC’s Distributed National Electronic Resource (DNER) programme (later renamed the JISC Information Environment Standards document (JISC, 2001). This work in turn influenced the NOF-digitise Technical Standards document (NOF, 2001)  used by the national NOF-digitisation programme which was responsible for digitisation projects across the cultural heritage sector.

The authors have been involved in providing technical advice and a support infrastructure for both JISC-funded development programmes and the NOF-digitise programme. We will now review the experience we gained.

Case Study 1: QA Focus Project

Although projects funded by the eLib programme were expected to comply with the eLib standards document, in practice compliance was never formally checked. It was probably sensible at the time (the mid 1990s) to avoid mandating a formal technical architecture and corresponding open standards – that could easily had led to mandating use of Gopher! In those early days of the Web, we were seeing rapid developments in the variety of services which were being provided on the Web and many new open standards being developed. However over time, and as the Web matured and the rate of innovation slowed, there was an increasing realisation of the need to provide a more stable environment for technical developments and the corresponding need to address the issue of compliance.

In 2000 JISC funded the QA Focus project (http://www.ukoln.ac.uk/qa-focus/) to develop a quality assurance framework, which would help ensure that future projects would comply with standards and recommendations and deploy best practices (Kelly, 2003). The project’s aim was to develop a quality assurance (QA) methodology which would help to ensure that projects funded by JISC digital library programmes were functional, widely accessible and interoperable; to provide support materials to accompany the QA framework and to help to embed the QA methodology in projects’ working practices. Liaison with a number of projects provided feedback on the current approach to use of standards. The feedback indicated: (a) a lack of awareness of the standards document; (b) difficulties in seeing how the standards could be applied to projects’ particular needs; (c) concerns that the standards would change during the project lifetime; (d) lack of technical expertise and time to implement appropriate standards; (e) concerns that standards may not be sufficiently mature to be used; (f) concerns that the mainstream browsers may not support appropriate standards and (g) concerns that projects were not always starting from scratch but may be building on existing work and in such cases it would be difficult to deploy appropriate standards. Many of these were legitimate concerns, which needed to be addressed in future programmes.

This feedback was very valuable and provided a counter-balance to views which suggested the need for a heavyweight compliance regime which forced projects to comply fully with a technical architecture and corresponding open standards. The feedback led to the development of a contextual framework which is described later.

Case Study 2: Support For The NOF-digitise Programme

Unlike the approaches taken by JISC, the NOF-digitise programme involved the use of an external standards compliance service. This approach taken required projects to report on any deviance from documented open standards. In addition a limited amount of checking of project Web sites was also carried out. Initial reports from some of the projects and discussion on mailing lists showed that there were occasions when full compliance with mandated standards was not felt to be possible as compliance would likely reduce the effectiveness or usability of the Web site. In order to address this, the project reporting form was changed to allow projects to document reasons for non-compliance, supported by an FAQ document which provided examples of permissible non-compliance.

This flexibility helped the programme to produce valuable cultural heritage on-line services within the timescale of the programme. However, on reflection, the approach taken in support of the NOF-digitise programme had its limitations:

• External compliance checking: An external body was used to check compliance with open standards. However, there are issues related to the cost of providing this service and the expertise needed in order to monitor the diversity of solutions developed.
• Lack of embedding: There was a danger that third party compliance checking the use of open standards mean the standards would fail to be embedded in other development work, leading to a lack of embedding and a danger that the open standards approach would fail to be embedded within the organisation.
• Lack of a QA framework: Use of an external compliance checking service could result in failure to develop an internal quality assurance framework.
• Limited community involvement: Although a mailing list was provided to support the projects, in reality this mailing list tended to be used to submit detailed technical queries. There was not really any feel for a sustainable community which would be willing to engage in a wider range of discussions.

Although the NOF-digitisation programe proved very successful, reflecting on the limitations of the support infrastructure was useful for looking at best practices which should be adopted to support future development programmes.

Case Study 3: Digitisation Projects Funded By The AHRB

A third example in the UK has been within digitisation projects supported by the UK’s funding body for the arts and humanities, the AHRC (Arts and Humanities Research Council). It has funded hundreds of digitisation projects since its establishment as a Research Board in 1998. During its existence, a mixed carrot / stick approach has been adopted to try to ensure the implementation of open standards for the digitisation projects it has been funding. However, this has also been tempered by awareness that open standards by themselves are not enough to ensure successful digital resources.

The approach taken has largely revolved around requiring applicants to the funding body to submit a ‘technical appendix’ alongside the main intellectual submission for funding. The technical appendix requires the applicant to consider numerous issues relating to the creation of a digital resource. This includes not just open standards, but documentation and metadata, rights, preservation and access, etc. This appendix is then marked by experts in the field, examining the formats and standards the project plans to use and also its commitment to established good practice in digitisation.

Those projects that are well-prepared, e.g. keen to use open standards, have good plans for metadata and documentation, have considered copyright implications, etc., are given the green light. Those that are not well-thought out (for instance,an insistence on using MS Word or PDF as the sole digital format or a lack of adequate metadata) are informed of the weaknesses in their application, and are usually asked to resubmit at a later date.

The panel of humanities computing experts is mainly drawn from the Arts and Humanities Data Service (AHDS), a national advisory service. The involvement of the AHDS within the marking process is part of a larger national strategy relating to digital archiving. Once projects funded by the AHRC have finished, they are obliged to offer a copy of the data to the AHDS digital archive, which has responsibility for managing and disseminating this content. The task of preservation is made much easier by the fact that most material arrives in open formats (e.g. XML or RTF for text, TIFF and JPEG for images). The AHDS has a training and advisory role as well, offering applicants significant advice on digitisation projects before they submit their applications.

While there are some weaknesses in the process (notably, there is little technical monitoring of projects once they have commenced), it has succeeded in inculcating a strong belief within the arts and humanities faculties in the importance of open standards and good practice in digitisation. Those keen to succeed in obtaining large research grants have had to respond to the demands for good practice.

The process has been running since 1999. The initial concerns of both applicants and markers were, unsurprisingly, to the use of open standards. TIFF, SQL and XML were less established than they are now, and a wide choice of proprietary formats could easily have been taken up. But more recently, the focus has shifted to a more holistic approach to digital creation. Open standards have certainly not been jettisoned, but there has been a realisation that by themselves they are not sufficient to ensure long-lasting, valuable digital resources.

This has mainly been because open standards are, depending on the data type being worked with, either easy or difficult to implement. For the more straightforward data types (text, images, databases), the use of open standards is now almost a given. It is now rare to see an application that proposes to create a digitised text using MS Excel, a relatively common event in the early days of digitisation.

But even projects that do use open standards can still create poor resources - the importance of other issues (the need for quality metadata, the importance of building sustainable Web sites) now requires greater attention than open standards,.

In other fields, however, it has proved impossible to settle on open standards because of the lack of usable standards. For more complex data types such as GIS (Geographical Information Systems), video or audio, proprietary standards have been preferred, perhaps  because of their greater functionality, stability, ease-of-use, industry take-up etc. Such issues are known to staff working at the AHDS and involved in marking digitisation applications and they respond in pragmatic fashion, in order to ensure that useful project outcomes can be delivered.

A Conceptual Model For Open Standards

We have described some of the limitations of open standards and the feedback we have received from those seeking to make use of open standards in their development work. However, as we have seen in the third case study, this need not mean an abandonment of a commitment to seek to exploit the benefits of open standards. Nor should it mean imposing a stricter regime for ensuring compliance. Experience has made it clear that there is a need to adopt a culture which is supportive of use of open standards but provides flexibility to cater to the difficulties in achieving this, as was illustrated in the third case study. This culture and approach is based on:

• A contextual model which recognizes the diversity and complexities of the technical, development and funding environments;
• A process of learning and refinement from patterns of successful and unsuccessful experiences;
• A support infrastructure based on openness, such as use of Creative Commons to encourage take-up of support materials and address the maintenance and sustainability of such resources.

There is a need to recognise the contextual nature to this problem; i.e. there is not a universal solution, but we should try to recognise local, regional and cultural factors which will inform the selection and use of open standards.

Over time, in response to the problems outlined, the authors and others have developed a layered approach intended for used in development work (Kelly, 2005). This approach is illustrated in Figure 1.

Fig 1: A Layered Approach to Use of Standards

This approach uses the following layers:

• Contextual Layer: This reflects the context in which the standards are being used. Large, well-funded organisations may choose to mandate strict use of open standards in order to build large, well-integrated systemsintended for long term use. For a smaller organisation, perhaps reliant on volunteer effort with uncertain long-term viability, a simpler approach may be more appropriate, perhaps making use of proprietary solutions.
• Policy Layer: This provides an annotated description (or catalogue) of relevant policies in a range of areas. The areas will include descriptions of standards, ownership, maturity, risk assessment, etc. It summarises the strengths and weaknesses of the standards.
• Compliance Layer: This describes mechanisms to ensure that development work complies with the requirements defined within the particular context. For large, public funded programmes there could be a formal monitoring process carried out by external auditors. In other contexts, projects may be expected to carry out their own self-assessment. In such cases, the findings could be simply used internally within the project, or, alternatively, reported (if deviations are significant) to the funding body.

It should be noted that, although it is possible to deploy this three-layered approach within a funding programme or community, there will be a need to recognise external factors over which there may be no direct control. This may include legal factors, wider organisational factors (for example, there are differences between higher and further education, museums, libraries and archives), cultural factors, and available funding and resources etc.

It is also important to note that the contextual approach is not intended to provide an excuse to continue to make use of proprietary solutions which may fail to provide the required interoperability. Rather, the approach seeks to ensure that a pragmatic approach is taken and that lessons can be learnt from the experiences gained. In order to ensure that the experiences are shared across the development community (and more widely), it will be important to ensure that systematic procedures are in place to ensure that the experiences are properly recorded and widely disseminated.

A requirement that funded projects should document their decisions on the selection of the standards to be used and provide reports based on their experiences in the use of the standards will help to ensure that such information is recorded in a systematic way. Providing this information in an open and easily accessed fashion will help ensure that such information can be widely disseminated. The use of a Wiki with RSS to allow the content to be syndicated, with news of changes to the information, can help to support this.

After the selection and deployment of standards, there will be a need to ensure that the standards are being used in an appropriate fashion. One means of ensuring that this happens is the use of a quality assurance framework to ensure that technical policies are documented and that systematic procedures for ensuring that the policies are being implemented correctly are in place. Feedback on the process and standards used is also key for success.

Following validation of the ideas documented above, the approaches are now being deployed by JISC as part of its support infrastructure for development programmes.

Supporting This Model

The provision and implementation of a model which provides a pragmatic approach to the selection and use of standards will not guarantee that appropriate decisions are made and that the selected standards are deployed in the most appropriate fashion. There will be a need to ensure that a support infrastructure is in place to ensure that technical managers, implementers, designers and others involved in research and development activities are able to make technical decisions appropriate for the intended purpose.

A support model which is being developed is illustrated in Figure 2.

Fig 2:  Support Model For Use of Standards

This support model is based on the following features:

• The contextual model: This is described elsewhere in this paper. The contextual model has been developed primarily for use by the development community. The end user community need not be aware of the contextual model which was used as part of the development process.
• User engagement: Engagement with the user community will be essential to ensure the sustainability of the approach – the development approach is not an end in itself, but a means for satisfying the needs of the end user community.

There are several user communities involved in development activities. The development community will typically focus on areas related to the standards, development approach and related areas. The user community, in contrast, will often be uninterested in such issues, concerned primarily with use of a service which functions effectively. Although developers should be aware of the needs to address end user needs, it may be difficult to achieve this goal. It should therefore be a requirement of the funding body or organisation to ensure that mechanisms are put in place to ensure that the approaches taken in development will ensure that the needs of the user community are satisfied.

Mechanisms for ensuring the development work is successful in meeting user needs may include:

• Advocacy: There will be a need for the development community to promote the advantages of the preferred approaches to development. This could include promoting the advantages of use of open standards. Such advocacy needs to be tailored for the intended target audience, with other developers and end users requiring different approaches.
• Feedback: A wide range of feedback will be required. For example, developers will need to provide detailed feedback on the contents of the standards catalogue; funders on the contextual model and implementation experiences; and end users on the end user service.
• Engagement: A passive feedback mechanism is unlikely to provide useful feedback. A more effective approach is to provide engaging mechanisms which not only act as a one-way transfer of information, but also provide richer two-way discussions.
• Refinement: The feedback and engagement processes should help to refine those areas in which deficiencies have been identified. This could include over-simplistic or over-complex approaches to the development model.

The Parallel With Web 2.0

The Web 2.0 term gained popularity after our involvement in supporting the eLib, JISC Information Environment and NOF-digitise programmes. However the underlying principles associated with Web 2.0, such as the focus on the user and on user participation and a flexible ‘always beta’ approach, have strong parallels with the conclusions reached in our support work, including:

• A culture of openness and sharing: People are now being more open about the way they do things. This often means more use of open standards but can also mean being up front about their inappropriateness or limited use.
• Aiming for simplicity: The current trend is for simplicity and ease of use. Many Web 2.0 services which are popular with the end user community can also be exploited by the museums development community. This can provide several benefits: software and services are already in place, so no effort is required in installing and configuring software.
• Willingness to take risks: One other important aspect of Web 2.0 is the apparent weighing up of risk. Often there is a risk factor in using these services as there are no guarantees that they will always be around, but people are finding that the benefits of use outweigh the risks. The increasing willingness to take risk is relative. Waiting for solutions to be perfect has its own set of risks.
• A culture of sharing: Web 2.0 has many opportunities and mechanisms for peer-to-peer support: Learning from the experiences of other developers can be particularly valuable. Mechanisms for providing such peer-to-peer support can build on existing approaches (face-to-face meeting; use of e-mail lists, bulletin boards, etc.) and explore use of Web 2.0 communication tools and social networking services.
• A community-approach: It will be important for mechanisms to be in place to ensure that support materials can be maintained and the support infrastructure is sustainable. Approaches based on building on established Communities of Practice are being explored.
• Being flexible: Web 2.0 uses the expression ‘always beta’. This expresses the concept of ongoing development and responsivity to user experiences and feedback.

Conclusions

This paper has argued that what is needed is a more contextual approach to open standards. It could be argued that what we need is not a list of open standards but an open standards process based on a desire to exploit the potential benefits of open standards, tempered by a degree of flexibility to ensure that the importance of satisfying end users’ needs and requirements is not lost and that over-complex solutions are avoided. This process could adopt the contextual approach documented in this paper and watch patterns of usage.

The contextual approach aims to provide a degree of flexibility. In addition, a community-led approach based on a culture of sharing and openness can help the development community. The concepts associated with Web 2.0, used in conjunction with Web 2.0 applications such as social networking tools, can provide a valuable mechanism for realising this aim.

References

eLib (1996). , eLib Standards Guidelines, http://www.ukoln.ac.uk/services/elib/papers/other/standards/  (Accessed 22 January 2007).

JISC (2001)., Standards and Guidelines to Build a National Resource, . http://www.jisc.ac.uk/fundingopportunities/projman_standards.aspx  (Accessed 22 January 2007).

Kelly, B., M. Guy and H. James (2003). “Developing A Quality Culture For Digital Library Programmes”.  Informatica Vol. 27 No. 3 Oct. 2000.  http://www.ukoln.ac.uk/qa-focus/documents/papers/eunis-2003/

Kelly, B., R. Russell , P. Johnston,  A. Dunning, P. Hollins and L. Phipps (2005).  “A Standards Framework For Digital Library Programmes”.  ichim05 Conference Proceedings. http://www.ukoln.ac.uk/web-focus/papers/ichim05/

NOF (2001),. NOF-digitise Technical Standards And Guidelines., http://www.mla.gov.uk/resources/assets/T/technicalstandardsv5_pdf_7959.pdf  (Accessed 22 January 2007).

Cite as:

Kelly, B., et al., Addressing The Limitations of Open Standards, in J. Trant and D. Bearman (eds.). Museums and the Web 2007: Proceedings, Toronto: Archives & Museum Informatics, published March 1, 2007 Consulted http://www.archimuse.com/mw2007/papers/kelly/kelly.html

Editorial Note