Outline of the Categories of Information
Building a Common Framework for Catalogue Entries
Implementing a Common Framework
Organization of the Guidelines
Subjects/Built Works
People/Corporate Bodies
Geographic Locations
Bibliographic Sources
Group Entries
Volume (Sketchbook) Entry
Item Entries
Printer Friendly PDFs

A Guide to the Description of Architectural Drawings

Implementing a Common Framework

The preceding discussion identified the components of a broad framework for a common approach to cataloguing. The implementation of such a framework, described below, is directed primarily to computerized databases, but it deals with concepts that are relevant to other approaches to cataloguing.

Choosing an Appropriate Data Structure

The structure and content of traditional catalogue entries reflect the formats developed for conventional methods of dissemination. Computerized records for architectural drawings and archives offer an opportunity to expand on traditional approaches. In particular, computer-based systems eliminate the need to record information in the form or forms in which it is to be viewed. The objective is an ability to generate printed—and in the future illustrated—catalogue entries with a minimum of effort, but also to be able to retrieve by as many individual pieces of information as possible. Information for entries must therefore be compiled, recorded, stored, and made accessible in ways that allow both these aims to be achieved.

Numerous considerations are worth keeping in mind in the design process, among them the level of skill required to operate a system, the resources required to capture information, the speed of retrieval, and the quantity of information that can be stored. The ability of a computer-based system to meet the requirements of its users depends not only on the information content, but on the data structure in which it is held. Data structure refers to the entities within an entry, the categories of which they are composed, and all the relationships that are established within this framework. The suitability of any data structure may be determined in part by asking the following questions:
  • Can it be used to record all the categories of information required?
  • Will it hold that information in a way that is both logical and consistent?
  • Is it possible to retrieve information from the categories that are designated as access points in all the combinations that are required?

An important aspect of this process is the decision whether to adopt a flat or a relational data structure. In the former, all information about an item, its subject, related people, etc., resides within a single file, while in the latter, categories of information are distributed among a number of files (often referred to as tables). The advantage of flat structures is that they can be relatively cheap to implement and easy to use. This ease of use results from the fact that all the information that pertains to an entry is held in a single file, making the retrieval of that information a fairly simple process. The great disadvantage of flat structures is, however, their lack of flexibility. This relative inflexibility means that they are not well suited to coping efficiently with relationships between the categories of information of which an entry is composed. For example, a repository may have to catalogue a single drawing that depicts several subjects, some of which may be depicted—individually or collectively—by a number of other drawings in the collection. In the same way, a single draftsman may have been responsible for a number of drawings, while a single drawing could be the work of more than one draftsman. Similar relationships—sometimes characterized as many-to-many relationships—will exist between all the principal categories of information into which an entry can be divided: in the context of the Guide, groups/items, subjects/built works, people/corporate bodies, and geographic locations. Some relationships between these can be expressed as follows:

  • Items will have geographic locations, makers, and subjects.

  • Subjects/Built Works may be depicted by items, may be related to people, and may have geographic locations.

  • People may have made items, may be related to subjects and built works, and may have known loci of activity.

  • Geographic Locations may be locations of items, subjects, or built works, or be the loci of activity of people.

Other principal relationships are shown below:
Relationships between Groups/Items and authorities

In other words, each of these areas is related to all the others. An attempt to implement this model on a flat system would result in an unwieldy structure that duplicated a great deal of information. The constraint of expending time and effort in duplicating information of this sort has led many institutions with flat systems to opt for relatively unambitious and therefore limiting records that typically do not allow for ancillary information such as a biography within an entry for an item.

The most common solution to this problem, and one which is being adopted increasingly, is to use a relational database system. Relational databases allow for data structures that hold the information relating to a single entry in a number of files. The principal files, or groups of files, correspond to principal areas of information: groups and items, subjects, built works, people, corporate bodies, and geographic locations. Categories of information extrinsic to groups and items are stored in authority files, those files being linkable to all the other files needed to answer a particular query, or for the creation of a catalogue entry. A relational structure implemented along these lines enables the user to make requests such as: "find all items (item file) that represent the Ponte Vecchio (subject file) by draftsmen (persons and corporate bodies file) whose locus of activity was France (geographic location file)."

The strength of the relational database, then, lies in its ability to mirror relationships between entities, and to make it possible to record and retrieve information by relating fields that reflect those entities. The weakness of this approach is that a number of specific links must be made between the files in order to answer a query. Also, the more fields and groups of fields that need to repeat, the more complex the process of extracting information from them. The corollary of a gain in flexibility of structure can, therefore, be a loss of flexibility in use. The more complex the structure, the more time-consuming it can be to add information to it and retrieve from it. It is important, therefore, to strike a balance between structural complexity and ease of use.

Back to Top

Recording and Relating Information

The extent to which the categories of information defined in the Guide can be adopted and the ways in which they may be implemented depend on the type of retrieval system proposed. The Guide does not seek to recommend a particular approach or specify a data structure. There are, however, considerations of data structure implicit in the definition of categories and the relationships between them, since implementation would require either a highly linked relational data structure or a great deal of repetition of individual categories or groups of categories. Some general guidelines on implementation given here cover:

Recording multiple pieces of information within a record
Preserving hierarchical relationships within and between categories of information
Recording information of the same type in different contexts
Relating records
    Recording multiple pieces of information for a single category

