You have until October 1, 2013.

Award for Outstanding Work in Digital Archaeology

Digital technologies are driving important changes in archaeology.  Despite the increasing acceptance of digital technology in daily life, however, determining how to assess digital scholarship has proved difficult: many universities remain unsure about how to evaluate digital work along side more traditional forms of print publication when faced with tenure and promotion decisions.  Recognizing the value of digital scholarship, and aiming to encourage its practice, the AIA offers this award to honor projects, groups, and individuals that deploy digital technology in innovative ways in the realms of excavation, research, teaching, publishing, or outreach.

Criteria for Selection 
Nominations of projects and individuals are welcome. Nominations may be made by anyone, including the project director or the principal members of the team responsible for the digital creation. Nominations of collaborative projects are encouraged. At least one member of the leadership team, or any individual nominee, must be a member in good standing of the AIA. Please submit the AIA membership number(s) with the nomination.

Due Date for Nomination
September 15, 2013 Extended to October 1, 2013


Apple now offering older iOS device owners ‘last compatible version’ of apps

From Engadget:

With iOS 7 arriving tomorrow, Apple is extending some love to the owners of older iOS devices that have been left behind. New compatibility features, first spotted on Reddit, will now kick into action if you attempt to download an app that is not supported by your current firmware. Instead, the company now asks if you’d like to install the last compatible version, which, for some apps, can be over a year old.

I could have used this during the past summer when I had to reset a first-gen iPad but couldn’t install OmniGraffle.

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:

  • timestamp
  • 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.

This is a practical post looking at the results of two 3d-modeling sessions. The objects I’m working on were excavated in the 1960s as part of the American Excavations at Kenchreai, which Prof. Joseph Rife directs. I had written a little bit more intro in my last Kenchreai post so please see that if you’re interested.


The first model is of object KE 1224 (S 57), a marble paw of a lion or other large cat. Click through to see the entry for the object, along with an embedded model, though I will also link to that directly from this post.

The method I’m using to make the models is photo-based. As in, I take a bunch of pictures and use Agisoft Photoscan to calculate a mesh describing the 3d-volume of the object and then to build a more-or-less photo-realistic texture to “drape” over that mesh. Bill Caraher has recently discussed an article by B. Olson et al. that describes the process.

Here’s a picture of the object on a photo stand:


You can see that I’ve used a styrofoam block to help the paw stand upright, and that there is an offset styrofoam block to help Photoscan figure out the physical relationships I’m capturing in the set of photos I took of this piece. I shot 78 images with my iPhone and used 31 to make the model. Why the iPhone? It’s small, so works well as a hand-held, and has a sensitive shutter “button” that I can trigger without shaking too much. I could perhaps get better pictures with a high-end point-and-shoot but the iPhone works for now.

Here’s the result as shown in a Photoscan screen-capture, with thumbnails of a few of the pictures I took and an indication of which of those I used. No red “no entry” icon means Photoscan incorporated that view.


Cooler than that image, though, is the ability to share the model itself so you, the reader, can rotate it at will. Click on this image to go to the site, with the paw shown with no automatic lighting.


Although I said this is a “practical” post, I encourage you to zoom in on the chisel marks by holding down the ‘x’ key. And note the blurred division between intentional marks that indicate fur and the underlying chiseling that also contributes texture. Ancient art was partly a form of craft production and this fragment, when shown in 3D, encourages consideration of that aspect of the piece.


The paw has a broken edge so it wasn’t a great loss to use that to balance it on the stand. KE 235 (L 61) is an essentially complete Late Roman lamp so here the challenge is to get all the way round the object. That being the case, let me say now that I didn’t quite succeed.

I used the same basic process, but this time I suspended the piece using fishing line. Here’s a picture:


Of the 88 pictures I took, I selected 47 to use in making the model. The ones I didn’t use were either very close duplicates or out of focus.

I had to move carefully so as not to make the whole thing shake. But again, I couldn’t really get good pictures from all angles. I was in a narrow space, which didn’t help. But the real problem was that when I got under the lamp to shoot from below the handle end, I was pointing at ceiling lights and getting terrible glare.

