Smart Farming Ontology: A Care Practice Guide for AI Data Management

Introduction to Ontology-Driven Data Management in Agriculture

In the realm of modern agriculture, the integration of AI and data management has become pivotal. One of the most compelling approaches is ontology-driven data management, which provides a structured framework for understanding and acting upon agricultural data. This article delves into a practical example from smart farming—specifically, the detection and management of rice planthoppers—to illustrate how ontologies, rules, and workflows work together to facilitate informed decision-making and timely interventions. By the end, you'll grasp how this methodology enhances care practices in farming, ensuring crop health and optimized resource use.

The Core Challenge: From Data to Action

Consider a scenario where a pest outbreak is detected in a specific field. The system not only identifies the issue but also recommends and executes a control measure. This process involves multiple components: object types, instances, thresholds, rules, and actions. The central question is: how do these elements interact to transform raw sensor data into meaningful actions? The answer lies in the clear separation of definitions and executions. The ontology defines the business world; rules interpret business conditions; and workflows execute business actions. Importantly, the ontology itself does not receive sensor data or trigger drones—it merely provides the semantic backbone.

Distinguishing Object Types from Instances

A common pitfall is confusing object types with their instances. Object types are abstract categories, such as 'Field', 'Crop', 'Pest', and 'UAV Task'. Instances are specific examples, like 'Field A', 'Rice', 'Planthopper', and 'UAV Task D-001'. This distinction is crucial for accurate data modeling and communication. For instance, 'Field A' is not the same as the concept of a field; it's a particular entity with its own attributes and relationships.

Modeling Core Business Objects

In the ontology, we identify core business objects that represent independent entities in the agricultural domain. These include Field, Crop, Pest, Growth Stage, Monitoring Record, Control Threshold, Risk Assessment, Control Plan, Treatment Work Order, UAV, and UAV Task. Each object has its own lifecycle, status, and responsibilities. For example, a UAV Task is not merely a database record; it has a unique ID, status, and execution process, and it relates to work orders, equipment, fields, and outcomes. Thus, it qualifies as a separate business object.

Relationships Between Object Types

Relationships define how object types can be connected. These are not actual data but semantic rules. For instance, a Field is related to a Crop through a 'planting' relationship. A Monitoring Record is linked to a Field via 'occurs at', and to a Pest via 'monitors'. Control Thresholds apply to specific Crops, Pests, and Growth Stages. Risk Assessments are based on Monitoring Records and reference Control Thresholds. Treatment Work Orders target Fields and Pests, adopt Control Plans, and rely on Risk Assessments. UAV Tasks originate from Treatment Work Orders, operate on Fields, use UAVs, and follow Control Plans. During runtime, these relationships become concrete, such as 'Field A plants Rice' or 'Record M-102 occurs at Field A'.

Object Types vs. Database Tables

It's essential not to equate object types with database tables. Database tables are technical implementations, whereas ontology objects carry business semantics. For instance, a UAV might generate a location point every second, leading to a separate 'position_points' table for performance reasons. However, these points are technical details, not independent business objects. Conversely, a UAV Task, even if its data is sourced from multiple tables or APIs, remains an ontology object because business users independently query, approve, cancel, and track it. To decide if something should be an object, ask: Does it need a unique ID? Does it have its own state changes, responsible parties, or approvals? Is it independently referenced by other objects? Do business users need to query, explain, or manage it separately? If most answers are yes, it's likely an object; otherwise, treat it as an attribute, attachment, or technical detail.

How the System Knows a Field Exceeds Thresholds

The ontology is not a sensor or recognition model; it doesn't directly produce values like '48 insects per hundred tillers'. Facts come from sensors, manual inspections, traps, drone imagery, or AI vision models. For example, a monitoring record might state: Field A, pest: planthopper, metric: population density, value: 48, unit: insects per hundred tillers, sampling time: 2026-08-03 09:20, source: manual survey/image recognition model, confidence: 0.92. Additionally, the system queries other facts: current growth stage (heading stage), 24-hour rainfall probability (10%), average wind speed in the next operational window (4 m/s), and UAV U-01 status (available). These facts are stored according to the ontology's types and relationships, enabling unified querying and combination.

Understanding Thresholds

