Data Model

The AgriFoodData data model is the data model of the draft ITU-T Recommendation Data model for digital agriculture and farm management systems (draft, revision 3 of 2026-07-29, proposed to ITU-T Study Group 20). It describes a farm — its parties, land, crops, work, products, machines, animals, observations, economics, compliance and processing runs — as 47 entities in 14 packages.

The model is published in machine-readable form at datamodel.agrifooddata.org (source repository). This page explains how to read it; the API reference explains how to use it over HTTP.

{
  "id": "069a9d2c-0d5c-5eda-b447-1eb9d3791f7e",
  "name": "Fungizidbehandlung Septoria, Nordschlag",
  "farmId": "997142c3-14cf-5cb4-b260-048af4b57a76",
  "status": "COMPLETED",
  "typeUri": "http://aims.fao.org/aos/agrovoc/c_5978",
  "createdAt": "2026-05-10T07:00:00Z",
  "updatedAt": "2026-05-12T06:20:00Z",
  "originType": "USER",
  "createdByUserId": "b630da76-9ec3-5faa-a1d7-e66d56bc5db4"
}

This is a Task — plain JSON, readable by any client. Through the JSON-LD context the same record reads as agfoda:Task in RDF, on the properties of the ontology.

One source, four views

Every artefact is generated from one source, so they cannot drift apart.

View	Standard	Answers
JSON Schema (schema/<Entity>.json)	JSON Schema 2020-12	Is this JSON a well-formed record?
OpenAPI (openapi.yaml, openapi.json)	OpenAPI 3.1	How is a record read, written and synchronised over HTTP?
JSON-LD context (context.jsonld)	JSON-LD 1.1	What does it mean, in the terms of the ontology?
SHACL shapes (shapes.ttl, shapes-dataset.ttl)	SHACL	Does its RDF — and a dataset of such records — hold together?

Also published: model.json (the whole model in one document, for code generators), a consistent example dataset (examples/<Entity>.json, one fictitious farm through all 47 entities) and a reference page per entity. Everything lives under https://datamodel.agrifooddata.org/v1/.

Authority and versioning

• The Recommendation is the authority. If the machine-readable model or the ontology differs from its text, the text takes precedence. Every known difference is listed, with the reading taken, on the divergences page.
• An address keeps its meaning. Artefacts are published under the major version (v1/). Within it changes are additive — a new optional attribute, a new enumeration value. A breaking change gets v2/ next to it, and v1/ stays where it is.
• Until the Recommendation is approved the version carries its revision as a pre-release label (currently 1.0.0-draft.3), and v1/ may still follow the text.
• The model and everything generated from it are licensed CC BY 4.0.

Conventions every record follows

These conventions (clause 5.1 of the Recommendation) apply to every entity and are not repeated in the attribute tables.

Convention	What it means
Identifier	Every record has an id: a UUID in lower case, generated by the client that creates it, so that records created offline never collide.
System fields	createdAt and updatedAt are set by the server, in UTC (ISO 8601-1). updatedAt is the synchronisation cursor and the basis of conflict resolution.
Provenance	originType (USER, SERVICE, DEVICE, IMPORT, SYSTEM), createdByUserId, createdByJobId and clientId say how a record came into being. createdByUserId, createdByJobId and clientId are set by the server from the authenticated caller; originType is declared when the record is created and checked against the caller. None of them changes afterwards. A USER record names its user; a SERVICE record names the processing run (rule V04).
Geometry	Every geometry is a GeoJSON geometry (RFC 7946) in WGS 84 and can be served through OGC API – Features.
Semantic type identifiers	typeUri and every other attribute ending in Uri hold dereferenceable URIs of canonical vocabularies — AGROVOC first. See the ontology.
Self-description	Field, Region, Site, Machine, Device, Data, ProcessingService and Result may carry a description holding a W3C WoT Thing Description in JSON-LD.
External synchronisation	Organization, Farm, Field, Machine, Animal, Product and Device may carry externalId and externalProvider to reference records of external systems.
Exclusive references	Where an entity can point at one of several parents, exactly one is set (rule V03).
Retention	Operational records are withdrawn by a terminal status or an endsAt timestamp — not deleted. Every change is recorded in the append-only AuditLog. Personal data in User and Worker is erased or pseudonymised where the law requires it, while identifiers and operational references stay.
Units and codes	Units should be UCUM codes (the schema describes UCUM but does not reject other units); currencies are ISO 4217, countries ISO 3166-1, languages BCP 47 — these are checked.
Naming	Entities in PascalCase, attributes in camelCase, foreign keys named <entity>Id. Enumeration values are in UPPER_CASE (clause 9).

Three decisions of the JSON binding matter in practice:

• An optional attribute that is not set is omitted, never null. (null appears only in a merge patch, where it means "remove".)
• The schemas are closed: an attribute the model does not have is rejected, so a misspelt attribute is found. A client reading responses should still ignore what it does not know.
• An application's own fields belong in the application's own namespace, not in the model.

Where to go next

• Packages & entities — the 47 entities and how they relate.
• Rules & state models — what the model guarantees.
• Representations — JSON, JSON Schema, JSON-LD, SHACL.
• Ontology — the vocabulary the …Uri attributes draw from.
• Digital farm REST API — the HTTP binding.

See it in action

• Getting started — create and read your first records
• Reference pages — every entity with its attributes, constraints and example