The CHIPS Database: A Repository for Chemical Data in Archaeometallurgy of Iron

3.1. ‘Contexts’ table

It is composed of 14 fields (primary key: ‘context_id’; Table 1). Its purpose is to identify and geolocate archaeological contexts, link them to geoadministrative data, and define their chronology. A context is classified as either a locus, a phase of occupation or activity, or a stratigraphic unit. Multiple contexts may belong to the same archaeological site. For instance, metallurgical sites often contain heaps of slag that were successively piled up but remain stratigraphically distinct. In such cases, each heap is treated as an individual context, with its name recorded in the ‘context_name’ field. The archaeological site of which these heaps are part is registered for each single context in the ‘place_name’ field. An additional field ‘context_type_id’ used as a foreign key allows a more precise description of the context: locus, phase, stratigraphical unit, etc. A ‘context_type’ field with a value constraint is used to express the type of context. The ‘locality_id’ field acts as a foreign key to the ‘gadm’ parent table. The Global Administrative Areas dataset (GADM), published online by U.C. Davis, includes approximately 400,000 administrative entities worldwide. These entities are documented across five hierarchical levels, ranging from country to municipality (GADM n.d.). Four fields provide spatial information. The ‘srid’ field is documented by the ‘spatial_ref_sys’ table associated with the PostGIS extension, and is used to interpret the coordinates in the ‘long’ and ‘lat’ fields (decimal degrees or projected coordinates). In the source documents, the geographic coordinates are expressed in a variety of projection systems, depending on the location of the study area or national administrative recommendations. For France, for example, coordinates are often published in the Lambert-93 system (EPSG:2154; International Organization for Standardization 2019). The Boolean ‘centroid’ field indicates whether the coordinates are those of the site, or those of the administrative entity’s centroid. Three fields are associated with chronology. The field ‘edtf’ gathers EDTF (ISO 8601-2:2019) temporal information on the different contexts allowing, among others, to record chronology uncertainities (‘?’ mark) and approximations (‘~’ mark). Along with the ‘edtf’ field, the ‘periodo_id’ field links the chronological data to the Periodo gazetteer to ease the definition of the periods of activity. The last field, ‘points’, is made up of objects of type GEOGRAPHY, produced using the PostGIS ST_MakePoint geospatial function. A field ‘cont_bibreference’ is used as a foreign key to the ‘literature’ table. It allows to get access to the documentation related to archaeological data and excavation, as this kind of information is often summarized in the publications dealing with chemical data.

3.2. ‘Samples’ table

The ‘samples’ table is composed of 5 fields (Table 2). Two fields identify the sample: ‘sample_id’ is the table’s primary key and ‘sample_name’ is the identifier given by the archaeologist during the post-excavation study of the material, or a code given when the sample was taken. ‘site_id’ is the foreign key referencing the context in which the artefacts were found. A ‘comment’ field allows a more precise yet less standardised description of the sample if needed. The ‘id_typo’ field is filled in by the ‘typology’ table, the aim of which is to obtain information on the artefacts as precisely as possible, while ensuring the effectiveness of categorical queries.

The ‘typology’ table therefore has a hierarchical structure with five levels (Table 3). The first level ‘process’ corresponds to the ironmaking process in question, i.e. the direct or indirect process. Establishing this difference is fundamental, since the chaînes opératoires and physico-chemical processes involved are radically different. The data associated with either process cannot therefore be compared directly. The ‘context’ field specifies whether the material was collected in a geological (i.e., extra-site, for ore or earth), archaeological (i.e., intra-site) or experimental context. The ‘material’ field indicates the nature of the artefact: slag, earth, ore, rock, etc. The ‘category’ field is the first level of qualification for the material. For the material slag, this qualifier could be ore smelting or metal forging, for example. The ‘subcategory’ field is the second level of qualification, which can give even more details about the material. For a smelting slag, this second level can be used to determine whether the slag is moulded at the bottom of the furnace, or whether it has flowed out of the furnace. This level of precision is necessary to accurately interpret the archaeological context and the associated chemical data. A last field ‘ark_frantic’ references each typological entity with an ARK permanent identifier linked to the Pactols thesaurus. This aspect will be further developed in section 4.1.

