Archives for category: General

An article written by Billur Tekkok, Sebastian Heath and myself is about to appear in Studia Troica. They have kindly allowed us to host a pre-print version of the article.

The authors present a non-technical overview of the database structures that record information about the Post-Bronze Age ceramic assemblage at ilion. its purpose is not to fully document the system used at troia, but instead to identify practices that can be useful in other contexts. The article particularly stresses that it is important to assign a primary identity to all sherds that will be subject to individual study and that this identity can be re-used in such record keeping processes as drawing and photography. further use of such identities in print and digital publication is likely to make online linking of ceramic data to contextual information easier in the future.

This article describes our method for recording what was a truly staggering amount of pottery, even for an urban site. And this post gives me the opportunity to show one of my favorite pictures of Troy:

This is the area in front of the dig house at Troy. The vertical sidewalk in the photo separates the Bronze Age team ceramic processing tent on the left from the Post Bronze Age team ceramic processing on the right. Keep in mind that this is pottery from the current year only, waiting to be processed. The tent itself is full of tables with pottery spread out for analysis.

The Troy database is probably more similar to data collection schemes found in Greece than the work that I am posting based on the Pompeii data. Since our PARP:PS pottery is not read for publication until after the project is complete, I haven’t had to add tables to find all of the associated drawings of a piece. Another difference is how the individual numbers are assigned. The Troy database would hand out the next unique individual sherd numbers to the scholar. At Pompeii the scholars will come and study the ceramics during the winter when we are not there. So I have to devise a way for someone to assign a number to a ceramic without the possibility of duplication. We have a procedure in place but it is relatively untested.

This came from a discussion I had during the 2010 field season at Pompeii. Leigh Lieberman is one of our registrars at PARP:PS. We were talking about the overall team’s acceptance of the new technological changes that had been introduced in the past few years. Leigh observed that the team might be resistant to change during the season that change is introduced, but by the next season they are already used to it. We decided to shorten that thought to the following principle:

Technology becomes second nature in its second year.

Bill Caraher who blogs at The New Archaeology of the Mediterranean World posted a comment to my New Math post. Since the gist of the New Math post was a quote by Richard Rothaus, not me, I wasn’t really prepared to answer his comment immediately. But I thought that his comment on cost of tech vs. labor deserved its own post. So I am elevating it to an article and have commented on it below.

John,

That comment caused me to think a good bit as well! I keep trying to think of ways to factor in the true cost of digital archaeology.  For example, while I agree that converting paper to digital is a hassle, it is nevertheless a hassle that can be accomplished back in the US by inexpensive labor (e.g. graduate students, spouses, faculty free time). Digital data capture in the field (and you know that I am a huge fan of a digital archaeological workflow) may take additional time in the field (Richard even admits to this).  Time in country is expensive.

Moreover, technology is (compared to paper) expensive.

Person hours, from the perspective of an academic archaeology (and Richard has “gone pro”) are cheap.

So the equation is more complex (as you know).

I’m pretty excited to read your blog and learn how you came up with such clever processes!

Bill

Bill,

Thanks for the comment.

I find that expense, as it relates to digital vs. paper is directly related to the process, not the goal.

I have seen many examples of time wasted in the field by moving the exact same notes from one paper media to another. From, say, an informal field notebook to a ‘clean’ representation of the same data on a form, and finally entered into a database and even printed out for a more permanent ‘bound’ notebook. That is an extreme example, but this happens with every bit of each process: photo tagging, data entry, matrix building, final report writing. And the larger the team the greater number of people hours spent redoing the same work.

I have also seen a progression over the years. At Troy everything was written down and selected bits were entered into the computer (films scanned, drawings scanned, notebooks and field forms scanned, finds quantified and entered) and all the Troy grad students did during the academic year was to catch up on this work. My experience in Albania, on survey was different and governed by an “everything digital before we leave the site” principle. But there were still some data entry and data check projects done by students after the field season. Now I am on the brink of having a project with complete “born digital” data and now our students get to spend their winter helping with the research and analytical tasks instead of remedial data entry and scanning.

I don’t really embrace the “technology is expensive” argument. Some tech is expensive some is not. Some tech is expensive and doesn’t contribute much. Some is cheap and can change everything about the way you work.

So I hope to expand on this complex equation in the course of this blog.

John

 

In order to establish a baseline for conversation, I should outline what it is that I do. Some of this might be obvious but it should be made explicit.

