Practical Thoughts on a New Archaeological Data Project

This weekend, I began to think seriously about my summer fieldwork with the Princeton Polis Expedition.  This summer our plan is to clarify the chronology of one of the two basilicas at the site initially built during  the Early Christian period and, then, modified over time.  Our goal is to use stratigraphic information, a careful examination of existing architecture, and an analysis of ceramic finds from the site to date more clearly the various architectural modifications to one particular basilica known as EF2.  We hope that our work this summer will help us to develop an approach to documenting the relationship between archaeological material and architecture that we can then apply to the more complex basilica at the nearby site of EG0.

As part of this work, I began to consider how to translate information recorded in excavation notebooks into a more formal and consistent structure.   I reasoned that the notebook information could form the basic framework for the other archaeological data that we will ultimately collect from the study of the ceramics, wall plaster, architecture, glass, coins et c. The notebooks are actually in pretty good shape (although it will still be a challenge to extract the stratigraphic relationships from every context), but the basic data structure developed for Polis is rather underdeveloped. At present the context database is a single, flat table without any primary key or other tools in place to control how data is entered. Moreover, the various fields were not defined in an easily understood way and it wasn’t clear at all what the most basic record would be.  For example, should we record information only for each “level” (which coincide to gross stratigraphic or spatial divisions in the trenches) or do we record information for each “pass” which represents a single context of material removed from a level.

The reason for this ambiguity is that this database was not designed for my research project. In other words, the data base isn’t the problem (although it is inelegant and doesn’t necessarily follow best practice); the problems rests with how I need to use the existing data structure.  So I am left with the prospect of re-designing the existing database to suit my needs (and to make sure that it is backwards compatible to suit the needs of the designer of the original database).

I have been diligently reading John Walrodt’s Paperless Archaeology over the past few weeks. This blog documents in detail how a project implemented their digital workflow.  From what I have seen so far, the tools that they developed and deployed served to facilitate their ongoing, in the field, research (although I am sure that there are provisions for archiving the data in a responsible way).  I could approach the Polis notebooks in a similar way. I could develop a data structure best suited to answer our immediate research questions.  (As an aside, very few of the other people involved in documenting the basilica use Microsoft Access which is my preferred database. I have used Access extensively for other projects (making it easy for me to borrow structure from other databases), integrates well with ArcGIS (our GIS software), and is the database that our ceramicist uses. So, it is possible that I could create a database that few of my colleagues can actually use!  This tempts me to be even more practical (read: idiosyncratic) in how I organize data.)

On the other hand, I could imagine a data structure (undoubtedly more complex) best suited to preparing the Polis data for some form of digital publication (or at least archival storage).  Few projects in the Eastern Mediterranean with a Byzantine focus have made their data publicly available. In this regard, the Polis data could be an important step toward making stratigraphic, typological, and chronological data from the Byzantine period available in digital form.  At the same time,the two Early Christian churches represent just one part of a much larger and more complex site. Taking the time to produce a thorough and well-structured dataset could be a fool’s errand if it ends up being incompatible with other work ongoing at the site or finds very few comparable datasets elsewhere in the region.

So as with so much of archaeology, the key is to find the best balance between immediate utility and long term value.

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 )

Google photo

You are commenting using your Google 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