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

7. Publication

It is expected that end-user access to resources will be primarily through the use of Internet protocols. Preparation for publication requires the processing of the “digital master” to generate digital objects suitable for use in the Internet context, typically by reducing quality in order to gen­erate files of sizes suitable for transfer over networks.
Also, video and audio may be made available either for download or for streaming, which means that instead the entire file being trans­ferred before playback can start, a small buffer space is created on the user’s computer, and data is transmitted into the buffer. As soon as the buffer is full, the streaming file starts to play, while more data contin­ues to be transmitted.

Consideration must be given to the fact that variations exist in

• the types of hardware device and client software employed by users
• the levels of bandwidth restriction within which users operate

To maximise potential audience reach, projects should make resources available in alternative sizes or formats or at alternative resolutions/bit-rates. Project should periodically review the criteria on which decisions about delivery formats and parameters are based. Note: The following recommendations on delivery formats should be read in conjunction with the requirements for file formats for storage of resources (see 5.1).

7.1 Processing for delivery

Delivery of text

Character encoding
The character encoding used in text-based documents should be trans­mitted in the HTTP header, and also recorded within documents as appropriate (see 5.1.1.1).
Note that some XML-based protocols may mandate the use of a spec­ified character encoding, e.g. the OAI Protocol for Metadata Harvesting (see 8.1) requires the use of the UTF-8 character encoding.

Guidance:
JukkaKorpela, A Tutorial on Character Code Issues
http://www.cs.tut.fi/~jkorpela/chars.html
Available 2005-02-15

Document formats
Text-based content must be delivered as XHTML 1.0 or HTML 4 (or sub­sequent versions), though the use of SGML or XML formats conform­ing to other DTDs or Schemas may sometimes be appropriate (Source: NOF-digitise).
In some cases, delivery in proprietary formats such as PDF, RTF or Microsoft Word may be appropriate as a supplementary format to XHTML/HTML, but projects must ensure that accessibility issues have been addressed (Source: NOF-digitise).

Standards:
HTML 4.01 HyperTextMarkupLanguage
http://www.w3.org/TR/html401/
Available 2005-02-15

XHTML 1.0 The Extensible HyperTextMarkup Language
http://www.w3.org/TR/xhtml1/
Available 2005-02-15

Other references:
Portable Document Format (PDF)
http://www.adobe.com/products/acrobat/adobepdf.html
Available 2005-02-15

Delivery of still images

Photographic images
Images must be provided on the Web as JPEG/SPIFF format. Consideration should be given to providing various sizes of image to offer readability appropriate to the context of use. IPR issues may also contribute to decisions about the size and quality of image provided.
Thumbnail images should be provided at a resolution of 72 dpi, using a bit depth of 24-bit colour or 8-bit greyscale, and using a maximum of 100-200 pixels for the longest dimension (Source: EMII-DCF). Images for full-screen presentation should be provided at a resolution of 150 dpi, using a bit depth of 24-bit colour or 8-bit greyscale and using a maximum of 600 pixels for the longest dimension. This resolu­tion remains lower than that required for high quality print reproduc­tion (Source: EMII-DCF).

Graphic non-vector images
Images should be delivered on the Web using Graphical Interchange Format (GIF) or Portable Network Graphics (PNG) format.

Graphic vector images
Images should be delivered on the Web using the Scalable Vector Graphics (SVG) formats.

Delivery of video

Consideration should be given to the possibility that users’ access to video may be constrained by bandwidth restrictions and it may be appropriate to provide a range of files or streams of different quality.

Downloading
Video for download should be delivered on the Web using the MPEG-1 format or the proprietary Microsoft Audio Video Interleave (AVI), Windows Media Video (WMV) or Apple Quicktime formats. (Source: NOF-Digi, EMII-DCF)

Moving Pictures Experts Group (MPEG)
http://www.cselt.it/mpeg/
Available 2005-02-15

Streaming
Video for streaming should be delivered on the Web using Microsoft Advanced Streaming Format (ASF), Windows Media Video (WMV) or Apple Quicktime formats (Source: NOF-Digi, EMII-DCF).

Delivery of audio

Consideration should be given to the possibility that users’ access to audio may be constrained by bandwidth restrictions and it may be appropriate to provide a range of files or streams of different quality.

Downloading
Audio should be delivered on the Web in a compressed form, using the MPEG Layer 3 (MP3) format or the proprietary RealAudio (RA) or Microsoft Windows Media Audio (WMA) formats. A bitrate of 256 Kbps should be used where near CD quality sound is required; a bitrate of 160 Kbps provides good quality (Source: EMII-DCF).
Audio may be delivered in uncompressed forms using the Microsoft WAV/AIFF or Sun AU formats.

Streaming
Audio for streaming should be delivered on the Web using the MPEG Layer 3 (MP3) format or the proprietary RealAudio (RA) or Microsoft Windows Media Audio (WMA) formats.

Identification