I work in a US university on Mediterranean archaeological projects. This means several things:
  1. For fieldwork we carry on a plane almost everything that we use. We can certainly find some stuff locally, especially the basic tools and excavation equipment. But we also carry bags, tags, and lots of specialty items that are sometimes either hard to get or just plain cheaper to buy in the US. We carry all of our tech equipment (including computing hardware, total stations, rods, and tripods) all of which needs to be hand carried. Peripherals are kept to a minimum.
  2. We often aren’t guaranteed decent Internet access. Even at Pompeii, using wireless cards, it is difficult to get a signal. Other times we are working in isolated areas without any hope of any type of net access.
  3. We have access only to portable computers. No desktop machines with large hard drives. No servers (in the physical sense, I mean), and no decent sized monitors.
  4. I work for other projects outside of UC, but I only work for academic projects. There is quite a difference between government run archaeology, CRM archaeology, and academic archaeology. Academic archaeologists tend to focus their data gathering techniques based on their own research design. They also don’t tend to write reports in the CRM fashion, but are focused solely on academic peer reviewed publishing. Academic field projects also don’t have a centralized data management scheme. There have been attempts over the years to standardize data collected in the field but most projects still create a whole new documentation and database scheme for each project. Even several field projects in the same academic department have different storage and data sharing mechanisms for inter-project communication and research. Again, this is very unlike CRM archaeology, with which I have a passing familiarity, but I have never worked for a CRM firm.
  5. There is a constant stream of new personnel on the projects. Almost all are graduate students and almost all end up actually ‘working’ for a project for a maximum of five years. Some only work for any given project for one or two seasons. So there is a lot of training that we have to do for each project, every year. To give a sense of perspective to this: UC’s participation in the current Trioa Project began in 1988. We are still publishing annual reports in the form of Studia Troica from that project, and two major monographs (and one dissertation) are still in the final stages of completion.
These are the circumstances under which I work. Given these circumstances, I have worked out the following strategies:
  1. I don’t code. Maybe a little. I write scripts for databases and computer automation. I code some web pages in php and lasso (for database integration). But making an app is beyond what my time allows. So no custom software. It has to be off-the-shelf.
  2. I don’t work with enterprise-level databases for fieldwork. They require too much in the way of coding and training. I need desktop (or now tablet) apps. Open source is great, but often the projects can afford professional level software with academic pricing.
  3. The software has to be something that I can teach to a beginner in a very short amount of time. Software that a classicist can use. I can train almost anybody to use FileMaker. Seventy-five percent of the field personnel can understand what we need to do with Photoshop in less than an hour. Fifty-percent will understand GIS well enough to use it. Unfortunately the number drops considerably when it comes to working with a vector drawing app like Illustrator. And almost no one but specialists can use CAD tools efficiently. I have to plan for that, and identify students who show affinity for one type of software over another.
  4. I do have the luxury of a server. I run an OSX file, web, and database server here at UC. So I can host collaborative software of my choosing without having to work through my university IT people, and non-UC people can have accounts on my server.
Almost all (academic) field projects have one person who can handle most of the software necessary. It is their job to take something complex, like a notation system being used by five team leaders with different academic backgrounds who have been taught that there is only one right way to do something, and produce a clean, consistent data set. That person serves as a developer for the project. Someone who will take it upon themselves to tackle the difficult problems so that the others in the field project don’t have to. That person is my audience. In the future, I will be posting samples of our work at PARP:PS. I don’t expect them to be used by themselves, but I will post them so that they can be an example for  project developers to adapt for their own work.
I should also note that I recognize that there are many ways to do something correctly. I use FileMaker and Mac-based tools when I can. I use Windows when I have to. But other teams have different tools. If I post some samples that use one method but you want to use another, I invite you to be a part of this learning process and post some samples of your own.

Alex Marko (top) and Kevin Dicus make a scaled drawing on the iPad. Photo by Steve Ellis.

This blog is born of a promise that I made to several archaeologists that I met at Pompeii while working on the PARP:PS project during the summer of 2009. Our project made the bold move of completely abandoning paper and we experimented with a totally paperless data acquisition scheme using iPads. Many of our colleagues dropped by the gate to see what we were doing and we received many requests for more detailed information than a simple ten minute tour would allow. So I promised that I would post as much information about our experiences as I could, and I wanted to do this in a way that would allow full access to the materials and techniques that we used, while allowing for discussion.
This is the result. In many ways it is an extension of the PARP:PS website itself, but we didn’t want to clutter up that website with this diversionary discussion.
Paperless Archaeology goes beyond the field acquisition of data. There are four aspects of paperless archaeology that I would like to discuss here:
  • immediate digitization of field observations
  • using digital tools during the research and writing process
  • the publication of the results electronically
  • archiving project data
But mostly, I want to look at how these four parts fit together into a single workflow. At PARP:PS we are working on all of these at the same time. Our observations are directly entered into a computer. Our database strives to be more than a digital collection of field observer’s notes and allow some analysis from the raw data. And the results of the project are largely published digitally in the Journal of Fasti Online. Once published, our data will be preserved in our department and most likely hosted on our servers in the way that the PRAP project is made available.
Since this three part focus is quite a wide range, I will rely from time to time on cross-postings from other blogs that are working on similar topics.
The initial focus, however, will be on the use of tablet computers in the trenches themselves: the techniques, the workflows, the training, and the results.
Special thanks goes to Steven Ellis, the director of PARP:PS, who has allowed me to post information from the site with relatively few restrictions.