Results, as seen in the linked screen capture from, are not, however, unusable.


Click through to see for yourself.

When oriented handle at the left and looking at the side, the transition from the shoulder to wall didn’t come out well. And the base under the handle didn’t work well at all. But again, it gives a sense of the shape and surface of the object so I’m willing to share it as part of a discussion about technique. You can learn from my less than perfect attempt. And I do consider this model something of a “floor” in terms of results. Better lighting, particularly the ability to dampen overheads, more space, and more experience should lead to much better outcomes. Stay tuned for those. Though we’ll all have to wait until next year as I’m back stateside now.

First off, thanks to John for letting me post here. I do hope to be back as the work described below progresses.

In May and June of this year I spent just over two weeks initiating the online publication of the Kenchreai Archaeological Archive (KAA). This is an initiative of the American Excavations at Kenchreai, which conducts its work via a permit from the Greek Ministry of Culture and under the auspices of the American School of Classical Studies at Athens. Joseph Rife of Vanderbilt University is the director and I’m grateful for his permission to publish the results of this collaborative project. The focus of my work is the written and visual documentation of the excavations carried out at Kenchreai in the 1960s by the University of Chicago. These records are now in the Isthmia Museum, along with the objects that the project saved.

Cutting to the chase after the above preliminaries, I am modeling KAA using the Resource Description Format (RDF) in combination with the principles of Linked Open Data (LOD). Before offering an introduction to RDF, I’ll say that I’m using it because RDF gives me a simple and robust structure for describing the highly variable archaeological information that I am discovering in the extant records.

Superbrief intro to RDF

What is RDF? Simplistic answer is that it’s a W3 standard for encoding information, one with a formal description at . More usefully, RDF has at its core the concept of a triple. For its part, a triple is a three part statement consisting of:

  • A subject: what you are talking about.
  • A predicate: the type of information that you’re saying about the subject.
  • An object: the value – meaning content – of that information.

Informally, the phrases:

  •  “Sebastian Heath”
  •  “is a”
  •  “human”

Could be understood as the RDF triple:

  • Subject: me (“Sebastian Heath”)
  • Predicate: assertion of nature (“is a”)
  • Object: human being (“human”)


  • Augustus
  • held the office
  • Roman Emperor

The last example becomes more interesting when we replace the words with web addresses:

I’ve now used a set of publicly available web addresses to construct a triple about an historical individual. In doing so I’ve merged the ideas of Linked Open Data (LOD) into this discussion of RDF.

LOD is a set of best practices that suggests using URIs – here meaning well-constructed and stable web addresses – to identify publicly accessible resources. It further suggests that the information available at those address should be machine readable.

I’m now a long way from Kenchreai. Before getting back on track, here are some links to information about RDF and LOD that readers may find useful:

RDF and LOD at Kenchreai

OK, back to Kenchreai. Upon my first diving into the 1960s notebooks, I was pleased to see that the project was very organized about creating identifiers for the archaeological phenomena they were encountering. “Archaeological phenomena” is my fancy term for things like “trench”, “layer”, “object”, “sherds found together”, etc. I happily note that I am at the early stages of understanding how these ideas were manifested at the site in the 1960s so that what follows here is highly preliminary and subject to change.

To give an example by way of a series of steps.

  • The Area E notebook for August 4, 1963 reads in part, “At level 0.90 m we started putting all sherds in [box E121].” You can see an image of that page via . Click thru on the image for more detail.
  • From box E121, a sherd was pulled and sent in to be inventoried.
  • When inventoried that sherd was assigned the ID “KE 670”. You can see the relevant entry in the inventory book via .
  • As was the practice at Kenchreai (and at other American excavations in Greece), KE 670 was also assigned a “subject number”, in this case “P 176”. This indicated that it was the 176th piece of pottery inventoried.

I could go on, but I hope it’s clear that there a lot of RDF triples implied in the above narrative. Taking KE 670 as our staring point, some of them are:

  • KE0670
  •  type
  •  Inventory number
  • KE0670
  •  is part of
  • box-e0121
  • KE0670
  • is the same as
  • P0176

