From the earliest days of SOD, starting with the Deep Sea Drilling Project (DSDP; 1968–1983) through to ODP (1985–2003) and, for some expeditions, until the end of IODP (2024), the core description scientists began their task with handwritten notes on paper forms (Figs. 1 and 2). The handwritten notes were made on templates printed for each section at intervals of ∼ 1.5 m. The templates featured a scale in centimeters from the top of the section, followed by columns for detailed observations, with the last column available for any comments. Igneous rock describers often typed the initial descriptions in a more structured fashion and added them to the template along with the handwritten notes (Fig. 2b). These initial notes were photographed and archived on microfiche until ∼ 1992 and scanned and archived as PDF files after that. They are accessible online for the period ending in 2005. In more recent years, if the handwritten notes were still created, it was up to the project scientists to determine if they should be included in the published expedition Proceedings Volume.

The handwritten notes were summarized and transcribed to visual core description diagrams (VCDDs) using graphic and text production tools available during that early phase (Figs. 3 and 4). The VCDDs were published in the Proceedings and represented the final descriptive data product from each expedition. Sediment descriptions were summarized for each up to a ∼ 11 m long core with the following 16 graphic columns (Fig. 3): time–rock unit; biostratigraphic zone and fossil character separately for foraminifers, nannofossils, radiolarians, diatoms, and another potential group; paleomagnetics; physical properties; chemistry; section number; meters from top of core; graphic lithology; drilling disturbance; sedimentary structures; samples taken; and lithologic description. Microscopic descriptions of sediment smear slides (typically one per core) were added to the VCDDs and included texture (percent sand, silt, and clay) and composition (percentage of microfossil groups and other significant components). Igneous rock descriptions with typically more detail were prepared for up to 1.5 m long sections cut from cores, with the following eight columns (for basalts, slightly modified for phaneritic rocks) (Fig. 4a): centimeter scale from top of section, piece number, graphic representation, orientation, shipboard studies, lithologic unit, and final wide column for detailed descriptions. The detailed descriptions were structured into paragraphs including the section ID, unit number (interpreted from compositional and textural characteristics), pieces included in the unit, curated section length, contacts, phenocrysts and groundmass in basalts or the major mineral phases in phaneritic rocks (abundance, size, shape, degree of alteration, and comments), color (of the dry rock), vesicles (abundance, distribution, size, shape, and fillings), structure, alteration (presence and characteristics of secondary minerals), veins and fractures (abundance, width, mineral fillings, orientation), and comments. Descriptions of igneous-rock thin sections were presented in separate structured forms and published following the VCDDs (Fig. 4b). They included rock name; texture; grain size; and primary mineralogy, with the current and original percentage of each phase present and their size and morphology, groundmass, secondary mineralogy, and vesicle description.

