I can hardly describe how useful the Mobilizing the Past: The Potential of Digital Archaeology workshop was last weekend. The organizers: Erin Averett, Derek Counts, Jody Gordon, and Michael Toumazou built a solid schedule of talks with a very tight thematic focus. I don’t know when I learned more in a single weekend.
Bill Caraher, the self-described resident luddite, has already posted parts one and two of his review of the workshop.
Wentworth Institute, who hosted the workshop, wasted no time getting the finished videos onto their YouTube channel so you can see the talks for yourself.
Although it wasn’t the first talk of the conference, this is my blog, so I will start with my keynote: “Why Paperless?”
The YouTube videos are almost, but not necessarily broken into the same time chunks as the sessions.
Part 1: Session One:
Part 2: Session Two (most of it, the video stops during Buxton’s talk on Underwater Exploration):
Part 3: Sessions Two and Three (starts mid-Buxton talk):
Part 4: Session Four (starts at 46:00, the video stops during Caraher’s talk):
Part 5: (starts mid-Caraher plus Round Table Discussion and Plenary Lecture: “The Ara Pacis and Montecitorio Obelisk of Augustus: a Simpirical Investigation” by Bernard Frischer (Indiana University):
According to FileMaker there is an issue between iOS 7 (due to be released on Sept 18) and FileMaker Go that affects the creation of a unique UUID number, which has the potential to wreak havoc on databases that rely on that unique number for syncing. This bug hits our own databases, as well as the copy of the database that is hosted at this blog.
Syncing from multiple copies of a database requires that each record have a very unique number. This is more than a straight serial number, since two separate copies of the database can each create a record in the same table which would give them the same serial number. Instead, our database relies on something more specific, a UUID which is generated from several types of information.
The UUID that we use is a custom function written by Jereme Bante a few years ago named UUID.New. It creates a unique number for each record based on:
- recid (an internal number generated by FileMaker)
- the NIC (or MAC) address of the device that created the record
This is stored as a custom function to allow all tables in the database access to it.
According to FileMaker, all iOS devices under iOS 7 will return the same NIC address,. This can theoretically return the same UUID for two records if two devices created a new record in the same table at the exact same time.
I am not very worried about this myself. The odds of two records returning the same UUID are pretty small. Also the syncing scripts that I have use items other than the UUID for matching. For instance each new record is given _DeviceCreated and a _DeviceModified fields. Those are set to auto-enter a calculation [Get ( SystemPlatform ) & “-” & Get ( HostName )]. So unless both devices are iPads and are both named the same (which shouldn’t happen), they won’t supply the same data.
If you are worried about this bug you can switch from using the UUID.New function to another of Jereme Bante’s functions named UUID.Random which replaces the NIC portion of the UUID to a set of random numbers. Switching to this function won’t affect your old records and won’t require that you wait for FileMaker to fix FMGo.
Bill Caraher blogging at The New Archaeology of the Mediterranean World yesterday posted a link to a demo of a new iPad app for trench side data collection at PKAP. Actually he originally linked to this page on April 20 but yesterday he gave a little more information. This seems to be a custom app written by Sam Fee from Washington and Jefferson College.
Bill is more heavily invested in linking social media to his field project than most people I know and the description of his use of iPads reflects that.
This summer, we’ll extend our social and new media reach into the field. Messiah College – one of our three co-sponsoring institutions – will provide the project with iPads for the students to use in the field, the museum, and the hotel. They should be able to publish photographs, video, and reflections directly from the field.
So the iPads are to be used to document more than just the archaeology but their use will expand to allow the students to be able to record and upload their own thoughts during the project.
There are several people that I know who are writing custom apps for their field projects. Most of them are in testing stages and there is very little that I know about how they are accepted by the teams and how the data collected is integrated into the larger data workflow. But the best part about Bill’s approach to archaeology is that I won’t have to wait long to hear about it.
Noel Hidalgo Tan from the Australian National University has recently presented a paper at the Australian Archaeological Association on his use of tablets to record the location and motif details of rock art in Thailand. He uses the full range of the hardware including the camera, GPS, and audio recordings for lengthy descriptions. He has blogged about the paper and has uploaded the slides from his presentation.
He uses slightly different software than we do at Pompeii, and I will have to check out Tap Forms, his preferred database app.
Sophie Graham photographs part of the site
Image tagging has long been one of the least efficient areas of our workflow. In previous years, photos of the site during excavation were taken with digital cameras. At the end of the day the trench supervisors were expected to upload the digital images to a computer, rename the files and add captions to the photos’ metadata with Adobe Bridge, and store them on the server. In the best of circumstances this meant that an image taken early in the morning would be tagged 9-10 hours later, likely after numerous other photos had been taken. To make things worse, as the season progressed and the trench supervisors became busier they tended to defer these tagging processes for a day or two. By that time they often had difficulty remembering exactly what was intended by the photo—even for archaeologists, it is sometimes hard to tell the difference between two photos of dirt.
This year we decided to move the captioning process out into the field. One of the key pieces of technology that enabled this was the Eye-Fi Connect X2, a camera memory card with built-in Wi-Fi. This card allowed us to continue to use dedicated digital cameras, which currently produce images of a much higher quality than the cameras built into many tablets and mobile devices, and to operate away from existing Wi-Fi networks. Using Eye-Fi’s Direct Mode we paired each card/camera with one iPad. After a photo is taken the card automatically broadcasts a Wi-Fi network to which the iPad connects. The card then transfers images to the iPad, putting the photos directly into the Camera Roll. The Eye-Fi app on the iPad does the actual transfer, but it can run in the background. The entire process takes from 30 seconds to a couple of minutes, depending on the number of photos.
Read the rest of this entry »