This chapter examines other standards activity that may be relevant to CHIO. Two specific areas are covered, Multilingualism and Watermarking. The multilingualism section includes character set and WWW activity.
Access to the cultural heritage of a given country is certainly not going to be restricted to the citizens of that country alone. Inevitably there will be market demand for access from citizens of other countries and since one of the objectives is to make access available to all sections of society, there must be mechanisms in place to allow text material to be presented in the language of the customer. The most obvious area to be considered in this respect is that of character set standardisation. Europe in the widest sense extends from the Urals to the Atlantic coast and from the Arctic to the Mediterranean. There are some 160 indigenous languages spoken although many of these are minority cases. Of these, some 120 have a written form. Each language draws characters from a particular repertoire and five indigenous scripts are in use (Latin, Greek, Cyrillic, Georgian and Armenian).
One important class of user is the research specialist and a requirement for the support of languages will extend to ancient languages which are no longer spoken and these will have their own specialist character repertoires. Examples are Anglo Saxon and Norsk. Runic symbols also need to be covered. However, the demand for the IT support of such languages may not be so apparent in the Museum's world since scholars inevitably will want access to visual images of artefacts containing written language and are likely to wish to communicate in their own (living) language.
Although character sets are important, there are a range of related topics, such as WWW standardisation, language codes, country codes, sorting orders, code conversion and transliteration, which also need to be considered.
Character set standards are divided into two broad groups, those based on the ISO/IEC 2022 code structure for 7 and 8-bit codes and those based upon the ISO/IEC 10646-1 code structure using multi-byte codes. The ISO/IEC 10646-1 code structure is relatively new and is considered to be the future for IT support of character sets. However, the installed base of systems and databases which support the ISO/IEC 2022 code structure means that it will need support for many years to come and may never go away.
The problem with single byte code structures is the limited capacity of the code (up to 192 graphic characters for the 8-bit code structure). For this reason, ISO/IEC 2022 specifies escape mechanisms that can be employed within a data stream to switch between different code tables (a code table being a mapping between characters of a specific character repertoire and the codes used to carry them). This allows the sender to signal to the receiver which code table is in use at any given time. Code tables are registered in the ISO/IEC 2350 registry maintained by Danish Standards. There is continuing registration activity and the register now has around 200 entries (although not all of these are for graphic character sets).
The ISO/IEC 2022 code structure in its fullest form is complex and implementations tend only to be of limited scope to the extent that often the code table in use is established by a priori agreement between the two ends of a communication link. In recognition of this, a multi-part standard, ISO/IEC 8859, has been developed. Aimed at the 8-bit code structure, each part identifies two code tables of 94 and 96 graphic characters, one for use in the code range 0-127, the other in the code range 128-255. Each pair of code tables is intended for use without code switching. Each part is intended to satisfy a particular community of use. There is continuing activity in the development of further parts of this standard and each code table is also registered.
The Internet mail MIME extensions, RFCs 1521 (ftp://ds.internic.net/rfc/rfc1521.txt) and 1522 (ftp://ds.internic.net/rfc/rfc1522.txt) , specify how to carry non 7-bit ASCII content and specify the character set to be used in individual body parts in the charset parameter. The MIME specification does not make use of ISO/IEC 2350 registration identifiers but the names registered with the Internet Assigned Numbers Authority (IANA). There is a restricted set of registrations, mainly of parts of ISO/IEC 8859 and proliferation is not encouraged. RFC 1521 only endorses the use of US-ASCII. No other character set name may be used in Internet mail without the publication of a formal specification and its registration with IANA, or by private agreement, in which case the character set name must begin with "X-". It should be noted that the MIME scheme is also used by HTTP for WWW purposes. This situation does mean that for other 7 and 8-bit character sets, bilateral arrangements must be made for Internet mail or WWW use. This also requires special software configurations. These restrictions mean that the use of the ISO/IEC 2022 code structure has little room for expansion in the future in Internet applications.
ISO/IEC 10646-1 is considered by industry and users alike to be the future for the use of character sets. This is certainly the case for Cultural Heritage On-line applications. It contains a repertoire and coding intended in the long term to contain all the characters of the world. ISO/IEC JTC1/SC2 ratified ISO/IEC 10646-1 (UCS) in 1993 (https://www.dkuug/JTC1/SC2/WG2). This standard with the options <UCS-2, subset 300 and level-3> is identical to UNICODE developed by the UNICODE Consortium (https://www.unicode.org). Since then a number of amendments have been ratified both adding functionality (e.g. UTF-8, UTF-16 transfer formats) and adding new characters to the repertoire. Every attempt has been made to keep the standard in line with UNICODE. Future amendments are expected to be restricted to the addition of new characters to the repertoire.
The code space is in four dimensions, 128 blocks each consisting of 256 planes each with 256 columns and 256 rows. A character is conceptually coded in 4 bytes (UCS-4). Part 1 of the standard specifies the allocation of characters to the lowest order plane known as the Basic Multilingual Plane (BMP). Around 40,000 characters have been assigned to the BMP. The code structure does not allow the whole of the BMP code space to be used for individual characters and the BMP is filling up rapidly. A character in the BMP can be referenced by just 2 bytes and this fact is used for the coding of the BMP (UCS-2).
Few products (at least in the short term) will provide full support for the whole of the UCS repertoire due to resource constraints. Although a product may be able to process the UCS internally, font resource will be a problem. With this in mind, both to guide suppliers and to help users, CEN TC 304 (https://tobbi.iti.is/tc304/default.html) has recently ratified ENV 1973, the Minimum European Subset (MES) of ISO/IEC 10646-1. This contains 926 characters and covers nearly all the languages in use in Europe which are written in the Latin, Greek and Cyrillic scripts together with a large number of commonly used symbols. This ENV also makes a suggestion for the specification of the Extended European Subset (EES) which contains all the characters defined in the UCS for the Latin, Greek, Cyrillic, Armenian and Georgian scripts together with a large number of symbols. Further work is in progress on the full specification of the EES.
Bearing in mind the need to ensure interoperability with legacy applications and legacy communications infrastructures and the need for cross script access, there is a need to provide for code conversion, fallback and transliteration. Code conversion is required whenever it is necessary for a character coded data stream has to cross an interface between two environments supporting incompatible character coding schemes. Code conversion can be one way or reversible. Fallback is a type of code conversion which has particular relevance when an exiting hardware or software platform is unable to present to the user the correct glyphs associated with coded characters. It can be reversible or non-reversible. Transliteration is needed when it is necessary to convert from one script to another and is dependent on the source and destination languages in use. It may or may not be reversible. CEN TC304 has active work items in each of these areas. In the case of Transliteration, ISO TC46/SC2 (https://www.iso.ch/meme/TC46.html) is also active.
It is often necessary to create indexes and directories and to define string comparison rules. For this, the sorting order (collation sequence) of a character repertoire needs to be defined. Generally, national standards organisations are providing local standards in this area. CEN TC304 has a work item for the specification of sorting for the MES and the EES, i.e. a pan European sorting specification. ISO/IEC JTC1/SC22 has an active project on International String Ordering.
The Hypertext Mark-up Language is used to mark-up text documents in the WWW environment. HTML V2.0 is published as RFC 1866 (ftp://ds.internic.net/rfc/rfc1866.txt). It corresponds to the capabilities of HTML generally in use before 1994. This version of HTML specifies ISO/IEC 8859-1, Latin Alphabet No 1 as the HTML Document Character Set. In addition to this, the specification states that "to support non-western writing systems, HTML user agents (i.e. browsers) are encouraged to support ISO/IEC-10646-UCS-2 or similar character encoding schemes and as much of the character repertoire of ISO/IEC-10646-1 as is practical". However, the specification gives no indication on the mechanisms that are permitted in order to represent ISO/IEC 10646-1. HTML Tags must use ISO/IEC 646 characters and this includes URLs. To all intents and purposes ISO/IEC 10646-1 cannot be used in the context of this version of HTML and retain interoperability.
HTML V3.0 never got past the draft stage and was considered to be too complex. It included many multilingual features. HTML V3.2 (https://www.w3.org/MarkUp/Wilbur/) does not include ISO/IEC 10646-1 as the Document Character Set nor the multilingual features that were in the HTML V3 draft. However, there is a new (Jan 1997) RFC2070 "Internationalization of the Hypertext Mark-up Language" (ftp://ds.internic.net/rfc/rfc2070.txt) which contains all these features. It is anticipated that the version of HTML coming after V3.2 will incorporate the features of RFC2070. RFC2070 is written relative to HTML V2 (RFC 1866) and it contains the following extensions which result in a specification which remains a valid application of SGML:
In particular, the following features are supported:
RFC2070 also contains a number of hints and recommendations aimed at implementors pointing out pitfalls to be avoided when handling ISO/IEC 10646-1, such as the different codings that are possible for the same character.
Both HTTP V1.0 (ftp://ds.internic.net/rfc/rfc1945.txt) and V1.1 (ftp://ds.internic.net/rfc/rfc1945.txt) can transfer message bodies coded according to the charset parameter, the values of which are registered by IANA. Both can therefore carry ISO/IEC 10646-1 coding.
It is possible to store several documents under one URL. Different versions could mean written in different languages. HTTP V1.0 allows the client to send Accept headers indicating user agent capabilities and user preferences. The server can then choose the appropriate version of the document to send. This is known a server driven negotiation. HTTP V1.1 allows this to be done the other way around - agent driven negotiation. A server can send the user agent a list of available document formats and the user agent can then choose. This may be done automatically, or the user himself may be given the option. The negotiation may take place in four "dimensions", media type, charset, language and features. Feature tags allow for extensibility and can be registered.
Transparent negotiation is a combination of both server-driven and agent-driven negotiation. When a cache is supplied with a form of the list of available representations of the response (as in agent-driven negotiation) and the dimensions of variance are completely understood by the cache, then the cache becomes capable of performing server- driven negotiation on behalf of the origin server for subsequent requests on that resource. Transparent negotiation has the advantage of distributing the negotiation work that would otherwise be required of the origin server and also removing the second request delay of agent-driven negotiation when the cache is able to correctly guess the right response. Transparent negotiation is not specified by HTTP V1.1 but is the subject of an Internet Draft. Internet drafts in the HTTP area may be found at https://www.ietf.org/ids.by.wg/http.html.
There is currently a significant debate going on about allowing the names used in URLs to consist of characters outside of US-ASCII. To quote the W3C site on this issue: "URLs must be expressible using nothing more than the 95 printable ASCII characters. They were designed to be unambiguous even when printed in a newspaper. In fact, they are printed so much, that people are beginning to think that it is unfair that Americans can often use their own name in a URL, but other people must transliterate many characters. A new type of URL or a directory layer on top of them might make it easier for people to remember and type Web addresses. W3C is not currently working on this."
A very recent development has seen an agreement to allow that part of the URL beyond the Internet domain name portion to use ISO/IEC 10646-1 character coding. This is still a very new development.
Web standards are changing rapidly. For right up to date information the reader should refer to https://www.w3.org. It is also worth referring to https://www.ietf.org/ids.by.wg/http.html to get up to date information on HTTP specifically.
RFC 2070 - Internationalization of HTML - makes use of two character language codes as specified in ISO 639 and two character country codes as specified in ISO 3166. These standards act as the registers for the codes and although stable, can be subject to periodic update. It should be noted that ISO 3166 also specifies 3 digit numeric country codes.
"The Language Engineering sector is part of the Telematics Application Programme of the Commission's 4th Framework. The Language Engineering sector is developing applications which help improve information access and interchange across languages. It is integrating written and spoken language processing technologies into telematics services, thus improving their ease of use and broadening their scope across national markets and users groups. New applications such as voice-controlled inquiry systems, multilingual information services and computer assisted translation are providing European citizens and businesses with better information and communication capabilities."
See https://www2.echo.lu/telematics/langeng/lehome.html
The Multilingual Information Society (MLIS) programme is complementary to the Language Engineering programme.
"The core objective for the programme is to create the right conditions for a multilingual information society by building on current European initiatives and stimulating collaboration among relevant groups of similar actors exploiting the opportunities offered by an increasingly networked environment. A coherent set of actions will focus on three main lines of action.
The coherence of these actions will be fostered and the effects of the actions enhanced through a number of accompanying measures."
See https://www2.echo.lu/mlis/en/intro.html.
Note: an analysis of the projects within these programmes to find out if there are any activities relevant to CHIO has yet to be done.
As of today, four different protection modes have been identified.
Watermarking perhaps offers the most promising technology for copyright protection.
A digital watermark is, in essence, a hidden message, within a digitized image, video recording or audio recording. The watermark is integrated with the content itself, and so requires no additional storage space or new format standards. It can contain various sorts of information. Unlike a traditional watermark, on paper, which is generally visible to the eye, digital watermarks can be made invisible or inaudible. They can, however, be read by a computer.
A digital watermark is a technology that provides a means for publishers of multimedia content to protect their copyrights on computer networks, or other digital media such as compact discs, as well as track content that is electronically distributed. Digital watermarking is probably the most promising in the area of multimedia copyright protection.
WIPO (https://www.wipo.int) has recently ratified a new Copyright Treaty which is specifically aimed at the protection of copyright when the work is distributed electronically via networks or via modern media such as CD-ROM.
Articles 11 and 12 of the treaty is particularly relevant to watermarking. To quote:
Article 11 Obligations concerning Technological Measures
Contacting parties shall provide legal protection and effective legal remedies against circumvention of effective technological measures that are used by authors in connection with the exercise of their rights under this Treaty or the Berne Convention and that restrict acts, in respect of their works, which are not authorised by the authors or permitted by law.
Article 12 Obligations concerning Rights Management Information
No matter what technology is used, it is always going to be possible to remove rights management information such as a watermark. What this treaty does is to provide an international legal framework for the protection of watermarks. This now brings the use of modern technology into line with the existing corpus of copyright law.
No standards yet exist for watermarks, but there are a number of competing technologies coming to market and a number of initiatives. Standards activity can be expected within the next 5 years.
The new Copyright Treaty, the emerging technology and the prospect of standards for watermarks goes a long way towards the removal of one of the major commercial barriers to the success of Cultural Heritage On-line.
It is useful here to present a description of the characteristics of watermark technology since it is relatively new and knowledge is still confined to a small specialist audience.
A watermark may hold as little or a much information as is required but typically, information including title, copyright and license ownership information. In order to protect against partial copying of a work, the multiple copies of the watermark may occur throughout the work. A work may contain different types of watermark each designed for different use. As an example, one such technology describes such separate use as a "channel". Each "channel" is accessible by a separately created "key." A channel may be designated as a "copyright channel" and watermarked with copyright information, the copyright channel key likely being controlled or escrowed by the copyright holder or its agents. A second channel in the same copy may be designated a "distribution channel" and watermarked with distribution channel using a second key. This key may be given to the intended distributor in the same way a distribution agreement is made between parties. A third channel may be designated as an "ownership channel" where consumer's information is watermarked as the consumer is paying for the content. The distributor would be free to issue an "ownership key" to the purchaser to validate the purchase in the same manner a receipt is issued in a real world purchase! All three channels are distinct and become an integrated audit trail accessible by the three separate keys, ensuring privacy and efficacy in identifying a given copy of content.
Illicit copies can be examined and the watermarks can provide an audit trail to allow the copyright owner to determine who is responsible for the appearance of illicit copies. It is even possible on the Internet, for example, to envisage a system for policing which would use such devices as intelligent agents and "crawlers".
DAVIC (https://www.davic.org) has issued its 7th call for proposals CFP7 (13/12/96 for input by 07/02/97) to augment part 10 of its specifications covering Copyright Protection (Copy Control and Monitoring) in a DAVIC Environment. The use of Data Embedding (watermarking, fingerprinting) technologies is envisaged. If successful, then this could result in an industry recognised standard for watermarking technology. It is useful here to list the requirements that the technology might be expected to meet. One such list is provided in the DAVIC call and these are repeated here.
A good place to start investigating watermark issues is at the Argent Web site (https://digital-watermark.com/ArgentFAQ.htm).
Other places are https://www.musicode.com/Billboard.html and https://poseidon.csd.auth.gr:80/signatures.
The following EC sponsored projects are examining IPR issues and in particular the use of digital protection technologies such as watermarking.
OCTALIS is a continuation of both OKAPI (https://www.tele.ucl.ac.be/OKAPI/index.html) and TALISMAN (https://www.tele.ucl.ac.be/TALISMAN/index.html), two European projects dealing with conditional access issues with TTPs and copyright protection issues respectively which were in turn follow-on projects from ACCOPI. OCTALIS is within the ACTS programme.
The main goal of OCTALIS is to integrate a global approach to conditional access and efficient copyright protection and to demonstrate its validity in large scale trials. It is intended to separate the management message traffic from the broadcast video traffic with the management traffic being carried across an Intranet. The project will make use of watermark technology for copyright protection.The project also plans to apply its technology to the distribution of still pictures across the Internet.
OCTALIS expects to feed its results to DAVIC, the EBU and DVB as contributions to their standardisation activity.
See https://www.uk.infowin.org/acts/analysys/projects/P119.htm and https://ns1.tele.ucl.ac.be:80/OCTALIS/index.html.
The primary objective is to assist the "vertical projects" concerned with IPR (Intellectual Property Rights) management and co-financed by the European Commission. The aim is to do this by taking advantage of the experience gained in an earlier ESPRIT Project, CITED (EP 5469, Copyright In Transmitted Electronic Documents). This will support the development and implementation of an interoperable IPR ECMS (Electronic Copyright Management System). A related objective is to cooperate with the vertical projects in a standardisation process that is necessary to permit interoperability among different ECMS.
https://www.newcastle.research.ec.org/esp-syn/text/20460.html
The project has two main, related goals. The first goal is to agree a swift and practical response based on a mutual understanding of the problems arising at the interface between lT, telecommunications and IPR concerns. This is to be done within a forum which represents a wide range of organisations in the information industry. The second goal is to identify and develop a set of tools to address those problems in the business, technological, standards and legal areas.