|
Building a database for the excavator of a site in Turkey this past summer provided some interesting new information for me and, indirectly, for excavators interested in the process - especially those reluctant to add a full, complex, relational database to their archaeological kit bag. I worked on the dig directed by Professor Marie-Henriette Gates (Bilkent University, Ankara) at the site of Kinet Höyük, not far from the modern city of Adana on the southern coast of Turkey. The site was apparently inhabited from the Neolithic period through the Hellenistic period and again in Medieval times; pre-Bronze Age levels have not yet been excavated, but Neolithic and early Chalcolithic (Halaf) sherds have been found in secondary contexts. Excavation has been on-going since 1992. The aim was to build a database for the excavated objects, their contexts, personnel, photographs, drawings, and so on.
One of the most interesting lessons of this work is the importance of the relationship between excavator and database specialist. Professor Gates and I have known each other, as friends as well as colleagues, for more than twenty years. As a result, there was neither tension nor any sense of unease in the air between us, and we were able to communicate effectively. Indeed, Professor Gates' willingness to permit me to work away on the database without interference was crucial. I did not feel that I was being second-guessed or watched, and that is important, especially when the job is in the early phases. Design decisions regarding a database are often made and remade as the design matures and complications are added. A nervous overseer can stir the pot but can rarely add taste to the broth.
Another lesson was brought home to me as well. In conversation with Professor Gates in advance, mostly via email, I made few requests/demands regarding computer hardware. That was a serious misjudgment. Building a system to run on unseen hardware was a new experience for me, and I lacked the experience to know how important more explicit directions could be. I was also reluctant to seem to be dictating to Mrs. Gates what hardware she should buy/own/have. I should have been more concerned about this point.
In fact, I would still be reluctant to specify hardware. However, I think it would be appropriate to provide a list of requirements in terms of function, not in terms of specific hardware. For instance, equipment should be at hand to run specific software, including a specified operating system. Hard disk size at least free space on the disk should also be specified, and I would make it clear that it must be possible to make back-ups of files too large to fit on floppy disks. Even such seemingly simple things as screen size can be very important and should be specified. (Designing a database entry form without knowing the size and resolution of the screen on which it will be used is very problematic.) Were such a list provided, the excavator could then take that list to someone on his/her campus, presumably in the computer center, to evaluate in terms of the actual equipment at hand.
Working in the opposite direction could be equally helpful. In that case, I could ask that an excavator provide a list of equipment and software including computer memory and hard disk size (and available space), monitor size and resolution, operating system, relevant software, back-up capacity, printers, and so on. If there were any doubt about the capacity of the equipment, I could then take that information to an expert to help me evaluate it.
It is probably more effective for me as database specialist to ask what is available than to state what is required. That puts more of the responsibility on me, and it is more appropriate that I take responsibility for the fit between equipment needs and capacities.
There was another lesson, one that came as no surprise but should nevertheless be mentioned. It is simply not possible to look at paper forms or examine abstract presentations of site data and understand correctly the way the recording system actually works for the excavation team in the field. Things that seem obvious to the excavator will not be; things that seem obvious to the database specialist will not be; things that seem clear to both will turn out to seem clear only because neither understands the other. In short, time with real data from the excavation is a critical requirement. The database person needs to understand accurately the way the information is derived and used. I do not necessarily mean that the database specialist must construct the database at the excavation site while digging and recording are in progress, but he/she must spend time with the excavator and with a supply of data already recorded if he/she hopes to gain a true understanding of the recording system as it is actually used in the field.
In this instance, that problem was reasonably well anticipated. Although I did preliminary work on the system at the CSA offices, we planned for nearly two weeks of development time in Ankara before heading to the site. That gave me time to examine much more data from prior seasons, to ask many questions, and to consider a variety of possible data entry options. The time was definitely needed; I found several points I had misunderstood, even though I had been able to examine filled-in data forms before departing for Turkey.
If a database is being designed in advance of the first season of excavation, there will, of course, be no data to work with, no experience at the specific site to rely upon. In that case careful advance consultation between excavator and database specialist will be even more important. There will be no real records to use as guides; so care must be taken to anticipate real-world conditions and the database designer should assume that the system prepared in advance will need adjustment after the real work begins just as an excavator is prepared to make changes in the paper system early in the excavation.
In either case, real data entry personnel need to test the system. At Kinet Höyük, for example, the system had nearly reached completion when we moved from Ankara to the site. It had been tested in Ankara, but the person who did some sample data entry in Ankara was a regular user of computers. One of the less computer-savvy members of the crew entered some sample data when we reached the site, and she did not like the subtle differences between the data entry screens and the paper forms. These were differences that both the other tester and I had thought were trivial, but the on-site tester was certainly a more typical user.
I changed the system. That change, of course, required other changes, and it took some time to get the system back to a stable state but it is important to note that the change not only made the system easier for some to operate (without making it more difficult for others) but it also generated changes that made the entire system much better. Such near-real-world tests are an important part of the development process.
As more and more data were entered, a few glitches were found and fixed. By the time I left Turkey, the system seemed to be working without problems. Nonetheless, it seemed that all concerned would have preferred that I remain beyond my planned departure date. Fortunately, there was someone else on the staff with considerable computer experience, and she was able to take charge of the system after I left. No significant problems occurred after my departure; so the time allotted was adequate.
A final reminder, again not something unexpected. The excavation at Kinet Höyük had been going on for some time, but the database was, of course, new. It can be tempting to try to rush to get all old data into the database while entering new data at the same time. However, there is enough complexity and change in the entry of new information; trying to enter old data at the same time is unnecessary and may cause problems. It makes sense to let the retrospective data entry wait until everyone has become more familiar with the database and the computers. As an alternative, one might choose to enter data from prior seasons before beginning to work on current records. But trying to enter new data and data from prior seasons at the same time is not a good idea.
One concern remains. Neither the woman who took charge of the system after my departure from the site nor I will be in Ankara to work with the excavators during the coming academic year. Few of the other members of the excavation team who will be in Ankara have the expertise to take charge of the database. The documentation of the database, though absolutely necessary, may not be sufficient if there are not experienced computer/database users available to put that information to use. Therefore, we will depend greatly on the Internet in the coming year. I will report further on our ability to do that in future issues of the Newsletter.
In conclusion, I want to emphasize again the importance of trust, cooperation, and good communication between the excavator and the database specialist. Good excavators are accustomed to giving considerable latitude to various on-site specialists; the database designer needs that as well. By the same token, the database specialist must understand that the excavator has designed a recording system that meets the needs of the site - and then build the computer version accordingly.
-- Harrison Eiteljorg, II
To send comments or questions to the author, please see our email contacts page.
For other Newsletter articles concerning issues surrounding the use and design of databases, consult the Subject index.
Next Article: CSA/AIA Database of Archaeological Projects on the Web
Table of Contents for the Fall, 1999 issue of the CSA Newsletter (Vol. XII, no. 2)
Table of Contents for all CSA Newsletter issues on the Web