A word about software posts: On this blog, I want to provide review type information about the myriad archaeology software out there, but also want to be clear about what precisely the review represents. In order from least to most rigorous, the different levels of software posts are: Closer Look, Hands-On, and Field Test. In “Closer Look” posts, I write about an application’s features and hypothesize about how an archaeologist might benefit from them. In “Hands-On” posts I write about my experience actually installing an application and trying out some of its basic features. In “Field Test” posts, I write about collecting or processing real data using the application.
The Federated Archaeological Information Management System (FAIMS) project is an open source software project by the University of New South Wales in Australia. The project is a subset of the National eResearch Collaboration Tools and Resources (NeCTAR) program, which aims to build new infrastructure for Australian researchers. The goal of FAIMS is to build a comprehensive information system for archaeology that allows archaeologists to collect digital data from sites using mobile devices, process them in local databases, archive data in digital repositories for long-term storage and future reanalysis, and easily exchange data with researchers across the world. The FAIMS mobile app runs on Android devices running version 4.0 or higher of the Android operating system.
I recently worked on a project customizing the FAIMS data collector for a US CRM company and creating data entry forms on the mobile application. I worked through the FAIMS cookbook, which explains how to create the different kinds of data entry fields, such as text boxes, calendars, dropdown menus, radio buttons, and even how to add in map layers and shapes using the FAIMS app’s internal vector GIS system (Figure 1).
Hardware Requirements and Essential Files
In order to set up the FAIMS mobile app, you need a device with running Android OS 4.0 or higher. The developers recommend a tablet to better fit all the controls on screen, but the app will also run on phones. I run FAIMS on a Nexus 7 tablet (wifi version), which also includes an internal GPS antenna. Second, you need a computer with the Ubuntu Linux operating system (OS) installed to run the FAIMS server. I run the FAIMS server from my laptop, but FAIMS developer Dr Brian Ballsun-Stanton says that you can also run the server by emulating an Ubuntu computer on a desktop computer or another server on your company or university network . Finally, you need to create three text files: an UI_Schema, a Data_Schema, and an UI_Logic file. The cookbook will show you what information needs to go in these files and in which formats but briefly, the UI_Schema is written in Extensible Markup Language (XML) and defines which labels, fields, buttons, and other controls need to appear on which screens when you load your project in the mobile app. The Data_Schema is also written in XML and defines the fields that you want to collect and what kind of data each field is. The FAIMS server takes your Data_Schema file and maps your custom fields to the more general fields and tables FAIMS uses. The UI_Logic file is written in Java and contains calls to the FAIMS application programming interface (API) and defines what each of the controls should do when pressed and what constraints are placed on the fields. An example of an API call in the logic file would be:
onEvent(“user/tab1/users”, “click”, “login()”); <–which tells FAIMS to run the “login()” function when a user clicks on the “users” button on “tab1.”
Installing the FAIMS server
Right now, you can either enter a list of commands or run an automated computer script to download and install the FAIMS server and the other software packages that are required. Ballsun-Stanton’s installation script automates much of the installation process. I ran into trouble with the server installation on my machine, however, likely because of its particular combination of hardware and previously installed programs, so Ballsun-Stanton had to walk me through the final few steps in order to get the server installed. In the near future, Ballsun-Stanton hopes to have a Debian package built so that server installation is as simple as installing any other application from the Ubuntu package manager.
Creating your Project Package
After you create the three essential files, you then upload the text files to the FAIMS server and type in some descriptive metadata about your project into the web form the server provides (e.g. the name of the project, the name of your organization, the creator’s name, etc.). The FAIMS server takes your files and creates the appropriate folders, database, and other files to create a project package. On the FAIMS app, you can click the server connection button to have the app search your local network for an active FAIMS server. If a local server is not found, you can also enter an IP address and server port for a remote server to connect to a server across the internet (Figure 2). This feature is very handy as it means you can continually sync your mobile app data back to either a server many miles away if you have an internet or cellular 4G connection OR you can also sync mobile devices back to a server running on a local network, which could be a laptop and wifi router you bring with you out to the field.
Getting your Project on Mobile
Once you connect to the server, you can browse through the different project packages stored there. From the list, you can pick a project and download it onto your mobile devices. Once on your device, you can open the project file and begin viewing or entering data. Provided you coded in the option, each project can contain a list of user profiles, so that the database can note which user has made a change and also provide differing levels of access for different users, such as full editing privileges for the crew chief or primary investigator, but only create and read privileges for field technicians (Figure 3). One of the key advantages of FAIMS over other data collector systems that I have investigated is that the FAIMS database uses an append-only data store and never deletes anything. This means that you can have multiple people recording the same feature and making changes to its database record at the same time and not have to worry about records getting overwritten. Instead, the FAIMS database simulates updates and deletions through insert statements. Later, when the different data collectors upload their data back to the server, the server will identify conflicting records and allow a supervisor to choose which record or combination of fields from a record are correct and then merge those changes together. Importantly, after the merge, the original disparate records are not deleted, but can still be examined, much like tracked changes in a Word document.
FAIMS currently supports data export through Heurist and development of output to Digital Antiquity’s tDAR repository is underway. I have not tested exporting data from FAIMS yet, but will update this section once I have gone through the Heurist tutorial.
As it stands, the beta version of the FAIMS app is still too rough for many archaeologists to build a project on top of. In fact, my client decided to use another data collector over FAIMS for his current project in part because he wanted even the less technically-minded archaeologists at his office to be able to create new forms if they needed. The form creation is not especially complex, and the cookbook does a good job of teaching the process, but many archaeologists probably will not find XML or Java immediately intuitive and may not be able to take the time to work through the FAIMS reference materials. Additionally, the FAIMS server takes a substantial amount of technical knowledge just to install in Linux and, in my case, even some professional coaching in case the install does not go perfectly on your machine. Data output is also a bit more confusing than it could be, requiring archaeologists to learn how to use Heurist, a pretty sophisticated DBMS, when many archaeologists may be more comfortable with an output in MS Access or FileMaker. That said, the FAIMS features: like the append-only data store, the abstract nature of the FAIMS database for comparison across different datasets, and the local server connection for field conditions where cell and WIFI connections are rare, clearly show that archaeologists and archaeological fieldwork were the primary design consideration across the board. So far, I have not seen some of these features in other mobile data collectors I have investigated.
For most archaeologists, I recommend waiting until FAIMS is out of beta and the tools for creating forms and installing the server are more polished. The time and cost saving advantages of using FAIMS out in the field are probably still offset by the cost of learning the software, unless you are preparing for a large project. That said, once you put in the time to learn the system, it could pay great dividends even on small projects (Figure 4).
If you are a technically savvy archaeologist, however, and are comfortable collaborating with other members of the FAIMS user group, I encourage you to try FAIMS on some smaller projects. Since the project is open source, free to use, and runs on low cost hardware, the price to use FAIMS is extremely attractive. Additionally, I expect archaeologists looking for a perfectly tailored solution to their projects to help actively develop the source code and for the best changes to be rolled back in to the main code. The developers are very responsive to questions and the online community is very helpful for troubleshooting. Consider heading over to post a question and try it for yourself. I’ll see you there!
If you have tried FAIMS, or have questions about working with it, please post them in the comments below. Don’t forget to see my list of other digital archaeology tools as well!
Test Dates: 8/2013
- FAIMS App: 2013 Nexus 7 (wifi) Tablet, Android 4.3
- FAIMS Server: HP Pavilion dv6tqe, Intel Core i7 CPU, 8GB RAM, Ubuntu 12.04