3.3. ‘Analyses’ table

This table contains 97 fields. The ‘sample_id’ field is the foreign key to the ‘samples’ table. Multiple analyses can be related to a single sample. Each of these analyses is implemented as distinct rows in the ‘analyses’ table and therefore have a single ‘chips_id’. Three other fields are foreign keys to a table listing the analytical devices used to perform the analyses. We distinguish between ‘major_setup_id’, ‘trace_setup_id’ and ‘isotope_setup_id’, corresponding respectively to the equipment used to measure major elements, trace elements and isotopes (Table 4). These three categories of chemical data are often acquired by distinct instruments. Most analytical methods are documented either through scientific papers or through technical documents which make it possible to determine reference values for limits of detection (LoD) and measurement uncertainties. This aspect will be detailed in section 0. A ‘bibreference’ field is documented by a ‘literature’ table, which gives the database user access to the publications associated with the analyses (Table 5). At present, the table includes 69 fields expressing chemical data, which form the core of the database. Of these, 65 are absolute concentrations of chemical elements. Fourteen fields relating to the contents of O, Na, Mg, Al, Si, P, S, Cl, K, Ca, Ti, Mn and Fe, as well as the loss on ignition, are expressed by weight percent (wt%). The ‘os_ppt’ field is filled in with contents expressed in ng.kg^-1. The fifty other fields associated with contents are expressed in mg.kg^-1 (International Organization for Standardization 2007). Four other fields document isotopic ratios. Depending on the type of analysis performed, only certain chemical elements are measured. For a given analysis, the absence of a measurement is represented by the NULL constant. In cases where the concentration of an element is too low to be reliably quantified, it is considered below the LoD. To represent such data, we use a single numerical value: ‘-1’. This negative value is easily distinguishable from elemental contents or isotopic ratios, which are always positive. It is common practice in data analysis to replace values below detection limits to avoid excluding other variable values for a given sample. Therefore, users of the CHIPS database have the option to apply a replacement rule for the ‘-1’ values in the exported dataset.

3.4. ‘measurement errors’ table

This table consists of 90 fields. An ‘error_id’ field is the table’s primary key (Table 6). The ‘chips_id’ field is a foreign key referenced in the ‘analyses’ table. The 88 other fields contain values which correspond to the uncertainties associated with each measurement in the ‘analyses’ database, expressed as mass fractions (either percents, mg.kg^-1, or ng.kg^-1; International Organization for Standardization 2007).These values are either provided directly by the authors in the context of certain publications, or calculated according to a protocol which will be detailed in section 4.2.

4.1. Data collation and standards

4.2. Data quality and accuracy

The quality or accuracy of three types of information is assessed in the database using specific indicators.

The accuracy of spatial data is expressed by a Boolean field indicating whether the coordinates of each entity in the ‘contexts’ table correspond to the actual location of the archaeological context. If precise coordinates are not documented, the entity is placed at the centroid of the relevant administrative entity, typically the location of the administrative building (e.g., town hall, county office). This accuracy is particularly important for spatial analyses, especially at a micro-regional scale, such as when studying ore mining and transport strategies.

Chronological data quality is managed using the Extended Date/Time Format (EDTF) ISO standard notation (Tarver & Phillips 2013). By convention, historical period intervals are expressed with approximation marks. The quality of chronological data is also assessed by a Boolean field, indicating whether the authors of the source documents consider the dating of the archaeological context to be fuzzy. When absolute dates are provided by the authors, they are entered as such in the database. If a period is mentioned, the commonly accepted intervals for that period are recorded. For example, sites dated to phase C1 of the Roman era in Poland are expressed as “150~/250~”, indicating the interval [150; 250].

