The scale of the underlying effort is extraordinary. Over roughly 37 years of JOIDES Resolution operations serving the Ocean Drilling Program, the Integrated Ocean Drilling Program, and the International Ocean Discovery Program, the ship drilled more than 640 kilometers of sediment and rock and recovered more than 370 kilometers of core. Every meter of that recovered material was visually described by teams of scientists working around the clock under severe time pressure. Those descriptions formed a complete record of the stratigraphic sections drilled, allowing subsequent investigators to select samples and integrate observations with shipboard measurements.

In the earliest phase, from 1985 to 1989, describers began with handwritten notes on paper templates printed for each 1.5-meter core section, with centimeter scales and columns for observations and comments. These notes were photographed onto microfiche until about 1992 and later scanned to PDF. They were then summarized onto graphic visual core description diagrams, or VCDDs, which were published in expedition proceedings as the final descriptive product. Sediment diagrams carried 16 columns covering everything from lithology and drilling disturbance to biostratigraphic zones and paleomagnetic data, while igneous rock diagrams used eight columns for more detailed descriptions of pieces, textures, alteration, veins, and vesicles.

As desktop computers spread in the mid-1980s, the community demanded digital databases. The System 1032 database running on VAX computers was introduced on the ship, and instrument data from devices such as the multi-sensor core logger flowed directly into it. Descriptive data proved far harder. Form-based entry programs such as HARVI and HRTHIN, deployed in 1989 for hard rock descriptions, offered data validation but imposed rigid structures that scientists found too restrictive. A successor called ROCKY, built in 1993 and 1994, was never accepted. Sedimentologists received the Macintosh-based ODP VCD drawing program in 1990, which reduced the 16-column diagram to 9 columns, but it produced pixel-raster files with no underlying database, and a follow-up application nicknamed Etch-a-Sketch was never completed.

A pivotal shift came as scientists turned, in growing numbers, to Excel spreadsheets to record detailed interval-by-interval observations that rigid forms could not accommodate. The Janus Oracle database, operational in 1997, managed instrument data but never gained a workable description entry program; draft schemas for descriptive observables mushroomed into an unmanageable number of tables. The contracted AppleCORE program, introduced in 1996 for sediment descriptions, coded graphical entries into data structures, but its configuration files were expedition-specific, binary, and now largely unreadable on modern systems. Petrologists never adopted it, and thin interbedded lithologies could not be adequately displayed. A 2002 advisory working group formally recommended that spreadsheet-based descriptions be incorporated into a relational database with common templates, effectively setting the blueprint for what came next.

That blueprint became DESClogik, created during the ship’s 2005 to 2009 renovation alongside a new Laboratory Information Management System. DESClogik used spreadsheet interfaces over a relational database to support sediments, igneous and metamorphic rocks, and microfossil assemblages at microscopic, macroscopic, and summary scales. Crucially, it decoupled data capture from data presentation: scientists recorded observations in customizable spreadsheets, and publication staff later used the commercial Strater plotting program to generate VCDDs combining descriptive and instrument data with digital core images. DESClogik generated a repository of relatively consistent spreadsheets from Expeditions 317 through 396 that remain available online. But it ran only on Windows, relied on Microsoft libraries, and frustrated micropaleontologists, who needed to alter templates constantly and could not do so without technician help.

GEODESC, proposed in 2016 and officially developed from 2019 to 2022, addressed these limits by moving everything to the web. Built on the Angular framework with the SpreadJS spreadsheet engine and Java back-end services, the toolset consists of four browser-based applications requiring no software installation, enabling secure collaboration among globally distributed team members before, during, and after a field campaign. Design and implementation took four years, involving three dedicated team members and more than 20 employees of the JOIDES Resolution Science Operator as designers, developers, and testers. The system was deployed for Expeditions 398 through 403, a shorter window than planned because the International Ocean Discovery Program ended earlier than expected.

