Small Archaeological Projects and the Social Context of their Data

I am still working away on the paper that I will deliver after the holidays at the Archaeological Institute of America annual meeting in Seattle. As with everything this time of year, it is taking me long than I thought it would and my ideas are refusing to coalesce without some rather painful reflexive thinking.

My paper is titled “Archaeological Data and Small Projects” and is scheduled to appear in a panel called Managing Archaeological Data in the Digital Age: Best Practices and Realities. My goal is to present some of the social and technological realities of how our project, the Pyla-Koutsopetria Archaeological Project, dealt with the translation of archaeological from the field to the computer. A very preliminary summary of my paper is here. The goal of my post today is to clarify and expand some parts of this summary as I begin to revise my paper for January.

One thing that several commentators have mentioned is that the use of iPads or other digital recording devices in the field increased efficiency in collecting, analyzing, and disseminating archaeological knowledge. These tools made it easier, in effect, to bridge the famous gap between the field and laboratory by eliminating the intermediate step of producing paper field notebooks which are then digitized “back at the lab” for inspection, study, and archiving. Smaller projects have struggled a bit to keep pace with the technology necessary to capture the various kinds of information produced at the edge of the trench (photographs, illustrations, and text) and to synthesize it in an integrated database. 

Our project captured archaeological information at the edge of the trench or from the survey unit using paper forms. A project director then translated this information into a format suitable for archiving and analysis in a database. While kept paper copies of the original trench notebooks and scanned them for both archival purposes and as a check on our databases, we conducted most of our analysis based on the data keyed into our trench database. (We are currently going through this same process with the trench notebooks from Polis-Chysochous on the western side of Cyprus.

As many of my colleagues have pointed out, this particular workflow is inefficient. There are, however, reasons for these practices. First, paper forms or notebooks are almost infinitely flexible data recording tools in the field. A trench supervisor can defy the standards established by even the most rigid form by simply overwriting the expected data type, changing the form midstream, or expanding it to meet a new challenge or observation in the field.  While this flexibility constantly threatens to produce data that is incompatible with the information being collected in other trenches or survey units in the study area and runs the risk of losing information, it also allows for trench side innovation, creativity, and ad hoc solutions to the almost limitless variety of objects and relationships encountered in a trench. Moreover, the paper form – when filled out correctly – makes it very difficult to delete or overwrite potentially meaningful mistakes. The record produced by the paper form, then, is in some ways more stable and dynamic than that collected directly in a digital context.  

I’d like to say that these advantages were our primary motivations for collecting archaeological information on paper forms at the side of the trench, but they were not. We found paper forms easier, less costly, and more stable than using a digital tool to directly gather data from the unit or the trench. Moreover, we knew how to make a good paper form, so the learning curve was quite modest. Conversely, our various database were notorious fickle creatures. The few times that we made it possible for a student or even a trench supervisor to key the data into one of our excavation databases, we ended up supervising their work closely, making tweaks to the database, and working with them to figure out ways to accommodate various incompatible or irregular entries on the forms within the more rigid structure of our database. After a short time, we concluded that it was easier for a project director to key the data into the database and use the translation from paper to pixels as a way to review and understand the data coming from each trench. 

IMG 2732

The technical limitations of our project staff and the relatively small areas exposed by our excavation or documented by our survey played a key role in shaping our workflow. It also shaped the process of digital data production by producing a distinct, intermediate step between archaeological documentation in the field and translation of this information into digital data. The documentation work performed at the edge of the trench or by the survey team leader derived from conversations with various team members, experience in the trench or the fields, and the systematic engagement with the stratigraphy or artifact scatters in situ.  In contrast, data entry mode involved the solitary keying of field observations into a database. Archaeological information recorded in the field was inevitably smoothed during data entry as I massaged the flexible character of paper forms to conform to the rather more rigid fields in our database without the benefit of trench side observation or collegial conversations with various participants in primary information collection. The field sheets were frequently in a different order than they were produced in the field  and the tedium of data entry often invoked a kind of frantically repetitive fugue state. Data entry was strangely satisfying, however, in that one could see the conversion of hours of fieldwork into a quantifiable series of records that became a shorthand for the quantity and quality of information collected from the field. 

The experience of data entry and field collection were significant different in terms of both the kind of information produced and preserved and the experience of the process. Our method was, of course, inefficient. The massaging of data to fit into a rather less flexible database likely caused some kind of data loss particularly in exceptional cases where the forms did not anticipate the kind archaeological “reality” in the field. Of course, maintaining data entry as a separate, distinct step of the process also allowed for use to adapt our databases on the fly to accommodate archaeological information from the field. 

Whatever the limitations or advantages of various forms of data capture produced by archaeological projects, the processes put in places by small projects with limited expertise invariably shape the kind of information recorded and analyzes. The tools and social contexts of a project dictate the kind of knowledge a project produces.


  1. We were lo-fi! Who wants to be efficient, anyway? Efficiency is for suits, and iPads are tools of a homogenizing corporate culture.


  2. I think labeling it inefficient is actually quite wrong for some data types. The process you describe is a type of Quality Assurance/Quality Control which should be built into any project. Academics rarely include this in methodologies in any formal way. When data is entered directly, errors may not get noted until the analysis phase, which can be so long after the event that correction is impossible. Some data errors also are unlikely to ever be noticed outside of immersion in the process (for example, a Munsell color that has Y instead of YR–only way to notice that is if you are immersed in the Munsells for a trench or whatever). Additionally, the data entry project familiarizes the PI with the data, which presumably has to happen sometime. There are, of course, correspondingly data types where this is overkill–e.g. elevations.

    There is also another efficiency issue with in-field data entry. I consider it the “number of balls in the air” problem. To do data entry in the field, one needs to constantly pay attention to things that aren’t the archaeology–hardware, power, data interfaces, glare and shade. While those things may only require a fraction of the intellectual power of the excavator, they still require attention. In my experience, directly doing field data entry and also employing people who I have forced to do field data entry, there is a cost. It can be disproportionately stressful, frustrating and un-fun, because it can create too many small details to attend to at one time. Crews can and should be stressed, but not to a point where it damages the quality of the work (or makes them quit).

    So, depending on the project, I vary from mostly analog to mostly digital field data collection. Soil probe transects=total data entry in the field. Shovel tests are usually 1/2 digital 1/2 analog. Formal excavation is mostly analog, including paper level forms. Delivery time can effect this–if a project is on a tight deadline, we do as much direct entry as possible. I also tend to give a bonus to the crew that suffers through this as it makes for headache inducing generally sucky days. My favorite setup is field crews doing paper while I do onsite digital entry (like Pettegrew at his table). This happens about never in reality for budgetary reasons.

    An exception is some spatial and GIS data–usually the two-dimensional. That is always direct in the field as I think that provides the best quality. If there is a mapping error, it frequently requires one to be on site to fix it. So for those, I emphasize do the GIS in the field and check it twice and then have someone else check it before you leave. Three dimensional I tend to do a mix of digital and paper, as that seems to be the fastest.


  3. Oh–and I use out-of-the-box software that crews already are accustomed to using. So, for example, soil probes just go in a Excel spreadsheet or even a Word doc. That way if they need to add a field or do similar, it is a non-issue. Likewise they don’t have to use a software package that isn’t second nature to them.


  4. I agree with Richard on the Quality Assurance/Quality Control issue. I won’t deny that exporting the data and then dumping it into the database later is inefficient; but I think think there is some value to that inefficiency. In the case of PKapp, it requires the trench supervisors to look at the data again, and it also gives the database administrator the chance to see it before it ever becomes a part of the archive. When you add in the simple data validation techniques built into the app, it means that folks would really have to try hard to get invalid data into the master database.

    Certainly, we could write directly to a SQL database residing on a server somewhere (and we may want to someday), but then someone is still going to need to look at those data and confirm their accuracy.

    I think efficiency is good as long as everyone knows what they are doing. But for small projects with regular turnover, perhaps the inefficiency serves us well?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s