## 3 IoT Standards and Protocols for Precision Agriculture
### The Entities in OGC SensorThings Database  
The rest of this section provides a more detailed analysis of the APIs of the OGC SensorThings standard. Figure 2 represents the relational model with which the standard is structured. The image summarizes the entities required for the creation of an OGC SensorThings database. For clarity, only the properties that must be explicitly defined for the creation of each entity are highlighted. The following specifications provide a brief description of the entities that make up the interoperable schema.  
Figure 2: Diagram of the relational model structure of the OGC SensorThings standard [52]. ‘0..” indicates a cardinality of “zero to many”, meaning that an element may be associated with none, one, or multiple elements of the other entity. Similarly, ‘1..” indicates a cardinality of “one to many”, meaning that an element must be associated with at least one or more elements of the other entity.  
**Thing:** The OGC SensorThings API follows the ITU-T definition, which states that, in the context of the Internet of Things, a Thing is an object from the physical world (physical things) or the information world (virtual things) that can be identified and integrated into communication networks [51].  
**Location:** This entity identifies the last known position of a Thing. In the context of IoT, the primary position of interest is typically associated with the location of the Thing, especially for in situ detection applications. For example, the location of interest for a WiFi connected sensor should be the barn or greenhouse where the smart sensor is located. However, the ultimate location of a Thing is not always the location of the Thing itself [51]. In these use cases, the content of a Thing's location differs from the content of the characteristic of interest of the Thing's observations.  
**Historical Location:** The Historical Location entity provides the timestamp of the current position (i.e., the last known) and previous positions of the associated Thing entity.  
**Sensor:** A device that observes a property or phenomenon with the goal of producing an estimate of the property's value.  
**Observed Property:** An Observed Property specifies the phenomenon of an observation.  
**Observation:** The act of measuring or otherwise determining the value of a property. Mandatory properties are as follows: (i) Timestamp of the observed phenomenon: TM_Object (ISO 8601 or Time Interval String) (corresponds to the time period during which the observed phenomenon evolves); (ii) Timestamp of the measurement: TM_Instant (exact moment when the measurement is made); (iii) Results: Any [52].  
**Feature of Interest:** An observation translates into a value assigned to a phenomenon. The phenomenon is a property of an element, and this element is the Feature of Interest of the observation. In the context of IoT, the Feature of Interest of many observations can be the location of the Thing. For example, the Feature of Interest of a WiFi connected may be the location of the sensor (i.e., the living room where the sensor is located). In the case of remote sensing, the Feature of Interest is the geographical area detected [80].  
Using the HTTP GET method, data can be requested from the server, and responses are returned in JSON format. For instance, the URI [[http://example.org/v1.0/](http://example.org/v1.0/)]([http://example.org/v1.0/](http://example.org/v1.0/)) addresses entities in the database (accessed on 1 January 2025). The response includes a JSON object with a value property containing a JSON array, where each element specifies the name of an entity set (e.g., THING, DATASTREAM, OBSERVATION) and its corresponding URI. CRUD operations (Create, Update, Delete) are carried out using HTTP methods such as POST, PATCH, PUT, and DELETE. These methods often include additional information in the body of the request to complete the operation [48].