Vol. XIII, No. 3

Winter, 2001

I hosted a workshop at the AIA/APA meetings in San Diego. The title was rather vague, to say the least -- "Archaeological Computing."

The vagueness of the title was not accidental, since my intent with the 2001 workshop was to aim the discussion less toward matters of specific programs and hardware and instead to try to confront some other issues such as, but not limited to, the following:

• Impact of computers and computing on the excavation/survey process and the staff.
• Personnel needs -- computer personnel AND the impact of computer processes in terms of time and attention required from all the members of the excavation team.
• Electronic publication as a part of the computer plans -- either as the ultimate publication or as interim publication(s). When and how should publication aims be considered in the overall computing plan?
• Computer and data security and safety.
• Trying to add computers to an on-going project.
• Finding computer processes that are appropriate for different tasks/project types.
• How much of the recording of excavation information should be done with computers, and how should the various kinds of information be related? How should new types of information be added to an existing system?

An announcement sent to various email lists included the foregoing description of the intent of the workshop so that potential attendees would better understand the intended nature of the meeting.

A group of thirty or so attended, and what follows is a biased report on the discussion -- biased not only by my own views but by the fact that I was trying to direct the discussion and may therefore not remember accurately all that was said.

The session began with two relatively short notes to serve as starting points. First, I argued that computer data can no longer be considered an aid to the process of getting information onto paper for publication or display. The computer data files -- whether in CAD, database, or GIS form -- are the crucial records from an excavation or survey. They are not intermediaries between the process of finding information and publishing it; they are the only forms capable of expressing the information fully and accurately. Though I did not go on to explore the implications of that view for publication, I did emphasize the change in attitude that may be required. Some project directors still view the computer data as, in a sense, a way-station on the way to publication; the time has come to view the computer files instead as the full representation of the information gleaned from a project -- information that will form the base for interpretation and analysis of a project both now and in the distant future when new scholars examine the same information with new ideas, new comparanda, and new theories. (For CSA Newsletter articles with related discussions, see "Digital Publishing At UCLA's Institute Of Archaeology," Louise Krasniewicz, Director, Digital Archaeology Lab, UCLA; Fall, 1999, vol. XII, no. 2: and "A Catalog Is Not A Database," H. Eiteljorg, II; Spring, 1997, vol. X, no. 1.)

It is worth repeating here one example of thinking about computer data as if paper representations were the real goal. A colleague has been considering using CAD. One of the things he needs is a way to print out drawings with heavy lines where he wants them for emphasis. He also believes that he needs to control the placement of the lines so that specific edges of heavy lines can be used to take measurements from a drawing. In his view, the actual position of such a line must not be determined by its center, because a user cannot accurately take a measurement to the center of a line from a drawing and use that measurement to determine a distance, via scale, between points. He is right, at one level, but a user of a CAD model should never need to measure a drawing at all. The model itself can be used directly for measurements; it can be queried directly for any measurement, and no user should need ever again to take a scaled measurement and calculate its real-world value. That is just the kind of attitude that must change. The digital data supply the information; drawings and tables are illustrations, not the best sources of dimensions or tabular data.

I also provided the attendees with a short review of some information about computer usage in archaeological projects that can be gleaned from the CSA web site of archaeological projects. Actually, the data in the underlying database provided the facts of note, not the Web site per se. Summarized briefly, those facts were as follows:

Any figures must be treated carefully, since all information was voluntarily submitted to go on the Web and since some computer sophistication could be expected of anyone who bothered to respond to the request for information. Nonetheless, of significant interest is the fact that "heavy users," those using at least word processors, database management software, and either CAD or GIS, accounted for sixty percent of the projects. On the other hand, "light users;" projects not employing database management, CAD, or GIS software; accounted for fourteen percent of those in the survey. Given expectations about who would respond to the survey, the general level of use of computer software is not surprising.

The meeting then moved into discussion mode, as planned, with a general question about computer processes in field projects: given the importance of the digital data collected, what level of oversight is required when computer processes are applied in field projects? The people in the session were keenly aware of the problems. Specialized software requires specialized knowledge, but project directors often lack such knowledge. Moreover, without some level of understanding, even the most basic oversight is difficult, if not impossible.

The discussion was first diverted to a related issue when some of the members of the audience asked about the use of project management software. Since such software is not widely used in archaeology -- to the consternation of some of those present -- the discussion then returned to the issue of oversight.

