A Tool for Understanding Taskscapes in Stone Age Coastal Hunter-Fisher-Gatherer Societies: Theoretical Aspects of Building a Relational Database (NAUTICC) for Large-Scale Analysis

2.1 The theoretical framework

To address the questions posed in Section 1, archaeological finds serve as analytical units for accessing information and knowledge about the lives of past communities. These remains are dispersed across the landscape, which, when viewed from a ‘dwelling perspective’ (Ingold, 1993), constitute an enduring record of the lives of the communities who inhabited it. Accessing past lives dynamically and holistically requires integrating the notion of landscape with that of temporality. This approach makes it possible to move beyond conceiving the landscape as a static backdrop to human action and to consider the cultural aspects of past communities not as isolated spheres but as a web of linked interactions with other agents in the landscape.

Techniques are not treated in isolation but, from a dwelling perspective, are examined as components of interlocked tasks that form the so-called taskscapes (Ingold, 1993). Viewing prehistoric sites through taskscapes shifts interpretation toward a temporal, engaged, and lived-in understanding of human–environment interaction (Driscoll, 2017). A holistic perspective allows us to avoid confining remains to their traditionally recognised functions and to identify how they participated in multiple taskscapes in the past, illustrating how everyday tasks were interwoven and flowed into one another. The traditional division between ritual and mundane, for example, is not applicable in every context or community.

To dwell is to perform tasks, to undertake a sequence of activities composed of specific technical actions (Ingold, 2017). Techniques within tasks, and tasks within taskscapes, are executed in an order established by the agent. The agent holds successive goals in mind, organising stages within a conceptual schéma opératoire to achieve a predetermined result (Pelegrin, 1990), which, as an inherent characteristic of a technique, must be the most effective attainable result (Mauss, 1973). The implementation of this conceptual schema can be documented and analysed through the chaîne opératoire (Leroi-Gourhan, 1993): a methodological and theoretical approach addressing operational sequences across artefacts, the physical actions, and the mental schema, thus the method (Sørensen, 2006b). Although prehistoric studies have traditionally applied the chaîne opératoire to lithic assemblages, lithics are not the only prehistoric technology to which this analysis is applicable (see for example Babalola, 2024; Hardy, 2008; Jordan, 2014, p. 187; López-Montalvo et al., 2017); as a methodological framework, it can be applied to any artefact and structure resulting from a technique, an ordered sequence of interconnected movements, without geo-temporal limitation.

Objects are not the physical actions performed with them, yet their study permits inferences about the cultural processes in which those actions were developed and transmitted. Consequently, by applying the chaîne opératoire as an analytical method, it becomes possible to reconstruct the stages and simultaneously the choices and behaviours structuring the various sequences of technical actions. The ordered series of technical actions performed to attain goals within the diversity of tasks required by the act of dwelling is examined here across the taskscapes that are characteristic of Stone Age communities: food-getting, food-processing, symbolic–ritual, handwork, lithic tool production, and dwelling.

Food-getting is essential for survival and includes a series of techniques aimed at acquiring edible resources to support a community. Although, as in every other taskscape, these techniques can be carried out solely through bodily actions (Mauss, 1973), most require adapted technologies, which sometimes emerge in the archaeological record. Over time, there has been growing attention to food-getting technologies (Kelly, 2013), as they show significant variation across time and space. Following Hayden’s definition (1998), these technologies fall under the category of ‘practical technology’, whose primary purpose is survival and basic comfort, and which are universally essential across human groups (Oswalt, 1973). For this reason, a wide variety of objects are used to achieve this goal. Oswalt defines them as subsistants (1973, p. 24), extrasomatic tools that assist agents in food-getting activities, both modified and unmodified. In organising this category, Oswalt establishes a division between naturefacts (unmodified natural objects) and artefacts (modified tools). Indeed, to pursue such a vital objective in everyday life, both artefacts and naturefacts can be effective when technologies are employed. In hunter-fisher-gatherer (HFG) communities, successful task execution within fishing, hunting, and gathering depends on the effectiveness of these actions. Therefore, the food-getting taskscape is analysed here to retrieve information on all techniques and activities related to the procurement of food among HFG groups. These include the gathering of malacofauna (e.g., molluscs and shellfish), the fishing of ichthyofauna (fish), the hunting of terrestrial and marine mammals, birds, and the collection of plant resources.

