An Open Record for
Pollination Data.
A small, vendor-neutral JSON schema for describing what was observed, where and when it happened, what biological layer it represents, how it was measured, and what permissions travel with the record.
Portable before proprietary.
Pollination data can come from cameras, hive sensors, radar, weather services, remote sensing, researchers, growers, or manual observations. A useful exchange format should preserve provenance and permissions while allowing those records to move between tools.
This is an early PollinationTech proposal, not an official industry standard. It is designed to be testable, forkable, and compatible with future mapping to efforts such as BeeXML and broader agricultural APIs.
The biological ladder is explicit.
Weather, bloom timing, habitat or other context around pollination.
A pollinator or colony activity signal is detected.
A visitor interacts with a flower or inflorescence.
Compatible pollen reaches the stigma or a direct pollen-transfer proxy is measured.
Fruit set, seed set, fertilization or another reproductive response.
Yield, quality, size, shape, shelf life or economic outcome.
Every observation carries context.
schema_version
observed_at
measurement_level
biological_context
value + unit
method + quality
provenance
permissions
{
"schema_version": "0.1.0",
"record_id": "pti-demo-2026-09-10-001",
"observed_at": "2026-09-10T14:30:00-04:00",
"observation_type": "flower_visitation",
"measurement_level": 2,
"source": {
"system_name": "Example Field Camera",
"organization": "PollinationTech demonstration",
"source_type": "computer_vision",
"device_id": "cam-07",
"software_version": "0.9.2"
},
"location": {
"latitude": 44.09,
"longitude": -75.81,
"accuracy_m": 25,
"field_id": "demo-field-01",
"privacy_precision": "1km"
},
"biological_context": {
"crop_common_name": "Sunflower",
"plant_scientific_name": "Helianthus annuus",
"pollinator_common_name": "bee",
"bloom_stage": "peak_bloom",
"flower_unit": "flower head"
},
"measurements": [
{
"variable": "flower_visits",
"value": 18,
"unit": "visits",
"aggregation": "count",
"interval_seconds": 900,
"confidence": 0.91,
"quality_flag": "estimated"
},
{
"variable": "visitor_rate",
"value": 1.2,
"unit": "visits/min",
"aggregation": "rate",
"interval_seconds": 900,
"confidence": 0.88,
"quality_flag": "estimated"
}
],
"environment": {
"temperature_c": 23.6,
"relative_humidity_pct": 58,
"wind_speed_m_s": 2.8
},
"provenance": {
"created_at": "2026-09-10T14:31:00-04:00",
"publisher": "PollinationTech demonstration",
"processing_notes": "Example only; not a real field observation.",
"license": "CC BY 4.0",
"attribution": "PollinationTech demonstration data"
},
"permissions": {
"access": "public",
"redistribution": "with_attribution",
"commercial_use": "allowed",
"location_redaction_required": true
},
"links": [
{
"rel": "schema",
"href": "https://pollinationtech.com/open/pollination-observation.schema.json"
}
]
}
…What the schema is trying to protect.
A value should say what it measures, its unit, method, aggregation, and quality.
Derived records should remain traceable to their publisher, source record, processing, and attribution.
A record should remain understandable outside the dashboard or device that created it.
Access, redistribution, commercial use, and location-redaction requirements travel with the data.
Exact apiary or habitat coordinates can be deliberately generalized or withheld.
Presence, visitation, pollen transfer, reproductive outcome, and agricultural outcome are not treated as interchangeable.
Five very different records. One envelope.
Version 0.2.0 was revised against examples spanning sensors, computer vision, environmental data, pollen transfer, and crop outcome. The goal is not to make every record identical; it is to make their identity, method, provenance, location precision, and biological meaning consistently exchangeable.
Complement existing standards. Don’t compete with them.
BeeXML is explicitly aimed at linking isolated bee-data systems through standardized exchange. PollinationTech Open should map compatible hive/apiary fields into that ecosystem rather than invent a parallel beekeeping vocabulary.
OADA intentionally focuses on secure interoperable APIs rather than forcing one universal agricultural file format. PollinationTech Open can be a payload format moved through an OADA-style API.
The 2026 ontology work formalizes bees, smart devices, monitoring, and observation concepts using established vocabularies such as SSN/SOSA and AGROVOC. Version 0.2.0 adds controlled-term hooks for future mapping.
USA-NPN observational and geospatial APIs are a natural source for environment, phenology, location, provenance, and controlled-term fields.
Still experimental. Much more useful.
Version 0.2.0 adds observation windows, explicit subjects, record relationships, calibration metadata, controlled vocabulary hooks, geometry references, richer provenance, and time-limited permission fields.
The next meaningful step is a reference ingestion endpoint: a tiny API that accepts a record, validates it, and returns precise errors. That would turn PollinationTech Open from a downloadable schema into working infrastructure.