The sense of the meeting moved first in one direction and then another, since the practical questions kept intruding. Indeed, practical issues of prime importance had to be consciously pushed aside to make some progress possible; we ignored financial constraints, issues involving the computerizing of long-running projects, and problems that plague smaller projects without funds to hire specialized personnel. The aim was to arrive at a consensus concerning the ideal situation -- a new project large enough in scale (and budget) to use computer processes well and wisely.

After lengthy discussion concerning the oversight question -- none of those in attendance suggested that the project director could or should directly oversee all the computer work -- there were two positions at either end of the scale of oversight diligence. Some argued that computer specialists should be given the requirements of the work and then allowed to operate more or less independently as contractors. Others thought that project personnel must be able to judge the quality of the computer work based on their own expertise. Naturally, some of the group thought a middle ground was appropriate.

As the discussion continued, fewer and fewer people remained comfortable with the independent contractor model, but the burdens of oversight on project directors remained worrisome. I repeated my long-standing favorite example of a terrible database, and others had their own examples of poor digital data. Eventually, the concerns about data quality pushed the group to an ideal solution favored by all: a single person with oversight responsibilities for the information systems used in a project. The title first suggested -- director of information technology -- was rejected in favor of director of information systems. (Director of information technology was the formal title I used in an article in the CSA Newsletter: "New Job Title: Head Geek," Harrison Eiteljorg, II; Winter, 2000, vol. XII, no. 3. The less formal appellation suggested was, of course, "head geek.") Although not specifically stated during the meeting, the preferred title of Director of Information Systems suggests a person with wider responsibilities: paper forms, data recording, and publication documents (whether electronic or not); that approach to the problem seems the best. In fact, one person in attendance has such a position at a major university, working as the information systems director for several projects from that university.

Finding the funds for a director of information systems is far from a trivial task. The "head geek " may be needed throughout the year for the duration of the project, though mostly on-call rather than on the job, and he/she will need to be on-site while fieldwork is in progress. Most important, the project computer specialist must be involved in the planning from the beginning -- not the beginning of the project but the beginning of the planning stage.

The discussion did not get beyond this ideal solution to discuss real-world considerations of affordability and practicality. Nevertheless, it was useful to have a group consider the issue of directing computer work on a project -- and reach unanimity as to the ideal solution. The suggested solution is very close to my thoughts about a "head geek," and the consensus at the meeting served to strengthen my conviction that projects need someone to be in charge of the technology in use. Both at the beginning of the session and later, nearer the end, it was suggested that projects wanting to use computers effectively need a combination of the right attitude about computers and computer data, careful planning of computer processes and integration into the work flow, and discipline to stay the course. Getting close to that ideal may be difficult, but this session helped define a clear target.

*******

After coming to agreement about ideal processes, there was some time left to discuss the digitizing of records from long-running excavations. Two things seemed clear:

1. hybrid solutions with part of the data in computer form and part on paper are undesirable;
2. speed is of the essence when moving from a paper-based to a digital data system.

Hybrid data storage means that any search is doubly complex, requiring one search of the paper records and another of the digital data, thus increasing the likelihood of problems and doubling the work. Once a decision has been made to digitize data, however, hybrid storage will be the result until all the legacy data can be transferred into digital form. That is why speed is of the essence. Only by moving quickly -- not hastily, but quickly -- to digitize the legacy data can one move to a unified data storage system with all data in computers.

*********

Training was also discussed, albeit briefly. Attendees were surprised to learn that there are degree programs for computer applications in archaeology (e.g., an M. Sc. in "Archaeological Science: Archaeological Computing" at the University of Southampton). Many felt that such a degree program would be very desirable and the proper preparation for a director of information services on an archaeological project.

**********

There was not sufficient time to discuss the problems of archaeological computing on smaller projects. All agreed that the smaller projects represent a more acute problem, both because there are more small projects and because they are not usually well enough funded permit hiring a computer specialist. Perhaps next year.

-- H. Eiteljorg, II

To send comments or questions to the author, please see our email contacts page.

For other Newsletter articles concerning the the use of databases, or electronic media in the humanities, consult the Subject index.

Next Article: Scanning Drawings for Preservation and Display -- What Resolution?

Table of Contents for the Winter, 2001 issue of the CSA Newsletter (Vol. XIII, no. 3)

Table of Contents for all CSA Newsletter issues on the Web