Artefacts play a crucial role in daily life as tools to perform essential tasks. Accordingly, time and energy are invested not only in their initial construction but also in their maintenance, to preserve their effectiveness (Torrence, 1983). These preparation and maintenance processes also require the application of specific techniques (e.g., the grinding of a lithic axe using a grinding plate), which are documented within the broader handwork taskscape, where various interlocked tasks appear, including some related to the use of tools. Lithic tool production is analysed within a separate taskscape due to the level of archaeological detail this domain allows. In this case, the focus lies on the production process and the chain of interconnected tasks it entails (see Section 3.5.1).

Dwelling, in the sense of inhabiting a place, involves a set of tasks and technical actions aimed at enabling a group to remain safely in an area for a variable period, thereby engaging in everyday activities (Fretheim, 2019). These tasks may include building shelters, hearths, or waste management systems. Such areas, often defined according to Binford’s concept of the residential base camp (1980), frequently display archaeological traces of food resource processing. While initial processing may occur at the collection site, final preparation is often carried out in residential zones (Kelly, 2013). Food-processing includes all techniques for preparing, cooking, or preserving food.

Defining an action as ritual or symbolic presents a more complex challenge, as it is difficult to reconstruct predetermined, effective results in a non-pragmatic sphere. The symbolic-ritual taskscape groups together scholarly interpretations that identify elements of ritualization in specific actions or objects. The concept of ritualization (Arias, 2009; Bell, 1997) allows symbolic meaning to be conferred depending on context, rather than assuming an inherent symbolic value. At times, mundane and symbolic meanings may coexist, signalling the object or action’s relevance to multiple taskscapes.

2.2 Conceptual design and ER model

The logical structure of NAUTICC stems from the theoretical framework described above (see Section 2.1) and revolves around three main conceptual entities: archaeological site, find and taskscape (see Table 1 for a summary).

The first conceptual entity is the archaeological site. An archaeological site can be defined as a spatial unit continuously covered by the remains of past occupations (Willey & Phillips, 2001). Even though this is what is commonly referred to when speaking of sites in an archaeological context, defining this concept in more detail presents some ontological issues (McCoy, 2020). First of all, the distribution of archaeological materials in a geographical area does not necessarily reflect the result of past human choices, as post-depositional processes alter the contextual relationships between artefacts and structures. Thus, what is observed when excavating an archaeological site is not a direct picture of past processes, but rather a combination of historical and natural processes that occurred over time. Another factor influencing the observed archaeological distribution is the field methodology used to uncover it (Cardinal, 2019); different protocols can lead to different conclusions. Visibility is another important factor, as it changes over time and consequently determines the kinds of observations that can be made at an archaeological site. Visibility is also political, since often only a small portion of a settlement can be excavated due to constraints of time and funding. The archaeological definition of a site rarely corresponds to that of the community that once inhabited it. The former, influenced by present-day perspectives and conceptions, offers only an approximation, sometimes merely a glimpse, of what the original inhabited place might have looked like. This is particularly evident regarding the Stone Age: it is the archaeologists who set the boundaries of what they consider to be a settlement, thereby excluding the surrounding areas and the activities that took place within them (Berg-Hansen et al., 2023). Considering all this, the archaeological site entity is a result of the chosen field method and the excavation activity (Cardinal, 2019). For the purposes of this research, it will be defined as the documented archaeological area where artefacts, ecofacts (natural remains, typically biological or environmental materials), and features suggest the contemporaneous engagement of dwellers in different taskscapes.

The second archaeological entity is the find. This concept refers to the material evidence uncovered during archaeological excavations; these are the primary data used to formulate hypotheses and draw conclusions. The types of finds of interest are varied and heterogeneous, as the main criterion for inclusion is the meaning and significance they carry within the broader structure of the database and, consequently, their ability to contribute to answering specific research questions. For this reason, finds gain importance primarily in relation to the taskscapes they are involved in.

Taskscape is the last central conceptual entity of this relational database, and it serves as a tool, a lens throughout which it is possible to look at the various acts of dwelling (Ingold, 1993) carried out in the studied sites. Taskscapes are described through a series of associations between techniques and their pertaining tasks.

