
General Functional Requirement
At its first two meetings the CIMI committee considered the requirements for the CIMI Standards Framework and suggested 14 functional requirements and 3 requirements of the standards development process itself. FIGURE 10 summarizes the requirements grouped under the headings Functional and Process. This section discusses how the functional requirements shaped the definition of interchange needs of museums upon which the Standards Framework for CIMI is based. The process requirements shaped how the CIMI Committee conducted its work.
The first two requirements listed in Figure 10 reflected one of the important contributions of CIMI to setting museum standards: the recognition that standards must be specific and appropriate to particular applications. The first of the functional requirements, that the CIMI Standards Framework must carry information for all museum application, led the CIMI Committee to conduct a brainstorming session at which it identified all the museum applications known to potentially require data interchange. The second requirement, that the standards should identify the museum application for which the interchange is intended led CIMI staff to analyze this list in order to cluster applications according to the particular types of standards applicable to them. From this emerged the concept of a matrix of standards discussed in the next chapter.
The third through sixth requirements reflected the knowledge CIMI Committee members had of the variety and complexity of data related to museum objects. Based on this knowledge, the Committee was able to state in advance that the standards would need to carry a great deal of data, a wide variety of types of data, numerous methods of representation, and possibly even permit the interchange of some data before its meaning was agreed to by exchanging parties.
The range of all possible types of data to be carried is diverse. From the interchange applications predicted in the near-term, the identifiable types included character based alphanumeric text in free and fielded format and continuous tone, bi-level, and raster images. A specific requirement was to enable the bi-directional interchange of data in all existing USMARC formats. The Committee concluded that in the midterm (5 years out) museum applications will evolve and technology advance to require facilities for interchange of vector graphics for Computer -aided design, binary files including multimedia, and sampled analog data such as sound or waveform, and linked hypermedia and time synchronized data. In the longer term even this list will need extension as other types are identified. Standards above the data representation level must be insulated from the nature of the data.
Multiple data representation methods must be accommodated. Textual information may be represented in a variety of alphabets, each encoded in a number of possible schemes from 7 bit ASCII through to emerging 32 or 16 bit standards for text encoding such as ISO 10646 or UNICODE. Images, graphics, and sound may be represented in different manners, each appropriate to differing degrees of fidelity, compression schemes, or simply representing a lack of a dominant standard. Any or all may be encountered in a single functional interchange. As the Committee learned more about OSI however, it became clear that the requirement to carry different kinds of data within a single session was satisfied by lower level OSI standards.
Especially given the potential need to interchange multimedia data objects which are often very large digitally encoded files, there must be no limiting restrictions on the size of records and the amount of data capable of being interchanged.
+----------------------------------------------------------------------------+ | | | Requirements for the CIMI Standards Framework | | | | | | Functional Requirements | | | | 1. The CIMI Standards Framework must carry information from | | any museum application; | | | | 2. Identify the application for which the interchange is intended; | | | | 3. Carry a variety of data types such as text, image, binary, | | graphic; | | | | 4. Accommodate the declaration or specification of multiple | | data types in the interchange session; | | | | 5. Accommodate multiple transmission protocols in a single | | interchange session; | | | | 6. Support a variety of data representation methods; | | | | 7. Support a range of media transmission options including | | magnetic, optical, 7 and 8 bit telecommunications, dynamic | | data exchange; | | | | 8. Accommodate the quantity of data needed with no restrictions on | | the size of records and the amount of data capable of being | | interchanged; | | | | 9. Carry information for one or more application purposes in a | | single interchange; | | | | 10. Support realtime, batch, and interactive modes of operation | | as applications require; | | | | 11. Enable interchange transactions not fully specified in | | advance; | | | | 12. Carry content independent of sending or receiving system, | | application, or implementation data model; | | | | 13. Support migration of data among systems and be compatible | | with existing network held data with limited loss; | | | | 14. Be both possible and practical to implement on a wide variety | | of systems. | | | | | | Process Requirements | | | | The effort must: | | | | 1. Produce results without excessive implementation costs; | | | | 2. Provide a mechanism for resolution of issues; | | | | 3. Adopt appropriate extant national and international standards. | | | | | +----------------------------------------------------------------------------+ Figure 10: Functional Requirements for the CIMI Standards Framework
The Committee was happy to discover that the seventh through tenth requirements on its initial list were satisfied by adopting the open systems model and its associated standards. Thus museums didn't need to construct standards specifically to support a range of media transmission options, accommodate multiple transmission protocols in a single interchange session, carry information for one or more museum applications in a single interchange session or support batch, and realtime interactive modes of operation as applications require.
In addition, the requirements numbered 11-14 were found to be either unnecessary to state or conceptually impossible to satisfy. For example, while all the protocols enabled interchange of transactions not fully specified in advance, the meaning of data received in this way would by definition be unknown to the receiving system, so the value of the interchange would be minimal. It was thought desirable to have a declarative capability within an interchange session allowing transactions to carry sufficient information about them to allow intelligent reception by receiving systems without complete prior agreements, but no actual need for this, not to mention the feasibility, has been demonstrated.
As more was learned about the role of standard formats as a neutral vehicle between two internal schemas we realized the requirement to carry content independent of sending or receiving system, application, or implementation data model was partly inherent in our definition of interchange and partly the responsibility of the Task Groups specifying data content requirements for services. The same conclusion was reached about the requirement to support migration of data between systems and be compatible with existing network held data with limited loss.
Finally, the requirement that the standards be both possible and practical to implement on a wide variety of systems was deemed important by all. The best way to assure this was to build the CIMI Standards Framework around existing frameworks such as OSI and OSE which were already impacting on the availability of standard methods on a wide variety of platforms and in many software environments.
Museum Applications and their Interchange Requirements
While exploring museum functional requirements, the CIMI Committee developed a list of museum applications that could involve interchange. This is shown in Figure 11.
Because CIMI had decided in principle to adopt interchange protocols, methods and standards that were already in service, it made sense to cluster the museum applications involving interchange in such a way that they corresponded with services in existing standards frameworks. Those frameworks suggested that interchange applications would employ the discrete suites of standards in building databases, exchanging messages, consulting databases, transmitting files, and conducting business transactions. Therefore, the CIMI list categorized museum applications as shown in Figure 12.
+----------------------------------------------------------------------------+ | | | | | Museum Applications potentially requiring interchange applications | | | | | | archives management loans processing | | authority building location control | | catalog access mail order sales | | cataloguing and description maintenance scheduling | | collections management movement control | | communications/terminal emulation material management | | conservation management name list management | | contacts management office automation | | database building, management personal research information | | decision support management | | event management personnel management | | exhibition management point of sale | | exhibition design project accounting | | file management project management | | fund raising management public access | | fund accounting publishing | | image management record management | | image retrieval remote access | | image processing research support system | | information retrieval reservations | | inventory control security | | invoicing subscription fulfillment | | library management ticketing | | list management tour management | | volunteer management | | | | | +----------------------------------------------------------------------------+ Figure 11: Museum Applications potentially involving interchange
+----------------------------------------------------------------------------+ | | | | | Museum Application | Activity | Examples | | | | | | Database Building | creating records, | Union catalogues, | | | editing, deleting | cooperative | | | | cataloguing, scope of | | | | collections, authority | | | | files, directories | | | | | | Information Retrieval | accessing stored | public access | | | information | catalogues, | | | | bibliographic | | | | databases, full text, | | | | directories, reference | | | | databases | | | | | | Business Transactions | electronic data | purchasing, order | | | interchange | fulfilment, loans | | | | processing, financial | | | | transactions, | | | | exhibition management | | | | | | Messaging | messaging services | email, conferencing, | | | | document exchange | | | | | | File Transfer | binary transfer | exchange of scientific | | | | data, data migration, | | | | media exchange | | | | | | Document Handling | document processing | correspondence, | | | | cooperative | | | | publichsing, research | | | | | | Real-time Links | machine-to-machine | interactive training, | | | | interactive exhibits, | | | | monitoring | | | | | +----------------------------------------------------------------------------+ Figure 12: Museum Applications and Their Interchange Requirements
Museums document their collections and build reference databases on people, organizations, places and events which played a role in the creation, trade and use of objects within the scope of their collections. Typically when museum professionals think of information interchange they think first about inter-institutional exchange of data about collections at the object level, however, our research suggests that there is less demand for interchange of this information than is initially envisioned. When museums do exchange this data to construct shared databases or union catalogues they obtain none of the economic advantages which libraries realize from being able to use such databases for copy cataloguing because museum objects are typically unique. Collection related information exchange seems to be more valuable for museums when the object of description is the collection or even the repository. This concept, well established in the archival community, was introduced to museums by the Common Agenda Database Task Force and is being further developed by the Cultural History Information Task Group of CIMI.
Museums do have a great interest in the exchange and copying of data about individuals, organizations, places and events associated with collection objects. These files of authoritative information which relate to entities other than the objects in collections are essential to research and to make links between objects for interpretation. Information about people in many roles (makers, donors, lenders, vendors), manufacturers, geographical locations, and events are commonly mentioned as being shareable, cooperatively developed or maintained, or consulted in reference fashion.
Museums also need to share vocabularies, thesauri, name lists, and classification systems which are used to index objects in collections. The Art and Architecture Thesaurus (now available electronically), classification schemes such as Iconclass, Linnean Taxonomy, and AASLH's Revised Nomenclature, artist names (Getty AHIP's Union List of Artist Names, CHIN's Artists in Canada), and geographic place names could enjoy more widespread implementation if interchange standards were adopted.
Research use of database information does not usually require the exchange of complete databases or of records being contributed to a central database, but depends rather on information retrieval. Standards for information retrieval should permit a user of one museum system to make inquiries into the public information on another museum system from a different vendor and receive a response through the familiar interface of his or her own system. With the growing use of the Internet by museums and scholarly organizations, information retrieval standards would result in the creation of large "virtual databases" comprised of many different systems, distributed in location but accessible through a single protocol.
There seems to be general agreement about the utility of a broad range of general reference bases used primarily in a consultative manner. Interest ranges from the expected bibliographic, abstracts/index through to taxonomic types, international law, administrative information relating to collections such as access policies and hours of operation, and conservation materials. This interest is substantiated both by the experience of information service providers such as CHIN and RLG who receive constant requests for such services, in the articulated needs of potential users, and in actual usage demonstrated by the Conservation Information Network. The library community has recently led the way in this area by developing and promoting a protocol for information retrieval which many vendors and networks are now implementing.
All organizations engage in transactions involving outside firms. Over the past decade, methods have been developed for many such transactions to be conducted electronically. We are all acquainted with the effect of this change as we use Automatic Teller Machines and enjoy the benefits of automatic reordering of inventory at the grocery. Museums conduct many of the same activities as any other business or organization; they manage facilities, operate retail and mail order operations, order supplies, manage staff. These activities involve a variety of forms-based transaction-oriented information interchange applications that are increasingly conducted in the commercial sector by EDI. When cost-effective, museums might move towards electronic transactions in these areas as well.
In addition, museums and other cultural repositories such as libraries and archives, engage in collections management activities which involve transactions specific to themselves, including acquisitions, loans, and numerous aspects of exhibition management. Specific obligatory relations are created in the course of these transactions which are now conducted on paper using the mail and fax. For example, deeds of gift must be executed, insurance and customs arrangements made, shippers arranged, loans requested and recalled. Libraries have again pioneered here in developing electronic ordering of books and electronic interlibrary loan requests, and museums have much to gain if they could electronically interchange the complex transactions surrounding exhibitions which otherwise must be rekeyed in numerous systems many times.
In an era of interconnected computers, the most widely used application service is message handling. The increased availability of electronic mail has stimulated interest in messaging and communications services for museums. A variety of list servers, bulletin boards, conferencing services, and interpersonal and inter-institutional communications in museums use electronic mail because the foundation standards for these services have been put in place by others.
The interchange of documents which look and act the way their authors wanted them to regardless of the receiving system has long been a goal of interchange. Museums would like to control the way their catalogues or even their correspondence looked to the recipients for the same reasons other institutions do. Museums also have the same need to be able to communicate documents to printers complete with appropriate mark up and to reformat documents created for one purpose without rekeying them. Document handling standards have been defined to support all these kinds of requirements, but as yet they have not been broadly implemented in commercial software because of their complexity and because many users do not have a strong enough requirement for final form document interchange to make it commercially necessary to provide such functions. It is anticipated that document handling functionality will be an increasingly important requirement in many business sectors in the next decade and standards for document handling will be more widely implemented. Meanwhile, in museums, the emphasis will be on interchange of the logical components of documents and the retention of whatever structure authors have created when the document is transferred to another system.
Sometimes institutions want to move entire data sets from one system to another. The purpose may be to replace the existing system (data migration), or to have a copy in a different location or integrated into another application. Examples of useful file transfer include publishing catalogues, printing gallery labels incorporating collections data, downloading specimen records to a customs broker or sending a research database to a colleague. These applications in museums are sufficiently generic that there are well established protocols for them in business computing.
Interactive exhibits and training, environmental and security monitoring, and programming often require one computer, with or without a human operator, to work directly on a remote system. Each of these categories employs a variety of standards which together establish semantic, data representation, and communication protocol agreement. Within these there are several dominant standards that could provide the technical methods for museum interchange functions.
Go Back
Go to Index