The system’s architecture reflects decades of accumulated lessons. A Catalog Manager holds starter templates drawn from past expeditions, hundreds of rigorously defined observables, thousands of geological entry values, and dedicated taxa, synonym, zone, and datum catalogs for micropaleontology. A six-element observable definition syntax, covering entry type, quantification, texture, source or state, composition, and focus, forces each observable to be an unambiguous English sentence whose definition and column header cannot be changed once created. The Template Manager lets project teams copy and customize catalog templates, while the Data Capture application offers validated spreadsheet entry with dropdown lists, autosaving, and a workset dashboard that lets only one user edit a given combination of template and cores at a time. Published data flow to a Data Access application that delivers tab-separated value files to project members and, after a moratorium period, the public.

GEODESC currently has no built-in visualization; shipboard teams relied on the browser-based LIVE plotting tool for real-time quality control and on Strater, whose support ended around the close of JR operations in 2024, for publication graphics. The authors outline development opportunities, including a generic sample registry for users outside the LIMS infrastructure, real-time plotting modules, and an illustrated catalog linking the thousands of geological terms to the hundreds of thousands of core images that scientific ocean drilling has produced, a resource they suggest could also feed machine learning approaches that remain limited today by scarce training data.

Now maintained by the Gulf Coast Repository at Texas A&M University, GEODESC remains available for use on cores or any other geological materials from any location with internet access, and the Scientific Ocean Drilling Coordination Office plans to use it on upcoming expedition projects. Because it is hosted centrally as a web service rather than packaged for local installation, even small university teaching labs can use the same tools as major drilling programs, with support needs limited to an administrator and modest IT tasks. The authors note that the toolset and its four-decade development history may also serve as a reference for any organization now building software for collaborative geological description, ensuring that the hard-won lessons of the JOIDES Resolution era outlive the ship itself.

Subject of Research: Collaborative geological core description software developed for the JOIDES Resolution

Article Title: GEODESC web applications for collaborative description of geological materials – a legacy of the JOIDES Resolution era

Article References: Blum, P., & Childress, L. B. (2026). GEODESC web applications for collaborative description of geological materials – a legacy of the JOIDES Resolution era. Scientific Drilling, 35(2), 229-254. https://doi.org/10.5194/sd-35-229-2026

Image Credits: AI Generated

DOI: 10.5194/sd-35-229-2026

Keywords: GEODESC, JOIDES Resolution, scientific ocean drilling, IODP, core description, visual core description diagrams, spreadsheet data capture, micropaleontology, relational database, DESClogik, web applications, Gulf Coast Repository

The system is called GRETA, short for Genetic REsults daTAbase, and it was developed by Cristian Riccio, Amra Dhabalia Ashok, Georgios Koliopanos and Andreas Ziegler at Cardio-CARE in Davos, together with colleagues at the University Medical Center Hamburg-Eppendorf, the University of Lübeck and the University of KwaZulu-Natal. At its core, GRETA is a relational database, meaning that information is organised into structured tables connected by defined keys, so that any single association result can be linked back to the exact dataset, analysis pipeline and parameter settings that produced it. That traceability is not a luxury. In genetic epidemiology, where a single spurious association can send a research group down a months-long dead end, knowing precisely how a result was generated is as important as the result itself.

What makes GRETA unusual is not merely that it stores data, but how it was designed. Rather than asking software engineers to guess what geneticists need, the team ran a formal requirements-engineering process grounded in user-centred design, a methodology borrowed from human-computer interaction in which the intended users shape the product at every stage. Through this process they defined product specifications across eight categories, covering everything from data upload and a graphical user interface to identity and access management and data protection. Only after these requirements were fixed did the team evaluate commercial database solutions and select a vendor to implement them, a deliberate choice to build on proven infrastructure rather than reinventing database technology from scratch.

The technical architecture reflects the realities of modern genomics. GRETA is built as a relational database management system, using Structured Query Language under the hood, but most users will never write a query. Instead, they interact with the system through a graphical user interface that allows interactive querying and visualisation of association results. Behind the scenes, the relational schema connects in-house association results, whether from genome-wide association studies or rare variant association studies, with public reference resources such as the Genotype-Tissue Expression project and functional annotation tools like Functional Mapping and Annotation. Every result carries links to its underlying data and analysis parameters, so a researcher can trace a finding from a summary statistic all the way back to the cohort and pipeline that produced it.