These three conceptual entities are linked through specific relationships that give meaning to the relational schema. These relationships are usually visualized using a diagrammatic technique called an Entity Relationship Diagram (ERD): entity types are represented by rectangles, and their relationships are shown as diamonds labelled with their names. In this case, the ERD presented (Figure 1) is a simplified version that excludes attributes, join tables, and lookup tables (which are described in further detail in the following sections and shown in the schema model in Figure 2), to focus on how the main tables are linked. The first relationship is between archaeological sites and finds. Here, the site entity provides the contextual, chronological, and geographical framework for the finds: finds are located at specific sites. At the same time, finds serve as the primary source for defining and identifying different taskscapes, as this entity is interpretative in nature. In this sense, it can be said that the relationship can be described in the following way: finds (interpretations) define taskscapes.

Figure 1

Figure 2

2.3 Software and data

The choice of a specific RDBMS (Relational Database Management System) and other tools for implementing a data model can be guided by various factors, such as compatibility with other software, the software’s ability to handle the complexity of the model (Anichini et al., 2012a), the user’s expertise, and specific research choices (e.g., the preference for non-proprietary tools). To determine the most suitable software for developing the NAUTICC relational database, two key factors were considered. First, compatibility with Geographic Information Systems (GIS) was required to ensure the spatial data stored in the database could be easily managed and analysed in future studies. Second, in alignment with the FAIR principles of this project, the use of proprietary software was avoided in favour of Open Science and widely adopted FLOSS (free/libre and open-source software) tools. PostgreSQL was selected as the preferred RDBMS, as this database engine ensures compatibility with GIS software (specifically QGIS 3.40.8) through the PostGIS extension (version 3.5.2), which enables the storage and management of spatial geometries directly within the database. This architecture allows the direct integration of the NAUTICC dataset in a GIS environment, for visualization purposes and to support the implementation of spatial analyses in future research phases. Additionally, RStudio (Posit team, 2025) was employed during the data entry phase.

Regarding the raw data and the sources consulted to retrieve them, both primary (original records of data collected firsthand during fieldwork) and secondary sources (processed data which were analysed, interpreted, or summarized) are used to populate the database:

• Field documentation

  • - Excavation reports, post-excavation reports, preliminary fieldwork reports

  • - Survey reports

  • - Scientific specialist reports (such as reports on radiocarbon dating, isotopic analyses, micromorphology, analyses on phytoliths or palynology, etc.)

• Academic literature and publications

  • - Peer-reviewed journal articles on excavation projects

  • - Peer-reviewed journal articles on scientific analyses

  • - Monographs on research projects

  • - Theses and dissertations

  • - Archaeological bulletins

• Digital resources

  • - Online archaeological catalogues and repositories

  • - Open-access archaeological datasets

  • - GIS platforms and web-viewers

The main sources consulted are documents produced during or after the excavation. These reports provide first-hand observations and interpretations of the stratigraphy and material remains by the researchers who conducted the fieldwork. The accessibility and format of such reports vary by country, requiring the continuous adaptation and adjustment of the consultation and data retrieval workflow (see, for example, reports available online from France and Norway: Viken & Sundström, 2017; Marchand, 2015).

A further challenge is linguistic. At present, the data already collected originate from France, Norway, and Latvia, and in most cases, they were obtained from reports written in the respective local languages. To overcome this challenge, AI tools were used whenever possible to translate the documentation, thus facilitating access to the data. The support of native-speaking researchers was essential to ensure the accuracy of translations, clarify technical terminology, and interpret contextual nuances that could not be fully captured by automated tools.

Most field documentation is not formally peer-reviewed or published through standard academic channels and therefore falls under the category of grey literature. This term was defined at the Third International Conference on Grey Literature (GL’97) in Luxembourg as: ‘that which is produced on all levels of government, academics, business and industry, in print and electronic formats, but which is not controlled by commercial publishers’ (Farace, 1998). The use of such sources enables the dissemination of data that would otherwise be difficult to access, and whose potential might remain unexplored and underutilized. From the sources listed above, a variety of data types are gathered to populate the database. Structured data are retrieved from pre-existing datasets to populate numerical and typological fields. Textual data from the literature are used for descriptive and interpretative entries. Spatial data are included in the form of coordinates with corresponding reference systems. Temporal data are used to record chronological information. Finally, ontological data are also present in the form of controlled vocabularies, which support the management of technical terminology and categorical classifications.