Digitised resources should be unambiguously identified and uniquely addressable directly from a user’s Web browser. It is impor­tant, for example, that the end user has the capability to directly and reliably cite an individual resource, rather than having to link to the Web site of a whole project. Projects should make use of the Uniform Resource Identifier (URI) for this purpose, and should ensure that the URI is reasonably persistent. Such URIsshould not embed information about file format, server technology, organisa­tional structure of the provider service or any other information that is likely to change within the lifetime of the resource. (Source: NOF-digitise, JISC IE)
Where appropriate, projects may wish to consider the use of Digital Object Identifiers or of persistent identifiers based on another identi­fier scheme.
Projects may also wish to ensure that logical sets within the resources they are providing are uniquely and persistently addressable.

Standards:

Uniform Resource Identifiers (URI)
http://www.w3.org/Addressing/
Available 2005-02-15

Digital Object Identifier (DOI)
http://www.doi.org/
Available 2005-02-15

7.2 3D and virtual reality issues

Projects making use of three-dimensional virtual reality (VR) ‘fly throughs’ and models must consider the needs of users accessing their site using typical computers and modem connections.
These models are typically used in the reconstruction of buildings and other structures or in simulating whole areas of a landscape. Traditionally, models have been constructed and displayed using power­ful computer workstations, and this continues to be the case for the most detailed. For projects that are required to deliver the results of their work to a large audience via the Internet, such highly detailed models may be unhelpful. Nevertheless, there is scope for usefully incorporating less complex models into the Web sites made available to users.
In generating these models, projects must be aware that the majority of their users for the foreseeable future will continue to access the Internet using a 56k modem or a shared connection, rather than any higher bandwidth technology. Similarly, the specifications of the com­puters being used by typical visitors are likely to be significantly lower than those of the machines on which projects generate and test any such models. Projects must therefore consider the usability of their models in such conditions, and must test them using typical modem connections and home, school, or library computer systems with a vari­ety of typical operating systems and browsers.
Standards in this area continue to evolve, but projects should produce VR models compatible with the X3D specification.
Apple’s QuickTime VR (QTVR) is not a true 3D image format, but does offer some useful functionality. Projects which do not require the full functionality of X3D may wish to consider using QTVR instead.

Standards:
Web3D Consortium
http://www.web3d.org/x3d/overview.html
Available 2005-02-15

X3D
http://www.web3d.org/x3d.html
Available 2005-02-15

QuickTime VR
http://developer.apple.com/quicktime/
Available 2005-02-15

Guidance:
Archaeology Data Service VR Guide to Good Practice
http://ads.ahds.ac.uk/project/goodguides/g2gp.html
Available 2005-02-15

7.3 Geographic information systems

Much cultural content has a grounding in place, and this offers one powerful means by which content might be grouped or retrieved. Geographic Information Systems (GIS) are software applications specifically designed to store, manipulate and retrieve place-based information, and they are increasingly widely deployed within the cul­tural heritage sector.
It is not necessary, however, for every project that wishes to store place­based information, or to include a location map on their web site, to install and maintain a GIS. Place-based information may be stored (although not necessarily fully manipulated or re-used) within a tradi­tional database, and simple images of location maps etc. may be created by various means. Projects must ensure that they can support a GIS implementation in the future, even if this is not planned within the proj­ect. The OAI-PMH harvesting of metadata (using a schema such as DC.Culture) can then allow the presentation of data through an external GIS system (see Section 8.1). For those projects that do require rich interaction with place-based information, such as that potentially offered by a GIS, the following must be borne in mind:

• projects seeking to employ a GIS must obtain appropriate permis­sions for use of any map data from third parties, ensuring that licences extend to delivering services to their defined audiences via their selected delivery channels
• projects must ensure that data sets combined for the purposes of delivering their service are of similar scale and resolution, and appro­priate for being used together in this manner
• commercial GIS products selected for use should comply with emerg­ing industry standards from the Open GIS Consortium
• projects must make use of and declare use of an appropriate stan­dard co-ordinate reference system when recording spatial data
• projectsmust make use of and declare use of appropriate national standards for the recording of street addresses.

Standards:
OpenGIS Consortium
http://www.opengeospatial.org/
Available 2005-02-15

Guidance:
Archaeology Data Service GIS Guide to Good Practice
http://ads.ahds.ac.uk/project/goodguides/gis/
Available 2005-02-15

7.4 Web sites

Project resources must be accessible using a Web browser. This will normally be achieved using HTML or XHTML and the HTTP 1.1 proto­col. If other protocols are used (e.g. Z39.50) gateways must be avail­able to provide access by a Web browser.
Projects should seek to provide maximum availability of their project Web site. Significant periods of unavailability should be accounted for to the funding programme.  

Standards:
Hypertext Transfer Protocol, HTTP/1.1
http://www.w3.org/Protocols/HTTP/
Available 2005-02-15

Accessibility

