Previous - Next
II. QUESTIONS TO BE PUT TO SYSTEMS SUPPLIERS
1. HARDWARE AND OPERATING SYSTEM LIMITATIONS
Computer systems are subject to hardware constraints: a given computer system is unlikely to be available in forms which will enable it to run on any computer, and a given computer is unlikely to be able to run all the computer programs or software its owners might wish to use. Among the first questions potential purchasers of systems should investigate, therefore, is the extent to which the system under consideration is compatible with systems already in use in or available to their organisation and with the computerisation policy of their institution or its parent body or funding agency. Even if they are operating in a true context of free choice, they should bear in mind that their decision on a first system will place constraints on their ability to choose future systems for different - or even for similar - applications.
It is important to check that any new system will fit in with existing systems and will not unduly restrict freedom of choice for future applications. The following types of issues arise.
IA. Hardware limitations.
1A1. Is the proposed system limited to one "family" of hardware - either one particular manufacturer model/range or a "compatible" group ? (Such limitations should be apparent through statements like "Hewlett-Packard minis and mainframes only" or "IBM XT or AT and true compatibles only" in descriptive or promotional literature.)
1A2. Does the system require other operating conditions - for example a minimum size of main memory?
1A3. Does it require a minimum capacity of hard disc storage to accommodate the system (let alone the data) ?
1A4. Does it have any special requirements in terms of control or display capability?
1B. Operating system limitations,
IB1. Is the system limited to a particular operating system or a particular version of a given operating system ? (Such limitations are usually phrased as, for example, "MS-DOS version 3.2 or later" in descriptive literature.)
1B2. Does the system match the user's expectations in the areas of single/multi-user operation or multi-tasking ?
2. SIZE AND FORMAT RESTRICTIONS
All computer systems impose some restrictions on the size of the various data elements they handle: in some cases, those limits can be set so high that the user is quite genuinely unlikely even to notice them but in others they can be something of which he or she must be constantly aware. Possibly the most invidious are those limitations which are not immediately apparent. For example, a system might place very high (and thus effectively Invisible) limits on the size of individual fields but also have an overall limit on the total record size. The overall limit may be generously high for the application for which the system was originally developed - book cataloguing, perhaps - but inadequate for the requirements of av cataloguing, which can consume a lot of space, and this shortcoming will not be apparent when the system is demonstrated in its original form. The topic of size and format restrictions is worth exploring with the software supplier in some detail, along the following lines.
2A. Field
2A1. Are fields defined within the system as being of maximum length, extendable maximum length, or open ended? (Examples of the first type would be 1130 characters maximum" - a hard and fast limit. For the second type, a definition might read 1120 characters extendable in multiples of 10 to 30. 40, 50 etc." In this case, 20 characters is expected to suffice in most cases, but the system will accept longer lengths if needed. Extensions are offered in small measures to restrict the overall growth of the file. "Open ended" or "unrestricted" means that any limit is placed so high that there is no effective limitation on length - or at least no limit until the overall system capabilities enter into consideration.)
2A2. If the system operates with a maximum length, how far is that length imposed by the system rather than a requirement of the system that the user define a limit ? (In other words, will the system not tolerate more than so many characters in any field, or does the system simply require the user to predict that so many characters will be the maximum space needed to record each type of information ? Note that user-defined field limits may still have to fit within a system-defined record limit - see below. Note also that some systems impose length limits on fields that will be defined as "searchable" but will allow unlimited length or at least less restriction on those defined as "non-searchable" text fields. It is also a characteristic of some systems to state a maximum number of characters in a field that can be used for sorting purposes even if the field itself may be of greater length: this can be significant if, for example, an archive may have a film series where episodes are distinguished only by a number coming at the end of a long title.)
2A3. Are fields fixed length ?
(In other words, if the actual data entered is less than the stated maximum length, does the computer store only the data entered, or does it store the necessary number of blank space characters to make up the difference? If only data entered is stored, the user can set generous limits that will allow for "longest possible" entries in each field: if the computer actually stores the full specified length for each field, however, this practice will add significantly to the total storage requirement and users will have to be prepared to compromise. They may, for example, have to think more in terms of catering only for "high average" rather than maximum lengths, and live with the need to truncate their very long entries.)
2B. Record size.
2B1. Does the system impose limits on the total length of a record - which could be done by limiting the total number of characters in all fields, the total number of fields, or the total number of types of fields ?
2B2. Can multiple, individually-addressable entries be made in single fields and/or are individual fields repeatable within the system; if so, is there a limit in either case on the number of such multiple entries or repeats ? (See 2C. of I. DEFINITIONS above. "Multiple entry" would be required, for example, to note several people sharing a single production role - e.g. "Direction: Powell, Michael & Pressburger, Emeric". A "repeating field" would be needed when there might otherwise be risk of misunderstanding entries. For example, if an archive wished to use a field to record both someone's real name and his or her alias - e.g. "Director: Walton, Joseph i.e. Losey, Joseph" - there would be scope for confusion between such usage - "two names for one person" - and the usage previously illustrated - "one name each for two persons". To avoid such confusion, a repeated field may be preferable to a multiple entry.)
2B3. If there is such a limit, is it user-defined or system- imposed?
2B4. Can users create and repeat groups of fields and/or fields containing sub-fields, or divide a record into sub-records ? (See 2C. of I. DEFINITIONS above for examples of possible uses of group fields, sub-fields and sub-records.)
2C. File size.
2C1. Does the system limit the total size of a file or data base, by placing a limit either on the total number of records or on the total combined character length of all records?
2C2. If the system uses an inverted file does it maintain a single inverted file for all data or separate inverted files for different fields ?
2C3. Are there system limits on the number of entries allowed in an inverted file ?
2C4. If the system offers a relational data base approach, how many data bases may be created and how many may be addressed at the same time ?
2C5. What are the restrictions (as suggested above) for each data base individually within a relational data base system and for the total system?
2C6. Is it possible to estimate in advance the likely disk- storage requirements for the total system or to provide "rule of thumb" guidelines for the relative sizes and growth rates of and inverted files based on a notional "average" record?
2C7. Does the system's performance change with the growth of files (for example by a noticeable slowing down in response when making searches) ? (See also Section 6B. for questions relating to deterioration performance with frequent amendments to data already in the system.)
3. SETTING UP THE SYSTEM
There can be a very wide difference between the experience of seeing a practiced demonstrator putting an existing system through its paces and that of being a novice computer owner opening a pack of floppy discs and a large but possibly poorly written manual and seeking to create a system that will repeat with one's own data and in one's own establishment the smooth operation that was originally demonstrated. It is essential to establish with the potential supplier in exactly what form the system is being offered. The following types of questions should arise.
3A. Specificity of application.
3A1. Is the system offered in the language the user requires - e.g. Spanish or Arabic - or only in English, French etc. ?
3A2. If the user requires more than one language is the system bi- or multi-lingual in the necessary languages? (These questions refer to the visible operation of the system - i.e. the language used in screen displays, "help" messages etc. rather than to the language of the data stored, a topic considered under SC. DATA ENTRY below.)
3A3. Is the buyer offered a tailor-made or "turn-key" application or a generalised system which he or she must adapt or have adapted to the specific needs of the buying organisation (See 2B. of I. DEFINITIONS above)
3A4. If the system is a generalised one, how easy is it for a non-expert to set up the necessary application - to create the framework of field names, types, lengths etc. that defines the shape and performance of the file and the specifications for formats etc. that determine display and output ? (This question should address both the actual ease of the operation and the helpfulness of the manual which comes with the system. It is regrettably quite common for good systems to be let down by poor manuals - see also 3B. below.)
3A5. Whether turn-key or generalised, what are the possibilities for changing the data structure definition once the file is active - for example by deleting a defined field or changing its definition, or by adding a new field ? (Note that. many systems allow new fields to be added only at the end of the existing structure.)
3A6. Can the buyer make such alterations even to a turn-key system, or must he or she expect again to employ the services of the supplier ? (The need to re-involve the supplier every time a system needs even minor adjustment can add appreciably to initial costs: it may be better either to look for a system which permits small running adjustments by the archive or alternatively to find a supplier offering attractive terms for a software maintenance and support agreement.)
3B. System maintenance and support.
3B1. Does the purchase price of the system entitle the buyer to benefit from any upgrades or improvements made by the developers of that system ?
3B2. If such rights are not automatic, will the supplier provide information services on upgrades, special prices to existing users, etc. ?
3B3. Does the supplier (and/or the original writers of the software) offer a software-maintenance service ?
3B4. What form does software maintenance take - response to failures only, or a more active help line facility - and how much does it cost? (A help line is an office which licensed users may call to receive advice on problems in using the software.)
3B5. Is there an active 'user group of people and organisations using the system, which will offer a framework for exchanging experiences and ideas for improvements to the system ?
3B6. What are relations like between the user group and the suppliers and writers of the system?
3B7. How much training and help is offered either by the supplier or by the system itself? (See 2B. of I. DEFINITIONS above.)
3B8. Is the system manual (instructional handbook) clearly written, helpfully laid out, adequately thorough in its explanations, well illustrated with examples, well indexed and (in spite of all the foregoing) still of manageable size?
3B9. Do the suppliers or writers of the software provide a sample data base to accompany the manual and further illustrate its examples ?
3B10. Can the suppliers of the software put potential users in touch with another institution which is already using the system for an exactly or nearly similar operation, so that they can discuss relevant experiences before committing themselves?
3B11. Will the suppliers provide a copy (at least of a demonstration version) of the system they wish the user to acquire, so that he or she can try it out at leisure with real archive data ? (Demonstration versions are usually - and understandably - in some way or other of reduced capability compared to the full version: for example, they may not accept more than a (low) maximum number of records or size of file. It can still be very useful for a user to have the opportunity to explore the system in contexts other than a demonstration or sales room.)
4. SYSTEM SECURITY
The data entered into a computer system is likely to represent a very serious investment for an archive, both in terms of the value of the hours of labour by cataloguing staff involved in the process of input and in terms of the disruption of the workings of an archive that has come to depend on its computer system which will follow any breakdown of that system. it is therefore important for that archive to seek reassurance that the investment is as safe as can reasonably be expected. Potential suppliers should be asked about the system's ability to withstand both accidental or deliberate damage at the hands of its users and operators and its resilience to other types of mischance. Typical questions might include the following.
4A. Security Provisions.
4A1. Does the software incorporate any security provisions, such as password protection either of designated data areas or of certain operating functions ? (For example, it may be desirable to limit access to confidential information, such as the addresses of donors, or to restrict to designated personnel only the capability to amend or delete data in the system. It is necessary to observe that password security - especially in some micro-computer systems - is relatively illusory, in the sense that it is not difficult to 'crack' the password code: however, any deterrence may be better than none.)
4A2. Does the system offer OPAC (on-line public access) facilities, with "read-only" access on any terminal designated for public rather than staff use? (Such terminals would offer no possibilities of entering, amending or deleting data, and so provide safeguards against accidental or malicious damage to the data by non-staff users.)
4A3. Does the hardware offer any form of physical protection against data loss or damage - such as the ability physically to lock or otherwise protect the keyboard, disk drives, etc.) ?
4B. System robustness.
4B1. At what stages of operation is the data in the system particularly vulnerable to 'act of god' or 'act of stupidity' damage ? (See 2D. of I. DEFINITIONS above.)
4B2. How severe may the resulting damage be, and does the software offer any damage limitation or recovery facilities?
4B3. Is the hardware vulnerable to physical conditions in the proposed working environment such as vibration, "dirty" electric power (characterised by fluctuations or "noise" from other users on the same circuit), static electricity, dust, smoke etc. ? (This question should be checked with an engineer - salesmen always claim systems are extremely robust. Suppliers should be able to recommend equipment to reduce these dangers.)
4C. Data security.
4C1. Does the system offer any help in producing security 'back- up' copies of data files, or is the user dependent on operating system facilities?
4C2. Does the system check (for example with the query "SURE-?" requiring a positive answer) before carrying out any commands that might result in the loss of data ? (Note that such checks can sometimes be over-protective, making It difficult to remove data that is genuinely unwanted, but it may be better to err on the safe side.)
4C3. Does the system invite the use of any commands that could cause damage if mistyped ? (For example, some systems use commands that are similar to the MS-DOS "COPY", "DEL" or "FORMAT" commands; if typed at the wrong moment by an inexperienced or tired operator, these might wipe out data on a large scale.
4C4. Does the system offer protection against the inadvertent double-entry of a record or the re-use of a record identifier (This is another area where a lapse in operator attention might result in the deletion of an existing catalogue entry if its number were used again for some different information).
5. SYSTEM USAGE: DATA ENTRY
As previously noted, the entry of data into the system will represent a major investment of an archives effort and staff time. It is of the greatest importance that the system be capable of accommodating and processing all the information which the archive will wish to load into it; it is also important that the system provide as much help as possible to make data entry an accurate and cost effective exercise. The following type of questions will explore the systems's capabilities in this area.
5A. Data limitations.
5A1. Does the system support the full range of characters required by the archive for example, non-latin scripts, accent or diacritics, etc. ?
5A2. Does the system designate any punctuation or other symbols for system usage, and if so which ones ? (For example, a system might reserve the colon as a separator between sub-fields. the dollar sign as an 'end of record" symbol or an asterisk as a "wildcard" character (see 7A. SELECTION); in such cases, users might not be able to use those symbols in the normal way in their own text.)
5A3. Can these symbols be re-defined if the user decides they are required within the data?
5A4. Is the system capable of recording (or at least displaying) dates in a form with which the archive will be content? (Some systems require the entry of a date in a system format which users may find "unfriendly" - e.g. 470206 for 6 February 1947; some may have problems with dates earlier than 1900 or later than 2000.)
5A5. Is the system capable of manipulating dates to the level of sophistication an archive might require - for example by working with date spans such as "1919 - 1933" or with date approximations such as "circa 1906?)
5B. Record/field identifications.
5B1. How does the system recognise the unique identity of a record: by the entry in a user-defined field, such as 'inventory number' or 'main title', or by a system-generated reference number ? (With the use of system-generated numbers, there is not likely to be an automatic safeguard against the double-entry of information on a film by two cataloguers unaware of each other's work; on the other hand, a requirement accurately to key in the full text of a main title before a record can be re-opened for editing or correction can be time-consuming and irritating.)
5B2. How do the system and/or the user identify individual data fields and sub-fields: by field names or labels, or by combinations of numbers, letters or other symbols? (Many systems use short tags consisting of letters and/or symbols to identify fields or to break fields up into sub-fields: some users find these unfriendly or difficult to learn.)
5C. Data entry facility.
5C1. Does the system provide facilities for validation - the checking of data as it is entered into an individual field? (Many systems offer at least the validation of data by type, length or pattern - e.g. alphabetic or numeric characters only; exact length or length within permitted limits; data in a specific pattern such as that required by dates; etc. Some systems, however, do not even offer this level of checking, while others do not extend it to all fields - for example, not to sub-fields.)
5C2. Does the system support an authority list or offer any comparable facilities: if so may an authority list be specific to individual fields or field types (for example, personal names) or is there one list generalised over the whole record ? (Systems may offer checking of data against an authority list of approved terminology - terms not found in the list are rejected or at least queried. This facility is most useful when a field has its own specific list. Procedures to add new terms are of varying complexity. In some of these systems there is also the facility to display the authority list for a given field as a menu of options from which the cataloguer may make a choice when cataloguing a film.)
5C3. Can the system facilitate data entry by automatically offering "probable" data for particular fields which the cataloguer may accept or over-write ? (It might save time, for example, if a gauge entry of "35 mm." or a language entry for the language of the country of the archive were automatically offered in the relevant fields as most-like options: the cataloguer would accept these entries with a single key-stroke, or overtype with the appropriate data.)
5C4. Can data be "held over" from one record to the next on the same accept-or-over-write principle, or stored for recall as "constants" in a holding file ? (Such facilities would, for example, mean that a series of film might be catalogued without the cataloguer having to re-enter t production credits and series title for each film individually.
5C5. Does the system support a facility for recognising coded abbreviated entries made by the cataloguer and expanding them the full text entry in the catalogue file ? (This facility would mean, for example, that cataloguers might type entries of "b" or "c" in the colour field and the system recognise them as meaning "B&W" or "Colour".)
5C6. Does the system support calculation of data for one field interpretation to specified formulae of information entered elsewhere - for example, a calculation of running time based on entries made for gauge and length ?
5C7. How does the system approach the question of subject or keyword retrieval: does it require the entry of separate lists of keywords or index terms, or is it capable of extracting keywords from text (e.g. of a summary) in which they are embedded ? (Some systems make long text fields "unsearchable": therefore, terms which need to be searched for must be entered into separate fields. This represents extra work for cataloguers/indexers though, in compensation, it gives an archive the possibility of producing specialised indexes - of people, places, events, etc. - rather than offering a single generalised searching capability: it will also facilitate production of printed indexes to accompany a printed catalogue. Other systems automatically enter in the inverted file all words in text fields apart from those on a stored list - a list of common words. This can give great flexibility in searching and reduces the burden on cataloguers of repeating keywords in index-fields: however, it substitutes the alternative burden of requiring cataloguers to write summaries in such a way that the terminology used is appropriate for searching. It also precludes the easy generation of actual subject indexes and tends also to increase the storage overhead of the system. A third category of system may offer in a kind of compromise the facility to mark a word or term in a text field as being relevant for indexing purposes.)
5C8. Is it possible (and, if possible, is it easy) to "import" data into the cataloguing system from another system ? (For example, an archive may find a specific data-entry package which offers some of the facilities listed above if they are not available in the main cataloguing system itself. Similarly, cataloguers might find a generalised word-processing package more convenient for the preparation of summaries than the system's own facilities. Finally, an archive may be offered machine-readable data from an outside source - e.g. distributed tapes in MARC format. In all these cases, it would be important to discover how easily the cataloguing system could batch add (see 2B. of I. DEFINITIONS, above) the output from the other sources.)
5C9. On completion of an input cycle, the data must be compiled into the system, with the inverted file(s) being updated etc. - a procedure which may take considerable time. Does this process happen at the end of each record, or at the end of an input session ?
5C10. Does the system offer facilities to defer full updating of the system after data entry?
6. SYSTEM USAGE: DATA EDITING
However thorough their procedures for checking data on entry, archives are likely to wish to amend or add to information already in their cataloguing systems: new information may come to light requiring the correction of previous assumptions or the entry of references to the new sources; the archive may acquire or make a new copy of a film, and so on. It is therefore necessary to explore the facilities offered by the system for editing the data it contains. Questions such as the following may be appropriate.
6A. Editing Procedures.
6A1. How easy is it to edit a record that already exists within the system by the addition, deletion or amendment of data in existing fields or in fields allowed in the data structure but not previously used in the record? (The addition of fields not previously allowed for to the structure is a matter of system change rather than mere data amendment - see 3A. SPECIFICITY OF APPLICATION above. Changes made to the catalogue file must be reflected in the inverted file(s), so the operation can be less simple than may at first seem likely: hence the following three questions.)
6A2. Does the cataloguer use a familiar process (for example, the same screen layout as is used for data entry) or is some special procedure required?
6A3. Can the cataloguer hunt for errors and proceed to make the necessary amendments In the appropriate records in a single operation, or would two separate aspects of the system involved? (Commonly, a system will not, for reasons of security, offer data editing facilities to those engaged on a search operation; a network system's file-locking or record-locking protocols may also expect the two functions to be separate. A user would thus have to search out an error, note the records needing amendment, leave the "search" part of the system and enter "edit", and then call up the relevant records. This is time consuming - though the security dimension should not be overlooked.)
6A4. Does the system offer any facilities for global editing or batch editing ? (These would be facilities either for making the same change to all occurrences of a given piece of data anywhere in the file - e.g. globally altering all mentions of "Peking" to read "Beijing" - or for making a given alteration to all records in a designated area of the file - for example, to change the copyright status of all films acquired from a particular donor.)
6B. Editing implications.
6B1. As noted earlier, in multi-user systems it is necessary for the system to have protocols that resolve the conflict between two users seeking access to the same record: is the system suitably equipped in this respect?
6B2. After the cataloguer has amended the data, the system must again update the inverted file(s): is this procedure an automatic part of an editing operation, or can it be deferred to a later time? (As with updating after data entry, this can be a lengthy process which it may be more convenient to run overnight or at a time that minimises disruption to researchers or other users.)
6B3. Does the performance of the system deteriorate if records are repeatedly edited or amended? (With many systems, the answer to this question is "yes", though suppliers are unlikely to talk willingly about it. Whereas data is originally loaded into a system in a reasonably coherent sequence, continuous amendment will disrupt this sequence and it will take the system longer to track down and re-combine the elements of data required for an operation. A common but often very time-consuming treatment for this problem is to down-load or dump the contents of a file and then reload it to restore something like the original coherence. The next two questions reflect this procedure.)
6B4. Is it possible to restore deteriorating performance - for example by dumping and reloading the data base ?
6B5. How easy (and how safe) is it to carry out a "dump and reload" procedure, and how long will it take ?
7. SYSTEM USAGE: DATA RETRIEVAL
When attention moves from the entry of data into the system and the editing of data already there to the retrieval of that data, one is finally addressing the issue of how the system will be used in the daily operations of the archive beyond the cataloguing section and how useful it will be in that context. It is as well to have a clear idea of the facilities that the methods already in operation in the archive are able to provide: how many users can be handled simultaneously, what sorts of questions can be dealt with, etc. Check that the new system is not offering any deterioration in existing facilities before worrying about what new facilities may be on offer! Having said that, it is also worthwhile to try to identify patterns of use which would be welcome in the archive but with which present methods are able to offer little help. Use such preparatory work to provide specific working examples for the following generic questions, and to determine priorities among the facilities that may be on offer.
7A. Selection.
7A1. Does the system offer a search language which users in the archive are likely to find adequately "user-friendly".
7A2. Does the system search a whole record or designated fields only - or may the user choose ?
7A3. How does the user designate the fields (or sub-fields) for a restricted search: is it possible to work on a screen that resembles the input screen or the standard display screen ?
7A4. If system field labels or tags must be used in designating the specific area for a search, can the system provide on-screen information on the data structure to help the user?
7A5. If the user is making a composite search, does the system support the usual Boolean operators for linking search targets, and does it also offer more precise targeting? ("'Boolean operators" enable enquirers to link targets in composite searches: the principal operators are 'AND', 'OR' and 'NOT'. Note that the meaning of these words is not quite the same as that in normal grammar: for example "FIND A AND B" means find records in which both A and B are present; "FIND A OR B" is the correct way of indicating that all occurrences of A and B are of equal interest. Examples of "more precise" targeting would be "X AND Y in the same occurrence of a repeating field" or "X AND Y within so many words in the same field", etc.)
7A6. Do the system's search facilities permit users to build up or refine complicated searches in stages by using the results of previous searches ?
7A7. Can well-established search patterns be held in some suitable form for easy access, and can complicated search formulae, which may be needed again, be stored for use in future sessions ? (For example, an archive may wish to store as a standard search "Find films with ... listed as director"; alternatively, a staff member who has built up and successfully used a complex enquiry for example, "Find films made in [country of archive] before [date of last use of nitrate in that country] with NO [safety] [viewing print]" - might wish to store the enquiry to run again, perhaps at quarterly intervals.)
7A8. How much flexibility does the system offer in matching targets? (The basic method of targeting data in searches is string- matching - i.e. recognising in the searched file the "string" or sequence of characters specified by the searcher. More sophisticated methods supported by a number of systems include the following:
wild cards or masking characters - the ability to indicate in various ways that the searcher does not care what character is found in a particular place in the string, for example, designating the search target as "organi?ation" to find spellings with either s or z, as "wom?n" to find occurrences of woman or women or as "195?" to find any date in the decade 1950-1959; alternative characters - where the use of a wild card in "Jo?n" intended to find John or Joan would also pick up unwanted references to Join, some systems allow the user to specify a range of acceptable alternative characters, e.g. as "Jo(a!h)n"; truncation - designating a search target in which all words with a common beginning (right-truncation) or, less frequently, a common ending (left-truncation) will be found, for example "direct*" to find director, directing, direction, directed, etc. or "*tography" to find photography, cinematography etc.; homophones or sounds-like - specifying an approximation of the word required if the searcher is unsure of the spelling: one system demonstrated to the writer successfully found 'Australia' when given the "sounds like" search target 'OSTRALYER'; creator than, less than or from... to - searching for a numeric or alphabetic range: commonly used for dates or dimensions - e.g. "> 1956" having the effect of "after 1956", or "running time < 30 minutes" - but also useful as an alternative to truncation - e.g. "from BRIT to BRIU" to find all uses of Britain, British etc.)
7A9. How does the system treat punctuation encountered in searching, including commas, hyphens, "end of line" or "carriage-return" symbols etc., and will this approach affect the archives possible searching requirements ?
7A10. Are the system's capabilities with regard to dates (as already questioned under data entry) adequate to the archives needs ?
7A11. Can the searcher safely halt or abandon before completion a search that he or she realises is inadequately defined or likely to take too long ? (Note the word safely.)
7A12. Most systems search through the inverted file(s) for data selection purposes, but some will also scan the master file if required: is this option available, and does the system warn the searcher that the process will take some time ?
7A13. Can the user browse the inverted file to choose search targets ? (It can save a lot of time to know which items it is worth searching for before initiating a search.)
7A14. Is the inverted file able to be used for any thesaurus-like operations ? (For example, in some systems the authority list may be used to provide a broader term/narrower term relationship between terms so that a search for "EEC" would automatically include all the individual member countries of the European Economic Community, or to offer some kind of synonym control so that "advertisement" and "commercial" would be cross referred.)
7A15. Is the searcher given reports on the progress of a search (e.g. the number of "hits" for each of the terms in a cumulative search) ?
7A16. Is the searcher able to scan the results of his or her search without seeing the whole of the record found ? (Some systems will display the record identification with an extract from the record showing the "context" of the find, perhaps with the target data highlighted. This can be helpful in rapidly identifying the useful from the less useful.)
7A17. If a user has a requirement where the search target is most easily specified negatively, does the search logic cope efficiently ? (Examples of such searches might be "all films except those where the production country = USA" or "all films which do not have an entry in the director field". Some systems are oriented primarily to positive searching, and would need to precede such searches with a command that would have the effect of "find everything" - a command which, however, is not always available, and for which some of the substitutes may take a very long time to process. Other systems find it difficult or impossible to search for an absence rather than a presence. These are not universal problems - in many systems, these are wholly irrelevant concerns; buyers should nonetheless ask the question because when it is a problem it can be a major one.)
7B. Display.
7B1. Can the user immediately see the results of a search - displayed on the computer screen or printed out - or is display a separate operation from searching ?
7B2. May the results be displayed only in a standard system format (and is it acceptable) or can they be displayed in the format used for input and/or in purpose-designed formats?
7B3. In screen-display, can the user browse backwards as well as forwards ? (In other words, having got to screen 3 of a display can he or she return to page or screen 1 without having to re-display? Surprisingly, not all systems offer this facility.)
7B4. Can the user have search results sorted for display in an order other than that determined by the record-identifier or by the search target ? (An example of such a requirement would be to search for films by a named director and display the results sorted by date.)
7B5. Does the archive have flexibility in determining how the system is to sort data entered in catalogue records, and if so, are decisions taken once only for the whole record, or may individual fields be defined differently ? (An archive may have preferences as to whether, for example, text should sort alphabetically "letter by letter" or "word by word" - in other words whether 'I do' should precede or follow 'Ice'. A system may also be able to offer the option of ignoring opening definite or indefinite articles in one or more languages so that 'Les automanes' files under "all without a need to change the word order; care must of course be taken in multi-lingual collections to make sure it is possible to avoid the inadvertent mis-filing of titles beginning with words that are articles in one language but not in others, as in 'Les Patterson saves the world'. A third issue may be whether numeric data should file as numbers or as decimals - i.e. in the sequence "1, 2, 11. 100" or 111. 100. 11. 2" - the latter being required for DDC or UDC (Dewey or Universal Decimal Classification) or similar classification schemes.)
7B6. If the system offers the archive the opportunity to design its own display or print formats, how easy to use is this report generator component of the system ?
7B7. Will the system generate all the forms of printout the archive may require ? (This obviously includes the field of cataloguing (for example: catalogues, indexes, or enquiry reports - e.g. a printout of details on a particular film, or a listing for a requested genre). Archives might, however, wish to explore possibilities useful for administration as well. In this category might be reports such as location lists, tables or even graphs analysing the collection by different criteria (e.g. domestic/foreign, film/television, colour/black and white, etc.), acquisition reports for management boards, programme notes for theatre screenings, or routine letters asking collectors to renew the deposit of materials held by the archive on loan.)
7B8. Does the system connect satisfactorily with the range of printers available to the archive ? (Note that special character sets or graphics capabilities may be a problem.)
8. THE OUTSIDE WORLD AND THE FUTURE
Although the principal issues considered here have been the immediate internal cataloguing needs of that archive, it is worth spending a little time considering the role the system might play in connection with other aspects of work within the archive and in the archives connections with the outside world. Thought should also be given to the system's suitability for some technological developments that are imminent. Some relevant questions might be the following.
8A. Connections with other systems.
8A1. How will the cataloguing system be able to link in with other computerised aspects of an archives work ? (Possible areas might include interaction with the archives acquisition procedures; loan and movement procedures; technical inspection and preservation procedures; theatrical programming activities; records relating to the copying of materials from the collection for television and production companies, for individual researchers, for other archives, etc.; information systems on other collections such as stills, posters, documentation, books; information systems on non-collection material such as filmographies; etc. These are not examined at length here, but all might be explored with the cataloguing system supplier. At the same time, however, the Commission would urge archives not to postpone the introduction of efficient film cataloguing procedures because of an inability to afford or to design a single, all-embracing information system covering all conceivable archive needs. Collection cataloguing is too important a fundamental requirement to allow such delays.)
8A2. If the archive thinks such usage might be advantageous, can the system accept input other than via the keyboard ? (An archive may, for example, wish to explore the possibilities of entering the text for summaries from old manual records via a scanner with OCR facilities, or of offering mouse-operation on retrieval searches - see IF. of 1. DEFINITIONS, above. Input from a bar-code reader might be important for an archive thinking of using bar-codes for other aspects of its work.)
8B. Connections with the outside world.
8B1. Can the system output data in a format that will readily communicate with another system if the archive is offered the chance to exchange data with other comparable organisations ? (Existing standards for data exchange in machine-readable formats include the MARC format and ISO 2709. Work on formats for data exchange has also been done by IFLA in the shape of the ISBD(NBM) (International Standard Bibliographic Description for Non-Book Materials) and by the FIAF Cataloguing Commission which has in preparation the FIAF standard Cataloguing Rules for the description of film in data exchange. Other customised formats may be developed by other data centres.)
8B2. Can the system generate data in a way that could be used by a desk-top publishing system or computerised type-setting to produce catalogues, filmographies, viewing notes, etc. ?
8C. Connections with new technology.
8C1. Do the suppliers of the system have any thoughts about the possibility of linking the cataloguing system to large-volume data storage systems based on optical discs, such as CD-ROM ? (CD-ROM - see 1G. of I. DEFINITIONS, above - and other similar technologies constitute a possible future answer to cheap mass storage of data that will not be significantly altered after its initial creation, although not an appropriate answer for data that is frequently updated. Cataloguing information (as distinct from administrative data) is frequently in the former category, and archives may be interested at least in keeping the option open.)
8C2. Do the suppliers have any thoughts about the possibility of linking the cataloguing system with systems to retrieve other forms of document or visual material ? (Technology now available already offers two possibilities. The first is the storage of digitally analysed still images on machine-readable storage media like the disc on which the computer data itself is held, so that the same system can call up both data and images - which could, in the context of a film archive, be "stills", posters, pages from scripts, letters or other documents, etc. The second possibility is to have the computer and the system running on it control the simultaneous operation of a linked video-disc player, so that the operator potentially has access (as well as to the catalogue data) to sequences of moving image material (with or without sound) and to the sorts of still image described for the previous system. Naturally, such facilities add appreciably to the cost of the total system. As well as the extra equipment required to generate the scanned or video images from which either system would start, the first system requires a very substantial increase in storage capacity (storage of a single image can require several Kb of disc space) and the second requires investment in the necessary video-disc players etc. The former system will also require the availability of a high-resolution screen to display the stored image - much higher in resolution (and therefore expense) than the screen required to display text only. The same may be true of the second system, though the alternative of twin-screen display (one for the video, one for the computer) should also be available. These possibilities may still seem a little far fetched at the moment, but the general history of computers suggests that today's far-fetched dream is tomorrows commonplace, and archives would do well to encourage suppliers to think hard about the obvious applicability of this sort of development to the film-archive field.)
CONCLUSION
It is perhaps worth repeating that there is little chance that any system offered to an archive will score a 100 % success rate against any list of desirable features or any specification of requirement, and no chance at all that a single system will score highly on all the questions raised here since some issues are mutually exclusive. The important consideration is that the purchasing archive be aware of the potential scope of cataloguing systems and of their potential limitations: an archives staff should not be obliged tb live with anything less than the best approximation to the ideal that can be found within the reach and budget of that archive.
At the risk of stating the obvious, potential buyers are reminded not to be satisfied with a theoretical discussion with a supplier. A new cataloguing system is in the archives terms, if not necessarily in the supplier's a major commitment, and one that needs to be very thoroughly prepared. Buyers should ask to see systems in operation: they should ask, if possible, to be put in touch with other users, especially ones whose needs approximate to those of their own archive; perhaps the membership of FIAF will provide an example of an existing user. A supplier anxious to make a good impression should be willing to provide a copy of the system on loan or at least to set up a demonstration in the show-room so that the buyer can enter some archive data and see how the system performs. Some systems are available in free or cheap demonstration versions (with the computer programs adjusted to provide less than full capability) so that a potential user may investigate those systems in his or her own time. Any such opportunity should be carefully explored. The decision is an important one. and it should not be rushed.