Download - MyWeb - Texas Tech University

The 2012 Season of the Chan Chich Archaeological Project
same catalog number; all the lithic tools from
that lot would have another number.
The crown jewel of the lab forms is the
Artifact Analysis form, and it worked very well
considering its complexity. The form was set
up to handle a wide range of artifact classes and
allow some data to be collected for groups of
artifacts (multiple primary flakes, for example,
or several sherds of the same ceramic type) and
specific attribute data for individual artifacts
(like a biface, for example).
Perhaps the best way to describe the function
of the Artifact Analysis form is to use an
actual example. Lot CC-10-E-1 yielded three
lithic tools, which were assigned the Catalog
# CC0039. When analyzing the first tool from
the group, the analyst created a new Artifact
Analysis form and selected “CC0039” from a
pull-down menu of all existing catalog numbers.
The database pulled the “Category” from the
Artifact Catalog form and automatically entered
it on the Artifact Analysis form. This serves as
a check for the analyst. If, for example, he is
holding a biface in his hand, but the data field
pulls in “Ceramic Sherds,” then he knows there
is an error in the database that must be corrected
before he analyzes the tool. The form also autopopulated
other information such as lot, subop,
op, and site. The analyst then assigned the tool a
unique specimen number, which was appended
to the Catalog #. This rather cumbersome step
ensures that each specimen will have a unique
number. Thus, the first biface from our example
was assigned the Spec # CC0039-01.
At that point, the analyst faced a series of
choices as he classified the artifact from its
general Category (stone, shell, bone, or clay),
to its Industry (chipped stone, ground stone,
polished stone, or unmodified stone), to its
Form (biface, blade, core, debitage, uniface),
and to its Subform (one of 13 choices for
bifaces), which in this case was GUB (general
utility biface). The power of the database
comes from the fact that each analytical level is
predicated on the one above it through a series
of conditional values. For example, chipped
stone is not an Industry choice if the Category
selected is clay.
The analyst then entered data on raw material
type and quality, completeness, dimensions,
and evidence for burning. Comments were also
entered, and finally a photograph was taken
directly into the database using the iPad’s
camera (Figure 7.3).
From the Field, to the Lab, and Back Again
As originally envisioned, by syncing the
databases each evening, the archaeologists in
the field would have the results of the latest
lab analyses on their iPads the next morning.
Each Lot form, for example, has a portal field
that pulls in information from the Artifact
Catalog and Artifact Analysis forms, giving the
excavator the ability to view their excavation
data right alongside the lab data. In theory, they
would also have access on their Lot forms to a
list of photographs of each lot.
That was the theory. In practice, that turned
out to be much more difficult than originally
believed. Basically, the problems stem from
the way FileMaker Pro syncs data. Although
our database structure had progressed beyond
what we called beta testing before we began
excavations, we had never tested the full
system in action with multiple iPads operating
at two different archaeological sites each day
(see below).
Other Practical Matters
The four field iPads were named CCAP iPad 1,
CCAP iPad 2, etc., and numbered “1” through
“4” with stickers on their cases. When a copy
of the database was installed on an iPad using
iTunes to transfer files, the database was named
“CCAP Database 5-27-12 iPad 1,” for example.
During syncing with the lab’s MacBook Pro,
78