One of the problems of designing any retrieval system is that of recording different pieces of information that belong to the same category, e.g., when two or more architects designed a particular building. In a manual system this would be handled by making a separate index card for each architect. For computerized records there are a number of possible approaches, some of which are specific to certain types of software. One solution is to record all these pieces of information in the same field, in the form of structured free text. By using punctuation marks or other delimiters, more than one piece of information may be cited. This process is sometimes called subfielding.

The following examples demonstrate ways in which to record more than one medium for an architectural drawing.


brown ink, brown wash, black chalk

Another solution is to create a predetermined number of occurrences of a field and ensure that only a single piece of information appears in any one.

Medium 1:

brown ink

Medium 2:

brown wash

Medium 3:

black chalk

A third is to use a relational system capable of allowing for an unlimited number of repetitions of individual fields, or groups of fields.


brown ink

brown wash

black chalk

There are limitations to all three of these options. The first is the easiest to implement, but offers the lowest potential for retrieval and manipulability of information. The second is relatively unwieldy and inflexible. It also creates a problem for retrieval by requiring searches to be run on every occurrence of a field in order to determine whether the information sought is present. Adopting the third option increases the complexity of the data structure, but it does increase its flexibility.

Another advantage of relational structures is their ability to allow for the creation of additional occurrences not only of individual fields, but also of groups of fields holding related pieces of information, e.g., the categories of information that combine to provide the geographic location of a building. The ability to repeat groups of fields also allows the recording of information such as the past name(s) of a geographic location as well as its present one(s), and the name in the vernacular as well as in the language of the repository. This is a particularly useful way of providing cross-referencing within authority records.

    Preserving hierarchical relationships within and between categories

Proper names and generic terms may subsume narrower terms and be subsumed by broader terms. If both broad and narrow terms are entered in the same field, the potential for retrieval of information held in that field will be reduced. For example, if a search is made in a field designated Building Type (by function/form) using the term house, the only records retrieved will be those entered as such. The query will not find all the houses that are recorded using narrower terms for house, such as cottage or, narrower still, cottage ornée. One solution is to have fields corresponding to more than one level of description, e.g., Building Type (Broad) and Building Type (Narrow). Another is to link the field to an online thesaurus that is structured in such a way that a query results in the retrieval not only of records in which that term was used, but also of those in which any children of the term appear.

There can be hierarchical relations between categories, as well as within them. Examples of categories that comprise a number of pieces of information at different hierarchical levels include Administrative Unit and Geographic Location. In the case of the former, repositories may wish to have a separate field for each level of the hierarchy. This would make possible retrieval, sorting, and display at the level of the administrative unit, not just at that of the repository as a whole. Similarly, the recording of a geographic location as a number of separate but related fields provides a greater degree of flexibility in retrieving and manipulating locational information (see Geographic Locations).

    Recording information of the same type in different contexts

One of the best examples of recording information of the same type in different contexts to be found in the Guide is the names and roles of people and corporate bodies. Such names are recorded in the following contexts:
  • Name in the People/Corporate Bodies authority file

  • Alternate Name in the People/Corporate Bodies authority file

  • Name [of origin/maker] in the Groups/Items file

  • Name [of former owner] in the Groups/Items file

  • Related Person/Corporate Body Name in both the Groups/Items file and the Subjects/Built Works file

  • Author Name in the Bibliographic Sources authority file

In a relational system all these names could be recorded via data entry screens designed to capture the particular categories of name, but might be stored in a single location: the People/Corporate Bodies authority file. The advantage of this solution is that only a single occurrence of the name is stored, and that name is authority-controlled. Queries on name could be carried out across the database by searching a single field, rather than seven. If preferred and alternate names are recorded in a single field, there must be a mechanism for indicating the status of individual names (e.g., preferred or alternate); see Ill. 8. This would make it possible to see at a glance which name in an authority record is the preferred one, and to screen out alternate versions for some displays of the information.
Categories that record the names of people and 

corporate bodies

Another example of a concept recorded in different contexts is the notion of roles, which are recorded in the following categories:
  • Life Role(s) in the People/Corporate Bodies authority file

  • Author Role in the Bibliographic Sources authority file

  • Role (Broad) and Role (Narrow) in Groups/Items

  • Related Role in Groups/Items and Subjects/Built Works

A person, or corporate body, can have a number of roles, each of which is specific to the context in which it is recorded (e.g., as the draftsman of a particular drawing, or the architect of a built work). If roles are recorded, but are not linked to their contexts, then a user might be able to find out that a particular person had been both a draftsman and an architect, but not which of those roles applied to particular items and subjects. It is desirable, therefore, to link people and corporate bodies to the groups or items, subjects, or built works with which they were involved via the roles they played.

    Relating one record to another

A data structure should provide some means both of relating the entities that combine to create a record and of relating one record to another, e.g.,
  • A record for a group to a record for an item within that group

  • An authority record for an architect to a record for his or her partner

  • A record for a complex of buildings to a record for one of the buildings that make up the complex

When records of the same type are related, they have a recursive relationship. The links that establish these relationships can be provided in a number of ways. One of the most common is to enter the primary record number or some other unique identifier of the related records in a field designed for that purpose.[1] The fact that two or more records have this value in common makes it possible for the system to recognize that a relationship exists between them. The unique numeric identifiers used to create these links in relational systems are called keys.

Back to Top