The relational database is currently hosted on the Huma-Num French Research Infrastructure (2013), an internationally-oriented platform dedicated to the Social Sciences and Humanities. Huma-Num promotes core principles and methodologies such as open science and FAIR data, aligning closely with the data policy adopted for this research. Huma-Num ensures accessibility and reusability through one of its services: the Nakala repository (2014). Nakala is an interoperable and secure service for depositing all types of research data. After the completion of the collection phase, the data will be uploaded to Nakala and made publicly available for free consultation and download. This step requires the data to be prepared according to the Huma-Num requirements (see ‘Data Preparation’ in Figure 3). After submission, the dataset will undergo three levels of control and curation before being deposited. Finally, at the moment of publication, a permanent DOI is assigned. Compiling metadata (following the schema of the Dublin Core Metadata Initiative, 2012) is one of the requirements of the data preparation phase prior to upload to the repository. Nakala supports the findability of metadata through a triplestore that can be queried via a SPARQL endpoint.

Figure 3

To enhance semantic interoperability, Linked Open Data (LOD) was used as a design principle. The overall aim of LOD is to connect open datasets and allow for cross-querying, for instance, to address research questions (Schmidt et al., 2022). To do so, when possible, entries in NAUTICC are linked to external semantic authorities such as gazetteers (e.g., GeoNames, Wikidata, and PeriodO), creating explicit connections with other datasets. Furthermore, to allow for global interlink and be included in cross-querying, the database schema was mapped to the CIDOC Conceptual Reference Model (CIDOC CRM, version 7.1.1), an ISO standard ontology widely adopted for the semantic representation of cultural heritage information (Doerr, 2003). Based on this conceptual alignment, relational data were transformed into Resource Description Framework (RDF) triples through custom Python scripts that extract records from the relational database and serialize them according to the CIDOC CRM model (Figure 4). Each entity was assigned a persistent URI, enabling unique identification within the semantic web environment.

Figure 4

The resulting RDF dataset will be published in a repository and made interrogable through a SPARQL endpoint (Schmidt et al., 2022).

Through the use of shared ontologies and semantic links, the NAUTICC dataset can be integrated into the broader network of cultural heritage Linked Open Data, effectively contributing to a large-scale knowledge graph in which heterogeneous archaeological datasets are interconnected.

3.1 Sites

A table storing information on archaeological sites where significant remains indicative of technical actions have been identified. The data recorded are primarily spatio-temporal and contextual in nature. Fields include:

id_site (PK): integer. A unique ID number assigned to each site. For Norwegian sites, specifically those investigated by the Kulturhistorisk Museum in Oslo, it was agreed, in consultation with the museum’s object database manager, that the ID would correspond to the collection number (C-nummer in Norwegian), a five-digit numerical code used to identify collections of finds (artefacts, ecofacts and scientific samples) from specific sites.

name: varchar. The name by which the archaeological site is commonly known and cited in reports, publications, and official documentation, recorded in the primary language of the source.

region (FK): varchar. This attribute is linked to the lookup table regions (see Section 3.7) and refers to the geographical region in which the archaeological site is located.

municipality: varchar. The present-day administrative division to which the archaeological site’s extension belongs.

period (FK): integer. A numeric identifier indicating a time unit that expresses the relative chronology associated with the period during which the analysed technical activities were carried out. To ensure consistency, the value is normalized through linkage to a lookup table, PeriodO, where it corresponds to a specific chronological definition (see Section 3.7). This table draws on data from the PeriodO public gazetteer of scholarly definitions of historical, art-historical, and archaeological periods (Rabinowitz et al., 2016). These definitions have been filtered to match the temporal and chronological scope of this research, but the structure is designed to be expandable, allowing for the inclusion of additional periods and regions in future developments.

C14_BCE_lower and C14_BCE_upper: integer. When ¹⁴C datings are available, a two-step procedure is followed to obtain the chronological boundaries (BCE). The first step involves the calibration of the sample of dates (using the IntCal20 calibration curve; Reimer et al., 2020) to produce probability distributions indicating the likelihood that each date falls within a particular calendar year. Subsequently, all of these per-year probabilities are summed, resulting in a curve representing the intensity of dates over time, known as the Summed Probability Distribution (SPD) (Crema & Bevan, 2021). From this distribution, a chronological range is defined using the 95% credible interval. The attributes C14_BCE_lower and C14_BCE_upper store the lower and upper bounds of this interval, thereby representing chronological uncertainty as a probabilistic time range. Both steps, calibration and SPD computation, are performed using the R package rcarbon (Crema, Dee, & Wanner, 2020).