If you’d like to see everything KAA is saying about KE0670 (to use the fully padded version), go to . But please understand that that’s the temporary location of KAA. I’ll report its permanent address when that’s available.

You may have noticed that the above pseudo-RDF makes reference to other Kenchreai identifiers. One of them is box-e0121, with KE0670 being said to be “is part of” that. KAA in turn says the following about box-e0121:

  •  box-e0121
  • type
  • excavation-box
  • box-e0121
  • is part of
  • trench-e-ii-x-1

And again in turn:

  • trench-e-ii-x-1
  • is part of
  • area-e

And yes, there are URIs for those identifiers: and .

I can summarize the above by saying that: KAA is establishing web-based equivalents of the Kenchreai identifiers and is using RDF triples to indicate relationships between those identifiers.

The above means that I think I have a single conceptual structure, the RDF triple, that I can use to represent all information inherent in the materials – both written, visual, and physical (meaning the objects themselves) – now stored in the Isthmia museum. As implied above, I’m at the stage of putting these ideas to the test.

An additional point: because I’ve worked to choose sensible strings of characters for each ID, it’s easy to turn them into URIs. You’ve seen some already, here are some more examples:

Note that on each of those web-pages, you can click on the identifiers it references to see what KAA says about those. Furthermore, and this is important, you can scroll to the bottom of each page and click the “as rdf” link to get a machine readable representation of the data represented at that web address.

Querying the Kenchreai RDF

Because KAA is a list of triples, it’s easy to make that list available. For now see:

for two versions of all current triples.

I’m not going to go into the details of the format of those files other than saying that they’re “raw rdf”. I’ve made them available as a convenience for readers, but also so that I can demonstrate a simple query into this dataset.

“Query” is just another fancy term for “extract useful information from some data.” Part of the RDF suite of technologies is a language for describing such queries. It’s called SPARQL and its details go beyond the scope of this post.

My use case for now is finding all inventory numbers that are said to be part of “Area E”, which is just the designation for a part of the site where the project excavated. This is an interesting problem because, as you may have noticed, KAA does not explicitly say that an inventory number is part of a particular area. But I do plan to assert that inventory numbers are part of excavations boxes (when they are), and that excavation boxes are part of trenches, and then that trenches are part of areas.

The “is part of” relationship is indicated by the RDF predicate “dc:isPartOf”. “dc” stands for “Dublin Core”, which is a set of “core” terms for describing data. As in, I have a standardized way for expressing the logical relationship that one KAA identifier is part of another. Read more about “dc:isPartOf” at .

So here’s an example of a SPARQL query that finds all inventory numbers that are part of “kaa:area-e”:

PREFIX dc: <>
PREFIX kaa: <>
PREFIX rdf: <>
SELECT ?kenchreai_id
?kenchreai_id ?p kaa:inventory-number .
?kenchreai_id dc:isPartOf+ kaa:area-e . }

The super important part is the ‘+’ symbol after ‘dc:isPartOf’ on the last line. That will cause a SPARQL query engine to follow all dc:isPartOf predicates to see if an identifier is said to be part of ‘kaa:area-e’. Cleverly, this builds on the pseudo-RDF for KE0670 that I presented above.

As a convenience, I have set up a link to the SPARQL query-engine (ok, “endpoint” for those in the know) at to run that query and return readable results. That link is

Yes, it’s true; I have only done the data entry to show that KE0670 is part of Area E. But when I’ve done more work, you’ll be able to get the entire list.


So, yeah, I think it’s cool that I have a simple structure to encode all data types in a format that can be queried using standards-based third party tools. And I’m really glad that I can do this without having to define a separate table for each datatype. That’s what I would have to do had I chosen a relational model for KAA. So perhaps the major take away from this post is that RDF represents one way to overcome the shortcomings of the relational databases that are so prevalent on archaeological projects today. I doubt that all will be with me as to that opinion, since this discussion has been too brief to justify that conclusion. But I’ll return to this space when progress warrants it and look forward to an ongoing exchange on the ideas I’ve floated here.