This data paper presents a new SQL database of sedimentary charcoal records. An important value and main motivation of this database, and of earlier versions of this database, is to understand the history of fire in the Earth system, at regional to global scales. As presented in the manuscript, there was considerable effort placed on quality checking, development of new age models, and adding site and entity metadata.  The new database represents a large improvement in the breadth and depth of past databases.  The authors claim several issues of data errors in the most recent database (the GCD, on paleofire.org).  While paleofire.org provides a user-friendly interface to the data, I agree that metadata on chronological control is lacking.

We thus have a situation where there are multiple databases with different PIs sponsoring the data bases.  To be up front regarding conflict-of-interests, I have no vested interest nor history of involvement in these databases except in their early genesis > 12 years ago when I participated in the first publications of this database.  Since then, my main interest has been on site-level interpretation, or at most intercomparisons of a few sites.  Thus, I am familiar with the nature of these data and I appreciate the goal of using these data in Earth-system science.

I found the manuscript to sufficiently describe the data.  Modest database skills are required to read the SQL database. As described by the authors, the database is unique given the additional sites, age models, and metadata added.  However, it is built from existing databases and my comments below address this issue.

My first concern is parallels with the Neotoma Paleoecology Database. The RPD has a data table structure that parallels Neotoma. All the variables in the RPD map directly to a variable in a table in Neotoma. The metadata forms in Tilia (which uploads to Neotoma) and the chronology information are much more thorough in Neotoma than in the RPD.  Furthermore, many (if not most) of these records contain other data types (pollen, geochemistry) that may be archived in Neotoma.  Thus, the effort at age model development would better serve the research community had the data been uploaded into Neotoma.  Of course, this can still be done.  As stated on the Neotoma database website: " Neotoma will enable joint analysis of multiproxy datasets to address paleoenvironmental questions that transcend those possible with single-proxy databases." Currently, only 25 sites in Neotoma have macrocharcoal data, and 19 sites have microcharcoal data.  However, many of the entities in the RPD exist in Neotoma for pollen and other data types. Neotoma is fully capable of defining all >100 types of units for measurements (area, counts, size fractions).  I understand the history that lead to this situation: the GPD began many years before Neotoma was archiving charcoal data.  I now think Neotoma is the proper home for sedimentary charcoal data.

However, there are limitations in the Neotoma database with respect to charcoal data for research. The API interface for Neotoma, as exists in the Neotoma package in R, can batch-download datasets. The API interface for downloading charcoal data may not be functioning for charcoal datasets. I am not very familiar with this interface.  Once functional, R scripts could generate the charcoal data and various other data from the same entities (e.g., LOI, pollen of fire-sensitive taxa). Thus in the absence of this interface, stand-alone databases such as this are needed.

A second concern is the universal application of Bacon age-depth modeling.  Bacon is superb when dating density is high enough to result in overlapping PDFs of the calibrated ages. In contrast, in situations when, for example, a 14,000-year record is dated by only five well-separated dates, in my experience, Bacon produces interpolations that are indistinguishable from linear interpolation.  In such cases, spline fits using, for example, Clam, will not result in abrupt changes in sedimentation rate at the dated depths and not miss dates that are a little out of line.  Often, original authors have placed considerable effort in the unique situations of their sediment record, and thus applying a canned approach (as described by the ageR package) may not be as desirable as simply updating the original model with INTCAL20 calibration.

This second concern provides another argument for Neotoma for dataset archiving.  Neotoma has separate geochronology tables (a list of all dates measured) and chronology tables (the age controls used for a particular age model or "chron").  New "chrons" may be added to existing data sets.

Finally, a third concern is that this database does not store the raw data values at most sites, but rather some derived value.  Specifically, the TYPE variable for most entities is 'concentration' or 'influx' or some other value that is very unclear to its meaning ('other').  I assume this derives from the original data collection efforts in the original databases, in which raw data may have not been archived.  (By 'raw data' I mean the measured value for each sample, e.g., 'count' or 'area', or 'mass').  Many statistics depend on these values (e.g., the CharAnalysis program).  It is also just good practice to archive raw values, not some derived value.  For example, the new age models cannot be used to recalculate new influx rates if the data are not stored as raw values (or at least concentration data).  Scanning the database, less than 20% of the entities have 'count' or 'raw count' under TYPE, while most are concentration.   Furthermore, converting from concentration back to raw values (multiplying by analytical_sample_volume) is not easily done because the 'analytical sample volume' is a string field with values such as '5cm3'.  I note that there was no effort to locate the raw data values (as they are available for several sites that are reported as influx), but rather to use whatever units were provided in the earlier databases.  Analysis of the RPD will need to be made very carefully to prevent errors such as double-calculating influx rates or concentrations. 

