Semantic and Syntactic Interoperability for Agricultural Open-Data Platforms in the Context of IoT Using Crop-Speciﬁc Trait Ontologies

Featured Application: This study describes an open-data platform named Open Data in Agriculture, whichisdesigned toenhanceprecisionagriculture(PA). Theplatformconsistsofseveralcomponents and tools based on semantic web technologies and the hazelnut ontology, a crop-specific trait ontology. The main focus of this study is to propose a data-integration approach at the semantic and syntactic interoperability levels and to develop a web-based open-data platform based on the proposed approach. Abstract: In recent years, Internet-of-Things (IoT)-based applications have been used in various domains such as health, industry and agriculture. Considerable amounts of data in diverse formats are collected from wireless sensor networks (WSNs) integrated into IoT devices. Semantic interoperability of data gathered from IoT devices is generally being carried out using existing sensor ontologies. However, crop-speciﬁc trait ontologies—which include site-speciﬁc parameters concerning hazelnut as a particular agricultural product—can be used to make links between domain-speciﬁc variables and sensor measurement values as well. This research seeks to address how to use crop-speciﬁc trait ontologies for linking site-speciﬁc parameters to sensor measurement values. A data-integration approach for semantic and syntactic interoperability is proposed to achieve this objective. An open-data platform is developed and its usability is evaluated to justify the viability of the proposed approach. Furthermore, this research shows how to use web services and APIs to carry out the syntactic interoperability of sensor data in agriculture domain.


Introduction
Precision agriculture (PA) is an agriculture management approach used to observe, measure and respond to intra-field variability in agricultural production [1]. Applying the concepts, methods and tools of information and communication technologies (ICTs) enhances the effectiveness of the PA activities. Implementing PA also provides data regarding meteorological factors, such as weather humidity, temperature, rainfall, wind and sunshine [2]. In addition, gathering and analyzing environmental and site-specific parameters such as topography, slope, soil moisture, soil pH, water availability and soil fertility improve PA. Furthermore, PA facilitates boosting effectiveness and productivity of an agricultural production system, which consists of varied ICTs and organizes the whole production cycle of plants and animals using a scientific approach [3]. Internet-of-Things (IoT) technologies, particularly radio-frequency identification (RFID) and wireless sensor network (WSN),

Related Works
The term IoT, which is first used in 1999, is characterized in three visions such as Internet-oriented, things-oriented and semantic-oriented [13,14]. It also consists of three components which enable ubiquitous computing such as hardware, middleware and presentation [15]. Due to having such features, IoT-based applications are used in a wide range of sectors such as discrete manufacturing, transportation, logistics, utilities, healthcare, energy and natural resources, retail, insurance and agriculture. This leads to a dramatic rise in the number of connected IoT devices and the amount of data generated [16]. However, there still exist varied issues to handle with respect to IoT, such as standards, scalability, device diversity, constructing generally accepted service language, finding service for a particular domain and providing interoperability [17]. This study mainly focuses on semantic and syntactic interoperability in the context of IoT.
Understanding the true meaning of data by utilizing the semantic web technologies is a key factor, which simplifies providing interoperability among IoT components. Semantic web technologies are also used for creating data models and integrating data gathered from heterogeneous IoT devices. This approach constitutes an enabling-technology in different IoT-related fields, like Industry 4.0 and smart manufacturing [18], smart and IoT-enhanced environments [19] and healthcare [20]. Annotating IoT data using the strength of semantic web technologies ensures the interoperability between IoT applications [21]. Utilizing IoT data, which are obtained from heterogeneous data sources, requires more complex operations and technical skills due to interoperability issues. Considering the heterogeneity of IoT data, semantic web technologies can be used for sharing data gathered from heterogeneous IoT devices by generating "common models" [22] of domains of knowledge-i.e., an ontology, shared and explicit conceptualization of the knowledge and of the relationships of the concepts composing a domain [23,24]. The diversity of IoT devices from several vendors can uncover semantic and syntactic errors [20]. However, IoT data are generally bound up with heterogeneous data models; and to overcome this heterogeneity, it is necessary to make data available homogeneously to allow integration from a wide variety of sources [8]. Due to the aforementioned reasons, one needs to take a closer look at interoperability in IoT.
One can examine various interoperability levels [25][26][27][28][29], but since syntactic and semantic levels are particularly essential for data integration, we focus on these two levels. Syntactic interoperability is concerned with software infrastructure needed, whereas semantic level addresses the meaning of data while sharing or exchanging data between systems [30].
It is worth bearing in mind that implementing semantic interoperability requires more effort such as developing an ontology and utilizing it to meet the interoperability requirements [31]. Table 1 summarizes representative studies on ontologies in the context of IoT and sensors. These ontologies generally aim to model resources, services and location information; however, new ontologies are developed to meet interoperability requirements as well [32]. The overall purpose of these ontologies is to provide robust solutions to heterogeneity issues regarding hardware, software and the data management for IoT devices [33]. Table 1. Existing Ontologies in the context of IoT and Sensors.

