I am so excited that the Digital Archaeology Commons is up and running! Here’s my first contribution.
Much has changed since I first posted on the website of the Institute for Digital Archaeology back in September. That post, entitled, “ Robust, Open, Flexible and Offline Digital Data Collection in the Field” outlined my background and interest in digital data collection. I won’t reiterate that here. However, I will restate the goal and the basic tenets of my project. The goal is to collect a set of tools for archaeological data collection, quality assurance, storage and analysis that are open source, simple to use and “play well” with each other. I would like this project to result in a concatenation of tools that:
1. Is browser-based (and, therefore, device independent)
2. Can be used off-line (now possible with HTML5)
3. Employs open source code
4. Can be connected to a database of choice (proprietary or open-source)
5. Is inexpensive and simple (at least on the user end once it has been built)
6. Promotes the open use of resulting data
I reiterate here my dedication to these six tenets, but will stress that number 5 has inched its way up the ladder to position #1 (though it was never really intended as a hierarchical list). The ability for archaeologists (and others) who do not consider themselves proficient in digital tools to be able to “pick up” these tools and use them will relatively little guidance and exploit their value in the field has become the prime directive of this project. I keep thinking about those times in my life when money and time were sparse, such as when I was a graduate student (and new father), an adjunct and a visiting professor. In these stages of my life, I needed something cheap (okay, FREE), easy to use and powerful.
While I originally proposed to employ a spectacular tool known as wq.io, I became frustrated with the complexity of the tool and the long slog that it would likely take to get it up and running specifically for archaeology. Please know that I don’t consider this a problem with the tool, but a void in my own skill set- and yet that same void exists for many archaeologists. I forced myself to learn some programming- I knew very little. Indeed, leading up to the Institute last August, we were required to learn a number of web languages. What I learned for this activity is that I am a poor programmer. I can feel my shoulders tense just thinking about it! So, while I will need to do some data wrangling and, hence some programming, I want to minimize this. The goal is to create documentation and perhaps short lines of code (gonna need help on the latter) that can combine a wide variety of tools.
I also have learned that I neglected one central aspect to my requirements:
7. Must promote and enable the use of geospatial data and tools
This was always a requirement; after all archaeologists are spatial creatures. However, I realized that this was a de facto requirement; this addition, therefore, is simply an admission. Although the central purpose of the different components may not be handle geospatial data, they need to be designed with spatiality in mind.
Before I introduce my proposed tool set, it is incredibly important to note that nearly all of these tools have competitors both in the open software and in the proprietary software worlds. Indeed, in picking these tools I have tried to choose options that seem the most flexible. That way, if you are a dedicated user of Filemaker Pro or Microsoft Access, you can still use your preferred database management software with the other tools. 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.
So, here’s my proposed basic tool set along with some open and proprietary alternatives (this list is not exhaustive and many of these tools have different capabilities).
Tool: PostgreSQL with PostGIS
Open source alternatives: MySQL; MongoDB; Cassandra; SQLite with SpatialLite
Proprietary alternatives: Native formats for ArcGIS, MS Access or Filemaker Pro (see below); Oracle; Microsoft SQL; and many, many more.
Relational database management software
Tool: LibreOffice Base
Open source alternatives: Many, many options here. Pgadmin is the standard for PostgreSQL
Proprietary alternatives: Microsoft Access; Filemaker Pro
I will leave off here. In future posts I will address the each individual component, their advantages and drawbacks and why each was eventually chosen. The goal, however, is not to try to justify the decision or convince an audience that this is the correct choice, but to engage in an open dialog about these different tools. I hope that others out there have their favorites and will contribute their perspectives. I look forward to hearing from you all!