The convention of publishing VCDDs by core for sediments and by section for igneous rocks remained consistent throughout ODP and IODP because igneous rocks are recovered at slower rates than sediments, which allows for a more detailed description of their variations in texture and composition, typically higher than those in sediments. As desktop computers became more widely available in the mid-1980s, the scientific community began demanding databases with data capture client programs for more detailed and consistent data collection and accessibility. At the start of ODP, the state-of-the-art System 1032 (Computer Corporation of America) or the S1032 database run on VAX computers was introduced on the JR. Routine instrument data, such as from the multi-sensor core logger, were directly written to the database. Other data were later entered by staff members. Entering descriptive data into the database proved to be a much bigger and, at the time, insurmountable challenge. The only data entry user application directly populating the S1032 database during this early phase of ODP (1985–1989) was Corelog, used to collect basic coring and sample curation information. During this time, considerable effort also went into entering existing DSDP and ODP legacy data into the S1032 database. This included instrument data tables and core description text blocks extracted from the VCDDs published in the expedition Proceedings. The migration of DSDP and ODP data continued during and after this early phase for ∼ 15 years, in parallel to the data capture tool developments described here, and included scanned handwritten core descriptions, images, and an increasing number of data types. Therefore, the data available in several formats from the NOAA (National Oceanic and Atmospheric Administration) National Centers for Environmental Information (NCEI) for the entirety of DSDP (https://www.ncei.noaa.gov/access/metadata/landing-page/bin/iso?id=gov.noaa.ngdc.mgg.geology:G00993, last accessed 13 October 2026) and for the ODP at https://www.ngdc.noaa.gov/mgg/geology/data/joides_resolution/ (last access: 13 October 2026) include various stages of data migration.

With the S1032 database in place and migration of legacy data underway, ODP launched projects to write client applications for the S1032 database. Advisory panels and working groups formulated basic requirements for core description and other data types as documented in the minutes of the Shipboard Measurement Panel (SMP; e.g., first meeting, SMP, 1989). Many applications were never completed, and those that were implemented for core description on the JR did not meet user expectations.

In 1989 the petrology community saw the deployment of two client applications called HARVI (for macroscopic HARdrock VIsual descriptions) and HRTHIN (for microscopic HardRock THIN section descriptions), which were form-based user interfaces to the S1032 database. Data entry consisted of synopses of the observers' handwritten observations into the categories defined in previous years for both macroscopic and microscopic descriptions (Fig. 4). The program provided basic data validations during data entry, such as the validity of sample identifiers. The programs' output emulated the structured, multi-paragraph text blocks that users could download and place in the VCDDs, which were still generated manually using production graphic tools. The appearance of the final VCDDs did not change significantly. The HRTHIN program was used to enter modal percentages and textural descriptions of individual phases in more detail. The program outputs were regularly edited in a word processor before they were printed in the Proceedings. The HARVI and HRTHIN programs failed to achieve popularity with the scientists: the rigid data entry forms were too restrictive, and the database was not directly accessible by investigators. Furthermore, the hard-coded procedure whereby data were summarized by lithologic units defined in real time rather than the original interval-based observations became questioned by many investigators as it was only and arguably justifiable for basalt descriptions. Science parties began to use the increasingly popular Excel “log sheets” for certain observables warranting more detailed observational recordings. The ODP advisory panel (Information Handling Panel, IHP) pushed for progress with a more satisfactory program. From 1993 to 1994, ROCKY, a potential replacement for HARVI/HRTHIN, was developed based on the newly available application 4D, which allowed rapid development of entry forms and reports supported by a relational database. The development process was not successful, arguably because it was based on the old concepts of transcribing summaries of handwritten notes into a digital form, which was perceived as restrictive and tedious.

In 1990, the sedimentology community saw the deployment of the “ODP VCD” program. Developed over 2 years for the increasingly popular Macintosh computer and operating system, the program allowed users to draw lithologic patterns and structural symbols and to type text blocks. The previous 16-column format of the VCDD was reduced to 9 columns (Fig. 5). Notably, data relating to the paleontological, paleomagnetic, geochemical, and physical properties that were previously reduced onto the VCDDs (Fig. 3) were now stored separately in their entirety in the S1032 database or organized otherwise in a file system. Starting in 1991, microscopic observations from smear slides were collected in Excel and made available as PDF files (Fig. 6). Integrating descriptive data with instrument data became a post-processing step, and scientists produced integrated graphics using commercial plotting and drafting tools. The user dissatisfaction with the ODP VCD program was primarily that no database for further interrogation or plotting was available. Furthermore, the data product was a PICT (pixel raster) file, which was converted into a MacDraw file by publication staff for further editing of the VCDD. In 1991–1993 attempts were made to create a more capable Macintosh-based custom application; however, the “Etch-a-Sketch” program development was never completed.

The major issue during this phase of core description software developments was that the original observations still had to be summarized and transcribed into rigid forms. Emulating existing data presentation standards required that the information be summarized in text blocks next to the core image and graphic symbols. Any change or addition to observables requested by scientists led to a breakdown in workflow. Scientists started to use Excel for flexibility; however, spreadsheet tables created spontaneously by individual observers were not considered to be an acceptable data product by the IHP.

In the early 1990s, it became apparent that the S1032 database system and its applications could not meet the needs of expanding data acquisition for both the number of data types and overall data volume. Based on community advice, ODP hired a company to develop Janus, a system based on the Oracle relational database. Janus became operational on the JR in 1997 for the management of instrumentation data but without any program for the capture of descriptive information. Towards the end of ODP, developers attempted to create Janus database schemas for all the observables that core describers had been using so that the information could be collected and accessed in a consistent way across all future expeditions (Mithal and Becker, 2006). The draft schemas mushroomed into an unmanageable and ever-growing number of tables before data entry applications could even be addressed. Any update to the schema based on user feedback would require days or weeks of developer attention, which was not compatible with the pace and nature of the shipboard core description workflows.

In 1996, at about the same time as the Janus database becoming operational for the most common instrumented data, ODP introduced the contracted program AppleCORE for Macintosh. The program was designed for sediment descriptions, and the graphic data entry interface emulated the previously used “ODP VCD” template, with several useful user interface additions. The final VCDD produced with AppleCORE looked very similar to that of the previous ODP VCD program, except that it featured colored lithologic columns (Fig. 7). The most significant innovation was that the graphically entered descriptions were coded into a data structure through a custom configuration file. However, the configuration file was expedition-specific and sometimes was not saved with the data. Using the coded data beyond expedition-specific VCDD generation was difficult at the time and is even more complex today because the binary configuration files are only readable by specialized software, which does not function with today's operating systems. Migration efforts are currently underway to produce a usable tabular form of these data. AppleCORE also had similar challenges to those of its predecessor program. Users could not fully configure observables for what they needed and sometimes had to use observable labels that did not correspond to the observations, with the explanations archived in a set of README files. AppleCORE did not include the description of smear slides or thin sections, for which scientists used Excel to capture the data, and publications staff turned them into PDF and text files. Despite adaptations to AppleCORE to satisfy igneous- and metamorphic-rock requirements, those communities never adopted the program for detailed descriptions. Thin interbedded lithologies also could not be adequately entered and displayed. Thin intervals can play an outsized role in stratigraphy, and this limitation was regularly criticized. Sedimentologists began supplementing AppleCORE entries of specific observables with detailed interval logs in Excel so that the downhole trends could be statistically examined and visualized using commercial plotting tools. AppleCORE was last used in 2005 during the early phase of IODP, on the last sediment drilling during Expedition 311 and before a major renovation of the JR.

Also in 1996, when Janus became ready for most instrument data and sedimentologists began using AppleCORE, petrologists abandoned HARVI/HRTHIN and the failed, brief replacement ROCKY program. Science parties, with the help of ODP staff, created a modified nine-column VCDD for igneous- and metamorphic-rock descriptions using a commercial drafting program to emulate the previous VCDDs (Fig. 8). Notably, the description entities were now generally defined by changes in texture, composition, and structure rather than summarized by artificial core, section, and piece intervals or by interpreted lithologic units. However, the description intervals were still custom-formatted text blocks and not tabulated records that could be used for data analysis and visualization. Therefore, Excel was used more regularly and extensively for more detailed descriptions, where observable columns could be easily added to develop new conventions for observations in metamorphic petrology and structural geology. Unfortunately, unrestricted use of Excel had its problems. With multiple scientists creating their own Excel log sheets during an expedition according to their preferences, organizational skill level, and style, redundancies and gaps in data capture were common. The spreadsheets were not compatible amongst each other in terms of basic row and column structure definition, let alone observable definitions. Many sheets used number codes for descriptive features, which created additional obstacles as the investigator would need the reference sheet to understand the data. Some sheets were linked to each other, and these links were not always persistent. Access to these spreadsheets today is not straightforward as they were not stored in a database or systematically appended in the Proceedings as supplementary material and sometimes were not included at all.

During the end of ODP and the transition to IODP, Excel spreadsheets had become the preferred method of data capture for core description. Spreadsheets were adopted for all microscopic descriptions and the petrologists' macroscopic descriptions. The rigor and flexibility that spreadsheet data capture provided informed the direction the community wanted to take, which is perhaps best summarized in the recommendations by the Scientific Measurements Panel's Hard Rock Working Group in 2002 (Allan et al. 2003, pp. 20–21):

Recommendation no. 10. Continuous quantitative and semi-quantitative descriptions of specific core features, as currently collected downcore in spreadsheet format, are integral to core description and must be incorporated into the database for core log integration and analysis.

During the major JR renovation from 2005 to 2009, all shipboard labs were upgraded, including the introduction of the new Laboratory Information Management System (LIMS). The period of refit for the JR was used as an opportunity to create DESClogik, a core description program using spreadsheets for the data capture interface and a relational database as a backbone, to support the description of all types of materials (sediments, igneous and metamorphic rocks, microfossils assemblages) at all scales (microscopic, macroscopic, summary). The initial ambitious ideas included a graphing module to produce geological plots from selected observables in the spreadsheets, but resources did not exist to complete such a development. Instead, the commercial geological plotting program Strater was used to produce VCDDs directly from the spreadsheets whereby user-selected observations were plotted downhole by description interval (Fig. 9). Publication staff operated Strater as visiting shipboard scientists could not be expected to master the software capabilities and workflow intricacies in a few days. Strater support by Golden Software ended around the end of JR operations in 2024. Strater plots as PDF diagrams and the data used to create them in Excel are available online as part of the IODP Proceedings and database. This workflow decoupled data capture from data presentation, allowing scientists to contemplate and decide which observables to plot and how to visualize them. This is a more flexible and arguably a more correct workflow compared to limiting data capture to a fixed graphic data display template. Both the data capture spreadsheet and the Strater graphic templates were customizable to meet a project's needs. The decoupled data plotting also allowed the combination of descriptive and instrument data plots in the VCDDs to become the norm, including the routine addition of digital image scans (Fig. 9).

The first rollout of DESClogik allowed each observer to create their own data capture spreadsheet, and this resulted in chaos. Best practices require that template definition be a group effort resulting in consensus by taking into account the time and expertise available, the type of material recovered, and other specific project needs. Hastily prepared templates at the beginning of an expedition could easily turn out to be less than scientifically rigorous or generally useful for analysis. With a modified version on Expedition 336 (2011), IODP representatives were in the position to provide the guidance shipboard scientists needed to implement customizations of templates and terminology.

Although continuously improved and widely accepted as a useful tool, the underlying data structure, key features, accessibility, and technology of DESClogik had unsurmountable limits. The program was based on Microsoft programming interfaces and libraries that only worked on Windows machines. Furthermore, DESClogik did not meet some important micropaleontology requirements (see Paleontology/biostratigraphy section). DESClogik did not provide a database with a normalized set of observables across all expeditions because attempts at such standardization had previously failed. Instead, the use of DESClogik generated a repository of Excel spreadsheets from Expeditions 317 through 396 that have a relatively consistent structure and are accessible online and readily available for further analysis (https://web.iodp.tamu.edu/DESCReport/, last access: 13 October 2026). The spreadsheets were also typically published as supplementary materials in the Proceedings of the IODP (https://publications.iodp.org/, last access: 13 October 2026), which are ultimately available on Zenodo (https://zenodo.org/communities/iodp/records?q=&l=list&p=1&s=10&sort=newest, last access: 13 October 2026). This collection of core description spreadsheets allowed more directly for the integration of descriptive and instrument data across multiple expeditions in a post-acquisition analytical process (Childress et al., 2024).

The microscopic analysis of samples to identify microfossil taxa and provide geological age estimates, a fundamental task during JR expeditions, is in many ways quite different from the description of sedimentary and rock materials. Yet, the history of shipboard database and data capture tool developments for micropaleontology bears a significant resemblance to that of core description tools.

Near the beginning of ODP, an effort was made to synthesize DSDP biostratigraphic data, similarly to the work done for other available shipboard data. Cenozoic records were extracted from the DSDP Initial Reports (IRs), which consisted mostly of range charts prepared by the paleontologists onshore after the expedition. These records were stored in the S1032 database and then extracted into files by microfossil group and made available through the NCEI (https://www.ncei.noaa.gov/access/metadata/landing-page/bin/iso?id=gov.noaa.ngdc.mgg.geology:G00993, last access: 13 October 2026). The records include sample identity and depth, microfossil group abundance, preservation, and age codes. During ODP, biostratigraphers had the opportunity to rework shipboard observations, examine additional samples, and publish the results in the Scientific Results (SR) volumes of ODP Proceedings, published 3 years after the expedition. The researchers typically used to prepare their charts, without a shared database.

Just as the petrologists had tried to seize on the availability of the 4D relational database software for non-programmers in 1993–1995, paleontologists made an attempt to develop the 4D-based program, Fossillist, to create paleontological range charts, as well as age–depth profiles, during expeditions. Like ROCKY, Fossillist never reached shipboard user acceptance. The main reason may have been that data capture in both prototypes used form-based data capture, one record at a time, rather than spreadsheets at a time when the community came to love Excel.

When the Janus database came online in 1997, the software company also developed the PALEO application with features to generate range charts, as well as age–depth diagrams. After a year of shipboard deployment, user comments were mostly critical of the application's complexity with regard to data entry and its unworkable slowness. Most importantly though, paleontologists were still hesitant to publish the rapid qualitative studies produced during an expedition before careful analysis and verification were possible. The consensus was that the focus should be on the basic biostratigraphic mission deliverables: render age dates, enter those into a database, and construct an age–depth plot.

During the remainder of ODP, all biostratigraphic data were collected in Excel worksheets during the expeditions, which were typically published as PDF tables in the IR of the Proceedings, and updated charts were published in the SR if researchers chose to do so. When the SR was discontinued at the end of ODP in 2003, an expectation remained that shipboard paleontologists would generate range charts during JR expeditions and publish them in the single Proceedings volume published 1 year after the expedition without major changes to the shipboard observations. Although the preliminary range charts were often published, many paleontologists disagreed with the publication of tentative shipboard analysis, done under serious time constraints and with the main objective of providing geological time estimates during drilling.

When DESClogik became available for core description during the early IODP, the program was also offered to micropaleontologists because it emulated the spreadsheets they had been using and would also provide them with database support. Although often used in that manner, DESClogik was not popular with paleontologists, primarily because, unlike the core describers, they frequently needed to make changes to the templates throughout the expedition, such as adding, deleting, and rearranging taxa columns. Scientists could not make these edits themselves, which resulted in a sometimes significant time lag before a technician was available to make edits to the template. During the development of GEODESC, the final stage of software evolution for the JR and the main topic of this article, a significant effort was made to build features specifically for paleontologists, addressing lessons learned from DESClogik and previous software. However, the fundamental issue of only having time on board for preliminary tabulation of taxa occurrences had not changed.

The fundamental objectives of the GEODESC toolset were the same as those for DESClogik: support collaborative description of all geological materials at multiple scales in a fast-paced multi-user environment, with user-configurable spreadsheet templates for specific scales and objectives. The choice of a spreadsheet interface for geological descriptions was based on decades of core description on board the JR by hundreds of scientists, as well as a user survey conducted at the start of the development. Geologists are accustomed to recording observations in a spreadsheet where rows represent samples or sample intervals, the first set of columns represents the scope of an observation including sample identification, and subsequent columns represent the parameters or observables characterizing the scope of observation. New requirements and objectives for GEODESC also arose from lessons learned during decades of core description on the JR. The most important one was the need for the toolset to provide more effective guidance and consistency for basic descriptions, particularly in support of observers who are not necessarily specialists, paired with flexibility to ensure that the toolset never restricts a project's observation capture, particularly in projects where expert observers are extending the range of observations traditionally made. Guidance is provided in GEODESC by a set of catalogs, including completely configured starter templates, as well as lists of observable definitions, geological and general terms, and taxa, to choose from. Flexibility is provided with the Template Manager application that allows users to modify templates to meet the project's needs, with or without the use of catalog items (Fig. 10). Additional improvements over DESClogik include a user-friendly Data Capture application that handles the safe collaborative and simultaneous descriptions of cores from multiple holes and provides a feature-rich spreadsheet interface with many types of data validations. The Data Access application provides access to the descriptions by project team members who are not describers themselves but are integrating the observations with their respective tasks and data. Furthermore, GEODESC provides unprecedented support for micropaleontology. Perhaps the most impactful innovation of this most recent core description toolset used on the JR was to make the applications independent of computer platforms and operating systems. Through the implementation of web applications, GEODESC achieved the long-standing goal of enabling safe collaboration among core description project team members regardless of the describers' location or the time before, during, or after a field campaign or other event. The resulting toolset consists of four browser-based user applications that work seamlessly together, with each application serving a specific purpose and type of user (Fig. 10), as described in more detail below.

The GEODESC replacement for DESClogik was proposed in 2016 based on the experience gained with DESClogik. Development officially began in 2019. It took until 2022 for the set of applications to be completed and deployed on the JR. The design and implementation took 4 years, with three team members involved for the project's entire duration and more than 20 JRSO employees from most service departments contributing to the project as designers, developers, and testers. The Angular web framework is used as a front-end throughout the applications. SpreadJS is integrated in the Angular applications for spreadsheet features. Several back-end APIs written in Java ensure connectivity. GEODESC was used on the JR for Expeditions 398 through 403. The limited deployment time compared to the significant development effort was an unfortunate consequence of the earlier-than-expected termination of IODP.

A GEODESC project is a set of geological descriptions acquired by a project team using the GEODESC toolset. All GEODESC projects use the same toolset, but each project has its own database instance to ensure non-interference among projects. Each project has access to a specific set of sample records (i.e., cores, sections, thin sections, processed fossil samples). A project on the JR typically centered on a 2-month expedition at sea and lasted around 5 years, from operational planning to the publication of the Proceedings. Some projects required multiple sea campaigns. Some projects revisited sites investigated years earlier and acquired data on the old, as well as the new, core sample material. The cores recovered on the JR and their derivative samples belonged to an expedition, and the data acquired as part of one or more expeditions belonged to the project. While this ownership framework was implicit in JR sample and data handling, it was an explicit concept in the development of GEODESC. Some GEODESC projects consist of workshops and educational modules.

Project team members are given user accounts that allow them to work on a project. The user accounts are given one or more of three defined user roles (Fig. 10). The most restrictive project role is the “template maker”, who configures the project templates according to team consensus. For core description, only one project team member or a few project team members are needed in this role, which is typically completed in the early phase of the project, with few subsequent modifications. The “observer role” is for description specialists recording their observations in the spreadsheets. All other project team members who have neither the template maker nor the observer role have real-time read access to the published data through the Data Access application but cannot directly edit data. This data access can be restricted to project team members during a moratorium period and ultimately becomes public based on IODP policy.

The final products of a GEODESC project are tab-separated value (TSV) files that can be analyzed and visualized. On the JR, graphic products were created based on these files using other existing applications. GEODESC therefore does not have its own visualization capabilities (see Development opportunities section). Two types of project files are generated: descriptive data files containing the observations and metadata files describing the templates used in recording the observations. In addition to the project files, catalog resources used in template creation are also accessible as TSV files.

The Template Manager (TM) application is used by project team members to select pre-configured catalog templates for core description and micropaleontology (Fig. 16) and to add them to the project's template collection where they can be modified to suit the project's needs (Fig. 17). For core description, templates are typically finalized early in a project, and later changes are rare, which led to the decision to make TM a separate application rather than combining it with the Data Capture application (next section), the tool used during the main data capture phase of the project. Typically, one core description scientist or a small subset of the core description scientists takes on the task of implementing team consensus-based changes to templates using the TM application.

Access to the GEODESC catalogs is a central feature of the TM application to facilitate the configuration of project templates. Pre-configured catalog observables can be added to any project template, and new observables that do not exist in the catalog can be created if needed using the same process illustrated for the observable catalog (Fig. 14). Default choice lists for list type observables can be edited by deleting values, selecting other values from the Entry Values catalog, creating new values if needed, reordering values in the choice list, and adding ranks to values (Fig. 18). Biostratigraphers can add taxa columns from multiple sources, including the existing GEODESC catalog and their personal lists. They can also add columns for multiple biozonal schemes, as well as datums with ages from multiple published timescales (Fig. 19). Of the 36 total TM user interfaces, 17 are dedicated to the configuration of micropaleontological templates.

When catalog templates are added to a project, 17 fixed columns containing the scope of description parameters are added in front of the observable columns. These fixed columns are shared by all project templates and implement the longstanding SOD convention for sample and sample interval identification. A sample or sample interval is defined by the parameters Expedition, Site, Hole, Core, Type, Section, A/W (archive or working half of split section), and Top offset and Bottom offset from the section top in centimeters. This sample ID is followed by three standard depth columns (CSF-A; IODP 2011) computed for the Top, Middle, and Bottom depths of the description interval in meters beneath the seafloor and another three columns for an alternate depth scale type (CSF-B by default; IODP 2011), also in meters. A new standard scope column added in GEODESC is the Domain. Domains are parts within a sample or sample interval not defined by a layer, such as two lithologies in a thin section or clast populations in a matrix. The final scope parameter is Piece numbers, a comma-delimited string of curated hard-rock pieces resulting from the drilling process, enumerated for each section and added automatically to the description interval if they exist.

The Data Capture application (DC) is used to capture observational data in custom spreadsheets using the project templates configured in TM. DC is the GEODESC application used by all core describers and paleontologists during a project. It has only two major interfaces, the “capture sheet dashboard” and the worksheet where observations are entered.

The initial design called for using Excel for the worksheets because most users are familiar with that application. However, customizing Excel and controlling the myriads of unnecessary and conflicting features was too complicated and costly. Furthermore, making an Excel application universally accessible on the web presented additional issues and costs. The decision was made to use the fully customizable SpreadJS platform instead, which also allowed for a smooth integration with the Angular framework used for all GEODESC applications. All GEODESC user applications except Data Access use SpreadJS for various implementations of spreadsheet functionality. The capture sheet dashboard (Fig. 20) was developed for safe and practical multi-user collaboration. Only one user can add or edit data for a given combination of template and cores at any one time. Observers create worksets by selecting a template; a hole; and, optionally, a subset of cores from that hole. Worksets can be deleted and re-created at any time since they are not the final data products – they just define the combination of a specific set of cores and a specific template an observer is “checking out” to work on temporarily. The existing worksets are listed on the dashboard, along with useful status information such as who created it, who is currently using it, and whether the latest changes have been published (Fig. 20). In GEODESC, “published” means that the autosaved data are written to the database entity from which any project team member can access the information using the Data Access applications (see next section). In addition to being a data security feature, the workset concept also allows collaborators to break down and divide up the task of describing and reviewing multiple and/or long stratigraphic sections.

When observers open a workset, they are presented with the spreadsheet interface with all existing data (autosaved and/or published) for the workset (Fig. 21). This is where observers spend most of their time. The DC spreadsheet has numerous quality control and convenience features, and a few are described here. For observables of the type “list”, observers can select from approved values using dropdown lists (Fig. 21 and 22c). The “Add Samples” button on the ribbon opens a modal window where users can filter all existing samples for sample type and/or test group and then select the ones they want to add to the spreadsheet for description (Fig. 21 and 22a). The row context menu can be activated anywhere on the row and presents a list of methods to add, insert, or delete rows (description intervals; Fig. 22b). Errors such as intervals that do not physically exist within a sample or numbers or list items not allowed based on the column configuration are indicated with a red box around the cell, and a pop-up explanation can be displayed by hovering the cursor. New data entries and data edits are autosaved immediately as the data entry cell is exited. Autosaved data are only accessible to the observer until published using the “Publish” button on the ribbon. Publishing triggers the update of the “currently final” data product file available via the Data Access application (next section). Closing a spreadsheet prompts the observer to publish the changes (or keep them unpublished) and to keep the workset so it can be opened again by any observer or to delete it as a way of keeping the workset list tidy.

The Data Access (DA) application provides all project team members (and the public for data no longer protected by moratorium) with an interface to access all published GEODESC data. Data are downloaded as TSV text files, with one file per template and hole (Fig. 23; https://web.iodp.tamu.edu/DataAccess/, last access: 13 October 2026). Users can filter the files by expedition, site, and hole and/or by template scale, type, and objective. Users can also download project template metadata files. Furthermore, DA provides public access to all GEODESC catalog contents (https://web.iodp.tamu.edu/DataAccess/#/catalogs, last access: 13 October 2026). The TSV files for IODP expeditions were also typically published as supplementary materials in Proceedings (https://publications.iodp.org/, last access: 13 October 2026), which will ultimately be available on Zenodo (https://zenodo.org/communities/iodp/records?q=&l=list&p=1&s=10&sort=newest, last access: 13 October 2026).

The GEODESC user applications are directly supported by two groups of Oracle database tables (Fig. 10): project tables and catalog tables. The project tables contain project template definitions managed with the TM user application, defined worksets, and descriptive data autosaved by the DC application. A new copy of the project tables is created for each project. The catalog tables store all of the GEODESC catalog contents.

In addition, GEODESC draws information from pre-existing LIMS tables: the Samples table and a group of associated depth scale tables (Fig. 10). The Samples table contains all cores collected on the JR and millions of subsamples in a recursive hierarchy. Observers load sample records into DC for description using the Add Samples interface in the DC spreadsheet (Fig. 22a). The depth tables are linked to the Samples table and contain procedures that routinely compute two depth types for each sample and sample interval, the Core depth below Sea Floor, method A and method B (CSF-A, CSF-B; IODP 2011). Two final product tables in LIMS hold description data and template metadata, respectively. The final description data are only updated from the project tables when a user publishes data in the DC application.

GEODESC applications interface with the Oracle database via a set of Java-based web services. Based on the way in which user authentication and data moratorium are implemented within the broader LIMS infrastructure, these web services and the associated pool manager ensure that GEODESC data are available only to authorized users. Specific privileges for individual users are managed via the Auther custom application, as was the case with other applications used on the JR.

At the end of a project, GEODESC project schemas can, in principle, be deleted as the published descriptive data and metadata stored in the final products table and accessible with DA are independent permanent data archives. Because GEODESC was built as a set of web applications with a database and is currently hosted at Texas A&M University (TAMU), it is not configured to be portable, installed, and managed at other locations. The advantage of web applications is that all future developments, including bug fixes and new features, as well as catalog edits and additions, are implemented in one place and become immediately accessible to all existing and future users and projects. This model supports collaborations over the internet and allows smaller organizations and projects such as university teaching labs to access and use the same tools that larger organizations such as scientific drilling programs employ. This model requires a hosting organization like TAMU with appropriate resources to provide the service. The required support is modest but critical and consists of science and IT components. Science support consists of a GEODESC administrator who interacts with new project users and directs and implements changes to the catalog content, as well as feature developments based on user monitoring and surveys. IT support consists of three types of tasks: support the project life cycle by initiating new projects with a copy of the GEODESC project data tables (and ultimately removing them), create project member accounts with appropriate application credentials and project roles, and development support to fix issues and potentially add features.