Given that chemical information is central to the database, particular attention was paid to qualifying data quality, which is expressed in the form of measurement errors. Each analytical device has its own characteristics that influence the trueness and precision of measurements. Trueness is determined using standard reference materials with known chemical compositions, where the differences between the known and measured values express accuracy (International Organization for Standardization 2023). Repeatability is determined by performing a series of measurements on the same material and studying the dispersion of the measured values around the mean, with standard deviation typically used as the indicator. The qualification of these factors has been widely discussed within the archaeological community, e.g. (Hughes 1998; Nazaroff, Prufer & Drake 2010; Frahm 2012). In the case of CHIPS, it was decided to use a single factor to express measurement quality: the measurement error. This error is a function of the factors mentioned above. Numerous methods can be used to calculate these values, as summarized by Buonaccorsi (2010). The measurement error is also influenced by the abundance of the element being measured in the material: the closer the measurement is to the instrument’s LoD, the greater the error. Most analytical laboratories use reference values to express measurement errors, typically in relative terms as a fraction of the measured value (e.g., 5%). In some cases, these values are provided in concentration intervals to account for the influence of abundance. These values are communicated either through scientific articles—as in our case (Carignan et al. 2001)—or technical documentation. Each time new data is added to the ‘analyses’ table, if the analytical setup includes known uncertainties, a function is triggered to automatically calculate the associated measurement errors. Of the 33 analytical devices currently listed, 9 have sufficiently precise documentation to determine measurement uncertainties. However, these 9 devices account for 2,122 out of the 3,004 open analyses in the database, or approximately 70%. Further documentation work will be carried out to extend this functionality to other analytical devices. In any case, this feature is proving very useful to users in identifying potential data processing biases due to analytical parameters. The detailed protocol for recording measurement errors and the trigger function are explained in the online database documentation (https://iramat.github.io/chips/docs/#measurement-errors).

5.1. The GEO app and the the ‘Fabrique Numérique du Passé’ platform hosting

The database is currently hosted on a shared web hosting solution provided by the Huma-Num research infrastructure (IR* Huma-Num) (Baude et al. 2019), the French national body of DARIAH-EU, through a PostgreSQL 15 server running in SSL mode. This solution was selected for its ability to provide long-term hosting of the database within an infrastructure where hardware and technologies are regularly updated. The database has been integrated into the Fabrique Numérique du Passé (FNP) platform, which is dedicated to the open sharing of scientific research data and is compliant with the FAIR principles (Costa 2023). A data query interface was developed by the Huma-Num Projets Time Machine consortium using the GEO software by Business Geografic (Costa and Disser n.d.). A cartographic solution was prioritized as the most suitable for meeting user needs. This approach allows for the comparison of the spatial distribution of CHIPS data with other information sources, such as geological maps. It facilitates the analysis of nearby mineral resource exploitation, simplifies data searches in geochemical documentation, and even supports the planning of field interventions, such as sampling.

Each context is represented by a circular marker, with the size proportional to the number of analyses available. The cartographic interface also enables the selection of entities based on spatial criteria, such as proximity. Spatial queries can be performed using predefined geometric shapes (ellipses, quadrilaterals) or free-form polygons. Additionally, queries based on administrative criteria have been implemented, allowing searches at two hierarchical levels: country and province/region/state. A search by sample name is also available, currently limited to exact matches, but future updates will include the PostgreSQL extensions pg_trgm and fuzzystrmatch, to enable fuzzy string matching and LIKE queries for partial matches. A chronological query option is also available, allowing users to define a date interval using start and end date fields. This query returns contexts where the start date is greater than or equal to the input start date and the end date is less than or equal to the input end date. Queries based on the nature of the analyzed material are also planned, enabling, for example, the selection of ore analyses only. Once contexts are selected, the data can be consulted through several nested forms. These forms display, in sequence, geo-administrative data for the context, information about the analyzed samples (sample name, typology), and chemical data divided into three subwindows: major elements, trace elements, and isotopes (Figure 2). A final sub-section lists the bibliographic references from which the analyses come.

Figure 2

This IT setup has two drawbacks. First, the ready-to-use GEO app is commercial software, requiring regular license renewal; otherwise, the technology can no longer be used. Second, although the FNP/Huma-Num platform provides strong IT security, it also imposes restricted database administration privileges, with only the PostgreSQL port (5432 by default) accessible to the authors. As a result, the database has limited interoperability with other software, such as dashboards, APIs, and external services.

5.2. The CHIPS RESTful API

To overcome these interoperability limitations, and stay in an open-source environment, we established a copy of the CHIPS instance on an Ubuntu virtual machine hosted on the Cloud@VirtualData platform of the Mésocentre Paris-Saclay. This copy operates in a more permissive environment, enabling the integration of additional IT applications, in particular with PostgREST. Regular data-only dumps from CHIPS to CHIPS-dev are performed using a Bash script.

The standalone PostgREST web server allows to expose a selection of CHIPS views as RESTful API endpoints. To demonstrate the value of reusing archaeometallurgical chemical data, we chose to first publish views of previously normalized datasets along with their bibliographic references. While PostgREST provides online access to raw data, we also deployed a Python dashboard that consumes these data to model the different datasets and provide a synoptic view of the CHIPS database content (Figure 3).

Figure 3

Additional information is provided on the CHIPS database website.

While the CHIPS dashboard aims to provide a synoptic view of the database content for dataset selection, we have started to develop an R package (iRamat; Institut de Recherche sur les ArchéoMATériaux n.d.) for more refined and advanced statistical analysis. Currently, this package includes only a limited number of functions (one of which connects to and retrieves data from the CHIPS API) and serves primarily as a prototype (Figure 4) for the future development of an R connector within the ASTR R package (Rose 2026). By doing so, our goal is to foster collaboration among archaeometallurgists—potentially alongside their datasets—in order to build a collective tool useful to the community, helping to standardise and make archaeometallurgical data more reusable.

Figure 4

Core developments

The CHIPS database is now at an advanced stage of development. The conceptual model has been tried and tested, ensuring the smooth operation of already implemented functions. The next stages of development will focus on improving the data query interface, particularly by introducing new query options. The database currently provides open access to 3,000+ chemical analyses related to 580+ archaeological contexts. However, it contains a total of 7,314 analyses from 1,298 different contexts. Moderation work is underway to ensure that the dissemination of these analyses complies with legislation on the protection of intellectual property rights. The repository will soon be enriched by the integration of structural data, such as the results of X-ray diffraction analyses. This data will be expressed in fractions of mineralogical species (e.g., hematite, siderite, quartz, etc.), and will be particularly useful for describing ore samples and enabling further interpretation of the geological contexts in which they were extracted.

User community

We aim to structure a community of users around the database in a bottom-up organization to foster collaborative research. The use of this tool will provide an opportunity to collectively consider the production of archaeometallurgical chemical data from different perspectives: intercomparability, reference materials, and analytical protocols. The rules for contributions, the contributions themselves, the intellectual property of the data, and their reuse rules are explicitly and transparently documented on the dabatase’s website (https://iramat.github.io/chips/docs/#how-to-cite). We envisage a CC-BY 4.0 license for the data, CC0 for the metadata, ODbL for the database and MIT for the computer code.

Expanding the database

An international communication campaign is being conducted via a webinar and a mailing list. A workflow for feeding the database with additional datasets is proposed on the website (https://iramat.github.io/chips/docs/#how-to-contribute). This will lead to the import of several new datasets in the near future, conducted by members of the user community. The data will be moderated prior to their integration into the database.

The initial communication campaigns around the CHIPS database have also sparked interest among researchers who are not strictly focused on iron archaeometallurgy. For example, “ore” is a cultural term used to identify a rock or mineral from which metal can be extracted. The same rock or mineral might instead be used as a pigment or colorant in another technological practice, meaning its function and identification depend on its use and context. More generally, the conceptual data model of the CHIPS database can be adapted to create chemical reference systems for the study of other archaeological materials, such as glass or copper alloys.