This matters because the people who most need access to genetic association results are often not the people who can get it. Traditionally, interrogating large result sets required command-line skills, familiarity with database systems and comfort manipulating enormous text files on high-performance computing clusters. Clinicians, early-career scientists and collaborators in adjacent fields were frequently locked out of the full richness of their own projects’ data. GRETA was explicitly designed to close that gap: the platform makes large-scale association results accessible to researchers without programming skills, while retaining the depth and flexibility that computational specialists expect. The result, the authors argue, is a secure, multi-user solution for exploring genetic association results and their functional annotation at scale.

The development team did not work in the abstract. GRETA was built to serve real studies, including the Hamburg City Health Study, one of Germany’s large population-based cohorts, whose participants and study staff made the underlying dataset possible. The genetic association analysis pipeline feeding the database was developed with contributions from researchers at Cardio-CARE, and the database itself was built by Mark Mallabone of Ovations Technologies Ltd, with the graphical interface implemented by Peter Wanjohi and Wisaal Behardien of iOCO GmbH. The collaboration between academic geneticists, statisticians and commercial software developers is itself a notable feature of the project, reflecting a growing recognition that scientific data infrastructure is too important and too complex to be left to ad hoc scripting.

Data protection received particular attention, and for good reason. Genomic data is among the most sensitive categories of personal information that exist, and studies like the Hamburg City Health Study operate under strict ethical oversight. The ethics committee of the Hamburg Medical Association raised no objections to the conduct of the study, and approvals were obtained from the data protection officer of the University Medical Center Hamburg-Eppendorf and the data protection commissioner of the Free and Hanseatic City of Hamburg. GRETA’s identity and access management features are designed to ensure that only authorised users can reach the results they are entitled to see, a crucial requirement for any platform intended to serve multiple research groups handling human genomic data.

Perhaps the most consequential decision the team made was to publish everything. Alongside the paper, the researchers have released the product requirements, the relational schema and the complete list of functionalities, so that other institutions can reproduce the system elsewhere. In a field where data infrastructure is often proprietary, fragmented or poorly documented, this commitment to openness could prove as influential as the software itself. The article is published open access under a Creative Commons licence, and extensive supplementary materials accompany it, giving any laboratory or consortium a detailed blueprint for building its own results database tailored to its own studies.

The implications reach well beyond cardiology, the field in which GRETA was born. As whole-genome sequencing becomes cheaper and cohort studies grow larger, the bottleneck in genetic research is shifting from data generation to data management and interpretation. Rare variant association studies, in particular, produce enormous volumes of results across vast numbers of genes, and integrating them with tissue-specific expression data and functional annotations is exactly the kind of task that overwhelms spreadsheets and home-grown scripts. A well-designed relational database that unifies results and reference data in one queryable place could accelerate everything from gene discovery to the interpretation of a patient’s genome in a clinical setting.

There are, of course, caveats. GRETA is a tool for storing and exploring association results, not a substitute for rigorous statistical analysis or biological validation, and its value depends on the quality of the results fed into it. The published paper describes an early-release version subject to further editorial revision, and the true test of any database is adoption by research groups beyond its birthplace. But the problem it addresses is real, widespread and growing, and the authors’ decision to share the full design openly means that the barrier to trying it elsewhere is unusually low. If GRETA and systems like it become standard fixtures in genomics laboratories, the era in which billions of hard-won genetic associations languished in unread files may finally be drawing to a close.

Subject of Research: A relational database for storing, integrating and querying whole-genome sequencing association results with public reference data

Article Title: GRETA: a results database for whole-genome sequencing studies

Article References: Riccio, C., Ashok, A. D., Guo, L., Koliopanos, G., Zeller, T., Twerenbold, R., & Ziegler, A. (2026). GRETA: a results database for whole-genome sequencing studies. BMC Bioinformatics. https://doi.org/10.1186/s12859-026-06688-6

Image Credits: AI Generated

DOI: 10.1186/s12859-026-06688-6

Keywords: GRETA, whole-genome sequencing, relational database, genome-wide association study, rare variant association study, user-centred design, bioinformatics, genetic association results, functional annotation, data protection, cardiogenomics, Hamburg City Health Study