This post originally appeared at Digital Archaeology Commons
Dear Ben and fellow DAC members,
We at FAIMS have not been active on the blog, because we worked on a major grant application and overdue publications. We are now returning into the game, because we want to get the community feedback on the next upgrade of FAIMS, and because we were inspired by Ben Carter’s post.
We will try to respond to several points that Ben Carter made in a series of posts. This first one will focus on a misunderstanding of FAIMS evident in Ben Carter’s statement of : “I don’t want to create a single suite of tools that must be used together- that can be limiting as well (if you want this, I recommend you check out FAIMS. Flexibility is the name of the game.”
Ben suggests that FAIMS project offers a single suite of tools that is like a walled garden, where you either buy into the whole suite or nothing at all. The opposite is the reality. FAIMS has been and is building discrete tools for specific field research data tasks, that work together with other data services. FAIMS users are free to pick whatever suits their needs. FAIMS makes it possible, but does not mandate, that archaeologists use an entire data lifecycle. And so, you can use FAIMS Mobile to collect your data and either export it to your desktop software for further processing, or export it to Open Context or tDAR or your favorite MS Access db or other regional register for publication, sharing, or follow up work. None of these steps are required in any way, FAIMS project just makes them technically possible through the FAIMS ecosystem.
The FAIMS Mobile platform for offline data collection (the flagship product of the FAIMS project and one part of the ecosystem) is entirely customisable. Imagine a bucket of functionality that you can pick from: want spatial data? Get a mapping screen and figure out your projection. Need dropdowns or picture dictionaries? Pick those and populate them with illustrating images. Don’t care about recording video? Drop it. The FAIMS Mobile is flexible and can do as little or as much as anyone needs.
The FAIMS ecosystem is in my opinion the very “concatenation of tools” that Ben calls for. We call it a federated system because that’s what it is - a federation of tools managed by FAIMS and FAIMS partners (Open Context, Digital Antiquity), who are committed to the best practices and digital data standards, open source code, reproducibility and sustainability, etc.., - but which also lets archaeologists opt out and use their preferred desktop software at any time.
Later in the post, Ben proposes that archaeologists should use a palette of tools, which have been developed for a particular workflow. You can use survey forms for structured data, or QGIS for spatial data collection and visualisation, and so on. Yet, if your projects include multiple workflows, such as you need to take pictures while filling a form, than you are faced with the management of multiple disparate data sources and pieces of software, and need to ensure their integration, completeness and consistency at the end of your fieldwork. Do all records have associated images, do all images have the right labels and associations? If you work at a multi-year project, you also need to monitor the status of each piece of software, its compatibility with your hardware, latest upgrades, connectivity to external sensors etc., and constantly evaluate if they are still suitable for your task at hand. We see this as a major overhead.
The advantage of FAIMS over this palette of separate tools is that if you use FAIMS Mobile you do not need a separate application for pictures, a separate application for GIS data, a separate application for diaries, or structured data. FAIMS Mobile creates all of these data types together as part of a unified record. On export you have the choice of either exporting all the data as an integrated whole (sqlite database) or in discrete groups of data types (csvs, pictures, GIS shapefiles or kmls). If you choose the latter, all exported data groups will have the attributes of the record embedded in it (picture will have data embedded in it, GPS point shapefile will have an attribute table, etc.), so that if your pictures get separated, they can always be identified and traced back to their origin. And tedious, labor-intensive tasks, such as the labeling of images, will be done for you by the computer, automatically, in one push of a button.
FAIMS has other features that are designed for field researchers, which we will discuss later. The bottom line here is that archaeologists should not need to compromise using software that was designed for other domains. Neither should should they need to manage and maintain several complex pieces of software while undertaking fieldwork. Some projects and small scale jobs may only require survey forms or GPS points, and will be well served by Excel or Garmin DNS. Yet, large scale projects that require integrated data collection and do not want to juggle multiple pieces of software while in the field can find many of their needs fulfilled by FAIMS.