Ontology Definition
Sensor node ontology It identifies sensor node's essential elements [34].
Formal pedigree ontology for level-one sensor fusion An ontology for one-level sensor fusion regarding naval operations. The general concepts of this ontology are suitable to apply to any domain which includes sensor fusion [35].

OntoSensor
It is a prototype sensor knowledge repository and involves the definitions of concepts and properties adopted in part from SensorML [36].
Sensor-data ontology Developed for managing information of sensors in an efficient way and easing data retrieving processes for users or search engines [37].
The Semantic Sensor Network Ontology It identifies the facilities and activities of the sensors [38].
Sensor Web Enablement (SWE) common data model It describes models which are used to transmit data obtained from sensors in the low-level [39].
Sensor Model Language (SensorML). It is one of the standards, which are generated under SWE [40].
Semantic Sensor Network (SSN) It identifies sensors, their accuracy and capabilities and the procedures used while sensing [41].
Sensor, Observation, Sample and Actuator (SOSA) ontology It includes core concepts, which are used by SSN as well [42].
The Marine Metadata Interoperability (MMI) device ontology It identifies varied types of instruments using an extendable conceptual model and controlled vocabularies [43].

The Extensible Observation Ontology (OBOE)
It is a formal ontology used for modeling scientific observation and semantic measurement [44].
Each one of the ontologies represented in Table 1 provides significant and valuable contribution to solve the interoperability issues in IoT applications. However, they are not aimed to links between the mapping domain-specific variables that needed crop-specific trait ontologies and sensor measurements. Furthermore, crop-specific trait ontologies can be used to create, publish and share linked open data concerning a particular agricultural product on the web-based platforms as well.
The next part of this study introduces the proposed data-integration approach for agricultural data platforms.

The Proposed Data Integration Approach for Agricultural Open Data Platforms
The proposed approach representing on Figure 1 consists of four layers, which provide acceptable solutions to deal with data integration issues in terms of publishing data in appropriate formats from agricultural open-data platforms to domain stakeholders. These interconnected layers are (1) physical layer, (2) processing and storage layer, (3) semantic interoperability layer and (4) web services and exportation layer, respectively.

Physical Layer (PL)
In the agriculture domain, IoT devices have been frequently used for gathering environmental and site-specific data such as soil moisture, soil salinity, soil pH and climate of the site (temperature, rainfall, wind, light, relative humidity). PL, which is the primary level of the proposed approach, comprises IoT devices formed as wireless sensor networks (WSN), which are structured as several routers controlled by one coordinator. Two variants of WSNs are generally used in agricultural applications: terrestrial WSNs and underground WSNs [45]. These agricultural WSNs applications can use different WSN standardizations such as ZigBee, WirelessHART and 6LoWPAN. There is no restriction in terms of choosing WSN types and standards according to the proposed approach. Thus, any options can be used while establishing IoT devices on any agriculture field.

Processing and Storage Layer (PSL)
This layer corresponds to decomposing raw sensor data streams, cleaning raw sensor data, modeling objects and storing data. PSL enables transforming raw sensor data into an appropriate format mapped to object models and storing these data in varied database options. PSL is composed of four sublayers: data decomposition engine (DDE), data cleansing engine (DCE), Object Modeling Engine (OME) and data storage engine (DSE). Next, these four sublayers are described in detail.

