Soil Organic Carbon Knowledge Graph
- Soil Organic Carbon Knowledge Graph is a semantic framework that integrates diverse SOC and agricultural experiment data into a queryable knowledge graph.
- It employs a dual-database architecture and interactive dashboard to facilitate advanced SOC stock analysis and comparison across treatments.
- Interoperability is achieved through rigorous ontology design and alignment with NALT, ensuring detailed exploration of long-term experimental datasets.
Searching arXiv for the specified paper and related context. Soil Organic Carbon Knowledge Graph (SOCKG) is a semantic knowledge infrastructure for integrating heterogeneous soil organic carbon (SOC) and agricultural experiment data into a queryable, interoperable knowledge graph. It is designed to make soil carbon data easier to find, connect, compare, and analyze so that researchers can better understand SOC dynamics, identify drivers of carbon change, and support climate-mitigation-oriented agriculture. The system is presented as a resource for soil carbon modeling, carbon sequestration research, agricultural sustainability, advanced querying across experiments, treatments, and soil measurements, and improved interoperability through ontology design and alignment with the National Agricultural Library Thesaurus (NALT) (Shirvani-Mahdavi et al., 14 Aug 2025).
1. Scientific motivation and problem setting
SOC is described as central to soil health, nutrient cycling, water retention, microbial activity, agricultural productivity, carbon sequestration, and climate mitigation (Shirvani-Mahdavi et al., 14 Aug 2025). The underlying problem is that SOC research depends on data that are heterogeneous, distributed across many fields and years, and embedded in complex experimental designs and management practices. In this setting, the principal challenge is not merely data storage, but coherent representation of experimental context, treatment structure, sampling depth, and measurement semantics.
SOCKG addresses this problem by integrating data from many sources into one graph, standardizing terminology with an ontology, linking terms to controlled agricultural vocabulary, supporting semantic queries and graph traversal, and providing a dashboard and a data-cube-style API for non-expert users. The paper characterizes the result as a structured semantic resource that supports both exploration and analysis rather than a passive repository (Shirvani-Mahdavi et al., 14 Aug 2025).
This suggests that the core contribution of SOCKG is epistemic as much as computational: it attempts to preserve the semantics of long-term agricultural experimentation while making those semantics operational for comparative SOC analysis.
2. Source data, empirical scope, and represented entities
The knowledge graph is populated from the Agricultural Collaborative Research Outcomes System (AgCROS) spreadsheet dataset. The reported scope of the source data is up to 45 years, 4,220 experimental units, 58 fields, 33 cities, and 20 states. The dataset includes 37,214 soil physical samples, 77,167 soil chemical samples, and 19,572 soil biological samples (Shirvani-Mahdavi et al., 14 Aug 2025).
The principal represented entities are the experimental unit or subplot, treatment, soil samples, soil measurements, and contextual metadata. The experimental hierarchy is explicitly given as field, block, plot, and subplot or experimental unit. These are the units at which treatments are applied and observations are recorded. Treatments comprise agricultural management conditions such as crop rotation, nitrogen level, fertilizer type, and other management practices. Examples include continuous corn and corn/soybean (2-yr), as well as nitrogen categories of 0, low, and high. The exact nitrogen amount depends on crop type: for corn or sorghum, low equals 33 kg N/ha and high equals 67 kg N/ha; for soybean or oat+clover, low equals 90 kg N/ha and high equals 180 kg N/ha (Shirvani-Mahdavi et al., 14 Aug 2025).
Soil samples are represented as soil physical sample, soil chemical sample, and soil biological sample. The source spreadsheet does not indicate whether measurements came from the same real-world sample, so the graph models these as separate sample classes. Measurement examples include bulk density, pH, organic matter, electrical conductivity, and microbial and biological indicators of soil health. The spreadsheet also contains contextual notes on measurement scale, range, acronyms, units, and interpretations of ambiguous headers, and these notes informed ontology design and data standardization (Shirvani-Mahdavi et al., 14 Aug 2025).
A concise view of the source scope is given below.
| Aspect | Reported scope |
|---|---|
| Temporal coverage | Up to 45 years |
| Experimental structure | 4,220 experimental units; 58 fields |
| Geographic scope | 33 cities; 20 states |
| Soil samples | 37,214 physical; 77,167 chemical; 19,572 biological |
The significance of this representation lies in its attempt to retain the granularity of agricultural experimentation rather than collapsing it into undifferentiated measurements. A plausible implication is that comparative analyses across sites and treatments depend critically on this preserved experimental hierarchy.
3. Ontological model and semantic design decisions
SOCKG is built using an OWL ontology with classes, object properties, data properties, and an RDFS annotation property. Ontology development proceeded by analyzing spreadsheet columns and contextual notes, identifying core concepts as classes, defining attributes as data properties, modeling relationships as object properties, consulting domain experts, and using Protégé for ontology engineering. The ontology contains 46 classes, 64 object properties, and 590 data properties. The instantiated data graph contains 46 classes, 53 object properties, and 489 data properties (Shirvani-Mahdavi et al., 14 Aug 2025).
A central modeling decision concerns sample representation. The ontology explicitly avoids a generic pattern such as SoilSample, SoilPhysicalMeasure, SoilChemicalMeasure, and SoilBiologicalMeasure, because the source data do not reliably show whether measurements at the same depth and time came from the same real-world sample. Instead, SOCKG uses SoilPhysicalSample, SoilChemicalSample, and SoilBiologicalSample and links them directly to the experimental unit. This is presented as a fidelity-preserving choice that avoids introducing unsupported assumptions (Shirvani-Mahdavi et al., 14 Aug 2025).
The ontology also adopts clear naming conventions. Classes use UpperCamelCase, exemplified by ExperimentalUnit. Object and data properties use lowerCamelCase, exemplified by hasAmendment. Properties with units encode the unit with underscores, exemplified by aboveGroundBiomass_kg_per_ha. Ambiguous acronyms are expanded when possible, including FAME to fattyAcidMethylEsters, PLFA to phospholipidFattyAcids, and POM to particulateOrganicMatter_gC_per_kg (Shirvani-Mahdavi et al., 14 Aug 2025).
The paper reproduces formal Turtle definitions for a class, a datatype property, and an object property:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
@prefix sockg: <https://idir.uta.edu/sockg-ontology/docs/> . sockg:SoilPhysicalSample rdf:type owl:Class ; rdfs:comment "Represents a sample of soil collected from a specific depth range encompassing various physical properties essential for agricultural analysis and land management." ; rdfs:seeAlso <https://lod.nal.usda.gov/nalt/5142> . sockg:bulkDensitySd_g_per_cm_cubed rdf:type owl:DatatypeProperty ; rdfs:domain sockg:SoilPhysicalSample ; rdfs:range xsd:float ; rdfs:seeAlso <https://lod.nal.usda.gov/nalt/20349> . sockg:hasChemSample rdf:type owl:ObjectProperty ; rdfs:domain sockg:ExperimentalUnit ; rdfs:range sockg:SoilChemicalSample . |
These definitions illustrate the semantic granularity of the model: OWL classes define experimental and sampling entities, datatype properties attach measured values, and object properties encode experimental relationships. This suggests that SOCKG prioritizes source-faithful semantic structure over aggressive abstraction.
4. NALT alignment and interoperability strategy
A major design principle of SOCKG is semantic alignment with the National Agricultural Library Thesaurus. This alignment is performed primarily through manual curation to ensure accuracy, and the ontology uses the RDFS annotation property rdfs:seeAlso to link ontology terms to related NALT concepts. An example is the SOCKG class Treatment, linked to the NALT term “experimental treatments” at https://lod.nal.usda.gov/nalt/6148134. Approximately 61% of SOCKG classes and properties have been aligned with NALT (Shirvani-Mahdavi et al., 14 Aug 2025).
The stated rationale is improved interoperability with other agricultural datasets, standardized terminology, semantic consistency, discoverability, and future integration with broader agricultural knowledge systems. This is particularly relevant because agricultural data are often collected by different groups using different terms for the same or similar concepts. The authors also note future plans to use stronger OWL relations such as owl:equivalentClass and owl:equivalentProperty for more precise semantic alignment (Shirvani-Mahdavi et al., 14 Aug 2025).
The alignment strategy is noteworthy because it treats controlled vocabulary linkage not as a post hoc annotation layer but as part of the core semantic architecture. A plausible implication is that SOCKG can function as a bridge between local experimental data structures and broader agricultural semantic ecosystems.
5. Storage architecture, RDF pipeline, and resolvable URIs
SOCKG is implemented in a dual-graph-database setup consisting of GraphDB and Neo4j. The ontology and data are first processed into RDF using RDFlib. The reported workflow is to parse the ontology into an RDF graph, create data entities based on ontology classes, assign data properties, add object properties, serialize to RDF formats such as Turtle, N-Triples, JSON-LD, and XML, and then export to GraphDB or Neo4j (Shirvani-Mahdavi et al., 14 Aug 2025).
GraphDB serves as the semantic RDF store. Its relevance is attributed to support for RDF, support for SPARQL, and suitability for semantic querying and reasoning. Neo4j serves as the property graph backend. Its relevance is attributed to optimization for highly connected graph traversal, support for Cypher, and efficient exploration of relationships (Shirvani-Mahdavi et al., 14 Aug 2025).
The ontology terms are exposed through resolvable URIs of the form https://idir.uta.edu/sockg-ontology/docs/{conceptName}. These pages expose metadata including descriptions, related NALT terms, object properties of classes, and domain and range of properties. The URIs are hosted on a managed public server, and only classes and properties are currently resolvable, though instance-level URIs are planned (Shirvani-Mahdavi et al., 14 Aug 2025).
| Component | Reported role |
|---|---|
| RDFlib | RDF processing and serialization |
| GraphDB | Semantic RDF store with SPARQL support |
| Neo4j | Property graph backend for traversal and visualization |
| Resolvable URIs | Browser-accessible ontology classes and properties |
This architecture separates semantic representation from traversal-oriented interaction. The design indicates that RDF semantics and property-graph usability are treated as complementary rather than competing paradigms.
6. Dashboard, ontology exploration, and analytical interface
To lower the barrier posed by SPARQL and semantic web complexity, SOCKG includes a Streamlit-based interactive dashboard. The dashboard is intended for scientists, developers, researchers, and potentially other stakeholders unfamiliar with SPARQL (Shirvani-Mahdavi et al., 14 Aug 2025).
The experimental unit exploration page provides a U.S. heat map of experimental units, filtering by state, county, site, and field, map location for a selected experimental unit, pie chart of soil sample counts, table views of samples, and plotting of selected columns with customizable chart types. The treatment exploration page supports filtering by treatment attributes such as crop type, fertilizer type, and residue removal, and uses a faceted interface in which selecting one filter dynamically updates the available options in others. Users can then inspect all experimental units associated with a selected treatment and navigate to their pages. The ontology exploration page provides a visual view of the ontology in which clicking a node reveals class instance counts, double-clicking a class reveals data properties, and clicking a property reveals sample values and data types. The paper notes that this explorer also helped validate the ontology during development by revealing missing relationships and checking consistency (Shirvani-Mahdavi et al., 14 Aug 2025).
In addition to the dashboard, the system provides a simplified data cube API implemented with FastAPI. This interface is described as supporting analytical queries that are too cumbersome or slow to express directly in RDF or SPARQL (Shirvani-Mahdavi et al., 14 Aug 2025).
The combination of dashboard and API is significant because it operationalizes different access modes to the same semantic resource: interactive visual exploration for inspection and discovery, and structured analytical access for recurrent computations.
7. Query patterns, SOC stock computation, and reported contributions
SOCKG is designed for analytical querying of SOC dynamics rather than only storage. The paper identifies two direct difficulties with RDF-native analytics. First, graph traversal cost is high because experimental units are highly connected and many years of repeated measurements increase traversal complexity; analytical queries can take around 15 seconds in the reported experiments. Second, SPARQL complexity is high: even a simple query such as average SOC stock for 0–30 cm can require around 45 lines of SPARQL, and SOC stock often requires derived calculations rather than direct lookup (Shirvani-Mahdavi et al., 14 Aug 2025).
A representative analytical question is: determine the average SOC stock (kgC/ha) for every treatment ID between 0–30 cm. The paper gives the formula as
and an interpolation expression
for layers between 0–30 cm (Shirvani-Mahdavi et al., 14 Aug 2025).
Three edge cases are explicitly handled. If a sample does not extend to the requested lower depth, it is excluded. If the 30 cm boundary falls inside a layer, linear interpolation is used for the partial layer. SOC stock is standardized by computing it per layer, summing across layers within a sample, and averaging across the chosen grouping such as treatment ID, field, or other categories (Shirvani-Mahdavi et al., 14 Aug 2025).
The system is described as supporting comparisons of SOC change across fields and treatments, ranking treatments by SOC gain, comparing management practices such as tillage, residue removal, fertilizer class, and irrigation, and analyzing associations between SOC and soil properties, climate or weather, management history, and soil type. To make such analytics faster and easier, the authors adopt a multidimensional data cube model with dimensions such as weather, soil management, soil type, time, and location. Because precomputing all combinations would be storage-expensive, the reported compromise is to select relevant dimension values, generate combinations, execute SPARQL from templates, and store results for fast lookup in a NoSQL-style cache or database. The current version exposes a REST API with flattened GET parameters (Shirvani-Mahdavi et al., 14 Aug 2025).
The paper identifies eight main contributions: a new ontology-driven knowledge graph for soil carbon research; semantic modeling of complex agricultural experiments; alignment with NALT; dual storage implementation in GraphDB and Neo4j; resolvable ontology URIs; a user-friendly Streamlit dashboard; a data-cube-based analytical interface; and demonstrated support for SOC stock comparisons, especially across fields and treatments, with depth handling and interpolation (Shirvani-Mahdavi et al., 14 Aug 2025).
In aggregate, these elements position SOCKG as an infrastructure for more reliable SOC accounting, better comparison of management practices, scalable analysis across many fields and years, integration with semantic web and agricultural vocabularies, improved support for climate-smart agriculture and carbon markets, and stronger foundations for future machine learning and predictive modeling. Because these latter functions are presented as motivations and implications rather than benchmarked outcomes, they are best understood as the intended research and application horizon of the system rather than as fully validated downstream results.