type_of_site (FK): varchar. This attribute is linked to a lookup table with the same name (see Section 3.7), defining general types of archaeological sites (e.g., open air, rock shelter, shell midden, cave, etc.). It is a contextual information, which indicates the type of environment in which the investigation has been carried out.

long_y_N and lat_x_E: numeric. A field used to record the spatial coordinates for geographically locating the sites. The coordinates are retrieved from the consulted sources, and as such, their format and reference system may vary (e.g., longitude and latitude, X and Y, Northing and Easting). This variability is the reason behind the generic labelling of this column. The purpose of this column is to keep the provided information of the original coordinates.

reference_sys: integer. As mentioned above, geographical coordinates can have different reference systems. This depends on several factors, the most notable being the use of sources produced by numerous authors, with varying purposes, over a wide time span. Working with data from three different countries also plays a major role: when the coordinates provided are not geodetic (such as WGS84) but projected, local reference systems are often used. Moreover, within the same country, different choices may be made, and archaeological sites may be located in different geographical zones. To preserve the original source information, it was decided to retain the original reference systems in this attribute by providing their EPSG code. Through the geom attribute, all coordinates are also expressed in a consistent univocal reference system.

geom: geometry. To enable integration of the database within a GIS environment, all spatial coordinates are stored as spatial objects in a dedicated geom column. An ad hoc function ensures that every record is associated with a single, consistent geodetic reference system (WGS84, EPSG:4326). The function is executed automatically through a trigger whenever coordinate values are inserted or updated in the sites table. It constructs a point geometry from the submitted coordinates and, when necessary, transforms it into WGS84 if the EPSG code specified in reference_sys differs from 4326.geonames_uri: text. When available, this attribute stores the persistent URI of the corresponding geographic entity in the GeoNames gazetteer. The identifier links the archaeological site to an external geographic authority, ensuring interoperability with other datasets and supporting integration within the Linked Open Data ecosystem while preserving the internal identifier used in the database (id_site).

notes: text. This attribute is used to give clarifications on one or more entries of the corresponding row. For example, it can include specifications on the ¹⁴C datings and their calibration, such as how the reservoir effect was treated, if present. Furthermore, it is useful to collect general indications on the excavation projects.

3.2 C14 Dates

The introduction of the C14_dates table enables the preservation of original radiocarbon measurements associated with each archaeological site, ensuring methodological transparency and long-term reusability of chronological data. The fields provide the information on the original dates, that appear as calibrated ranges in the sites table. In the case of sites with multi-period dates, only those corresponding to the period specified in the PeriodO attribute are retained.

id_site (FK): integer. References Sites.id_site (see section 3.1).

lab_code (PK): varchar. Unique identifier assigned to the dated sample by the laboratory that performed the measurement.

C14_age: integer. Conventional radiocarbon age.

C14_SD: integer. Standard deviation of the measurement (1σ).

material: varchar. Type of material dated (charcoal, seed, animal bone, etc.).

id_reference (FK): varchar. Corresponding bibliographical reference, stored in the references table.

3.3 Finds

This table stores factual data on finds. The term ‘find’ refers to any identified or retrieved object, assemblage of objects, structure, feature, or naturefact, i.e., an object extracted from its natural setting and subsequently used without modification (Oswalt, 1973, p. 14, for instance, an unmodified shell used to scrape or an unretouched stone used as a hammer), which was, during the interpretative phase, linked by the researcher to a specific technique or task. Based on this reasoning, one might mistakenly associate the concept of a find solely with that of a tool. However, the role a find may have played during its pre-depositional life can vary greatly: it could be a tool, a product, a by-product, waste from various production processes, or the material trace of dwelling, use, or consumption activities. The result is a highly heterogeneous group of items, which are standardised through the following fields:

id_find (PK): integer. Unique identifier for each row.

site (FK): integer. References Sites.id_site (see Section 3.1).

type: varchar. This attribute identifies the find according to the definition provided by the researcher who studied it (for example, scrapers, crab remains, decorated shells, etc.). It does not rely on an established typological framework, but instead reflects a descriptive identification.

