- Email: [email protected]
Computers I: Reference work
Museum Management
and Curatorship
(1992), 11,92-106
Professional Notes Museum Management
and Curatorship does not publish ‘Letters to the Editor’, but this ‘Professional Notes’ section is open to all those wishing to add to or refute statements made in earlier articles. The Editors have expanded the scope of this section to provide a forum for short contributions of a more technical nature, including museum management and conservation training world-wide, and they welcome both contributions and suggestions concerning topics and authors.
Computers I: Reference Work Collections’ records bulge with references to other sources of information. Among these are literary citations, primary documents, ephemera such as art gallery fliers, auction catalogues, curatorial jottings, collectors’ field notes, press cuttings (‘clippings’ in the reports, records of inUS), conservation house exhibitions and loans for display or research, reproductions and ‘related objects’ in the same or other collections. Sources may be written, pictorial, diagrammatic, auditory or cinematographic. Some are integral parts documentation: of the museum’s own photographic files or archives. Others are published, by the museum or others, rare or in print. Some are not source materials in the literary sense but objects: studies for or after a work of art, copies, other versions or treatments of the same subject by other artists. For fragmentary objects there may be reference to other parts of what was once a unitary whole. Some sources refer only to the catalogued object, others to lists or classes of object. Others refer to the object indirectly, documenting its maker, subject or history. The object of most references is to enable one to find the actual source and, for extended documents, to find the relevant part or page. The form and amount of data needed for this are variable. Notice, too, that any given object’s set of references is open-ended, for more may always be found
or published in the future. This is another in the seemingly endless series of problems that were less troublesome in the time of paper records, when there could be some latitude for case-by-case improvizatiom and extra lines or cards might be used at will. Cannot the same degree of flexibility be regained in an automated context? As usual the touchstone is the case of the relational model, in which an open-ended list is forbidden. It will be recalled that a relational database is conceived as a two-dimensional table in which every ‘row’ contains data about one entity (one catalogue entry, in our world), while each ‘column’ holds one kind of data (e.g. year of acquisition). Every column, of course, intersects each row; and at each intersection is a field containing a single datum (or fact). There must always be one column or a set of columns such that their combined content is unique in each and every row. They contain the ‘primary key’, i.e. the name, of the row. In a catalogue database the primary key is usually the ‘object’ or ‘accession’ number. Although the database (or ‘relation’) is often pictured as an array of uniform rectangles, all columns are not usually of the same width. Each has its own data definition. One column may consist of 16-bit binary numbers, another of four-digit decimal integers and yet another of 128-byte ‘character’ or ‘text’ units. There is no theoretical limit to the width of a text
0260-4779/92/01
Ltd
0092-15
0
1992 Butterworth-Heinemann
Professional
column, though every software system must impose some arbitrary limit in practice. It would seem, therefore, that one might solve the reference problem by defining a column of very large text fields and writing in it as one would on paper. The flaw in this is familiar: first, most of the space will generally be wasted and, second, no amount of space will always be enough. Some quasi-relational systems offer an apparent solution. One may define what looks and behaves like a variable-length text field. What the column actually contains, invisible to the user, is a ‘pointer’, a numerical code that specifies a separate block of storage, apart from the relational table itself, where the text-or at least the beginning of it-will reside. This block is not huge; but, if it fills and overflows, another pointer appears at its end, another block of space is allocated, and so on indefinitely. Each pointer says, in on page x’. When the effect, ‘continued catalogue entries are displayed or printed, not the pointer(s) but the characters, retrieved from a chain of far-away textual islands, are seen. A drawback is that such ‘free text’ stored outside the table cannot participate in such processes as automatic selection, sorting and-note this well--joining.
Another consideration is redundancy. Many references, such as those pointing to record photographs, are unique, one-to-one connections, but others are not. The latter include references to publications and to exhibition history. It is always a bad idea to repeat the same data in multiple records-at least in permanent files. (Redundancy is harmless and often necessary in temporary files, as we see below.) One would not wish, Table 1.
Field name
key citation
for example, to repeat a passage like the following in each of the 164 catalogue entries where it would be appropriate: . . . published: Museum of Fine Arts, Boston. American Paintings 1815-1865. Boston. 1956 . . exhibition: American Paintings circulating 1815-1865 [followed by a list of exhibition sites and dates] . . . Instead of this almost every museum use abbreviated notation: . . . Publ956AmPtg#91Repr(colour)p61 Exh1957AmPtg#91 . . .
would .
(32) (224)
.
This serves well enough for in-house reference, but how is an outside reader to go from cryptic notes to viewing the actual publication in a library far from Boston? If the data are meant to serve the general public, then additional files are in order: files of publications cited, of exhibitions, of former collections and more. In such files the primary key of each entry would have to be the same as the standard abbreviations used for reference in the object catalogue (Table 1). Otherwise there can be no link between an object in one file and a publication in another. Methods discussed thus far may combine to duplicate the reference functions inherited from manual systems, but they lack elegance. They stretch the relational model without taking advantage of its powers or, indeed, those of computing. We answer the onesided question ‘Where is this object cited?‘, but not the converse ‘What is in the publication? (or . . . was in the exhibition?)‘. An information system ought to cut both ways. The relational solution depends upon an called ‘join’, which combines operation
One possible format for a file of literary references
Data definition CHARACTER CHARACTER
93
Notes
Sample content ‘Publ956AmPtg’ ‘Museum of Fine Arts, Boston. American Paintings 1815-1865. Museum of Fine Arts. 1956, Boston. 112pp, illus.’
In this illustration the ‘key’ field is the primary key of the reference file and its content must match references in the other file(s). In place of the single long ‘citation’ field one might substitute the multiple fields of a standard library card.
94
Professional Notes
selected data from two files, forming a new one suited to the purpose of the moment. The permanent files (or ‘tables’ or ‘relations’) are not changed; and usually the new file is discarded after use. This operation depends upon finding identical content in specified fields (or ‘rows’) of both files. This match must be made with the primary key of one record because, by definition, this is the only feature that absolutely identifies the wanted record. It is the handle. For example, ‘Heade, Martin Johnson’ in the ‘attribution’ column of an object record and the same in the of a biographical record ‘name’ column shows that the biographical note (or data from it) may be incorporated into the object record. In this example ‘attribution’ is not a primary key, since it can be the same in any number of object records; and they all may be said to ‘own’ the one biographical record where Mr Heade’s name is the primary key. What has been described is a ‘one-toone person to many many’ relationship, objects. But here’s the conundrum: how to relate many objects to many exhibitions and many publications-given that none of the records may contain a list? This is the ‘many-to-many’ case, and its solution involves a separate, permanent file of connections (Table 2). What this contains are Table 2. Format and sample content
Field name key 1 remark key 2
nothing more nor less than all the ‘lists’ that are missing from the other files, but here in an acceptable relational format. (The primary key is the conjunction of all three fields, and this is ‘legal’.) It would be devilishly hard to construct such a file by direct keyboard input; but, fortunately, it can be generated semi-automatically from the same data that would be needed to add reference lists to the object records. To see how this works, let us suppose the connections be joined to the object file with a view to adding a list of publications to every object that has any. First, select from the connections file all records with an object number as ‘key 1’ and a publication as ‘key 2’. In our example this is easy because all object numbers begin with a digit, all publication references with ‘I”. This step avoids having to process most of the connections again. Second, join the shortened file of connections to the object file. The result is a temporary file in which every ‘key 1’ is replaced by a full or partial object record. This, obviously, will be bloated with redundancy, since each object will appear as many times as it has publication references. However, redundancy is acceptable in a temporary file. Remember, too, that a of a relational ‘connections’
file
Data definition CHARACTER (32) CHARACTER (32) CHARACTER (32)
‘1951.25.240’ ‘Giftl951MFA’ ‘ColKarolikMM’
‘ColKarolikMM’ ‘Giftl951MFA’ ‘1951.25.240’
‘Exhl957AmPtg’ ‘#91’ ‘1951.25.240’
‘Publ956AmPtg’ ‘#SlRepro61Colour’ ‘1951.25.240’
‘1951.25.240’ ‘#91’ ‘Exhl957AmPtg’
‘ColKarohkMM’ ‘Circ1957_9(part)’ ‘Exhl957AmPtg’
‘Exh1957AmPtg’ ‘Circ1957_9(part)’ ‘ColKarolikMM’
‘Publ956AmPtg’ ‘164Ptg94Repro3C’ ‘ColKarolikMM’
‘1951.25.240’ ‘#SlRepro61Cofour’ ‘Publ956AmPtg’
‘ColKarolikMM’ ‘164Ptg94Repro3C’ ‘Publ956AmPtg’
‘Exhl957AmPtg’ ‘ExhCat’ ‘Publ956AmPtg’
‘Publ956AmPtg’ ‘ExhCat’ ‘Exhl957AmPtg’
In this illustration the primary key is the conjunction of all three fields, no one or two being necessarily unique in each record. The data used are from the actual exhibition catalogue as published (cf. Table l), except the accession number ‘1951.25.240’, which is a fabrication.
Professional Notes
95
well-designed system will not actually copy the object data but only insert a pointer to its physical location. Third, join this temporary file to the one of publications. This substitutes a full citation in place of each ‘key 2’. The file now contains all the required data. Each record consists of an object record followed by a ‘remark’ field from the connections file, followed in turn by a literary citation. The file, however, is unfit to print because of its senseless repetition of object data. It is necessary to use a printing or display programme capable of omitting data fields that are unchanged from one record to the next. Given this common facility, the output will be what is wanted: a
list of objects, each followed by a list of publication references. In our example they will even appear in chronological sequence. In the future it may be possible to go one step further and replace a literary citation with actual page images of the appropriate passages and illustrations. The technology for this exists today, but the enormo% libraries of digitized pages, including obscure publications, do not. Finally, as always, be aware that not every ‘package’ touted as relational will necessarily do everything you may read of in these pages. Do not purchase software without first viewing a full, large-scale demonstration.
Computers II: ICHiM ‘91
time for distribution at the conference. Even if this means it does not entirely reflect the content of the conference, it is nonetheless a worthwhile addition to the museological library, not least because relatively little has been published specifically on museum applications of multimedia technologies and related issues.’ One speaker summed up hypermedia as ‘a medium that combines many media and makes use of them interactively’. Several others observed that, since the visitor experience in modern museums typically has multimedia and participative characteristics, hypermedia offers a tool perfectly compatible with museums’ educational strategies. Branching, links and user-driven navigation are all concepts common to hypermedia and to the way museums organize exhibitions. No less important is hypermedia’s potential for making museum collections and other information resources accessible to much wider audiences through electronic outreach. Computer-mediated experiences of museums must therefore be seen, it was agreed, as supporting, rather than subverting, the process of museum evolution. Keynote speaker and a pioneer of interactive technology, Myron Krueger, entertained and tantalized delegates with videos of his experiments with human full-body interactivity in virtual environments, as a technique
Pittsburgh was the site of the first International Conference on Hypermedia and Interactivity in Museums (October IVYI), bringing together over 300 professionals from North America, Europe and Asia. Presentations were predominantly by representatives of museums, or other cultural or educational institutions, rather than of industry; this helped keep the promotional ‘hype’ out of hypermedia-papers tended to be more at the level of practical advice and critical assessment. Industry accessed the conference (or vice versa) through trade show and product review components. Over the course of three days some 60 papers were presented or projects demonstrated. Delegates also had the opportunity to attend full-day workshops or half-day tutorials on various aspects of the technology, as well as the chance to visit the newly opened Carnegie Science Center, featuring the latest in interactive theatres and exhibits. The conference was organized by Archives and Museum Informatics, who have published the proceedings as number I4 in their Technical Reports series. Conference chairman, David Bearman, is to be congratulated on having this volume (containing 32 full papers and summaries of 10 others) ready in
DAVID VANCE
and Curatorship
(1992), 11,92-106
Professional Notes Museum Management
and Curatorship does not publish ‘Letters to the Editor’, but this ‘Professional Notes’ section is open to all those wishing to add to or refute statements made in earlier articles. The Editors have expanded the scope of this section to provide a forum for short contributions of a more technical nature, including museum management and conservation training world-wide, and they welcome both contributions and suggestions concerning topics and authors.
Computers I: Reference Work Collections’ records bulge with references to other sources of information. Among these are literary citations, primary documents, ephemera such as art gallery fliers, auction catalogues, curatorial jottings, collectors’ field notes, press cuttings (‘clippings’ in the reports, records of inUS), conservation house exhibitions and loans for display or research, reproductions and ‘related objects’ in the same or other collections. Sources may be written, pictorial, diagrammatic, auditory or cinematographic. Some are integral parts documentation: of the museum’s own photographic files or archives. Others are published, by the museum or others, rare or in print. Some are not source materials in the literary sense but objects: studies for or after a work of art, copies, other versions or treatments of the same subject by other artists. For fragmentary objects there may be reference to other parts of what was once a unitary whole. Some sources refer only to the catalogued object, others to lists or classes of object. Others refer to the object indirectly, documenting its maker, subject or history. The object of most references is to enable one to find the actual source and, for extended documents, to find the relevant part or page. The form and amount of data needed for this are variable. Notice, too, that any given object’s set of references is open-ended, for more may always be found
or published in the future. This is another in the seemingly endless series of problems that were less troublesome in the time of paper records, when there could be some latitude for case-by-case improvizatiom and extra lines or cards might be used at will. Cannot the same degree of flexibility be regained in an automated context? As usual the touchstone is the case of the relational model, in which an open-ended list is forbidden. It will be recalled that a relational database is conceived as a two-dimensional table in which every ‘row’ contains data about one entity (one catalogue entry, in our world), while each ‘column’ holds one kind of data (e.g. year of acquisition). Every column, of course, intersects each row; and at each intersection is a field containing a single datum (or fact). There must always be one column or a set of columns such that their combined content is unique in each and every row. They contain the ‘primary key’, i.e. the name, of the row. In a catalogue database the primary key is usually the ‘object’ or ‘accession’ number. Although the database (or ‘relation’) is often pictured as an array of uniform rectangles, all columns are not usually of the same width. Each has its own data definition. One column may consist of 16-bit binary numbers, another of four-digit decimal integers and yet another of 128-byte ‘character’ or ‘text’ units. There is no theoretical limit to the width of a text
0260-4779/92/01
Ltd
0092-15
0
1992 Butterworth-Heinemann
Professional
column, though every software system must impose some arbitrary limit in practice. It would seem, therefore, that one might solve the reference problem by defining a column of very large text fields and writing in it as one would on paper. The flaw in this is familiar: first, most of the space will generally be wasted and, second, no amount of space will always be enough. Some quasi-relational systems offer an apparent solution. One may define what looks and behaves like a variable-length text field. What the column actually contains, invisible to the user, is a ‘pointer’, a numerical code that specifies a separate block of storage, apart from the relational table itself, where the text-or at least the beginning of it-will reside. This block is not huge; but, if it fills and overflows, another pointer appears at its end, another block of space is allocated, and so on indefinitely. Each pointer says, in on page x’. When the effect, ‘continued catalogue entries are displayed or printed, not the pointer(s) but the characters, retrieved from a chain of far-away textual islands, are seen. A drawback is that such ‘free text’ stored outside the table cannot participate in such processes as automatic selection, sorting and-note this well--joining.
Another consideration is redundancy. Many references, such as those pointing to record photographs, are unique, one-to-one connections, but others are not. The latter include references to publications and to exhibition history. It is always a bad idea to repeat the same data in multiple records-at least in permanent files. (Redundancy is harmless and often necessary in temporary files, as we see below.) One would not wish, Table 1.
Field name
key citation
for example, to repeat a passage like the following in each of the 164 catalogue entries where it would be appropriate: . . . published: Museum of Fine Arts, Boston. American Paintings 1815-1865. Boston. 1956 . . exhibition: American Paintings circulating 1815-1865 [followed by a list of exhibition sites and dates] . . . Instead of this almost every museum use abbreviated notation: . . . Publ956AmPtg#91Repr(colour)p61 Exh1957AmPtg#91 . . .
would .
(32) (224)
.
This serves well enough for in-house reference, but how is an outside reader to go from cryptic notes to viewing the actual publication in a library far from Boston? If the data are meant to serve the general public, then additional files are in order: files of publications cited, of exhibitions, of former collections and more. In such files the primary key of each entry would have to be the same as the standard abbreviations used for reference in the object catalogue (Table 1). Otherwise there can be no link between an object in one file and a publication in another. Methods discussed thus far may combine to duplicate the reference functions inherited from manual systems, but they lack elegance. They stretch the relational model without taking advantage of its powers or, indeed, those of computing. We answer the onesided question ‘Where is this object cited?‘, but not the converse ‘What is in the publication? (or . . . was in the exhibition?)‘. An information system ought to cut both ways. The relational solution depends upon an called ‘join’, which combines operation
One possible format for a file of literary references
Data definition CHARACTER CHARACTER
93
Notes
Sample content ‘Publ956AmPtg’ ‘Museum of Fine Arts, Boston. American Paintings 1815-1865. Museum of Fine Arts. 1956, Boston. 112pp, illus.’
In this illustration the ‘key’ field is the primary key of the reference file and its content must match references in the other file(s). In place of the single long ‘citation’ field one might substitute the multiple fields of a standard library card.
94
Professional Notes
selected data from two files, forming a new one suited to the purpose of the moment. The permanent files (or ‘tables’ or ‘relations’) are not changed; and usually the new file is discarded after use. This operation depends upon finding identical content in specified fields (or ‘rows’) of both files. This match must be made with the primary key of one record because, by definition, this is the only feature that absolutely identifies the wanted record. It is the handle. For example, ‘Heade, Martin Johnson’ in the ‘attribution’ column of an object record and the same in the of a biographical record ‘name’ column shows that the biographical note (or data from it) may be incorporated into the object record. In this example ‘attribution’ is not a primary key, since it can be the same in any number of object records; and they all may be said to ‘own’ the one biographical record where Mr Heade’s name is the primary key. What has been described is a ‘one-toone person to many many’ relationship, objects. But here’s the conundrum: how to relate many objects to many exhibitions and many publications-given that none of the records may contain a list? This is the ‘many-to-many’ case, and its solution involves a separate, permanent file of connections (Table 2). What this contains are Table 2. Format and sample content
Field name key 1 remark key 2
nothing more nor less than all the ‘lists’ that are missing from the other files, but here in an acceptable relational format. (The primary key is the conjunction of all three fields, and this is ‘legal’.) It would be devilishly hard to construct such a file by direct keyboard input; but, fortunately, it can be generated semi-automatically from the same data that would be needed to add reference lists to the object records. To see how this works, let us suppose the connections be joined to the object file with a view to adding a list of publications to every object that has any. First, select from the connections file all records with an object number as ‘key 1’ and a publication as ‘key 2’. In our example this is easy because all object numbers begin with a digit, all publication references with ‘I”. This step avoids having to process most of the connections again. Second, join the shortened file of connections to the object file. The result is a temporary file in which every ‘key 1’ is replaced by a full or partial object record. This, obviously, will be bloated with redundancy, since each object will appear as many times as it has publication references. However, redundancy is acceptable in a temporary file. Remember, too, that a of a relational ‘connections’
file
Data definition CHARACTER (32) CHARACTER (32) CHARACTER (32)
‘1951.25.240’ ‘Giftl951MFA’ ‘ColKarolikMM’
‘ColKarolikMM’ ‘Giftl951MFA’ ‘1951.25.240’
‘Exhl957AmPtg’ ‘#91’ ‘1951.25.240’
‘Publ956AmPtg’ ‘#SlRepro61Colour’ ‘1951.25.240’
‘1951.25.240’ ‘#91’ ‘Exhl957AmPtg’
‘ColKarohkMM’ ‘Circ1957_9(part)’ ‘Exhl957AmPtg’
‘Exh1957AmPtg’ ‘Circ1957_9(part)’ ‘ColKarolikMM’
‘Publ956AmPtg’ ‘164Ptg94Repro3C’ ‘ColKarolikMM’
‘1951.25.240’ ‘#SlRepro61Cofour’ ‘Publ956AmPtg’
‘ColKarolikMM’ ‘164Ptg94Repro3C’ ‘Publ956AmPtg’
‘Exhl957AmPtg’ ‘ExhCat’ ‘Publ956AmPtg’
‘Publ956AmPtg’ ‘ExhCat’ ‘Exhl957AmPtg’
In this illustration the primary key is the conjunction of all three fields, no one or two being necessarily unique in each record. The data used are from the actual exhibition catalogue as published (cf. Table l), except the accession number ‘1951.25.240’, which is a fabrication.
Professional Notes
95
well-designed system will not actually copy the object data but only insert a pointer to its physical location. Third, join this temporary file to the one of publications. This substitutes a full citation in place of each ‘key 2’. The file now contains all the required data. Each record consists of an object record followed by a ‘remark’ field from the connections file, followed in turn by a literary citation. The file, however, is unfit to print because of its senseless repetition of object data. It is necessary to use a printing or display programme capable of omitting data fields that are unchanged from one record to the next. Given this common facility, the output will be what is wanted: a
list of objects, each followed by a list of publication references. In our example they will even appear in chronological sequence. In the future it may be possible to go one step further and replace a literary citation with actual page images of the appropriate passages and illustrations. The technology for this exists today, but the enormo% libraries of digitized pages, including obscure publications, do not. Finally, as always, be aware that not every ‘package’ touted as relational will necessarily do everything you may read of in these pages. Do not purchase software without first viewing a full, large-scale demonstration.
Computers II: ICHiM ‘91
time for distribution at the conference. Even if this means it does not entirely reflect the content of the conference, it is nonetheless a worthwhile addition to the museological library, not least because relatively little has been published specifically on museum applications of multimedia technologies and related issues.’ One speaker summed up hypermedia as ‘a medium that combines many media and makes use of them interactively’. Several others observed that, since the visitor experience in modern museums typically has multimedia and participative characteristics, hypermedia offers a tool perfectly compatible with museums’ educational strategies. Branching, links and user-driven navigation are all concepts common to hypermedia and to the way museums organize exhibitions. No less important is hypermedia’s potential for making museum collections and other information resources accessible to much wider audiences through electronic outreach. Computer-mediated experiences of museums must therefore be seen, it was agreed, as supporting, rather than subverting, the process of museum evolution. Keynote speaker and a pioneer of interactive technology, Myron Krueger, entertained and tantalized delegates with videos of his experiments with human full-body interactivity in virtual environments, as a technique
Pittsburgh was the site of the first International Conference on Hypermedia and Interactivity in Museums (October IVYI), bringing together over 300 professionals from North America, Europe and Asia. Presentations were predominantly by representatives of museums, or other cultural or educational institutions, rather than of industry; this helped keep the promotional ‘hype’ out of hypermedia-papers tended to be more at the level of practical advice and critical assessment. Industry accessed the conference (or vice versa) through trade show and product review components. Over the course of three days some 60 papers were presented or projects demonstrated. Delegates also had the opportunity to attend full-day workshops or half-day tutorials on various aspects of the technology, as well as the chance to visit the newly opened Carnegie Science Center, featuring the latest in interactive theatres and exhibits. The conference was organized by Archives and Museum Informatics, who have published the proceedings as number I4 in their Technical Reports series. Conference chairman, David Bearman, is to be congratulated on having this volume (containing 32 full papers and summaries of 10 others) ready in
DAVID VANCE