I examined five of my sites within the database.  I found errors in each of these sites.  Correct data exist on Neotoma and on my personal web page (for most):

1. Yahoo Lake: 1) does not have a new age model (missing from the age_model table).  2) Data described as concentration, but the units in the sample table are influx values.  3) The sample volumes are incorrect.
2. Cooley Lake: 1) data described as concentration, but the values in the sample table are counts. The data are on Neotoma and my personal web page. 2) The sample thickness values are 0 (which is impossible) or 0.01, but most samples have a 0.5 cm (0.005) thickness.
3. Clayoquot Lake: data described as concentration, but the values in the sample table are counts.
4. Rockslide Lake: 1) data described as influx and are indeed influx in the sample table! However, raw count data are available 2) The sample thickness values are 0 (which is impossible) or 0.01, but most samples have a 0.5 cm (0.005) thickness.
5. Wentworth Lake: 1) data described as concentration, but the values in sample table are counts. 2) sample thicknesses and volumes missing.

It is interesting to surmise the sources of these errors.  In my case, I provided the original raw data in spreadsheets which included measured values,  concentration, and influx columns. Thus, over time, through different versions of databases, information was lost or changed.  If these issues were detected in the five sites that I checked, there is reason to believe such issues exist with all the sites. 

I recognize the effort placed into creating this database.  I see much work was spent on adding new sites, the ageR age models, and developing the MySQL schema, and adding some new metadata fields.  However, it is quite concerning those errors in old databases are perpetuated into new databases. I highly recommend Tilia and Neotoma as a means of correcting errors. The data upload process into Neotoma (performed by data stewards) involves several quality control procedures. Uploading to Neotoma is time consuming because 1) the errors in the GCD and RCD will preclude using a bulk upload method, requiring checking against original publications, and possibly contacting authors, and 2) the quality control checks in Neotoma often detect additional errors.

My recommendation for a major revision is for a large but very do-able job:

1) Check if the site and entity exist in Neotoma and provide a table that matches the entity to the Neotoma entity.

2) Check the measurement units and change values to raw measurement units where possible.  Also provide correct thickness values wherever possible. The numerous coauthors should be able to help with this task.

3) Change the analytical_sample_volume to double and include a new variable for volume units or standardize all samples to cm3. 

4) Have the sample table contain four columns for 1) value (e.g., count), 2) volume, 3) concentration, and 4) influx (calculated using the new age model when possible).  In theory, columns 3 and 4 could be omitted and generated on the fly as needed. However, it will not be possible to have raw values for all sites, thus requiring these four columns to exist.

This manuscript presents the Reading Palaeofire Database (RPD), a SQL database of palaeofire records. The authors took great care in collating new palaeofire records, combining these new records with published databases (such as the Global Charcoal Database (GCD) and its various versions), correcting errors, collecting metadata, and assigning consistent and up-to-date chronologies to each record. 

Overall, I readily acknowledge that the RPD was a formidable undertaking and that its publication could be very useful to the palaeofire field. However, I do have several concerns which would need to be addressed before I could recommend publication. In addition to more specific comments regarding components of the manuscript and its associated SI, I also have several more general comments which are made below. I would also like to state that I broadly agree with the comments made by Drs Gavin and Williams. As such, I would urge the authors to note the recurrent themes in my comments/criticisms of this manuscript and the associated RPD data product. 

General Comments:

The manuscript in its current state is ambiguous with regard to the RPD’s relationship with the Global Palaeofire Database. I mean this both in a direct sense (i.e. how much of the data in the RPD was directly pulled from the GPD, both earlier versions and the most up to date web version?) as well as in a logistical sense (was the Global Palaeofire Working Group involved in the creation of the RPD?). Statements about these relationships are ambiguous (see specific comments below regarding L98-99, 266-269, and SI Table 1). For example, the current presentation of the RPD does not allow the viewer to tell from where each dataset came. Despite the assertion that the RPD “is a community effort,” it is rather unclear how members of this community (e.g., the Global Palaeofire Working Group) were engaged and involved in the process. More broadly, I am very curious as to why the RPD is not being directly integrated into the existing community framework of the Global Palaeofire Database and Working Group? 