description: text. A free-text field for discursive descriptions of the find, allowing elaboration on one or more attributes recorded in the other columns.

quantity: integer. Indicates how many finds of the same kind are grouped together based on shared characteristics and interpretation.

intact: boolean. True or false.

investigation (FK): varchar. References the lookup table type_of_investigation (see Section 3.7) and it refers to the type of archaeological intervention that led to the discovery of the finds. This information is useful for assessing the quality of the data, as the context of retrieval and the type of investigation (e.g., survey, excavation) can provide different levels of detail and contextual information.

investigation_start and investigation_end: integer. Provide the timeframe of the investigation during which the specific find was identified, by specifying the start and end years.

3.4 Finds Materials

This table is linked to the finds and stores information on materials, with a focus on lithic and ceramic types, as these are the most abundant in Stone Age excavations and details about them are often recorded in the documentation.

id_material (PK): integer. Unique numeric identifier.

id_find (FK): integer. References Finds.id_find (see Section 3.2).

organic_inorganic: varchar. A constraint is applied to this attribute, allowing only the values ‘organic’ and ‘inorganic’. ‘Organic’ includes all materials with a carbon-based composition (such as bone, shell, or antler), whereas ‘inorganic’ refers to materials that do not contain carbon and have, for example, a mineral or lithic nature. The use of this controlled vocabulary ensures consistent categorization across the dataset.

material_specifics: varchar. Specification of the main material or materials that compose the find. A trigger function is associated with this attribute: if the value ‘lithic’ is present (either alone or among other values), then the two related fields, lithic_material and lithic_typology, become mandatory and must not be NULL.

lithic_material: varchar[]. Mandatory for lithic finds, it specifies the lithic raw material (flint, quartz, sandstone, etc.). The specificity of the classification may vary depending on the information available in the consulted literature.

lithic_typology: text. This field is used to provide further specification (in addition to the main type recorded in Section 3.2) on the typology of the lithic objects. Given that typological classification of lithic objects is a complex discipline, shaped by different research traditions across countries, it has been decided that this field should report the typological information exactly as provided by the original researcher, and in its original language. By avoiding the imposition of a single language (e.g., English), the risk of introducing interpretative errors is reduced.

ceramic_material: varchar[]. Contains specifications on the composition of ceramic materials (sand, mica, etc.), when such information is reported in the relevant documentation.

ceramic_typology: text. Typological information on the retrieved ceramic materials. This may refer to complete vessels (either found intact or reconstructed) or to the typology of sherds such as bases, handles, and rims. As with the lithic_typology field, the choice to retain the original language in this case is related to the long and complex tradition of pottery classification. Moreover, ceramic forms and features often reflect strong regional characteristics and show a high degree of variability.

3.5 Taskscapes

Taskscapes represent the interpretative layer of this database, as the data entered in these tables stem from the reasoning and interpretation carried out by the researcher responsible for analysing the corresponding finds (for the theoretical framework, see Section 2.1). General definition is provided by the table taskscapes_def, which, through the description column, describes the six sub-domains:

• - dwelling

• - food-getting

• - food-processing

• - handwork

• - lithic production

• - symbolic-ritual

The focus of this table is on technical actions; indeed, techniques are identified within the corresponding task. This table is linked to the finds table through the join table taskscapes, which also stores all additional attributes. Fields include:

id (PK): serial. An ID number, unique for each row, to identify technical actions, by the association task-technique and their related features.

id_find (FK): integer. References Finds.id_find (see Section 3.2).

id_taskscape (FK): integer. References the table taskscapes_def.

task: varchar. Any practical operation (Ingold, 1993) involving and indicated by the linked find, forming part of a set of connected tasks that define the corresponding taskscape (for example: organic material processing, waste management, game hunting, etc.)

technique: varchar. Definition of the identified technical action performed to reach an effective result within the task (for example: scraping, hook fishing, stone paving)

Number_of_studies_task and Number_of_studies_technique: integer. To address the uncertainty inherent in archaeological interpretations used to define tasks and techniques, a numeric attribute was added to the table. This number does not represent a value on an absolute scale; rather, it indicates the number of analyses and studies of various types that were conducted on a find in order to assign it to a specific task or technique. For example, in the case of lithic objects, beyond the general interpretation provided by the excavator, additional post-excavation analyses may have been conducted, such as microscopic analysis, use-wear studies, experimental archaeology, and other approaches. The goal is not to furnish a precise or accurate measure of interpretative reliability, but rather to offer an impression of how many different lines of evidence supported the conclusion.