Data Decomposition Engine (DDE)
DDE handles decomposing the raw sensor data that are generally in varied forms. Sensors are low-cost sensing solutions for measuring environmental and site-specific data in agricultural applications. As sensors measure at least one value, they can measure more as well. Considering there are varied sensors plugged on router devices, the proposed approach recommends using key value pairs to define sensors on WSNs. Suppose that one router (id = 1) has a sensor (id = 1) that measures weather humidity (key = WH), weather temperature (key = WT) and barometric pressure (key = PR) at the same time. There can be different ways for composing such a data stream. However, the proposed approach solves this issue using the following pattern.
[ (1) According to this pattern, sensor measurement value can be formulated as RID:1; SID:1; WH:45. This means that the value 45% of weather humidity is measured by the sensor numbered 1, which is plugged to router 1. Figure 2 illustrates how to decompose sensor raw data stream. DDE decomposes the raw sensor data and extracts router definitions, sensor definitions and sensors' measurement values from this data.
DDE is also responsible for matching the sensor measurement value to its unit using sensor information stored in the databases or any files and mapping sensors to their measurement value for creating appropriate object models of routers and sensors to utilize by visualization application tools. To meet mapping requirements, key value pairs of routers and their sensors can be passed as parameters through the queries. When sensor raw data stream is received by WSN coordinators, recognized router and sensor id are retrieved from databases or files. Then, mapping procedures are accomplished by data decomposition engine.

Data Cleansing Engine (DCE)
Missing value problems frequently occur within the sensors and it is accepted quite widely in WSNs. There exist several problems which cause missing value in WSNs, such as synchronization issues, sensor errors or transmission issues [46]. DCE is in charge of handling missing sensor measurements and anomalous values. It can be very crucial to estimate missing sensor measurement values and detect anomalies in terms of critical systems. In case of anomaly detection in WSNs, statistical, support Appl. Sci. 2020, 10, 4460 7 of 27 vector machine (SVM) and cluster analysis techniques play a significant role [47]. These techniques can be applied to the sensor data stream to provide solutions for estimating missing values and detecting anomaly. DDE is also responsible for matching the sensor measurement value to its unit using sensor information stored in the databases or any files and mapping sensors to their measurement value for creating appropriate object models of routers and sensors to utilize by visualization application tools. To meet mapping requirements, key value pairs of routers and their sensors can be passed as parameters through the queries. When sensor raw data stream is received by WSN coordinators, recognized router and sensor id are retrieved from databases or files. Then, mapping procedures are accomplished by data decomposition engine.

Data Cleansing Engine (DCE)
Missing value problems frequently occur within the sensors and it is accepted quite widely in WSNs. There exist several problems which cause missing value in WSNs, such as synchronization issues, sensor errors or transmission issues [46]. DCE is in charge of handling missing sensor measurements and anomalous values. It can be very crucial to estimate missing sensor measurement values and detect anomalies in terms of critical systems. In case of anomaly detection in WSNs, statistical, support vector machine (SVM) and cluster analysis techniques play a significant role [47]. These techniques can be applied to the sensor data stream to provide solutions for estimating missing values and detecting anomaly.

Object Modeling Engine (OME)
OME, which is a sublayer of PSL, enables creating coordinator object model, router object model, sensor object model, data stream object model and sensor data type object model. In other words, it provides mapping database objects to high-level abstract models created within any programming language using object-oriented programming techniques.

Data Storage Engine (DSE)
DSE is responsible for storing data obtained from sensors in three different storage options such as graph database, relational database and cloud database.

Object Modeling Engine (OME)
OME, which is a sublayer of PSL, enables creating coordinator object model, router object model, sensor object model, data stream object model and sensor data type object model. In other words, it provides mapping database objects to high-level abstract models created within any programming language using object-oriented programming techniques.

Data Storage Engine (DSE)
DSE is responsible for storing data obtained from sensors in three different storage options such as graph database, relational database and cloud database.

Semantic Interoperability Layer (SIL)
SIL plays an important role in the data integration process of the proposed approach. All considerable procedures for data integration such as executing SPARQL queries, applying mapping rules, making data interchange and storing mapped data within varied file formats are carried out within this layer. Crop-specific trait ontologies have also a very critical role in the subcomponent named data interchange engine of SIL. It uses crop-specific trait ontologies to map sensor measurement values to relevant traits of agricultural products for publishing more annotated data through open-data platforms for usage of any domain stakeholders. Domain experts may create these mapping rules by selecting relevant ontology classes and mapping them to corresponding sensor measurement values. Mapping rules are also used to link data obtained from IoT devices with agricultural ontology classes. They can be stored in RDF format and implemented by retrieving and manipulating with SPARQL to perform interchange operations when needed. Semantic web technologies are an important way of revealing the common knowledge of a particular domain by performing reasoning procedures [48].
Discovering information in RDF datasets is performed using simple protocol and RDF query language (SPARQL); and the result of the relevant SPARQL query is formed as RDF triples [49]. The inference rules can be defined by domain stakeholders via the relevant module of the platform, which is represented on Figure A3 to help managing knowledge in the context of agriculture. These rules assist with domain stakeholders' understanding of the true meaning of sensor measurement values to perform more precise agricultural activities.

Web Services and Exportation (WSE)
The open-data platforms can publish data in different formats. The proposed approach allows users to choose directly downloadable and web service options considering the heterogeneity of applications, which use the published data. The platform users can export linked open data, which are created by mapping agricultural ontology classes with data gathered from IoT devices in varied file formats such as XML, JSON, HTML, CSV, Excel spreadsheets, RDF/XML, RDF/JSON, N-triples, Turtle and Notation 3. Table 2 gives a brief overview with respect to these data formats. Notation 3 text/n3 An assertion and logic language, superset of RDF [56] Terse RDF triple language Turtle text/turtle An RDF graph to be written in a compact and natural text form [57] On the other hand, data can also be published through web services in XML and JSON formats. Consuming web services to process data requires relatively less effort than semantic web technologies. However, in the open-data world, it is indispensable to publish data in open-data formats. Software applications, which are designed and developed for stakeholders in agriculture domain, can use published data through open-data platforms. Software applications handling published data may be a desktop application, web application or mobile application. A major problem with this software applications' heterogeneity in terms of utilizing published data are that there needs to be a mechanism which provides suitable data formats for each type of software applications.
The proposed approach seeks to come up with developing XML web services, REST web services and Web APIs which help to address and provide robust and effective solutions for data type compatibility issues among software applications. In addition, web services, particularly RESTful web services, can help solve interoperability problems by allowing software applications running on different platforms to request, access and manipulate data, which can be easily processed. Interoperability between software applications is not only a problem for applications that run on different platforms, but also on the same platform as well. Therefore, the proposed approach strongly recommends developing REST web services, Web APIs or both. Another service of the proposed approach is Reporting Service, which enables us to create and manage well-designed data reports. The last service is SPARQL Query Service, which is developed for executing the SPARQL query statements to retrieve data from RDF datasets.

Implementation of an Open Data Platform in Accordance with the Proposed Approach
Below we describe our open-data platform (see in Supplementary Materials) developed by following the layers of the proposed approach. The platform has several modules, such as an ontology visualization tool and data acquisition form generation tool; however, the main focuses of this section are how to integrate sensor data using crop-specific trait ontologies with the open-data platform and how to make use of integrated data for domain stakeholders in open-data file formats.

Introducing Hazelnut Trait Ontology
The main purpose of developing hazelnut trait ontology is to develop a shared a common vocabulary and to provide an international format to standardize a general understanding with respect to hazelnuts. hazelnut trait ontology was developed using Web Ontology Language (OWL) considering the top-down approach in consultation with the hazelnut specialists. According to the top-down approach, the initial work for building an ontology is to begin the process by modeling top-level concepts [58]. hazelnut trait ontology consists of five top-level concepts named descriptors such as passport, management, environment and site, characterization and evaluation descriptors [59]. These descriptors are the top-level classes of the ontology and also, they designate the class hierarchy with the sub descriptors. The definitions and number of sub descriptors of each main descriptor are demonstrated on Table 3. The descriptors demonstrated on Table 3 are in a hierarchical structure that means subclasssuperclass relationships within the ontology, so while creating hazelnut trait ontology, this hierarchy should be considered. Table 3 presents an overview of the major descriptors of hazelnut. The hazelnut trait ontology is a hierarchical classification based on a "is_a" hierarchy. The detailed information concerning hazelnut trait ontology was provided at the link below: https://github.com/hazelnut-traitontology/hto.

Materials and Tools Used for the Development and Implementation of WSN and Open Data Platform Based on Proposed Approach
The initial component of the open-data platform is the establishment of a typical wireless sensor network to meet the requirements of gathering environmental data using sensors. Hence, a WSN, which consists of one coordinator and seven sensors plugged on three routers was built. The first sensor plugged on router 1 is BME280. It can measure relative humidity from 0 to 100% with ±3% accuracy, barometric pressure from 300 Pa to 1100 hPa with ± 1 hPa absolute accuracy and temperature from −40 • C to 85 • C with ±1.0 • C accuracy. The second sensor plugged on router 1 is GUVA-S12SD UV. It detects the UV wavelength from 240 nm to 370 nm in sunlight. The third and the last one plugged on router 1 is MICS-4514. It can detect the following gases: carbon monoxide from 1 ppm to 1000 ppm, nitrogen dioxide from 0.05 ppm to 10 ppm, ethanol from 10 ppm to 500 ppm, hydrogen from 1 ppm to 1000 ppm, ammonia from 1 ppm to 500 ppm and methane greater than 1000 ppm. Router 2 has three sensors such as soil moisture, rain and BH-1750 light level. The soil moisture sensor categorizes its measurements as dry soil, humid soil and in water. The rain sensor, actually a raindrop sensor, does not measure rainfall. It categorizes its measurements as raining, rain warning and not raining. BH-1750 sensor can measure light intensity from 1lx to 65535lx. Router 3 has only one sensor named MPU6050, which is 6 axis acceleration and gyro sensor. These sensors were defined for representation using abbreviations by a set of named constants which are illustrated on Table 4. Coordinators and their routers are illustrated on maps on open-data platforms according to their latitude and longitude information. Platform users can access the detailed information of WSNs by following the link on coordinator tooltips. Each one of the sensors, routers and coordinators can be visualized as hierarchical nodes on the platform; and platform users can access sensors' data, which are measured in the last five minutes and visualized in appropriate graphs by using clickable features of the routers' icons. Figure 3 shows how each component of WSN is viewed on the open-data platform.
format requires using microcontrollers. Therefore, Arduino, which is an open-source member of family of electronic microprocessor boards, based on easy-to-use hardware and software, was used as router and coordinator devices within the WSN. Other reasons to use Arduino as router and coordinator devices are as follows: it is inexpensive; its IDE runs on cross-platforms and easy-to-use; and its hardware and software are open source [60]. Furthermore, it ensures key features to collect both economic and practical benefits for researchers [61].  It is a well-known fact that reading sensor inputs and transforming them into a meaningful format requires using microcontrollers. Therefore, Arduino, which is an open-source member of family of electronic microprocessor boards, based on easy-to-use hardware and software, was used as router and coordinator devices within the WSN. Other reasons to use Arduino as router and coordinator devices are as follows: it is inexpensive; its IDE runs on cross-platforms and easy-to-use; and its hardware and software are open source [60]. Furthermore, it ensures key features to collect both economic and practical benefits for researchers [61].
Raspberry PI, which is a low-cost and single-board computer, is used for interfacing the coordinator device through serial ports to receive data assembled from routers. Raspbian which is a kind of operating system based on Debian developed for Raspberry Pi can be freely accessed and is downloadable by any users. In addition, Raspbian is a commonly preferred operating system option for Raspberry Pi computers and freely available community project under active development. Therefore, it was considered the suitable operating system option that will run on the Raspberry Pi computer, which plays the manager role of established WSN. Furthermore, a Python program was developed to read raw sensor data gathered from a coordinator device through a serial port. This program is also responsible to store raw data in a relational database using RESTful web service operations.
XBee module, which supports multiple protocols, is highly configurable and consists of small radio frequency (RF) devices that transmit and receive data over air using radio signals [62]. It was used to transmit data wirelessly between routers and the coordinator. Each XBee device is configured as Application Programming Interface (API) mode within the built WSN. There exist several reasons behind preferring API mode. API operating mode eases managing transmission of data towards multiple destinations. Each received data contains the address of the sender device. This mode provides advanced Zigbee addressing, advanced networking diagnostics and remote configuration [63]. XBee devices, which are configured as API operating mode, uses API frame illustrated in Figure 4 to transmit data from routers towards the coordinator. After router devices measured environmental data through their sensors, they transform the sensor measurement values to API data frame using relevant Arduino libraries.
The received data through the coordinator are decomposed into several pieces to distinguish the router, sensor and sensor measurement value. In other words, the purpose of this operation is to access RF data, which are part of API frame to extract key value pairs. After key value pairs are extracted from RF data, it is necessary to match the sensor to its measurement unit using sensor information stored in the database. This matching process is performed by retrieving relevant data from database using REST web services. The reason for applying this method is to keep the total number of bytes included in the API frame's data file small. Considering the sensors of WSN, the following measurement units are matched to relevant sensor measurement data types: lux for light intensity, • C for temperature, % for humidity, Pa for pressure, m for altitude, • /s for slope, nm for ultraviolet, ppm for carbon monoxide concentration and ppb for nitrogen dioxide concentration.
program is also responsible to store raw data in a relational database using RESTful web service operations.
XBee module, which supports multiple protocols, is highly configurable and consists of small radio frequency (RF) devices that transmit and receive data over air using radio signals [62]. It was used to transmit data wirelessly between routers and the coordinator. Each XBee device is configured as Application Programming Interface (API) mode within the built WSN. There exist several reasons behind preferring API mode. API operating mode eases managing transmission of data towards multiple destinations. Each received data contains the address of the sender device. This mode provides advanced Zigbee addressing, advanced networking diagnostics and remote configuration [63]. XBee devices, which are configured as API operating mode, uses API frame illustrated in Figure  4 to transmit data from routers towards the coordinator. After router devices measured environmental data through their sensors, they transform the sensor measurement values to API data frame using relevant Arduino libraries. The received data through the coordinator are decomposed into several pieces to distinguish the router, sensor and sensor measurement value. In other words, the purpose of this operation is to access RF data, which are part of API frame to extract key value pairs. After key value pairs are extracted from RF data, it is necessary to match the sensor to its measurement unit using sensor information stored in the database. This matching process is performed by retrieving relevant data from database using REST web services. The reason for applying this method is to keep the total number of bytes included in the API frame's data file small. Considering the sensors of WSN, the following measurement units are matched to relevant sensor measurement data types: lux for light intensity, °C for temperature, % for humidity, Pa for pressure, m for altitude, °/s for slope, nm for ultraviolet, ppm for carbon monoxide concentration and ppb for nitrogen dioxide concentration.
The model creation needs to be undertaken for decomposed and cleaned data using a programming language according to the proposed approach. C# programming language is used to create objects, which are represented in Figure 5. It is also a major programming language which is used to develop web services and open-data platform.
There exist three different storage options recommended by DSE. MS SQL Server 2016, which was a relational database management system, is used to store data.  Figure 4. API data frame.
The model creation needs to be undertaken for decomposed and cleaned data using a programming language according to the proposed approach. C# programming language is used to create objects, which are represented in Figure 5. It is also a major programming language which is used to develop web services and open-data platform.  The Windows communication foundation (WCF), which is a framework for building serviceoriented applications, was used to develop XML and RESTful web services. dotNetRDF, which is a common. NET API for working with RDF triple stores, was used to parse, manage, query and write RDF datasets [64]. ASP.NET Web API framework, which provides an easy and secure way for building HTTP based services, consumed by a wide range of software applications, was used to develop the Web APIs.

Providing Semantic Interoperability between IoT Devices and Open Data Platforms Using Agricultural Trait Ontologies
This section of the study examines how to integrate sensor data using a crop-specific trait There exist three different storage options recommended by DSE. MS SQL Server 2016, which was a relational database management system, is used to store data.
The Windows communication foundation (WCF), which is a framework for building serviceoriented applications, was used to develop XML and RESTful web services. dotNetRDF, which is a common. NET API for working with RDF triple stores, was used to parse, manage, query and write RDF datasets [64]. ASP.NET Web API framework, which provides an easy and secure way for building HTTP based services, consumed by a wide range of software applications, was used to develop the Web APIs.

Providing Semantic Interoperability between IoT Devices and Open Data Platforms Using Agricultural Trait Ontologies
This section of the study examines how to integrate sensor data using a crop-specific trait ontology. This section also shows how to create mapping rules for linking sensor data types with relevant ontology classes by storing in RDF file.
The classes which can be mapped into the relevant sensor measurement data types are sub-classes of: EnvironmentAndSite class. This describes the environmental and site-specific parameters with respect to hazelnut within the hazelnut trait ontology. After sensor data streams are decomposed as key value pairs and stored in the database in compliance with the object models created by OME, there is a need to create mapping rules using the relevant UI through open-data platform. The open-data platform uses these rules to map the sensor measurement data types with the relevant ontology classes to integrate and annotate data semantically. Varied data files mentioned in the previous section of the study are generated by linking the stored datasets to relevant classes of agricultural ontology. Through using these mapping rules, domain-specific datasets are built. Considering the presence of irrelevant sensor measurement data types within any WSN, it is reasonable to use these mapping rules for combining data from different sources in a single and unified view. The established WSN, which was introduced within the previous section of this study, uses seven sensor measurement data types corresponding to the relevant hazelnut trait ontology classes. Table 5 presents sensor measurement data types, abbreviations, data units and class axioms, which are used while creating mapping rules. Measurement values of mapped data types can be viewed using open-data platform and they will be integrated with hazelnut datasets. As shown in Figure 6, decomposed sensor data streams are mapped with the relevant hazelnut trait ontology classes by rule engine using mapping rules. One of the rule examples, which represents mapping the temperature measurement data type with: Temperature class of hazelnut trait ontology, is illustrated in Table 6.
Appl. Sci. 2020, 10, x FOR PEER REVIEW 15 of 29 Figure 6. Mapping sensor measurement data type to ontology classes.   It is apparent from this example that rules use URI reference to identify resources in datasets stored in RDF files. The base URI of hazelnut trait ontology is http://www.opendatainagriculture.com/ ontologies/hazelnutontology. The URI reference should be the same with the URI reference of the relevant ontology classes to make a link between the sensor information and class definition within the mapping rule file. While linking sensor measurement data types with hazelnut trait ontology classes, SPARQL query statements are used to retrieve each attribute of sensor data from mapping rule file. The SPARQL query statement represented in Table 7 retrieves base ontology URI with: Temperature class, sensor data type URI and the value of Id attribute of the sensor data type from mapping rule RDF file. This query statement is executed by rule engine of open-data platform and viewed as RDF triple, which contains three components named subject, predicate and object, respectively. In the example, subject, predicate and object are: Temperature class, sensor data type and the value of Id attribute of the sensor data type, respectively. When the mapping procedure is completed using the data interchange engine of proposed approach, any stakeholder could create, export and publish datasets with respect to agricultural product, which is hazelnut in this case, in varied formats such as XML, JSON, RDF/XML, RDF/JSON, N-triples, Turtle, Notation 3, HTML, Excel spreadsheet and CSV. Figure A7 illustrates how to export these datasets from the platform. They can fulfil the procedures for discovering and analyzing using datasets stored in these files.
The open-data platform improves the quality of data integration by applying inference rules on the traits which are mapped with the relevant sensor measurements. Furthermore, the inferred knowledge of a trait helps make better decisions concerning agricultural production for stakeholders who lack much information concerning how to perform PA activities. For instance, the "topography" class of hazelnut trait ontology can have the rules which are generated by a domain expert, using semantic web rule language (SWRL), represented in Table 8. According to the inferences provided by these rules, any stakeholder can easily identify whether the topography of an agricultural land surface is flat, hilly or mountainous.

Evaluation of the Tools of Open Data Platform Used for Implementing the Proposed Approach
The quality of the tools of open-data platform used for implementing the proposed data-integration approach were evaluated in terms of efficiency, affect, helpfulness, control, learnability and usability by twenty-seven respondents-15 males and 12 females-with different levels of software skills and technical knowledge. The respondents are representative of the software developers who are experienced with developing web-based software platform and non-technical users who can use any web-based software platforms easily. They are also representative of the IT specialists and researchers from agricultural domain, with a high-level education. Respondents average age is 29.44. Table 9 provides an overview of the respondents' profile. In this evaluation process, the following modules were evaluated: (i) "Ontology viewing and loading" represented on Figure A1; (ii) "Selecting individuals of traits for inference rules creation" represented on Figure A2; (iii) "Creating rules definitions for individuals" represented on Figure A3; (iv) "Creating mapping rules" represented on Figure A4; (v) "Wireless sensor networks management" represented on Figure A5; (vi) "Charting and managing mapped sensor measurements" represented on Figure A6. The following tasks were assigned to each respondent to complete: register to the platform; login to the platform; access the UI of ontology viewing; access the UI of creation of mapping rules; select the individuals of traits for creating inference rules; access the UI of creating rules definitions for selected individuals; save defined rules for each selected individual; access the UI of WSN lists, select the relevant WSN and access the list of its routers and coordinators; select any sensor of router and access the UI of visualizing collected data on the charts; access the UI of listing mapped sensor data. Each respondent completed all assigned tasks to him/her successfully. While each respondent was performing the tasks, he/she recorded the elapsed time. Figure 7  The software usability measurement inventory (SUMI), which is a rigorously tested and proven method of measuring software quality from the end user's point of view [65], was used to measure the usability of the open-data platform. Figure 8 reveals that there were satisfactory results of the entire scales. It also shows the range of the 95% confidence interval of the means of the scales.
The SUMI scales are statistically adjusted so that the population mean in its database is 50 and the standard deviation is 10, what is known as a 50/10 distribution. The range of SUMI scores goes from 73 to 10. SUMI scores exhibit a slight positive skew. Each scale is computed by a process of weighting and averaging of SUMI items. The mean, standard deviation, median, interquartile range (IQR), minimum and maximum calculations results of each SUMI scale are presented in Table 10. As can be very clearly illustrated in Table 10, the developed open-data platform has satisfactory result for each SUMI scale. The software usability measurement inventory (SUMI), which is a rigorously tested and proven method of measuring software quality from the end user's point of view [65], was used to measure the usability of the open-data platform. Figure 8 reveals that there were satisfactory results of the entire scales. It also shows the range of the 95% confidence interval of the means of the scales. 19   The software usability measurement inventory (SUMI), which is a rigorously tested and proven method of measuring software quality from the end user's point of view [65], was used to measure the usability of the open-data platform. Figure 8 reveals that there were satisfactory results of the entire scales. It also shows the range of the 95% confidence interval of the means of the scales. 19 ELAPSED TIME (in minutes) Figure 8. Graphical summary of software usability measurement inventory (SUMI) scales.  Figure 9 shows the means and standard deviations for each of the SUMI scales and for the global usability scale of the sample being analyzed. The cross in the center of the ring shows the location of the mean, the bars are extended by one standard deviation on each side of the mean.

RESPONDENTS
weighting and averaging of SUMI items. The mean, standard deviation, median, interquartile range (IQR), minimum and maximum calculations results of each SUMI scale are presented in Table 10. As can be very clearly illustrated in Table 10, the developed open-data platform has satisfactory result for each SUMI scale.  Figure 9 shows the means and standard deviations for each of the SUMI scales and for the global usability scale of the sample being analyzed. The cross in the center of the ring shows the location of the mean, the bars are extended by one standard deviation on each side of the mean. There are four different respondent profiles recommended by SUMI in terms of software skills and technical knowledge. Table 11 shows the profiles of respondents who were asked to evaluate the Global usability of the open-data platform, which means a general feeling of satisfaction concerning the experiences of the users with the software platform, was calculated as 67.67. This result is quite reasonable in terms of usability score. The calculation results of efficiency, affect, helpfulness, controllability and learnability are 63.33, 64.52, 63.07, 64.81, 56.78, respectively. Considering the scores of the SUMI scales are calculated in the range between 10 and 73; the calculated scores for open-data platform are seen as acceptable.
There are four different respondent profiles recommended by SUMI in terms of software skills and technical knowledge. Table 11 shows the profiles of respondents who were asked to evaluate the open-data platform. Furthermore, it presents evaluation results of each scale obtained from respondents with different profiles.
The respondents were asked to determine the importance of the evaluated open-data platform with the following question: "How important for you is the kind of software you have just been rating?" Six respondents have noted that the open-data platform is "important". On the other hand, the open-data platform was perceived as extremely important by twenty-one respondents. Table 12 represents the calculated scores for each scale that belonged to the two groups of respondents who described the open-data platform as important and extremely important.
As mentioned above, the results of entire scales, which were used to measure the quality of the open-data platform, are quite reasonable. On the other hand, some enhancements should be carried out to increase the capabilities of the open-data platform. For instance, some respondents have noted that the class selection screen should be more flexible. Furthermore, the design of some user interfaces should be edited with the aim of enabling non-technical users to do their tasks in a quick and effective manner.

Conclusions
This study sets out to propose an approach to integrating data collected from IoT devices to agricultural open-data platforms from the perspective of semantic and syntactic interoperability. The proposed data-integration approach has enhanced an understanding of data integration lifecycle for agricultural IoT applications in the context of open-data platforms. The general tendency to provide data integration for data gathered from IoT devices is to use existing geospatial ontologies. However, this study has demonstrated, for the first time that a crop-specific trait ontology by constructing mapping rules was used to annotate the environmental data for a particular agricultural product with the aim of achieving semantic interoperability. The most obvious finding to emerge from this study is that semantic interoperability for data collected from IoT devices can be carried out using a crop-specific trait ontology by constructing mapping rules. Another important finding is to demonstrate how to use web services and APIs to provide syntactical interoperability for data gathered from IoT devices using crop-specific trait ontologies.
This research demonstrates the value of the proposed approach along with its implementation of software applications. First, the open-data platform which is developed based on the proposed approach enables agricultural domain stakeholders export linked open data in varied open formats or standards. It provides a visualization infrastructure for IoT devices and their data. Thus, stakeholders could access and export data gathered from IoT devices belonging to a particular wireless sensor network established for the relevant agricultural product. Second, web services and APIs allow stakeholders to share data about a particular agricultural product between different kinds of software applications. By this means, syntactical interoperability was carried out through these services and APIs.
The open-data platform was evaluated in terms of usability considering five different scales such as efficiency, affect, helpfulness, control and learnability by using SUMI questionnaire [65]. According to the usability results, the developed platform has satisfactory scores for each one of them. Furthermore, the score of global usability scale is quite reasonable for the open-data platform.
The implementation part of this study focused on hazelnut agricultural product. However, the proposed approach is appropriate for different types of crop-specific trait ontologies, which are created using OWL and includes site-specific variables. The present study has only examined semantic and syntactic interoperability. However, further research may investigate other interoperability layers for open-data platforms. One may be interested in making use of web services and APIs from mobile-based software applications to provide meaningful information for the relevant agricultural product and its production lifecycle.          Figure A5. Screenshot of wireless sensor networks management.
Appl. Sci. 2020, 10, x FOR PEER REVIEW 25 of 29 Figure A6. Screenshot of charting and managing mapped sensor measurements. Figure A6. Screenshot of charting and managing mapped sensor measurements.