Despite the merits of this manuscript and its associated RPD, I feel that if released in its current form (i.e. as a self-standing database) and without a plan for community integration, then this work could have a detrimental impact on the broader palaeofire field and the willingness of its members to share data. By downloading multiple community-driven databases that embody the spirit of open data, making improvements and expansions, and then creating a separate and less accessible database (see comment below), I would argue this is a step in the wrong direction. Why go through all of the work of improving community databases to then refuse to return the database to these same communities and in these same frameworks? Despite its flaws, the GCD’s web interface is significantly more ‘available’ than an SQL database (see comment below). The same would be true for Neotoma. As Drs Gavin and Williams have previously expressed in their comments, interfacing the RPD with existing community databases would achieve greater impact and utility for the palaeofire community. 

Although I understand that SQL is open source and theoretically available to all. I assert that providing the data only in a SQL format poses an equity and accessibility issue. Use of the SQL database requires downloading a large program to read the files. To then use or access the data requires knowledge of a programming language to construct queries. I argue that this is an undue burden on accessibility. For anyone without knowledge of SQL to access the data would require potentially hours of instruction and learning. As a test case, it took nearly two hours for me to download and install mySQL, and then to import the data. Barring integration with community databases, I think the simplest way to address this issue would be to also provide text or csv files of the tables that make up the SQL database. This way, anyone (even those without knowledge of this database style and language) could assess the data freely and easily. I feel that ignoring the hurdle that the SQL format poses to potential users of the RPD would represent undue gatekeeping in direct contradiction to ESSD’s aim of “furthering the reuse of high-quality data of benefit to Earth system sciences.” Alternatively, I reiterate the suggestions of Drs Gavin and Williams to integrate the RPD with either Neotoma or the Global Palaeofire Database. 

Manuscript main text – Specific Comments:

L24-30: References? These statements should be supported by relevant literature. 

L33-36: Same comment as above. 

L66: I think a clear statement as to the logistical relationship between RPD and the Global Palaeofire Database as well as the GPWG is needed here. Was the RPD as created by these authors done so independently from the GPWG? Was there community involvement and input during the creation of the RPD?

L98-99: Does this mean that any/all charcoal datasets which were not previously publicly available were provided by one of the authors of this article? Relating to my query regarding L66 above, I think a statement is needed to explain who the authors of this article are and what constituted a ‘contribution’ to this article, especially as the bulk of the RPD is derived from the GCD and GPWG. Were original authors of datasets in the GCD version not included as co-authors by virtue of their having made their data publicly available?

L103-108: Although the download of mySQL and the importation of the RPD was relatively straightforward and aided by the documentation provided by the authors, I wonder if this format poses an equity issue and accessibility issue. Namely, could the tables also be provided as csv or text documents so that those less technologically inclined could still view the RPD without using SQL queries?

L126-127: However, in many cases, I suspect that the accuracy of GPS coordinates for sites are not this great. How can trailing nought values in these latitudes and longitudes be differentiated as being reflective of accurate GPS location versus merely artefacts of non-exact GPS? 

L159-160: Charcoal measurements are not always made in terms of volume (e.g., by dry mass basis). How were these types of measurements integrated into the RPD? Or were they simply omitted?

L266-269: This sentence is misleading as both versions 3 and 4 are several years old and many datasets have since been added to the online version of the GPD. E.g. as of 16 November 2021, the GPD contains 1231 cores. This is not a fair comparison. A more direct measure of the RPD’s value would be the number of new records (not sourced from the GPD or any earlier versions of the GCD). 

L326: Here again, the ‘community’ needs to be defined (similar to my comment regarding L66 and L98-99). 

L329: It is very difficult to judge whether there is actually expanded coverage (as per my comments regarding L266-269). More direct comparison or quantifications are needed to assess the validity of this statement. 

Tables 1, 2 , and 4: For the fields which were ‘Selected from predefined list’, it would be prudent to provide the choices contained within these lists. Upon reading the SI, I see there are tables containing these. It might be good to note this in the main text. 

Figure 4: The legend text is fairly small and hard to read, please consider making this text larger. 

Supplementary Information – Specific Comments:

SI Table 1: An extremely useful and important field that is missing from this table is the source of each site (i.e. which version of the GCD did each come from, was it a new addition by the authors or this article, etc.). 

SI Table 1: I believe that all of the datasets coming from the NOAA database are inaccurately cited. As per the NOAA database site: “Please cite original publication, online resource and date accessed when using this data. If there is no publication information, please cite Investigator, title, online resource and date accessed.” For example, Bass Lake Kandiyohi County should be attributed to Marlon and Umbahowar. 

SI Table 1 : There appears to be duplicates of the Wild Tussock site.