stage: varchar. This field can only assume the values ‘use’ or ‘reuse’ (enforced via a constraint), and it becomes mandatory when the id_taskscape corresponding to ‘dwelling’ is entered. As a result, many entries will contain a NULL value. The stage attribute is admissible only for the dwelling taskscape, since in all other cases it is difficult to determine whether a find was deposited after its first and only use, or whether it resulted from subsequent reuse over time. For example, at the stratigraphic level, it is often possible to interpret the reuse of certain features after an initial use, as in the case of storage pits later repurposed for waste management activities (Marchand, 2014).

3.5.1 Lithic Production taskscape. The chaîne opératoire and dynamic-technology approach

The choice to record the tasks involved in lithic work in a separate table (lithic_production_taskscape) stems from the need to build a tailored structure containing attributes that are unique to this taskscape. Specific attention is given to lithic remains due to their ubiquity and density in Stone Age sites (Larson & Kornfeld, 1997), and consequently, the richness of information that can be inferred and the opportunity to use them as a common comparative reference.

Traditionally, there are numerous levels of observation for lithic materials and different methodologies of analysis (Inizan et al., 1999; Sørensen, 2006b), each focusing on various aspects such as typology and function of tools, raw materials, physical actions, and the methods, techniques and skills involved in their use and production. Generally, when analysing tasks and techniques, as in the purpose of this project, it is possible to focus on the processes involved either in the production of lithic tools or in their use. The latter is included in the general taskscapes table; the former, by contrast, is more thoroughly detailed through the use of this dedicated table.

The structure is built to be aligned to the chosen methodological approach: the dynamic-technological classification (DTC). This approach has its focus on the technician rather than on the techniques or on the objects, aiming at showing the artisan’s intensions by grouping together chipped stone objects resulting from similar actions in the production process (Schild, 1980; Sørensen, 2006a; Berg-Hansen, 2017). In this sense, it is possible to say that the DTC allows to access the ‘conceptual schéma opératoire’ (Pelegrin, 1990), i.e., a chain of intensions, of stages organised to reach a specific anticipated result. Effectively, it is crucial to apply the DTC approach in conjunction with the concept of the chaîne opératoire (Leroi-Gourhan, 1993), which serves as a framework for locating and organising objects within the broader sequence of actions (see Section 2.1). For stone tool production, this sequence includes every step from the initial procurement of raw materials to the final stage of tool discard due to damage, wear, or loss (see Table 2).

Table 2

Operational sequence for the production of lithic flake tools. Adapted from Eriksen (2000), as cited in Berg-Hansen (2017).

STEP	ACTIVITY	DESCRIPTION
1	Procurement (of raw materials)	Localisation/source, testing, selection and transport.
2	Preparation	Primary preparation: initial shaping of raw materials as preparation for the blank production. Secondary preparation: maintenance, correction and reworking of cores.
3	Blank production	Production of blanks for further modification into tools.
4	Production of tools	Selection of blanks, shaping of tools.
5	Use	Use of tools including resharpening and reworking.
6	Discard	Damage, wear, loss, deposition.

In applying the DTC approach, the focus will be on three specific steps of the chaîne opératoire: preparation (2), blank production (3), and modification/tool production (4).Specifically, the application of the DTC to the lithic assemblages described in the consulted literature will follow the methodology used by Berg-Hansen, Damlien, and Zagorska (2019) in their technological study of the lithic assemblage from the Latvian site of Salaspils Laukskola, dating to the Final Palaeolithic. This methodology is based on Schild’s work, Introduction to Dynamic Technological Analysis of Chipped Stone Assemblages (1980), in which he outlines the method, develops classification lists, and tests them through three case studies from different chronological contexts.

This approach consists in identifying the stages of the lithic production process represented at an archaeological site by recognizing the artefacts resulting from each stage. Typically, this classification is performed separately for each raw material. However, for the purposes of this research, all artefacts from all exploited raw materials at the site are considered as a single, unified assemblage. This choice stems from the need to conduct a broader cross-unit comparison of the technological strategies employed at the site (Schild, 1980).

