Core Ideas - Limited Scope, Simplicity

A key design choice was to focus on the most pertinent functionality for specialists work on the publication of material from the dig. Therefore, rather than dealing with the total archaeological excavation operation, this project is limited to presenting the small finds and their provenience (although some other dig data are present for the purpose of completeness and future development). The software was designed to allow specialists (typically presented with boxes of pottery sherds/stones/bones etc..) to have access to information such as

• What context are the items from?
• What else was found in these contexts?
• Media related to these contexts and finds

It thus avoids the complexities of spatial relationships, inherently subjective and questionable. It also avoids geospatial technologies, inherently resource heavy, complex, and subject to the whims of ever-changing technologies.

Even with this software scope limitation, numerous problems related to terminology and classification remain. A few standard vocubularies and reference frameworks emerged in the attempt to tackle similar issues (e.g. CIDOC-CRM, CRMarchaeo, DublinCore). However we chose nit to utilize them as we deem their enormity and inherited complexities, paired with a steep learning curve, as a barrier to use which may outweigh their usefulness.

As an illustration for issues related to their adaptation, consider the likelihood that groundstone experts will invariably disagree on terminology used to describe their objects of study and will probably resist top-down, pre-assigned existing vocubularies, while lacking the technical skills to modify and expand them.

The simple approach we chose instead, is to allow the specialists to define their own limited terminology in a simple “tagging system” (See below). The appeal of a limited terminology, targeted to a specific site and easily modified, seems worth the loss of generality offered by competing universal systems.

Modules, Collections and Items

The project's basic design is centered around the module (see terminology). Each module has its set of tables, forms, tags, possible relations with other modules, and more, which fits into a unified, application level standartized pages, menus and display elements.

As far as the user is concerned, each module consists of a collection of items that may be filtered, ordered, and viewed in various ways. A user with editorial privilages may add/delete items, edit their free text properties and attach/detach media, relations, and tags to them.

Our design choice to divide the data into seperate module is based on the observation that the most pertinent characteristics and queries are module specific (e.g. stone queries have little overlap with metal queries). Limiting queries to be module specific significantly reduces the complexity of the software. Notwithstanding, there are no substantial issues with further development of multi-step, multi-modules queries.

Partitions, Categories, Groups, and Options (tags)

Another design decision is the heavy reliance on groups consisting of a limited number of options for characterizing certain properties of items. For example, a stone item material property may include all known stones and minerals; however, for all practical purposes, a list of 20 options or less will be sufficent. The addition of “Unassigned” and “Unknown” options completes the partition without the loss of generality. This general idea of "selecting an option from a partition" can be expanded to include required/optional and singular/multiple selections. The options, which are simple textual labels, may also be expanded to more abstract concepts. For example, a faunal remain may be initially characterized by the following required, single selection groups:

• Scope: [Unassigned, Unknown, Single Item, Anatomical Cluster, Complete Skeleton, Nonindicative]
• Element: [Unassigned, Unknown, Bone, Tooth, Horn/Antler/Hoof, Leather, Shell, Carapace/Spicule]
• Taxon: [Unassigned, Unknown, Human, Mammal, Bird, Fish, Insect, Reptile, Mollusca]

While the software implementation of the different group types differ, as far as the user is concerned, their interface is the same - a selection is made from a limited number of options.

Due to the potentially large number of groups, they are grouped together into seperate Categories. The complete structure is thus of Module:Categories/Groups/Options.

The Options Dependency System

Many characteristics of a specific item are dependent on other characteristics. For example, in the fauna example above, there is no sense in the selection from the "Element" group if the Scope is anything but a "Single Element".

A simple dependency system was devised to implement these restrictions: Each group contains a dependency array that defines when it becomes “active”.

Groups that are not “active” will not be displayed and no selection will be available (if they are defined as required a default option is assigned). Similarly, categories that have no active groups will not be displayed.

For example, in the fauna example above the group "Element" may be defined with the following dependency array: [Scope:Single Item],

the group "Taxon" with: [Scope:Single Item, Scope:Anatomical Cluster, Skope:Complete Skeleton],

and the group "Mammal" with [Taxon:Mammal].

The software maintains the consistency of this three-tier system by ensuring that unselecting an element, will unselect its dependencies. Please note that this dependency system is shared by both the tagging and filtering systems. It may help to reduce errors in data entry.

TIP

The dependency system is not intended to replace any formal knowledge representation system, but rather to allow for an easy to use solution for a specific problem.

The Filtering System

With the trio infrastructure in place, nuanced and focused filtering is available. The selection of “Unassigned” and “Unknown” allows the user full control and understanding of what the filters are actually doing. In addition to the groups/options filtering, textual-search, media related queries, and ordering are available through the same unified interface.

Summary

In essence, this project is a simple "notes and pictures" database.

The FAIR principles or any formal knowledge system were never considered in its design.

It offers a simple solution for digitizing and organizing archaeological records and observations as they emerge from an archaeological excavation and further processing by specialists.

It facilitates making these data available on the web easily and cheaply, allows for colloboration, further analysis and interpretation, and may function as a bridge to a future institutional publication.