Modern farms generate data from many independent sources: soil and weather sensors; farm management software; machinery; drone and satellite imagery; and veterinary or laboratory systems. Each of these systems tends to describe the same real-world thing, a parcel, a crop, an animal or an observation, in its own way, using its own field names, units and formats. When a cooperative, an advisory service or a public authority wants to combine information from several of these sources, for example to plan irrigation, forecast a pest outbreak or report on Common Agricultural Policy (CAP) eco-scheme compliance, that mismatch has to be resolved somewhere, usually through one-off, manual integration work. This is one of the main reasons agricultural data, despite being collected in growing volumes, is not used to its full potential: the effort needed to make it usable elsewhere often exceeds the effort needed to collect it in the first place.
Data spaces, not a single platform
AgriDataValue addresses this challenge by building what its most recent architecture update calls a “platform of platforms”: rather than moving all agricultural data into one central system, independent platforms, sensor networks and pilot environments stay where they are and connect through common interoperability mechanisms, an approach closer to a data space than to a conventional integration project. A data space, in the sense defined by International Data Spaces (IDS) approach, is not a single piece of software but an ecosystem in which participants exchange data under agreed rules while keeping control over their own resources. For that to work in practice, participants need to align on four layers: technical (including syntactic), so systems can exchange data at all; semantic, so the data carries the same meaning for everyone; organizational, so roles and processes are agreed; and legal, so usage terms are clear. Agriculture, with its mix of small and large actors, public and private data holders and cross-border pilots, is a demanding test of exactly that alignment, and much of it starts with something deceptively basic: a common way to describe what a dataset contains, who may use it and under what conditions.
The ADV Data Model: a DCAT Application Profile for agriculture
This is the gap the AgriDataValue (ADV) Data Model is built to close. The Data Catalog Vocabulary (DCAT) is a World Wide Web Consortium (W3C) standard for describing datasets so that they can be found and understood across different catalogs. Because DCAT is deliberately generic, communities that need more specific structure typically define a DCAT Application Profile (DCAT-AP) on top of it, in the same way the European Commission maintains a DCAT-AP for public sector data portals or a geospatial extension, GeoDCAT-AP, for spatial data. The ADV Data Model, sometimes called AgriDCAT-AP within the project, follows the same pattern for agriculture: a DCAT Application Profile for describing and sharing agricultural datasets through data spaces, currently at version 3.0.0.
Rather than inventing a new agricultural vocabulary, the model combines two layers. A governance wrapper, built on DCAT together with the Open Digital Rights Language (ODRL), covers what any data space needs regardless of domain: a description of the dataset for catalog discovery and a machine-readable usage policy attached to it. The domain content layer then describes the agricultural data itself using vocabularies the sector already maintains: the W3C’s SOSA vocabulary (Sensor, Observation, Sample and Actuator) for sensor and earth-observation measurements; the European Telecommunications Standards Institute’s (ETSI) Smart Applications REFerence ontology, extended for agriculture as SAREF4AGRI, for parcels, crops and livestock; concepts carried over from the FOODIE project (Farm-Oriented Open Data In Europe) for field interventions and alerts; and the Food and Agriculture Organization’s AGROVOC thesaurus for controlled terms. Seven ready-made profiles cover observations, weather data, soil analysis, parcel and crop information, interventions, animals and alerts, each with a Shapes Constraint Language (SHACL) definition that can validate a dataset before it is shared and a matching JavaScript Object Notation for Linked Data (JSON-LD) template. A set of ready-to-use ODRL policy templates, for example open access, attribution required, research-only or time-limited, means a data provider can attach a usage condition without drafting one from scratch. The resulting dataset descriptions and policies remain exchangeable through the Dataspace Protocol (DSP), the interoperable protocol for data space interactions, or through any other DCAT-compatible catalog.
What this contributes to interoperability
The model’s contribution can be set against the four layers of interoperability that data space standards use to describe what makes exchange work: technical (including syntactic), semantic, organizational and legal. Reusing SOSA, SAREF4AGRI, FOODIE and AGROVOC keeps the semantic layer aligned with the same vocabularies behind the Agriculture Information Model (AIM) from the DEMETER project, which AgriDataValue’s own reference architecture treats as the domain-semantics counterpart to the IDS Information Model. Expressing profiles as JSON-LD with SHACL validation gives the technical layer an automatic conformance check instead of a manual one. Documented bridges to AgGateway’s ADAPT Standard (Agricultural Data Application Programming Toolkit) for farm-equipment data and to the FIWARE platform’s context-data model mean the organizational layer does not require every pilot or platform to abandon tools already in use. The bundled ODRL policies give the legal layer a concrete, machine-readable way to express data sovereignty, the principle that a provider keeps control over how its data is used, rather than leaving it to a separate contract. The model itself is published under a Creative Commons Attribution 4.0 license (CC BY 4.0) and maintained openly on GitHub, so its profiles, validation rules and policy templates can be reused, adapted or extended outside AgriDataValue.
None of this makes agricultural data sharing effortless. A profile can only standardize how data is described and governed; it cannot replace the trust-building, pilot testing and stakeholder engagement that AgriDataValue’s wider work carries out across its pilot sites, 23 of them at present, spanning different sectors and countries. What a profile like this provides is more modest and, for that reason, more durable: a common, tested, openly licensed structure that other agricultural data-sharing efforts do not have to design from zero. IDSA, as a partner in the AgriDataValue consortium, sees the ADV Data Model as a concrete example of how a sector-specific DCAT Application Profile can be built consistent with data space principles, one that other domains facing similar fragmentation may find worth a closer look.
References
1. AgriDataValue Consortium. ADV Data Model (ADV-Data-Model repository), version 3.0.0. https://github.com/agridatavalue/ADV-Data-Model
2. AgriDataValue. “From Semantic Interoperability to Operational Intelligence.” 15 July 2026. https://agridatavalue.eu/index.php/2026/07/15/from-semantic-interoperability-to-operational-intelligence/
3. AgriDataValue. “Enhancing Agricultural Data Models and Semantic Interoperability.” 17 March 2025. https://agridatavalue.eu/index.php/2025/03/17/enhancing-agricultural-data-models-and-semantic-interoperability/
4. World Wide Web Consortium (W3C). Data Catalog Vocabulary (DCAT), Version 3.
5. European Commission, Interoperable Europe. DCAT Application Profile for Data Portals in Europe (DCAT-AP).
6. International Data Spaces Association. International Data Spaces Reference Architecture Model (IDS-RAM).