Projects must be accessible by a variety of browsers, hardware systems, automated programs and end-users.
Web sites must be accessible to a wide range of browsers and hard­ware devices (e.g. Personal Digital Assistants - PDAs - as well as PCs). Web sites must be usable by browsers that support W3C recommen­dations such as HTML/XHTML, Cascading Style Sheets (CSS) and the Document Object Model (DOM). Projects that make use of proprietary file formats and browser plug-in technologies must ensure that their content is still usable on browsers that do not have the plug-ins. As a result, the use of technologies such as Javascript and Macromedia Flash in navigation of the site must be carefully considered.
The appearance of a Web site should be controlled by use of style sheets in line with W3C architecture and accessibility recommenda­tions. The latest version of Cascading Style Sheets (CSS) recommended by W3C (currently CSS 2) should be used, although, due to incomplete support by browsers, not all features defined in CSS 2 may be usable.
Projects must implement W3C Web Accessibility Initiative (WAI) rec­ommendations and so ensure a high degree of accessibility for people with disabilities. Projects must achieve WAI level A conformance; proj­ects should aim to achieve WAI level AA conformance.

Standards:
Cascading Style Sheets (CSS), Level 2
http://www.w3.org/TR/REC-CSS2/
Available 2005-02-15

Web Content Accessibility Guidelines (WCAG) 1.0
http://www.w3.org/TR/WCAG10/
Available 2005-02-15

Guidance:
Web Accessibility Initiative (WAI)
http://www.w3.org/WAI/
Available 2005-02-15

RNIB: Accessible Web Design
http://www.rnib.org.uk/digital/hints.htm
Available 2005-02-15

Watchfire Bobby Online Service
http://bobby.watchfire.com/
Available 2005-02-15

Jakob Nielsen, useit.com
http://www.useit.com/
Available 2005-02-15

Security

The machines used to deliver projects must be operated in as secure a manner as possible. The advice in operating system manuals concern­ing security must be followed. All known security patches must be applied.
Machines should be configured to run only the minimum number of network services. Machines should be placed behind a firewall if pos­sible, with access to the Internet only on those ports that are required for the project being delivered.
Projects should demonstrate awareness of the codes of practice pro­vided by ISO/IEC 17799:2000. The management and use of any per­sonal information must conform to relevant national legislation.
Where sensitive information is being passed from a client to a server across the network, projects must use Secure Sockets Layer (SSL) to encrypt the data. This includes the transfer of usernames and pass­words, credit card details and other personal information. Note that the use of SSL also provides the end-user with an increased level of confidence in the authenticity of the service.

Standards:
Secure Sockets Layer (SSL) 3.0
http://wp.netscape.com/eng/ssl3/
Available 2005-02-15

Guidance:
Introduction to Secure Socket Layer (SSL)
http://developer.netscape.com/docs/manuals/security/sslin/index.htm
Available 2005-02-15

Authenticity

Project specific domain names should be registered in the Domain Name System (DNS). The domain name forms part of the project ‘branding’ and will help end-users identify the authenticity of the content being deliv­ered. Domain names should therefore be clearly branded with either the name of the project or the organisation delivering the project.
In some situations it may be appropriate to secure the network con­nection between the client and the server using Secure Sockets Layer (SSL) to give end-users increased confidence that they are exchanging information with the correct project Web site.
Museums providing Web sites should consider registering a “.muse­um” top-level domain name in order to improve disclosure of their services and to indicate that their sites are associated with genuine museums.

Guidance:
Domain Names System (DNS) Resources Directory
http://www.dns.net/dnsrd/
Available 2005-02-15

DotMuseum
http://about.museum/
Available 2005-02-15

User authentication

Some projects may wish to limit access to parts of their resources (for example to very high-resolution images or maps, etc.) to authenticat­ed users only. User authentication is an important tool for ensuring that only legitimate users can access the project’s online resources.
If projects choose to implement user authentication for selected mate­rials it should be based on a username and password combination. In the case of Web-based projects, HTTP Basic Authentication must be used to pass the username/password combination from the browser to the server.
In some cases IP-based authentication (comparing the IP address of the client against a list of known IP addresses) may be an appropriate alternative to usernames and passwords. However, the use of this authentication method is strongly discouraged since the growth in the use of dynamic IP addressing by many Internet Service Providers will make it very difficult to manage a list of approved IP addresses. In addition support for mobile users and users behind firewalls will also make IP authentication difficult to manage.
Projects may choose to make use of third party authentication serv­ices to manage usernames and passwords on their behalf, if appro­priate.

Standards:
Hypertext Transfer Protocol, HTTP/1.1
http://www.w3.org/Protocols/HTTP/
Available 2005-02-15

Performance indicators

Performance indicators can be used to provide objective measures of the usage of a Web service and provide some indication of the impact of the digitisation project. The most popular performance indicator makes use of Web server log files. Analysis of server log files can provide valuable information on the growth of a service and usage patterns, although reports need to be interpreted care­fully.
Projects must maintain statistics about the usage of Web sites and should use them appropriately to analyse the usage of the digitised resources.
Further guidance in this area will be developed.