Thresholds are neither monitoring facts nor actions; they are normative knowledge or policy parameters. They are determined by technical guidelines, plant protection experts, local policies, or enterprise strategies, and should have sources, versions, and effective periods. In the ontology, model them as Control Threshold objects. For instance, Threshold T-01: pest: planthopper, crop: rice, growth stage: heading, metric: population density, comparator: >=, value: 40, unit: insects per hundred tillers, source: local plant protection technical guidelines, version: 2026.1, effective period: 2026-01-01 to 2026-12-31. This prevents hardcoding the value in code, allowing updates when policies change while preserving historical traceability.

Rules: Defining How to Judge, Not How to Execute

Rules are combinations of conditions and conclusions. They reference objects, relationships, properties, and thresholds defined in the ontology but are typically executed by a rule engine, DMN decision table, or business code. There are three key types:

Detection Rule

Rule R-01: If the monitoring record's pest is planthopper, the field's crop is rice, the current growth stage is heading, and the monitored value is >= the valid applicable threshold, then create a risk assessment with level 'high' and record the basis. For example, 48 >= 40 triggers a 'high risk' assessment for Field A.

Decision Rule

Rule R-02: If risk level is 'high', growth stage is heading, and no pesticide restriction constraints are triggered, then recommend biological control plan S-01 and suggest creating a treatment work order.

Execution Admission Rule

Rule R-03: If the work order is approved, the UAV is available, wind speed is within limits, rainfall conditions are suitable, and the operation area permits flight, then allow dispatching the UAV task. Separating these rules is vital: detecting risk doesn't automatically mean spraying; recommending a plan doesn't grant immediate execution permission.

Actions: Defining Capabilities, Not Instances

Action types are business capability definitions in the ontology. They describe the action name, inputs, preconditions, outputs, responsible parties, and external impacts. For example:

Action Type A-01: Create Treatment Work Order

Inputs: field, pest, risk assessment, recommended plan, operational window. Precondition: a valid high-risk assessment exists. Output: a pending approval work order. Responsible: agronomist or automated workflow. External impact: none, only creates business records and notifications.

Action Type A-02: Dispatch UAV Task

Inputs: approved work order, UAV, flight path, operational window. Precondition: UAV operation admission rules are met. Output: a UAV task. Responsible: scheduling system. External impact: calls UAV dispatch platform API. Action types are definitions; actual executions are instances. For instance, Work Order W-001 is an instance of A-01, and UAV Task D-001 is an instance of A-02. In initial versions, operational data like trajectory, area, actual usage, completion time, and effect records can be attributes or attachments of the UAV task, not separate objects.

The Role of Engines and Workflows

Ontologies are declarative knowledge, describing what things are and what constraints they must satisfy. Executing real-world actions is imperative behavior, requiring identity permissions, approvals, message retries, failure compensation, device protocols, audit, and security controls. Thus, it's inaccurate to say 'rules and actions are in the engine'. The correct statement is: the ontology stores the business definitions and semantic associations of rules and actions; engines interpret these definitions and apply them to real-time facts or external systems.

A Complete Worked Example

Let's walk through the entire process:

1. A trap, manual survey, or image recognition generates monitoring record M-102: Field A has a planthopper density of 48 per hundred tillers.
2. The system queries knowledge: Field A is planted with rice and is in the heading stage; Threshold T-01 requires control when density >= 40.
3. Rule R-01 concludes: create risk assessment D-001 with level 'high', referencing M-102 and T-01.
4. Rule R-02 concludes: recommend biological control plan S-01 and suggest executing A-01.
5. The workflow instantiates A-01: creates work order W-001 for agronomist approval.
6. After approval, the scheduling system checks R-03: wind speed is acceptable, no rain, U-01 is available, and the area is allowed for flight.
7. The workflow instantiates A-02: creates and dispatches UAV task D-001.
8. The UAV completes the operation and sends back actual trajectory, usage, coverage area, completion status, and anomalies, which are written or linked to D-001.
9. These post-operation data are linked with subsequent monitoring data for evaluating control effectiveness, reviewing rules, and updating plans.

Conclusion: The Power of Ontology in Care Practices

In summary, the ontology clarifies agricultural objects, relationships, rule definitions, and action definitions. Real-time data tells the system what is actually happening. Rule engines derive risks and recommendations based on facts and knowledge. Workflows and scheduling transform authorized recommendations into work orders and UAV tasks. Execution results are written back as new facts, forming a traceable closed loop. This approach not only enhances efficiency but also ensures that care practices are data-driven, adaptive, and accountable. By adopting ontology-driven data management, smart farming can achieve more precise and sustainable crop care.