Adaptation of ontology sets for water related scenarios management with IoT systems for a more productive and sustainable agriculture systems Diego Sánchez-de-Rivera Tomás Robles Juan A. López Departamento de Ingeniería de Departamento de Ingeniería de Equipo de Sistemas de Información Sistemas Telemáticos Sistemas Telemáticos Geográfico y Teledetección Universidad Politécnica de Madrid, Universidad Politécnica de Madrid, IMIDA, Spain Spain Spain juanantonio.lopez@carm.es diegosanchez@dit.upm.es trobles@dit.upm.es Azucena Sierra de Miguel Mariano Navarro De La Cruz María Sofía Iglesias Gómez TRAGSA, Madrid, Spain TRAGSA, Madrid, Spain TRAGSA, Madrid, Spain asdm@tragsa.es mnc@tragsa.es msig@tragsa.es Juan A. Martínez Antonio F. Skarmeta Odin Solutions S.L. Departamento de Ingeniería de la Murcia, Spain Información y las Comunicaciones jamartinez@odins.es Universidad de Murcia, Spain skarmeta@um.es ABSTRACT KEYWORDS Water management is a key scenario for the deployment of IoT Ontology, agriculture, IoT, management systems because of the particularities that arise depending on the geographical region as well as its inherent weather conditions. 1 INTRODUCTION This scenario offers different and challenging problems to the deployment of IoT based applications and services which must Nowadays water resources management scenarios benefit from rely on a rich technological vocabulary able to represent such innovative techniques that support the seamless integration by characteristics and particularities. This is the reason why upgrading the necessary components and methodologies with ontologies are the medium to achieve this goal. In this paper, we more technological and flexible systems. Water systems have a review the most well-known related ontologies as well as propose great background of state-of-the-art management systems that a model called MEGA promoted at state level with the objective take advantage of the newest developments in the Internet of of not only representing the information, but also integrating all Things (IoT) field. By incorporating intelligent devices, water the elements of an irrigation system, specially water distribution management can be controlled and managed by a common entity networks under interoperable platforms or systems.1 that enables new capabilities and goals than in a traditional way. This ends with a better resource exploitation and ultimately in CCS CONCEPTS essential resources preservation. Currently, water resources management is mainly confined to • CCS → Information systems → Data management the water reserve supervision and provisioning, and this is clearly systems → Information integration making use of the current existing technologies. But, what can be expected when this boundary ispassed beyond? The answer is a totally lack of a multi-disciplinary and standardized methodology when more than one area of interest is involved. In this work, we study other rural management fields in addition to the water management environment, as currently, any © 2017 Copyright held by the author/owners. combination made is getting more important with the relevant SEMANTiCS 2017 workshops proceedings: SIS-IoT ecological awareness that the green economy directives dictate. September 11-14, 2017, Amsterdam, Netherlands The need of a seamless integration between these several concepts SIS-IoT 2017, September 2016, Amsterdam, Netherlands D. Sánchez-de-Rivera et al. in a technological system is a key factor to develop an existing devices, but once a successful integration has been done, interoperable and linked managed environment. new requirements has been observed. The lack of a standardized To achieve this, existing ontologies try to combine themselves vocabulary that allows a more in-depth relationship definition with deprecated methods that are not taking any advantage of along with their properties decrease the future growth of the current state of the art, but in this research paper we are studying developed system. As presented in Figure 1, interfaces driven by the problematics, requirements and possible solutions to enable the web services mechanism (primarily SOAP) are in charge of more advanced methodologies that will allow several relaying information between different layers. This improvements on a rural management domain. communication is made without any vocabulary nor correlation The rest of the paper is as follows: Section 2 introduces the between the implied subsystems. water related management scenario used to test and deploy the development, Section 3 analyses the state of the art of the relevant areas that this paper covers, Section 4 states the standardization process proposed in this work and Section 5 describes ongoing work and conclusions. 2 WATER RELATED MANAGEMENT SCENARIO Spanish south-eastern has an arid or semi-arid climate according to the climatic classification of the United Nations Environment Program (UNEP), which is mainly defined by high temperatures from May to September, with lower or null rainfall, and slightly lower although moderate temperatures from October to April with some more rainfall. Both characteristics, the lower and irregularity of rainfall coupled with the higher evaporative Figure 1: MEGA platform functional levels rate, are the limiting factors for the agricultural development. In this situation, the irrigation plays an important role in the Thanks to this real deployment, several needs have been production system, and therefore the efficient use of water must observed with this development and deployment. In addition, a set be an essential requirement. of requisites have been identified to be satisfied with the inclusion The agricultural sector is in continuous evolution in which IoT of a global ontology vocabulary. technologies must be adopted to manage all the objects which are located on the farm under a single system. These technologies will 2.1 Requirements improve the crop productivity through the management and water To achieve a successful deployment and integration of a novel control and by optimizing the energy consumption. As a use platform, we use the expertise acquired in the previous scenario, a community of irrigators could be selected due to the development to create a set of requirements in order to collect all fact is the organism where the farmers are grouped with the the needs that a final management system require in a real world purpose to self-manage to distribute the water of irrigation of an situation. We use the scenario described in the section 2 in the effective and equitable way among its members. requirements definition process. To combat the water management problematics here in Spain, Following, along with each requirement, a short description is a new platform endorsed by the Spanish government is being provided in order to clarify and establish the future needs of the developed within the agriculture sector to provide a new and standard. novel mechanism for water resources management: MEGA [1, 2]. REQ #1: Unique device identification: In a management For the last years, development in MEGA has been focused on system, a reliable identification of the final device is a key establish a reliable communication between the different actors requisite that allow to control and communicate system wide and involved into the development management [4]. From the provide singularity to precise events. As in our case scenario the business model to the final device placed on the ground, several devices or entities can be virtual, the process of creating and gateways have been implemented and tested. A graphical assuring a unique identification is critical for a successfully representation of the platform is represented in Figure 1. implementation. The devices will be identified by means of an Currently, web services are the main communication identifier as used by Open Geospatial Consortium (OGC). mechanism for controlling processes in the MEGA infrastructure. REQ #2: Recursive entity grouping: In complex system As MEGA introduces a new concept called “virtual entities” environments like water management scenarios, some entities by (composition of several hydraulic entities that reside in one or themselves are not capable of performing any substantial process several subsystems) in addition to the logical devices found in the nor even smart enough to be able to communicate with other system, a web service defined between the interfaces drives the elements. In this case, aggrupation is made to encompass one or complex compound of the involved devices. The selection of this more entities in one device that can be recognized by the technology helped in the deployment of this new system into the 2 Adaptation of ontology sets for water related scenarios management SIS-IoT 2017, September 2016, Amsterdam, Netherlands management system. This grouping can be done recursively, as the devices can be part of a superior level device that is in charge of their dependent operations. Thus, a device can be composed by a single entity or a group of entities, in a recursive way. REQ #3: Group characterization: To give a proper computing capacity to a device, a characterization of the properties and capabilities offered by the component is required to allocate the correct resources. Characterization implies that a list of predefined capabilities must be assigned before and thus, a configuration process has to be carried out. Once the system is initialized, the management and exploitation layer is able to build an available resources schema with all the gathered information. REQ #4: Group interoperability on all levels: As the system Figure 2: UML model of devices will be deployed on land, communication between different subsystems is mandatory. To provide interoperability, the communication among same layer devices and inter layer are used. 2.2 Objectives REQ #5: KPI measure capability: As a management system Based on the information acquired in the requisites entails, measurements of certain aspects are required to analyze identification phase, authors expose a list of desirable objectives the performance and reliability of the system. The system must be to achieve thanks to this novel adaptation. able to collect metrics and provide interfaces to interact seamlessly for KPI generation and report. 1. Provide a high-level abstraction and virtualized REQ #6: Request optimization: In a multi-layer system, inter- representations of the water related systems layer requests have to be optimized to reduce any unnecessary 2. Enable access, configuration and operation of the water- overhead. In this sense, a valid request can be addressed to a energy systems using high level common interfaces certain device whose upper layer know in advance its inability to 3. Develop a semantic annotation model for interoperable process the request, so this request has to be redirected or data/service exchange between the different domains cancelled at this layer, avoiding excessive requests. and also between each domain and higher-level REQ #7: Sensing and acting capability: Unlike sensor-only services/applications. systems, a water management environment requires acting 4. Provide common interfaces and common control capabilities over some devices. In this case, the developed system mechanisms for real time control of the systems. must be able to command actuators and last verify the correct These objectives are the goal of our system, and in the state of the device. following sections, they will be analyzed and divided to REQ #8: Security and privacy: Every modern management contribute into the final solution. system has to take into account the security implication as a cross layer that involve every component of the system. As the system 3 RELATED WORK is composed of several subsystems, each one must have its own Many IoT available related research reviewes the current state security measures in addition to the global layer that cover the of the art in the domain of the IoT ontologies. Additionally, there whole system. In this work, security is omitted as the authors are many ontologies that have been available specifically for IoT relay the security mechanism to the selected framework and sensors and other related areas. In this section we analyze some of protocols. Even, the semantic addition does not modify the these IoT related ontologies, and several ongoing integration security implications of the platform. works for defining unified ontologies that are intended for In Figure 2, a representation of a generic device is shown, covering different applications domains. In the following providing the requisites defined previously. subsections, we provide detail of the most relevant ones. The objective of this work is similar to that published by K.W. Chau[13] but choosing as main element the use of water for irrigation management, in addition new ontology methodology such as Neon [14] will be used and geographic information systems (GIS). 3.1 LOV4IoT To provide a fundamental basis on the existing ontologies, a project called Linked Open Vocabularies for Internet of Things (LOV4IoT) was created [3]. It is a dataset that links almost three 3 SIS-IoT 2017, September 2016, Amsterdam, Netherlands D. Sánchez-de-Rivera et al. hundred ontology projects related to the IoT world. Each project • Adoption of the ontology is classified by its domain and added to a central repository for an • Level of sophistication easy location. Domains are defined previously and currently there • Weakest features are nineteen domains in which a new ontology should match, As conclusion, they state that the W3C SSN is a great these from highest to lowest are (in brackets, the number of combination of the most important sensor ontologies at that time. ontologies present in each domain): healthcare(59), smart It defines the key aspects of sensor representation and includes home(51), transportation(35), food/restaurant(30), tourism(30), high-level concepts for the critical observation and representation security(32), water(5), Internet of Things(51), weather(17), within the sensor environment. agriculture(20), activity recognition(13), environment(15), smart 3.2.2 IoT-Lite ontology energy(10), fire management(7), smart city(15), affective science(7), music(6), unit(5) and others things(0). Summarizing The IoT-Lite [10] ontology is a lighter instantiation of the SSN ontology with the aim of describing the IoT fundamental concepts the data , IoT and smart agriculture are both in the mid chart, and the number are getting bigger each year without a proper to enable interoperability between different IoT platforms, other ontologies are recommended to be joined in order to span more. standardization. The main issue arising from the LOV4IoT is: the lack of IoT-Lite describes the concepts of IoT in three main classes: projects for water domain and the lack of an interoperability objects, system or resources and services. IoT-Lite focuses on detection, although it has a high level of performance concept standard to avoid reuse many domains of knowledge. Instead, it may be worthwhile to integrate in a unique ontology all the which allows any future extension in this area, this would be a weakness of the ontology. information present in every similar domain category and in this case, LOV4IoT data can be of a great help to identify information 3.2.3 Fiesta-IoT ontology duplicated in similar ontologies to unify them with more Fiesta-IoT [9] was born with the aim of promoting semantic integrated and interoperable procedures. interoperability because not all ontologies provide it. Fista-IoT reuses the results of previous and current EU projects in the use of 3.2 IoT related ontologies semantic web technologies such as OpenIoT, Citypulse, VITAL, In order to discern which ontologies are the best candidates to Spitfire, IoT-est, IoT-A, IoT6, iCore, Sensei, etc. our management system, a more detailed analysis of the Internet The main objective can be summarized as the establishment of of Things related ontologies is made in order to extract the a new infrastructure for global experimentation, where concepts necessary information about this specific domain. This will be the such as virtualization, federation and interoperability (semantics) selected expertise area to use in our water management play a fundamental role in IoT platforms (Internet of Things) of deployment. the future. In the literature, several related ontologies have been analyzed. Fiesta-IoT addresses the issues of semantic interoperability at In this section we have selected the most known ones as they seven levels: comply with our interoperability goal in the water ecosystem • Hardware level, provides middleware based on semantics domain: (eg OpenIoT) to handle heterogeneous hardware devices. • Data level, unifies data produced by devices from 3.2.1 W3C SSN ontology different cities and projects using the semantically data. The W3C forum has defined a Semantic Sensor Networks • Model level, aligns existing IoT ontologies to ensure (SSN) [11] as a standard description of sensor devices networks better interoperability. for sensor discovery operations. • Level of consultation, queries of unified knowledge bases In that sense, SSN is primarily focus on offering great (ontologies and set of data). interoperability of the capabilities offered by the devices in order • Level of reasoning, unifies how to derive meaningful to facilitate the later addition and auto-discoverability of the information from the data sensor to avoid redundancy of sensor devices [8]. One limitation of this approach is the the "if not then" constant rules redesigned in all IoT deliberate set aside of the additional data but not sensor specific. applications. This data such as units, sensor types, locations and features are • Service / application level, brings the innovative idea of not included in to the ontology. "Experimentation-as-a-Service (EaaS)" of Cloud So, to deal with the lack of this information, some observation Computing. EaaS is built on top of "Linked Open concepts were included to allow link external ontologies and Services" based on the Linked Data approach that building a complex hierarchical ontology based on observation currently extends to IoT domain. properties. • Application domain level, build applications between Different studies based on sensor ontologies compared the domains / vertical applications to interconnect and reuse / following aspects: specific horizontal applications of the current domain (eg, • Purpose of the ontology smart home). • Status of the ontology: online, documentation, maintained, etc. • Key concepts found in the ontology 4 Adaptation of ontology sets for water related scenarios management SIS-IoT 2017, September 2016, Amsterdam, Netherlands The use of FIESTA-IoT can be applied to all IoT projects, with OGC has been working on data models since 1995, one of its these benefits: reusing domain knowledge, reusing existing first documents was a Spatial Scheme that in its essence was a ontologies and designing inteoperable applications global data model. SWE offers a common data encoding that is used throughout the suite of OGC standards. Moreover, SWE 3.2.4 SOSA ontology Common Data Model [6] is used to define the representation, the The Sensor, Observation, Sample and Actuator (SOSA) 2 nature, the structure and encoding of data related to sensors. ontology is considered a second version of SSN. SOSA provides a Another of its functions is to maintain the functionality required lightweight core for SSN and aims to expand the target audience by all OGC standards. and the application areas that can make use of the ontologies of As for data models, organizations that need a web-based the Semantic Web. At the same time, SOSA acts as a minimum platform to manage, store, share and analyse data from sensor level of interoperability, i.e. it defines those common classes and observations can use the SensorThings API [7]. This API properties for which data can be exchanged with security between simplifies and accelerates the development of IoT applications all SSN applications, their modules and SOSA. improving complex tasks that previously could not be done. It is Two of the new entities provided by SOSA are: part of the OGC Web Enablement Sensor, as a standard for IoT. It - Actuator: device that is used by, or implements, a is based on the model of O&M data (OGC / ISO 19156: 2011), so procedure that changes the state of an object. that it can easily interoperate with SOS services. The main - Actuation: is the action that is performed to change the difference is that it is a RESTful service that uses the encoding state of an object using an actuator. efficient JSON, and adopts the OASIS pattern. SOSA extends the original scope of SSN beyond sensors and It provides an open, unified framework for interconnecting IoT their observations, including classes and properties for actuators devices, data and applications through the Internet. The and sampling. SensorThings API is designed to transform the several 3.2.5. Other related projects disconnected IoTs on a fully-connected platform where complex Other projects or ontologies that can serve as reference to this tasks can be synchronized and performed. work are: As a standardized data model, the SensorThings API offers the IoT-O ontology: It's another ontology [15] that integrates the following benefits: concepts of other ontologies like SSN (sensing module), SAN 1. It allows the development of new high value services with (acting module), DUL .. one of the fundamental differences is that lower development cost and of a wider scope. it adds an energy module, based on powerOnt [16] 2. Lower risks, time and costs through a complete IoT Water-m project: the aim is finding solutions to the product cycle. interoperability, real-time, big data and heterogeneous data 3. Simplify device-to-device and device-to-application challenges to being able to guarantee water supply and quality applications. along with the stability and reliability of a smart water network The data model is composed of two distinct parts. A sensing [17]. Since part of this project has designed an ontology and profile that allows devices and their applications: create, read, inside the use cases that are described inside the project there is modify and erase data in a SensorThings service. And another one “Use Case 8: Urban Farming” that it might use as reference to (tasking profile) that allows applications to control the devices the ontology of this work through a service. 3.3 OGC models 3.4 FI-Ware Due to the lack of interoperability between the different FI-Ware is an open-source European initiative that aims at sensors, the Open Geospatial Consortium (OGC) [5] founded creating the necessary standards to develop applications in a wide Sensor Web Enablement (SWE) to define standards to improve spectrum of smart domains such as smart cities and smart interoperability and access of sensors on the Internet. agriculture. FI-Ware wants to develop a standard to describe how One fact to consider should be the use of a data model (set of to collect, manage and distribute the essential context information rules which control the transfer from the real world to the that enables its exploitation and finally a business model. This computer systems) which must be open and configurable enough standard is key to build intelligent applications capable of provide to ensure its adoption is not an abrupt process and thus it will be a one unique digital market for smart applications where solutions able to promote better forms and more consistent to publish and to could be ported seamlessly from one customer to another. access data of common interest. The FI-Ware platform provides cloud capabilities based on the In any adopted solution, it is necessary to use a data model OpenStack framework with a set of value tools and libraries called with spatial component, that allows us to share the information in Generic Enablers (GEs). These GEs offer open interfaces that ease a regulated framework. Although, this entails the migration of the task such as integrating IoT deployments and infrastructures by model used to another one. allowing the data management and processing with common and reusable modules. The specifications and APIs of the GEs are public and royalty 2 https://www.w3.org/2015/spatial/wiki/SOSA_Ontology free with open source code available of each implementation. This 5 SIS-IoT 2017, September 2016, Amsterdam, Netherlands D. Sánchez-de-Rivera et al. allows FI-Ware vendors to emerge on the market, sharing APIs, incorporation in European regions. With this approximation, and therefore building extensible applications that can be selected Spain regions can test and incorporate new technological ways to between several vendors hosting to store the solution and process power the water management industry. the data. As FI-Ware is conceived as a cloud computing platform, it is aimed at providing Smart solutions for different scopes like: Smart cities, Smart ports, Smart logistics, Smart irrigation systems and the likes. Additionally, and unlike other private solutions, FI- Ware provides an open and free architecture along with a set of specifications that allow developers of service providers and any other company or organization to develop products promoting the creation of a marketplace to offer innovative solutions. Usually, smart solutions are characterized by a three-step process: gathering information of interest from heterogeneous sources of information, storing the information into a repository of information, and its processing in order to generate the knowledge for the solutions. In addition, a fourth step could take place if actuation over certain elements is required. FI-Ware is making a great effort at both first steps by Figure 3: MEGA high-level functional architecture implementing the NGSI standard [8] for requesting, registering and subscribing to certain information, and by establishing data MEGA architecture is described in Figure 3. The proposed models with the goal of unifying the representation of the high-level model identifies three layers (from right to left): the information according to the scope it belongs. Subsystems layer, the Coordination layer and the Management In this sense, FI-Ware has proposed the following and Exploitation layer. These layers deal with a common Water categorization: Alarms, parks and gardens, environment, point of Management Model that is built based on two key elements: the interest, street lighting, civic Issue tracking, IoT Device Physical Model, which includes the component model, and the transportation, indicators, waste management, parking and Process Model. The water management model is the key element weather. for enabling MEGA to provide a common behavior framework. This way, by using this representation, as well as the NGSI Between the Subsystem layer and the Coordination layer there is a interface, all the information related to the above areas will be Coordination interface and between the Coordination and the represented the same way promoting and encouraging the Management and exploitation layer there is a Common interoperability and data exchange. Communication interface. The integration of IoT into the water management system 3.5 Conclusions could prove to be very beneficial for both information and It is clear that the large amount of IoT related ontologies only communication technologies (ICT) areas and their business. In the increases the difficulty of selecting a unique candidate to resolve rest of this section we analyse how IoT and Smart Environments all the vocabulary requirements that an organization or a system are defined, their key characteristics to understand how they can need. With this in mind, it is evident the need of creation a be used in the definition of the reference model for Smart Water standardized method to embrace all the vocabulary entities of a Management, taking advantage of the new advances in ICT precise environment. OCG models offers the necessary technologies, for creating feasible and commercial systems. interoperability and the FI-Ware establishes the formal specification of an open and reusable module. 4.1 Adapting IoT ontologies to MEGA In the next Sections, a first phase is described and a formal MEGA is based on a top-down model that tries to solve the development is defined within the region of Spain. basic problems of a water management system by separating it in several layers of control. This deployment is abstracted by the 4 STANDARDIZATION ON WATER- physical model to enable the interaction of the control model. ENERGY MANAGEMENT Besides, it allows an industrial management layer to define processes such as run water procedures and water supervision that As previously mentioned, Spanish government and more are executed in the physical layer. specifically Tragsa3, is endorsing a new model called MEGA to Physical entities, that can be unified in virtual entities by the overcome the problematics and to find new techniques of water coordination layer, are in charge of providing the interfaces and to management and optimization in Spain, but with a view of future verify the correct execution of the created recipes. In addition, this layer generates additional information that relayed in a 3 Tragsa is part of the group of companies of the State Industrial Ownership synchronous or asynchronous way help to inform the status and Corporation (SEPI) process of the system. 6 Adaptation of ontology sets for water related scenarios management SIS-IoT 2017, September 2016, Amsterdam, Netherlands All of this implies that defined processes are externalized in Following a top down approach, we establish FI-Ware the management layer that integrates and monitors the diverse business framework as the management component to provide the information such as meteorological information, energy business intelligence layer at the upper level. Service application consumption, costs, etc. and allowing the development of a more level is driven by normalized applications developed taking complex recipe (irrigation programs) parameterised by this advantage of the NGSI interface provided by FI-Ware, as well as additional information. the different enablers existent in this platform. This interface As more information is gathered, the system approaches a guarantees the interoperability with other platforms and systems more data centred system and recedes from original model. This is thanks to the NGSI standard interface adoption. This way, close to the IoT model as the devices, communications and MEGA, as any other third party platforms can be integrated by processed are similar to the concepts in the IoT environment. The using directly the NGSI interface, or by using the Generic use of an IoT ontology to match the MEGA model is a reasonable Enablers already developed for the purpose, or developing an own arrangement to achieve a more modern water management adapter for such a task. Such interoperability guarantees the system. correct and uniform exchange of information and even the One of the basic characteristics for the design of a new actuation over the deployed sensors devices. ontology is the reuse of existing ones. One of the future works The purpose of MEGA is to allow interoperability between the could be to define a semantic layer for the MEGA project partially different elements of an irrigation system improving the water- using other ontologies. energy savings and smart farm production. In order to guarantee At first glance, it can be considered that there is a subset of the interoperability and the exchange of standardized information, MEGA elements that can be modelled with FIESTA-IoT, the rest MEGA will be linked to different IoT ontologies defining possible of entities that cannot be modelled with FIESTA will try to actions that apply to each system element, both in the physical perform with other ontologies available in the market as SOSA. model and in the procedural model. One of the fundamental concepts to be added to the ontology At the same time, efforts are put on establishing a better should be the management of the irrigation programs (Recipe of adaptation with the studied ontologies that allow an adequate the MEGA model) that can be mapped with the classes: interoperability between different managed systems in Spain and sosa:Actuation and sosa:Actuator. Europe. An example of this is a first approximation of the main The work hypothesis would be to start with the interface concepts of the MEGA model with the classes of the ontologies, between the coordinator and the subsystems. One of the first steps which is presented in the Table 1. will be to match the classes defined in FIESTA-IoT with those To conclude, MEGA project can be expanded as the experts defined in the MEGA data model. incorporates new additional extensions to the original profiles. By combining several datasets in a centralized infrastructure, a global 5 ONGOING WORKS AND CONCLUSIONS and interoperable managed system can be deployed and it will be capable of establish the implementations between structures Integration works are in process of achieving a FI-Ware developed for management and control of irrigation facilities. In compatible platform that enables their interoperability abilities this way, the standard can be applied under any technological along with the previously MEGA development. In order to platform in any type of irrigation system, regardless of the water summarize the relationships between the MEGA model and the management scheme (public or private, individual or collective). FI-Ware structure, Figure 4 resumes the interactions of the existing MEGA project with the FI-Ware components. ACKNOWLEDGMENTS This work was partially supported with the financial support of the research project FEDER 14-20-15 (Design and implementation of spatial data infrastructure on agriculture and water in the Murcia Region - IDEaRM), 80% co-funded by the European Regional Development Fund (ERDF). “A way to build Europe” and the financial support of the research Project INTERNET OF THINGS @ AGRO SPACES Programa FEDER INNTERCONECTA (EXP 00091605 / ITC-2016-20-45) and by the Ministry of Economy and Competitiveness through SEMOLA project (TEC2015-68284-R) and through the TORRES QUEVEDO Project granted to Odin Solutions S.L. with the reference PTQ-15-08073 . Figure 4: FI-Ware & MEGA interaction model 7 Table 1: Mega ontology model comparison Concept MEGA SSN IoT-Lite FIESTA-IoT SOSA Hydraulic element of the Entity Device / System Entity Device / Sensor Sensor / Platform physical model /Deployment Detectable event Event Not considered Not considered Not considered Not considered Run the defined process of Procedure Process Not considered Observation Procedure the process model Allow to execute the process Unit Not considered Not considered Not considered Not considered step defined procedure Run part of a process step Operation OperationProperty Not considered Not considered Actuation Attribute that defines an Property Property Attribute Attribute ActuableProperty entity Way of describing a process Recipe Event ActuatingDevice ActuatingDevice Actuator and runs Parameter [14] Suárez-Figueroa, Mari Carmen (2010). NeOn Methodology for Building REFERENCES Ontology Networks: Specification, Scheduling and Reuse. Tesis (Doctoral), [1] MEGA: developed by TRAGSA and MAPAMA. ISO 21622. Remote Facultad de Informática (UPM) [antigua denominación] Monitoring and Control for Irrigation Systems . http://www.gestiondelagua.es/en/ [15] https://www.irit.fr/recherches/MELODI/ontologies/IoT-O.html [2] Robles, T., Alcarria, R., Martín, D., Morales, A., Navarro, M., Calero, R., ... & López, M. (2014, May). An internet of things-based model for smart water [16] http: //elite.polito. It / ontologies / poweront.owl management. In Advanced Information Networking and Applications Workshops (WAINA), 2014 28th International Conference on (pp. 821-826). [17] https://itea3.org/project/water-m.html IEEE [3] A. Gyrard, C. Bonnet, K. Boudaoud and M. Serrano, "LOV4IoT: A Second Life for Ontology-Based Domain Knowledge to Build Semantic Web of Things Applications," 2016 IEEE 4th International Conference on Future Internet of Things and Cloud (FiCloud), Vienna, 2016, pp. 254-261. [4] Alcarria, R., Martín, D., Robles, T., & Sánchez-Picot, Á. (2016). Enabling Efficient Service Distribution using Process Model Transformations. International Journal of Data Warehousing and Mining (IJDWM), 12(1), 1-19. [5] «OGC Sensor Web Enablement Architecture: Version 0.4.0». Wayland, MA, OGC. Document No. 06- 021r4 [6] Robin A., «SWE Common Data Model, Encoding Standard, Version 2.0 (OGC 08-094r1)». Wayland, MA, USA, Open Geospatial Consortium Inc [7] «Web de SensorThings». [en línea], http://github.com/opengeospatial/sensorthings. [8] https://www.fiware.org/category/ngsi/ Bordel, B., Alcarria, R., Martín, D., Robles, T., & de Rivera, D. S. (2016). Self- configuration in humanized cyber-physical systems. Journal of Ambient Intelligence and Humanized Computing, 1-12. [10] Gyrard, A., Serrano, M., & Atemezing, G. A. (2015, December). Semantic web methodologies, best practices and ontology engineering applied to Internet of Things. In Internet of Things (WF-IoT), 2015 IEEE 2nd World Forum on (pp. 412-417). IEEE [11] Bermudez-Edo, M., Elsaleh, T., Barnaghi, P., & Taylor, K. (2016, July). IoT- Lite: a lightweight semantic model for the Internet of Things. In Ubiquitous Intelligence & Computing, Advanced and Trusted Computing, Scalable Computing and Communications, Cloud and Big Data Computing, Internet of People, and Smart World Congress (UIC/ATC/ScalCom/CBDCom/IoP/SmartWorld), 2016 Intl IEEE Conferences (pp. 90-97). IEEE [12] Compton, M., Barnaghi, P., Bermudez, L., GarcíA-Castro, R., Corcho, O., Cox, S., ... & Huang, V. (2012). The SSN ontology of the W3C semantic sensor network incubator group. Web semantics: science, services and agents on the World Wide Web, 17, 25-32. [13] Chau, K. W. (2007). An ontology-based knowledge management system for flow and water quality modeling. Advances in Engineering Software, 38(3), 172-181.