A separate lookup table, production_process_tasks, is used to store information on artefact categories and their corresponding tasks (see Figure 6). This table defines six stages of the knapping chaîne opératoire, and is based on Schild (1980) and Berg-Hansen, Damlien, and Zagorska (2019). The key difference lies in the absence of further subdivision by raw material. In fact, the main lithic_production_taskscape table includes data related to all types of lithic products without distinction. The attributes compiled in this table include unique identifiers, a reference to the task, the number of studies used to support the interpretation, and a notes field to register relevant observations. Identifying which tasks were carried out at the site, and which were absent, enables conclusions to be drawn about the organisation of the analysed hunter-gatherer communities and the function of the site they inhabited. These insights, in turn, shed light on economic strategies and ways of life (Larson & Kornfeld, 1997). For example, some sites may have served as workshops for specific tool types, while others might show a complete absence of debitage, suggesting specialized usage.

Figure 6

3.6 References

References are stored in a dedicated table, with attributes referring to the first author and year of publication, as well as a column containing the full bibliographic citation in APA 7 style. The first author and year are stored in separate fields to allow more complex queries on archaeological data by author or year. This table is linked to finds through an intermediate table, finds_references, which connects each find to the documents consulted to retrieve the relevant data.

3.7 Normalization and lookup tables

An important aspect of heterogeneous databases containing not only quantitative but also qualitative values is data consistency (Fronza, 2003). The primary objective is to enhance readability, interoperability, and query efficiency. Data consistency can be achieved through a range of strategies, such as enforcing non-null constraints on specific fields and defining strict data types. An archaeological database is typically populated with a variety of concepts and definitions that are not always unambiguous. The choice of a specific word or expression to define a feature or one of its attributes largely depends on the individual researcher, their experience, and academic background. To normalize terminology, a common strategy is the use of controlled vocabularies (Fronza, 2003; Gattiglia, 2018), that is, predefined lists of values that guide data entry and control the use of nomenclature. This type of normalization is enforced in the NAUTICC database through the use of four lookup tables: type_of_site, type_of_investigation, regions, and PeriodO_chronology. These are linked to the main tables via foreign keys, thus constraining the choice of values to those predefined in the thesauri. As a result, this approach prevents spelling errors and the use of irrelevant or inconsistent terms, contributing to a standardised and coherent structure across the entire database. In addition, the terms included in these lookup tables are aligned with external semantic authorities in order to enhance interoperability. Site types and investigation types are linked to corresponding entities in Wikidata through persistent identifiers; regions are linked with URIs from GeoNames; and chronological terms are aligned with PeriodO.

Lookup tables contribute not only to terminological normalization but also to the structural normalization of the database, which aims to minimize redundancies and ensure efficient data retrieval (Silberschatz, Korth & Sudarshan, 2019). This is part of an effort to achieve First Normal Form (1NF), where all attributes contain atomic, indivisible values. The 1NF is applied throughout the database, except for two array columns (lithic_material and ceramic_material). The decision not to unnest these attributes is based on two main considerations: data entry speed and the overall scope of the database. Since these fields may contain many values, splitting them into atomic units would significantly slow down the data entry process. Moreover, although important, these attributes do not represent the core of the research questions that guide the structure of the dataset, and therefore are not expected to be the primary focus of the majority of queries.

3.8 Relationships sets

The assignment of primary and foreign keys allows for the consolidation of relationships between tables. These keys ensure referential integrity, preventing the existence of orphan records and enabling the propagation of updates. The relationships in this database fall into two main categories: one-to-many and many-to-many. The former type formalizes the connection in which one row in a table corresponds to multiple rows in another, for instance, each site can be associated with multiple finds. In many-to-many relationships, multiple rows in one table can correspond to multiple rows in another. In this database, there are two such relationships, between finds and their corresponding references, and between finds and their associated taskscapes. Each find may be cited in multiple references, and each reference may include multiple finds. Similarly, each find may be included in multiple taskscapes, and each taskscape may comprise multiple finds. Many-to-many relationships are implemented through join tables, which link the two main tables by storing their respective primary keys. In the case of references, the join is handled by the finds_references table.For taskscapes, the join occurs through the table named taskscapes, which not only stores the primary keys of both finds and taskscapes_def, but also includes additional attributes related to the techniques and tasks, making it both a join table and a descriptive entity.