data or resources (metadata). In fact, Linked Data incorporates human and machinereadable metadata along with it, making it self-describing [6]. Moreover, RDF, the underlying standard for Linked Data interchange and query, was originally developed in the 1990s with the emphasis on the representation of metadata about Web resources; however later the vision of the Semantic Web was extended to the representation of semantic information in general, beyond simple RDF descriptions and Web documents as primary subjects of such descriptions [5], which provided the ground for the creation of the Linked Data initiative later on.

In the following, we discuss more in detail metadata, with focus on agriculture and other bio-sectors, followed by more technical information on Linked Data and related best practices. Next, we present different usage scenarios and experiences of using Linked Data in DataBio.

#### **7.2 Metadata**

Metadata is, as its name implies, data about data. It describes the properties of a dataset or resource. Metadata can cover various types of information, which according to [7], can be coarsely categorized into three categories: (i) *descriptive metadata* includes elements such as the title, abstract, author, and keywords, and is mostly used to discover and identify a dataset or another resource; (ii) *structural metadata*, which indicates how compound objects are put together (logical or physical relationships between objects and their parts); and (iii) *administrative metadata* with elements such as the license, intellectual property rights, when and how the dataset was created, who can access it, etc. Datasets in agriculture are either added locally, by a user, harvested from existing data portals, or fetched from operational systems or IoT ecosystems. The definition of a set of metadata elements is necessary to allow identification of the vast amount of information resources managed for which metadata is created, its classification and identification of its geographic location and temporal reference, quality and validity, conformity with implementing rules on the interoperability of spatial data sets and services, constraints related to access and use, and organization responsible for the resource.

Metadata of datasets and dataset series (particularly relevant for agriculture are the EO products derived from satellite imagery) should adhere to the INSPIRE Metadata Regulation5 with added theme-specific metadata elements for the agriculture, forestry and fishery domains if necessary. This approach will ensure that metadata created for the datasets, dataset series and services will be compliant with the INSPIRE requirements as well as with international standards.6, 7, 8 In addition, INSPIRE conformant metadata may be expressed also through the *DCAT* Application Profile,9 which defines a minimum set of metadata elements to ensure cross-domain and cross-border interoperability between metadata schemas used in European data portals. Such a mapping could support the inclusion of INSPIRE metadata10 in the Pan-European Open Data Portal11 for wider discovery across sectors beyond the geospatial domain.

A *Distribution* represents a way in which the data is made available. DCAT is a rather small vocabulary, which strategically leaves many details open as it welcomes "application profiles": more specific specifications built on top of DCAT12, e.g., GeoDCAT-AP13 as a geospatial extension. For sensors there is also SensorML14, a standard which can be used to describe a wide range of sensors, including both

5 https://inspire.ec.europa.eu/metadata/6541.

6 https://www.iso.org/standard/39229.html.

7 https://www.iso.org/standard/32557.html.

8 https://docs.opengeospatial.org/is/10-157r4/10-157r4.html.

9 https://joinup.ec.europa.eu/asset/dcat\_application\_profile/description.

10 https://inspire.ec.europa.eu/metadata/6541.

11 https://www.europeandataportal.eu/en/homepage.

12 https://www.w3.org/TR/vocab-dcat-2/.

13 https://inspire.ec.europa.eu/good-practice/geodcat-ap.

14 https://opengeospatial.org/standards/sensorml.

dynamic and stationary platforms and both in situ and remote sensors. Another possibility is Semantic Sensor Network Ontology15, which describes sensors and observations, and related concepts. It does not describe domain concepts, time, locations, etc.; these are intended to be included from other ontologies via OWL imports. This ontology is developed by the W3C Semantic Sensor Networks Incubator Group (SSN-XG).16

There is a need for metadata harmonization of the spatial and non-spatial datasets and services. GeoDCAT-AP is an obvious choice due to the strong focus on geographic datasets. The main advantage is that it enables users to query all geospatial datasets in a uniform way. GeoDCAT-AP is still very new, and the implementation of the new standard can provide feedback to OGC, W3C & JRC from both technical and end user point of view. Several software components are available in the DataBio architecture that have varying support for GeoDCAT-AP, being Micka17, CKAN18 [3], FedEO Gateway & Catalog19, and GeoNetwork20 [4]. For the DataBio purposes we also had to integrate Semantic Sensor Net Ontology and SensorML.

For enabling compatibility with COPERNICUS21, INSPIRE22, and GEOSS23, the DataBio project made three extensions: (i) Module for extended harvesting INSPIRE metadata to DCAT, based on XSLT and easy configuration; (ii) Module for user friendly visualisation of INSPIRE metadata in CKAN; and (iii) Module to output metadata in GeoDCAT-AP respectively SensorDCAT. DataBio used Micka and CKAN systems. Micka is a complex system for metadata management used for building Spatial Data Infrastructure (SDI) and geoportal solutions. It contains tools for editing and management of spatial data, and services metadata as well as other sources (documents, websites, etc.). Micka also fully supports GeoDCAT-AP and Open Search. CKAN supports DCAT to import or export its datasets. CKAN enables harvesting data from OGC:CSW catalogues, but not all mandatory INSPIRE metadata elements are supported. Unfortunately, the DCAT output does not fulfil all INSPIRE requirements, nor is GeoDCAT-AP fully supported.

For data identification, naming, and search keywords we used the INSPIRE data registry.24 The INSPIRE infrastructure involves a number of items, which require clear descriptions and the possibility to be referenced through unique identifiers. Examples of such items include INSPIRE themes, code lists, application schemas or discovery services. Registers provide a means to assign identifiers to items and their labels, definitions and descriptions (in different languages). The INSPIRE Registry is

15 https://www.w3.org/TR/vocab-ssn/.

16 https://www.w3.org/2005/Incubator/ssn/.

17 http://micka.bnhelp.cz/.

18 https://ckan.org/.

19 http://ceos.org/ourwork/workinggroups/wgiss/access/fedeo/.

20 http://geonetwork-opensource.org/.

21 https://www.copernicus.eu/en.

22 https://inspire.ec.europa.eu/.

23 https://www.earthobservations.org/geoss.php.

24 http://inspire.ec.europa.eu/registry.

a service giving access to INSPIRE semantic assets (e.g. application schemas, codelists, themes), and assigning to each of them a persistent URI. As such, this service can be considered also as a metadata directory/catalogue for INSPIRE, as well as a registry for the INSPIRE "terminology". Starting from June 2013, when the INSPIRE Registry was first published, several versions have been released, implementing new features based on the community's feedback.

Also important is *data lineage*, which refers to the sources of information, such as entities and processes, involved in producing or delivering an artifact. Data lineage records the derivation history of a data product. The history could include the algorithms used, the process steps taken, the computing environment run, data sources input to the processes, the organization/person responsible for the product, etc.*Provenance* provides important information to data users for them to determine the usability and reliability of the product. In the science domain, the data provenance is especially important since scientists need to use the information to determine the scientific validity of a data product and to decide if such a product can be used as the basis for further scientific analysis.

#### **7.3 Linked Data**

As noted above, Linked Data refers to a set of best practices for publishing and interlinking structured data thereby enabling it to be accessed by both humans and machines. The data interchange follows the RDF family of standards and SPARQL is used for querying. In particular, the key concepts and technologies that support Linked Data are:

More in detail, RDF expresses data as *triples* of the form < subject, predicate, object > . A triple encodes the relation of the object to the subject through the predicate. The subject is a URI, or more generally Internationalized Resource Identifier (IRI), which, as specified above, identifies a resource or a concept; the object may be either a literal e.g. number, string, date, or a URI which references another resource. Triples which interlink resources constitute RDF links, which construct the Web of Data.

#### **7.4 Linked Data Best Practices**

The growing popularity of Linked Data has led to the definition of more detailed guidelines for the development and delivery of (open) data as linked data. For instance, for open government (also applicable for LOD and the bioeconomic sector) data, the following best practices are recommended [8]:

It is important to note that although these best practices were conceived for open government data, they can be applied in most cases to many other domains.

To help prepare stakeholders, there are at least three well known lifecycle models (Hyland et al. [8], Hausenblas [9], Villazón-Terrazas et al. [10]) describing the process for publishing linked data. All of these models identify common needs of specifying, modelling and publishing data in the standard open Web format (https://www.databio.eu/wp-content/uploads/2017/05/Dat aBio\_D4.3-Data-sets-formats-and-models\_public-version.pdf, https://www.google. ca/search?q=%22standard+open+web+format%22). However even though all of the models somewhat deal with similar tasks, they have some differences between those tasks. To discuss more in detail the above mentioned tasks, we will focus on one of these models as their roles are similar and complementary. For the sake of consideration, Villazón-Terrazas et al. [10] has the following sub-tasks for each step:

	- Identification and analysis of the data sources by opening and publishing the data that have not yet opened up and published and by reusing or leveraging the data that had already been opened/published up by others. This may require contacting specific data owners to get access to their legacy data.
	- Ontologies ideally are expressed in OWL or RDF(S) both being based on RDF.
	- Reusing the existing and available vocabularies.
	- Reusing the available non-ontological resources like highly reliable websites, domain related sites, government catalogs etc.
	- Transformation of the data sources selected in the specification activity into RDF according to the vocabulary created in the modelling activity by using tools like CSV and spreadsheets, RDB or XML.
	- Data cleansing involves the finding and fixing of the possible errors specified in Hogan et al. which includes http-level issues, such as accessibility and dereferencability, reasoning issues such as namespace without vocabulary and malformed/incompatible data types.
	- Linking suitable datasets and discovering suitable relationships between the data items and validate the relationships discovered.
	- Dataset publication by using tools for storing RDF (e.g. Virtuoso Universal Server, Jena, Sesame, 4Store, YARS, OWLIM etc.) using SPARQL endpoint and Linked Data front end (e.g. Pubby, Talis Platform, Fuseki)
	- Metadata publication using VoID, which allows to express metadata about RDF datasets and by OPM (Open Provenance Model).
	- Dataset discovery by registering the datasets in the CKAN registry and generating sitemap files for the dataset, by using sitemap4rdf.25

25 http://mayor2.dia.fi.upm.es/oeg-upm/index.php/en/technologies/122-sitemap4rdf/index.html.

#### **7.5 The Linked Open Data (LOD) Cloud**

The LOD cloud comprises 1,255 datasets with 16,174 links (as of May 2020). Nevertheless, although large cross-domains datasets exist (like DBpedia26 or Wikidata27) and some domains are well covered, like Geography, Government, and Bioinformatics, this is still not the case for all domains. For instance, in the agriculture domain we can find relevant thesaurus like AGROVOC28 from FAO29, or the National Agricultural Library's Agricultural Thesaurus (NALT),30 but there is still a lack of datasets related to agricultural facilities and farm management activities. A similar situation occurs in the fishery domain where only some taxonomies for specific types of fish or regions are available, but no catching data exists, including, for example, locations, quantities, values, equipment used, vessels used, etc. This is also true in the forestry domain, where almost no specific Open Linked Data is available. This is in part due to the lack of standardized models for the representation of such data, even though some efforts in this direction have been made in the past, as discussed below.

FOODIE project,31 for instance, addressed this issue for the agriculture domain with the development of the FOODIE data model32 [11], which was reused and extended in the DataBio project. To ensure the maximum degree of data interoperability, the model is based on INSPIRE generic data models, specially the data model for Agricultural and Aquaculture Facilities (AF), which is extended and specialized. In particular, the model was created based on AF version 1.0, and thus it was found that there was a lack of a concept for an entity of finer granularity than *Site* that was part of the INSPIRE AF.33 The key motivation was to represent a continuous area of agricultural land with one type of crop species, cultivated by one user using one farming mode (conventional vs. transitional vs. organic farming). Such a concept is called *Plot* and represents the main element in the model, especially because it is the level to which the majority of agro data is related. One level lower than *Plot* is the *ManagementZone*, which enables a more precise description of the land characteristics in fine-grained areas. Additionally, the FOODIE model includes concepts for crop and soil data, treatments, interventions, agriculture machinery, etc. Furthermore, the model reuses data types defined in ISO standards (ISO 19101, ISO/TS 19103, ISO 8601 and ISO 19115) as well standardization efforts published under the INSPIRE Directive34 (like the structure of unique identifiers). The model was consulted with several experts from various institutions like the Directorate General

26 https://wiki.dbpedia.org/.

27 https://www.wikidata.org/wiki/Wikidata:Main\_Page.

28 http://aims.fao.org/vest-registry/vocabularies/agrovoc.

29 http://www.fao.org/home/en/.

30 http://aims.fao.org/news/nal-thesaurus-now-available-linked-open-data.

31 http://www.foodie-project.eu/.

32 https://github.com/Wirelessinfo/FOODIE-data-model.

33 http://inspire.ec.europa.eu/theme/af.

34 https://inspire.ec.europa.eu/inspire-directive/2.

Joint Research Centre (DG JRC) of the EU Commission, the EU Global Navigation Satellite Systems Agency (GSA), Czech Ministry of Agriculture, Global Earth Observation System of Systems (GEOSS), or the German Kuratorium für Technik und Bauwesen in der Landwirtschaft (KTBL). FOODIE data model was specified in Unified Modeling Language (UML) (as the INSPIRE models), but describes the process followed to transform this model into an OWL ontology in order to enable the publication of linked agricultural data [12]. FOODIE ontology follows a modular approach. Thus, while the core ontology includes all elements common to different applications, the ontology can be further specialized with profiles for a particular application or country needs. In the DataBio project, for example, the FOODIE ontology was reused in several agriculture pilots, which resulted in the addition of several new elements in the core, and with the creation of extensions for the specific needs of the pilot.

Regarding the fishery domain, there have been also some previous efforts to fill this standard model gap. For instance, in NeOn project, FAO produced a network of fisheries ontologies35 that included a catch record pattern, water areas (e.g. FAO division areas), species taxonomic classifications, fisheries commodities, vessels classifications, gear classifications, etc. Unfortunately, the work did not continue and many of these resources are no longer available. Nevertheless, in the DataBio project, some of these resources were reused when possible (e.g. catch pattern, species taxonomy), some others were re-created with further detail (e.g. water areas), and some new extensions were created to cover specific pilot needs in order to publish linked fishery data from them.

#### **7.6 Enterprise Linked Data (LED)**

Although Linked Data is mostly known and used to publish open data, and to link different open datasets, the underlying technologies and approach can also be applied in a (partially) closed setting, e.g. an enterprise, where potentially some data cannot be made openly available - this is especially relevant for all sectors of Bioeconomy with sensitive and geo-based data. In fact, even if the enterprise data remains closed, or accessible only via access control mechanisms to selected parties, it can still be linked with open data, and get all the benefits from that.

According to [11], Linked Enterprise Data (LED) meshes each and every enterprise data (e.g. structured records, documents or office files), wherever they come from, to create a global and unified information space from which new business information is created to solve operational needs. Hence, it federates the content of heterogeneous silos by interconnecting the data and creates a unified and coherent warehouse, called an information hub, that exposes and shares new knowledge objects [13]. Besides, as it follows the same standards, links can be established with other datasets, either internal or external (e.g. LOD).

35 http://aims.fao.org/network-fisheries-ontologies.

#### 7 Linked Data and Metadata 89

In order to restrict the access to internal data, LED must be used in combination with access control mechanisms enabling compliance with privacy and security constraints, as described in the next section. Regarding security of the stored RDF data, one of the most typical approaches to control the access to the data is by using different RDF graphs for the restricted datasets. An RDF graph is a set of RDF triples, normally identified by an IRI, which can be assigned different access control policies.

For instance, Virtuoso, the RDF store used in the DataBio project, features SPARQL endpoints, which are Web services capable of providing more than Read-Only access to back-end graphs. So, even though they are commonly general-purpose, SPARQL endpoints can also be purpose-specific, and their privileges may, therefore, be limited to specific Create, Read, Update, and/or Delete operations. The privileges provided by a given Virtuoso SPARQL endpoint may be based simply upon the endpoint's URL, or upon sophisticated rules which associate specific user identities with specific database roles and privileges. Virtuoso offers three methods for securing SPARQL endpoints:

In the DataBio project, the first method was tested in order to restrict access to some of the pilot datasets. In particular, the process of setting up a secure Virtuoso SPARQL endpoint using the method of Digest Authentication via SQL Accounts is as follows:

	- User can only READ but not WRITE from the personal system data graph.
	- User can both READ and WRITE from the personal system data graph.
	- Grant specific privileges on specific graph to public where the graphs (e.g. dbpedia.org) are intended for public consumption for:

READ but not WRITE; READ and WRITE.

#### **References**

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

## **Chapter 8 Linked Data Usages in DataBio**

**Raul Palma, Soumya Brahma, Christian Zinke-Wehlmann, Amit Kirschenbaum, Karel Charvát, Karel Charvat Jr., and Tomas Reznik**

**Abstract** One of the main goals of DataBio was the provision of solutions for big data management enabling, among others, the harmonisation and integration of a large variety of data generated and collected through various applications, services and devices. The DataBio approach to deliver such capabilities was based on the use of Linked Data as a federated layer to provide an integrated view over (initially) disconnected and heterogeneous datasets. The large amount of data sources, ranging from mostly static to highly dynamic, led to the design and implementation of Linked Data Pipelines. The goal of these pipelines is to automate as much as possible the process to transform and publish different input datasets as Linked Data. In this chapter, we describe these pipelines and how they were applied to support different uses cases in the project, including the tools and methods used to implement them.

#### **8.1 Introduction**

Linked Data has been extensively used in the DataBio project as a federated layer to support large-scale harmonization and integration of a large variety of data collected from various heterogeneous sources and to provide an integrated view on them. Accordingly, as part of the project, we generated a large number of linked datasets. In fact, the triplestore populated during the course of DataBio with Linked Data has over 1 billion triples, being one of the largest semantic repositories related to agriculture. The dataset has been recognized by the EC Innovation Radar as 'arable farming data integrator for smart farming.' In addition, we have deployed different

Poznan Supercomputing and Networking Center (PSNC), ul. Jana Pawła II 10, 61-139 Poznan, Poland

e-mail<EMAIL_ADDRESS>
C. Zinke-Wehlmann · A. Kirschenbaum

R. Palma (B) · S. Brahma

Institute for Applied Informatics (InfAI), University of Leipzig, Goerdelerring 9, 04109 Leipzig, Germany

K. Charvát · K. Charvat Jr. · T. Reznik Lesprojekt Služby Ltd., Martinov 197, 27713 Záryby, Czech Republic

endpoints providing access to some dynamic data sources in their native format as Linked Data by providing a virtual semantic layer on top of them.

Given the huge number of data sources, and data formats that were addressed during the course of DataBio, such layer has been realized in DataBio through the implementation of instantiations of a 'Generic Pipeline for the Publication and Integration of Linked Data,' which have been applied in different uses cases related to the bioeconomy sectors. The main goal of these pipeline instances is to define and deploy (semi-) automatic processes to carry out the necessary steps to transform and publish different input datasets as Linked Data. Accordingly, they connect different data processing components to carry out the transformation of data into RDF [1] format or the translation of queries to/from SPARQL [2] and the native data access interface, plus their linking, and include the mapping specifications to process the input datasets. Each pipeline instance is configured to support specific input dataset types (same format, model and delivery form), and they are created with the following general principles in mind:

Most of the Linked Data Publication pipeline instances discussed in this chapter perform the transformation and publication of agricultural data as Linked Data; however, there are also some pipelines that are focused on fishery data or on providing access to geospatial datasets metadata as Linked Data. The ultimate target is to query and access different heterogeneous data sources via an integrated layer, in compliance with any privacy and access control needs.

A high-level view of the end-to-end flow of the generic pipeline, aligned with the top-level DataBio generic pipeline, is depicted in Fig. 8.1. Following the best practices and guidelines for Linked Data Publication [3, 4], these pipelines (i) take as input selected datasets that are collected from heterogeneous sources (shapefiles, GeoJSON, CSV, relational databases, RESTful APIs), (ii) curate and/or preprocess the datasets when needed, (iii) select and/or create/extend the vocabularies (e.g., ontologies) for the representation of data in semantic format, (iv) process and transform the datasets into RDF triples according to underlying ontologies, (v) perform any necessary post-processing operations on the RDF data, (vi) identify links with other datasets and (vii) publish the generated datasets as Linked Data and applying required access control mechanisms. The transformation process depends on different aspects of the data like format of the available input data, the purpose (target use case) of the transformation and the volatility of the data (how dynamic is the data). Based on these characteristics, there are two main approaches for making

**Fig. 8.1** Generic flow for Linked Data integration and publication pipeline aligned with top-level generic pipeline

the transformation for a dataset: (i) data upgrade or lifting, which consists of generating RDF data from the source dataset according to mapping descriptions and then storing it in semantic triplestore (e.g., Virtuoso) and (ii) on-the-fly query transformation, which allows evaluating SPARQL queries over a virtual RDF dataset, by rewriting those queries into source query language according to the mapping descriptions. In this former scenario, data physically stays at their source and a new layer is provided to enable access to it over the virtual RDF dataset.

In every transformation process, regardless of the method or tools chosen, a mapping specification has to be defined to specify the rules to map the source elements (e.g., table columns, JSON elements, CSV columns, etc.) into target elements (e.g., ontology terms). Generally, this specification is an RDF document itself written in RML1/R2RML2 (and extensions) languages and/or nonstandard extensions of SPARQL, e.g., in the case of the Tarql CSV to RDF transformation tool.3

The resulting datasets can thereafter be exploited through SPARQL queries, or via a plethora of user interfaces. Some examples of these interfaces include:

1 https://rml.io/specs/rml/.

2 https://www.w3.org/TR/r2rml/.

3 https://tarql.github.io/.

**Fig. 8.2** Generic Linked Data Publication pipeline component view diagram

• Metaphactory: http://metaphactory.foodie-cloud.org/resource/Start.

The following diagram (Fig. 8.2) provides a simplified representation of the generic Linked Data Publication pipeline component view that includes the software components and interfaces involved. More information is available in [5, 6].

The URL link of the generic pipeline in the DataBioHub is https://mub.me/2f81.

#### **8.2 Linked Data Pipeline Instantiations in DataBio**

The Linked Data Pipeline, as described in the previous section, is a generalization of multiple instantiations, in particular two specific project's pilots and four additional experiments in DataBio. Thus, in order to show how this generic pipeline has been applied in each of these use cases, we present in this section for each of them the pipeline view, previously presented in [5], highlighting the specific methods and components used/applied, along with a description of the task performed and results achieved.

#### *8.2.1 Linked Data in Agriculture Related to Cereals and Biomass Crops*

This pipeline instance was focused toward publication of INSPIRE-based agricultural Linked Data from the farm data collected from cereals and biomass crop pilots, in order to query and access different heterogeneous data sources via an integrated layer. The input datasets used for this experiment include:

The source datasets, collected as shapefiles, were transformed into RDF format and published as Linked Data, using the FOODIE ontology as the underlying model. The resulting linked datasets are available for querying and exploitation through the DataBio SPARQL endpoint deployed at PSNC' HPC facilities. More in detail, the tasks carried out are as follows:

**Fig. 8.3** Mapping of the generic components into cereals and biomass crop pilots in the pipeline view

Please refer to Section 'Usage and Exploitation of Linked Data' for additional information of other visualization components.

The resulting linked datasets are accessible via: https://www.foodie-cloud.org/ sparql. A figure that maps the generic components identified in this pilot is given below (Fig. 8.3). The red highlighted markings indicate the components in use in the pilot.

#### *8.2.2 Linked Sensor Data from Machinery Management*

This pipeline was performed for the machinery management DataBio pilot, where sensor data from the SensLog service (used by FarmTelemeter service) was transformed into Linked Data on the fly; i.e., data stays at the source, and only a virtual semantic layer was created on top of it to access it as Linked Data. For modeling the sensor data, the following vocabularies/ontologies were selected:

4 https://www.w3.org/TR/vocab-ssn/.

includes well-known RDF vocabularies (SKOS,5 SCOVO,6 VOID, FOAF,7 Dublin Core8).

The SensLog service uses a relational database (PostgreSQL) to store the data. Hence, in the mapping stage, the creation of R2RML/RML definitions required different preprocessing tasks and some on-the-fly assumptions to engineer the alignment between the SensLog database and the ontologies/vocabularies.

Once the mapping file was generated (manually), the RDF data of the dataset was published using a D2RQ server that enables accessing relational database sources as virtual RDF graphs. This on-the-fly approach allows publishing of RDF data from large and/or live databases, and thus the need for replicating the data into a dedicated RDF triple store is not required. The Linked Data from the sensor data from SensLog (version 1) was published in the PSNC infrastructure in a D2RQ server available at http://senslogrdf.foodie-cloud.org/. The associated SPARQL endpoint to query the data is available at: http://senslogrdf.foodie-cloud.org/sparql.

The figure below (Fig. 8.4) highlights the main components used in this pilot from the generic pipeline components.

**Fig. 8.4** Mapping of the generic components into machinery management pilot in the pipeline view

5 https://www.w3.org/TR/skos-reference/.

6 http://vocab.deri.ie/scovo.

7 http://www.foaf-project.org/.

8 https://www.dublincore.org/specifications/dublin-core/dces/.

#### *8.2.3 Linked Open EU-Datasets Related to Agriculture and Other Bio Sectors*

This pipeline focuses on EU and national open data from various heterogeneous sources from a wide range of applications in the geospatial domain. The purpose was to experiment on these datasets by transforming them into Linked Data and exploiting them on various technology platforms for integration and visualization. The sources for all of these data contents are widely heterogeneous and in various forms (e.g., in shapefiles, CSV format, JSON and in relational databases), which required extensive work to identify the most suitable mode for their transformation. This included a careful inspection of the input data contents in order to identify available ontologies/vocabularies, and any required extensions, necessary for the representation of such data in RDF format. Additionally, since the source datasets were in different formats, selecting the most suitable tools for their transformation was a key activity in order to create the correct (R2RML/RML) mapping definitions. Some of the input datasets, their formats and the ontologies/vocabularies used for the representation of data in semantic format are described below.

9 https://ec.europa.eu/agriculture/rica/.

10 https://vocab.org/review/.

**Fig. 8.5** Mapping of the components used in the use case of linked open EU-datasets in the pipeline view

The generation of RDF triples was carried out using different tools (depending on the source dataset format). For shapefiles, GeoTriples tool was used, while for the JSON and CSV data the RML processor tool was used. The resulting RDF datasets were then loaded into DataBio Virtuoso triplestore providing SPARQL and faceted search endpoints for further exploitation. Finally, for the provision of an integrated view over the original datasets in case of agricultural and open data, SPARQL queries were generated and additional links were discovered using tools like SILK. For visualization, platforms like HS Layers NG and Metaphactory were used as discussed in Chap. 13.

The resulting linked datasets are accessible via: https://www.foodie-cloud.org/ sparql. The figure below (Fig. 8.5) highlights the main components used in this pilot from the generic pipeline components.

#### *8.2.4 Linked (Meta) Data of Geospatial Datasets*

This pipeline focuses on the publication of metadata from geospatial datasets as Linked Data. There were two data sources that were transformed.

The first dataset was metadata collected from the public Lesproject Micka registry,11 which includes information of over 100 K geospatial datasets. Micka is a software for spatial data/services metadata management according to ISO, OGC and

11 https://micka.lesprojekt.cz/en/.

INSPIRE standards, and it allows to retrieve the metadata in RDF using Geo-DCAT12 for the representation of geographic metadata compliant with the DCAT application profile for European data portals. Nevertheless, such metadata cannot be queried as Linked Data, and thus the goal was to make it available in this form in order to enable its integration with other datasets, e.g., Open Land Use (OLU). The process for publication, thus, was straightforward: A dump of all the metadata in RDF format was generated from Micka, which was then loaded into DataBio Virtuoso triplestore. Some example SPARQL queries were then generated to identify connection points for integration, e.g., get OLU entries and their metadata given a municipal code and type of area (e.g., agriculture lands). The dataset is accessible via: https://www.foo die-cloud.org/sparql.

The second dataset was more challenging. The goal was to make Earth Observation (EO) Collections and EO Products metadata available as Linked Data via a SPARQL compliant endpoint which makes requests to non-SPARQL back ends on the fly. Hence, we wanted to enable querying via SPARQL without harvesting all the metadata and storing the data in a triplestore but access them dynamically via the existing online interfaces. The metadata was accessible via an OpenSearch interface provided by the FedEO13 Clearinghouse in Spacebel (http://geo.spacebel.be/opense arch/readme.html) that enables retrieving the metadata in different formats, including atom/xml, RDF/xml, turtle, GeoJSON and LD-JSON. We used LD-JSON, which already defines the semantic properties used to represent the metadata elements. These properties comprise terms from different standard and well-known vocabularies/ontologies like Dublin Core, DCAT, SKOS, VOID and OM-Lite-lite, as well as from the OpenSearch specifications. Next, in order to enable access to a REST API via SPARQL queries that would allow linking with other Linked Datasets we used the Metaphactory platform. Metaphactory (https://www.metaphacts.com/pro duct) includes a component called Ephedra, which is a SPARQL federation engine aimed at processing hybrid queries. Ephedra provides a flexible declarative mechanism for including hybrid services into a SPARQL federation and implements a number of static and runtime query optimization techniques for improving the hybrid SPARQL query performance [8]. The RDF data is exposed via a SPARQL endpoint provided in the Metaphactory platform (http://metaphactory.foodie-cloud. org/sparql?repository=ephedra). A demo interface has also been implemented to visualize the Linked Data in Metaphactory (entry point: http://metaphactory.foodiecloud.org/resource/:ESA-datasets).

The figure below (Fig. 8.6) highlights the main components used in this pilot from the generic pipeline components. In the figure, the components related to the first sub-case (Micka) are highlighted in green, while the components related to the second sub-case (FedEO) are highlighted in orange.

12 https://ec.europa.eu/jrc/en/publication/geodcat-ap-representing-geographic-metadata-usingdcat-application-profile-data-portals-europe.

13 http://ceos.org/ourwork/workinggroups/wgiss/access/fedeo/.

**Fig. 8.6** Mapping of the components used in the use case of linked (meta) data of geospatial datasets in the pipeline view. The components related to the first sub-case (Micka) are highlighted in green, while the components related to the second sub-case (FedEO) are highlighted in orange

#### *8.2.5 Linked Fishery Data*

This pipeline focuses on the catch record data from the fisheries of Norwegian region. The purpose of this pipeline was to publish the catch record data from five years of historical data as Linked Data and perform experimentation operations to exploit and visualize them on various platforms. The input data was in the form of CSV files containing the catch record data of each year.

14 http://www.ontologydesignpatterns.org/cp/owl/fsdas/catchrecord.owl.

**Fig. 8.7** Mapping of the components used in the fishery use case in the pipeline view

• At present, the catch data from five years was transformed and uploaded to the Virtuoso triplestore providing SPARQL and faceted search endpoints for further exploitation.

For the purpose of showcasing the integration and visualization of the dataset, a Web interface using the Metaphactory platform was created, which includes map visualizations and representation of data in the form of charts and graphs. This process is ongoing, and more experimentations are to come by. The interface is presently available at http://metaphactory.foodie-cloud.org/resource/:CatchDataNor way\_v2. The resulting linked datasets are accessible via: https://www.foodie-cloud. org/sparql and https://www.foodie-cloud.org/fct.

The figure below (Fig. 8.7) highlights the main components used in this use case from the generic pipeline components.

#### **8.3 Experiences from DataBio with Linked Data**

#### *8.3.1 Usage and Exploitation of Linked Data*

The pipelines used in DataBio are part of an ongoing process and yet to be tested on other use cases and input data types. For example, as a result of the pipelines involving the LPIS and Czech field data, it was possible to perform integration experiments of the dataset for various use case scenarios of data integration.

As mentioned above, the datasets are deployed in the Virtuoso triplestore within PSNC and can be accessed via SPARQL and faceted search endpoints. The triplestore has **over 1 billion triples**, making it one of the largest semantic repositories related to agriculture.

The data in the triplestore is partitioned/organized into *named graphs*, where each named graph describes different contents and is identified by an IRI.

For example, the IRI <http://w3id.org/foodie/open/africa/GRIP> is the graph identifier of the African Roads Network dataset, which contains 27,586,675 triples.

Named graphs may be further composed of named subgraphs, as it is the case of the LPIS Poland dataset, which provides information about land-parcel identification in Poland, identified by the graph <http://w3id.org/foodie/open/pl/LPIS/>, and contains 727,517,039 triples. This graph contains, for example, the subgraph <http://w3id.org/ foodie/open/pl/LPIS/lubelskie>, which refers to the data associated with the Lublin Voivodeship.

The table below shows some of the respective graphs produced by all the pipelines previously described and the number of triples contained in them.

#### (continued)

#### (continued)

```
(continued)
```

The official SPARQL and the faceted search endpoints of the triplestore are: https://www.foodie-cloud.org/sparql (Fig. 8.8) and https://www.foodie-cloud.org/fct

**Fig. 8.8** SPARQL endpoint user interface (query and extract of result)

(Fig. 8.9).

Regarding the sensor data described in Sect. 1.3.2, it is published on the fly which serves the purpose of streaming transformation. This data can be accessed and linked through the following endpoints:

SPARQL endpoint: http://senslogrdf.foodie-cloud.org/sparql SNORQL search endpoint: http://senslogrdf.foodie-cloud.org/snorql/ Web-based visualization: http://senslogrdf.foodie-cloud.org/ (see Fig. 8.10).

#### *8.3.2 Experiences in the Agricultural Domain*

RDF links often connect entities from two different sources, with relations which are not necessarily described in either data source. In the agricultural domain, this

#### 8 Linked Data Usages in DataBio 107

**Fig. 8.9** Faceted search interface

**Fig. 8.10** Web interface entry page and visualization of an observation details of RDF generated on the fly

can be linking fields of specific crop type with the administrative region in which these fields reside, or find whether plots intersect with a buffer zone of water bodies in their vicinity. This is a means to control, e.g., the level and amount of pesticides used in those plots.

Creating such agricultural *knowledge graphs* is important due to environmental, economic and administrative reasons. However, constructing links manually is time and effort intensive, and links between concepts are rather to be *discovered* automatically. The basic idea of link discovery is to find data items within the target dataset which are logically connected to the source dataset. Formally, this means: Given *S* and *T* , sets of RDF resources, called source and target resources, respectively, and a relation *R*, the aim of link discovery methods is to find a mapping M = {(s,t) ∈ *S* ✕ *T* : *R*(s,t)}. Naive computation of M requires quadratic time to test for each s ∈ *S* and t ∈ *T* whether R holds, which is infeasible for large datasets, and leads to the development of link discovery tools, which address this task.

In the agricultural domain, entities are mostly geospatial objects, and the relations are of a topological nature. Existing tools for link discovery, such as SILK and LIMES, are limited when it comes to geospatial data and therefore, as part of the DataBio project, we developed Geo-L, a system designated for discovery of RDF spatial links based on topological relations.

The system provides flexible configuration options to define to-be-linked datasets for SPARQL affine users and employs retrieval and caching mechanisms, resulting in efficient dataset management.

Geo-L uses PostgreSQL, an open-source object–relational DBMS, with PostGIS extension, as the database back end which supports geospatial data processing.

We conducted experiments to evaluate the performance of our proposed system by searching geospatial links based on topological relations between geometries of datasets of the foodie cloud, in particular subsets of OLU, SPOI and NUTS.

The experiments show that Geo-L outperforms the state-of-the-art tools in terms of mapping time, accuracy and flexibility.15 It also proves to be more robust when it comes to handling errors in the data, as well as with managing large datasets.

We applied Geo-L to several use cases involving datasets from the foodie cloud, e.g.,

15 As shown in a case of searching topological relations with NUTS as target dataset, where geometries are not represented as expected and were transformed on the fly to polygons by our tool.

An example for the last case is depicted in the image below (Fig. 8.11), where an overlap area between a plot and a buffer zone of a water body in its vicinity is colored with orange.

The respective dataset resulting from linking water bodies whose buffer zones are intersected by Czech LPIS plots is available on the DBpedia Databus.16

#### *8.3.3 Experiences with DBpedia*

DBpedia is a crowd-sourced continuous community effort to extract structured information from Wikipedia and to make this information available as a knowledge graph on the Web. DBpedia allows querying against this data and information and linking to other datasets on the Web [9, 10]. Currently, DBpedia is one of the central interlinking hubs in the Linked Open Data (LOD) cloud. With over 28 million of described and localized things, it is one of the largest and open datasets.

As part of the project, we constructed links between satellite entities, available in the European Space Association (ESA) thesaurus,17 whose recorded images are employed in DataBio pilots and their respective DBpedia resources. These links are beneficial since the data in DBpedia is available in machine readable form for further processing, and in addition there are additional data and external links related to the satellite. We used REST API to retrieve satellite names from the ESA thesaurus and queried for DBpedia resources matching these names, which were then identified as satellites, based on their properties available in DBpedia.

**Fig. 8.11** Overlap area between a plot and a buffer zone of a water body in its vicinity, colored with orange

16 https://databus.dbpedia.org/amit/geo-L/bufferzones-intersect-lpisPlots/.

17 https://fedeo.spacebel.be/thesaurus/fr/.

The listing depicted in Fig. 8.12 presents an excerpt from the link-data result. The links allow, on the one hand, access to other properties of the respective DBpedia resources and, on the other hand, enable other DBpedia users to access the ESA set. This dataset can be found as an artifact18 on the DBpedia Databus.

DBpedia resources which refer to geographical regions include different important properties about those areas such as temperature amplitudes and monthly precipitation. Such properties may be helpful, e.g., analysis of yields. These resources, however, do not contain the actual geometry of the regions. We used OpenStreetMap to retrieve data about regions and applied Geo-L to link between DBpedia region resources and their geometries.

These geometries can be helpful then not only for the purpose of the DataBio or for agriculture in general, but may be used for locating points of interest, which coordinates are known, within a specific region, a thing which has not been possible so far.

#### **References**

18 https://databus.dbpedia.org/amit/esa/links/.

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

## **Chapter 9 Data Pipelines: Modeling and Evaluation of Models**

**Kaïs Chaabouni and Alessandra Bagnato**

**Abstract** This chapter outlines the utility of data pipelines modeling in the context of a data driven project and enumerates metrics for evaluating the quality of the data modeling regarding the readability and the comprehensibility of the models. We start with explaining the challenges surrounding the DataBio project that led to the adoption of data pipelines modeling using the Enterprise Architecture language ArchiMate. Then we present the data modeling process with examples from DataBio pilot studies starting with modeling software components provided by project stakeholders and ending up with integration of components into data pipelines that achieve the data analytics lifecycle intended by the pilot study. We end the chapter with the evaluation of the quality of DataBio data pipelines models with metrics collected by a monitoring tool for ArchiMate models.

#### **9.1 Introduction**

DataBio [1] aims to develop a platform that exploits the potential of big data technologies in the domains of agriculture, fishery and forestry. Given the complexity of the task, the project decided to adopt the "Enterprise Architecture" modelling language "ArchiMate 3.0" [2, 3] as a common modelling framework for representing the requirements of the pilots and modelling the technical architecture of the components, thus facilitating communication and comprehension among partners. Most of the software components interact with data from different origins and with various formats such as satellite imagery, sensors data, geospatial data (see Chap. 4), etc. In each pilot, components are connected together through several interfaces to form a data pipeline, (see Chap. 1) in which each component has a specific function in the

A. Bagnato e-mail<EMAIL_ADDRESS>
K. Chaabouni (B) · A. Bagnato (B)

Softeam Research Department, 21 Avenue Victor Hugo, 75016 Paris, France e-mail<EMAIL_ADDRESS>
data value chain such as data collecting, data processing, data analytics and visualization. The modelling approach consists of representing the components and the data pipelines according to a predefined model template. The modelling environment used for this task is "Modelio" [4], which allows contributors to collaborate around a synchronized ArchiMate model. The collaboration around the models faces some challenges regarding their potential to be efficiently exploited. Hence, we define metrics for evaluating the quality of the models and we measure continuously the quality level according to these metrics using a monitoring platform.

#### **9.2 Modelling Data Pipelines**

The Enterprise Architecture language ArchiMate provides several concepts for modelling the different layers of the enterprise:

The modelling of software components enabled the DataBio partners working in the various pilots to easily understand the underlying functioning of each pilot. At first, partners were asked to provide models for the software components that they have provided. In a second time round, the partners were instructed to provide data pipelines diagrams that highlight the integration of the components in each pilot study. All of the software components, pipelines and datasets can be found at the DataBio Hub [5].

#### *9.2.1 Modelling Software Components*

The project developed a naming convention, where each software component has an identifier with the pattern "Cxx.yy" where "C" refers to the word "Component", "xx" represents the number of the partner that had provided the component and "yy" represents the component number of that partner. Datasets are correspondingly expressed with the template "Dxx.yy", For example, "C16.01" denotes the first component from partner 16, which is VTT .An expanded notation is "C16.01: OpenVA (VTT)", as the component is called OpenVA, which is a platform that consists of software modules that are used as building blocks of web based visualisation and analytics applications [6]. Components are modelled with diagrams that follow a predefined template. These diagrams include deployment view, interfaces view and subordinates view.

**Fig. 9.1** OpenVA deployment view

#### **<IP_ADDRESS> Deployment View**

The deployment view describes how the application is being deployed by representing the executables of the software component, the software dependencies and the physical environment required for running the application. Figure 9.1 shows an example of the deployment view of the component "C16.01: OpenVA (VTT)". As shown by the figure, OpenVA is packaged as JAR Java Package (openva.jar) which is run as a server via Java Runtime Environment (JRE). The database is handled by the Database Management System (DBMS) PostgreSQL 9.6. OpenVA server depends on two applications: DeployR and OpenCPU. DeployR is an open source application that turns R scripts into web services, so R code can be executed by applications running on a secure server. The OpenCPU server provides an HTTP API for data analysis for running R scripts on the server. OpenCPU uses standard R packaging to deploy server applications.

#### **<IP_ADDRESS> Subordinates View**

The Subordinates view describes the subcomponents of the component such as the libraries, modules and frameworks that compose the whole application. For example, Fig. 9.2 shows the subcomponents of "C16.01: OpenVA (VTT)" which is composed

**Fig. 9.2** OpenVA Subordinates view

of "OpenVA server" (the backend of the application) and "OpenVA Browser UI" (the frontend of the application).

#### **<IP_ADDRESS> Interfaces View**

The interface view shows the provided and required interfaces of components which are designed for interactions with users or with other components through various communication protocols [7]. Figure 9.3 shows an example of the interface view of the component "C16.01: OpenVA (VTT)", which offers a web user interface for accessing OpenVA via a browser. OpenVA is also accessible via interfaces that can be provided by other components such as JDBC interface for accessing OpenVA database, Sqoop export tool for moving a set of files from HDFS (Hadoop Distributed File System) to RDBMS (Relational DataBase Management System).

**Fig. 9.3** OpenVA interface view

#### *9.2.2 Integrating Components into Data Pipelines*

Each pilot integrates in its workflow a set of software components that interact with each other in order to process huge amounts of heterogeneous data. These sets of interoperable software components are called pipelines and work as so-called white boxes showing the internal wiring and data flow between the single components of the pipeline. Hence, we model these pipelines with a "Pipeline View" that shows the different connections between components and a "LifeCycle View" that emphasizes the data value chain.

#### **<IP_ADDRESS> Pipeline View**

Pipeline Views illustrate the connections between the different components and the interfaces that allow them to interact together. Figure 9.4 illustrates the Pipeline View of the fishery pilot "Oceanic tuna fisheries immediate operational choices" [8]. In this pilot, measurements from the ship engines are recorded continuously and are then uploaded to the ship owner server. These measurements are processed and analysed by three major components: "C16.01: OpenVA (VTT)", "C34.01: EXUS Analytics Framework (EXUS)" and "C19.01: Proton (IBM)". Each of these components offers a web interface for interacting with users and visualizing data via dashboards. "C19.01: Proton" is an event processing engine that processes events from different sources such as reading from files or from RESTful API. In this example, we receive sensor readings from the ship's monitoring and logging system which are

**Fig. 9.4** "Oceanic tuna fisheries immediate operational choices" pilot—Pipeline view

then stored in the file system via FTP, from which it is read by Proton's file adapter and streamed into Proton engine for processing.

#### **<IP_ADDRESS> Lifecycle View**

The lifecycle view shows the different tasks accomplished by each component along the data value chain according to the Big Data Value Reference Model [6, 9]. Figure 9.5 illustrates the Lifecycle View of the same fishery pilot as above "Oceanic tuna fisheries immediate operational choices". In this figure, we can see that the "Ship legacy system" is responsible for collecting raw sensor data. Then, custom tools and specific scripts are applied for data preparing (cleaning and transforming data) before executing the analytics tools. Finally the three major tools "C16.01: OpenVA (VTT)", "C34.01: EXUS Analytics Framework (EXUS)" and "C19.01: Proton" are used for data analytics and data visualisation.

#### **9.3 Models Quality Metrics**

The DataBio ArchiMate models are structured in five so-called projects: three projects for describing the pilots of agriculture, forestry and fishery, one project for modelling software and IoT system components and one project for modelling

**Fig. 9.5** "Oceanic tuna fisheries immediate operational choices" pilot—Lifecycle View

"Earth Observation" data services. These projects are monitored by "Measure Platform" [10], which is a monitoring platform that allows to collect periodic measurements on monitored projects. In this case, these measurements are obtained via the model indexing tool "Hawk" [11], which processes the queries of ArchiMate models. For each metric, we define a query for Hawk to interrogate from the models. After this, we store and visualize the collected measurement via the Measure Platform [12].

#### *9.3.1 Metrics for the Quality of the Modelling with Modelio*

Ensuring a better quality of the models begins with monitoring the modelling process with Modelio, which follows the creation of elements, folders, diagrams and documentation inside an ArchiMate project. We present here metrics that reflect how optimal the usage of Modelio is to guarantee a complete system design.

#### **<IP_ADDRESS> Percentage of Unused Elements in Diagrams**

"Unused elements" are elements that have not been represented in diagrams and therefore do not bring any added value to the final generated diagrams. Each Modelio project contains a "Model Explorer" that is divided into two types of directories; one directory for managing the created elements and one directory for managing the diagrams. In the first directory we can visualize the list of all the elements that are created in the project whether they are displayed in diagrams or not. The second directory is for managing the diagrams that represent elements and their relationships. The "percentage of unused elements" metric could be an indicator of an incomplete modelling, where the element was created, but its relation with the rest of elements has not been yet specified. The unused elements could also be explained by the fact that users of Modelio sometimes create elements in diagrams and then mask them from the diagrams without deleting them from the project's Model Explorer. Moreover, this metric could also be an indicator of inefficiency, because it points to the incomplete work and to the wasted amount of work for creating useless elements. In addition, the unused elements will unnecessarily extend the list of displayed elements inside the Model Explorer, which would complicate the navigation for the user. Figure 9.6 shows that the percentage of unused elements in the monitored ArchiMate repositories in DataBio sub-projects has been between 20 and 50%.

#### **<IP_ADDRESS> Percentage of Duplicate Elements**

The presence of duplicate elements in the models adds complexity for Modelio users as the redundancies complicate needlessly the visibility of the project and cause confusion, when choosing a suitable element. Moreover, the duplication of elements

**Fig. 9.6** Percentage of unused ArchiMate elements in diagrams

prevents the full exploitation of Modelio features such as identifying shared elements. Those elements are represented by several diagrams or by all the relations associated to the specified element.

#### **<IP_ADDRESS> Percentage of Empty Diagrams**

The presence of empty diagrams is an indicator of unfinished or obsolete diagrams that need to be removed or updated.

#### **<IP_ADDRESS> Frequency of SVN Commits**

The Modelio projects are stored as SVN (Subversion, an open-source version control system) repositories and can therefore be monitored by observing the frequency of updates of the models. The number of SVN commits per week shows the periods of time during which the work on models has been carried out. This metric does not reflect the real amount of the committed work, but rather the frequency of submitting new releases of the monitored models. Figure 9.7 shows the number of weekly SVN commits in DataBio Archimate Models. We can see from this figure that the major work on the models has been done between May 2017 and June 2018. Other SVN related measures could be conducted such as the number of contributors and the frequency of submitting new updates by each contributor.

**Fig. 9.7** Number of commits per week

#### *9.3.2 ArchiMate Comprehensibility Metrics*

The quality evaluation of ArchiMate views is based on several criteria that capture how well the views have fulfilled their purpose, especially their ability to help understand certain aspects in the project. Therefore, we introduce the comprehensibility metrics that evaluate how easy it is for the user to read the diagram and how easy it is to understand the model. The readability of the diagrams is impacted by how easy it is to read elements in diagrams, distinguish them from each other and find all the links between them. The understandability of the model from the provided diagrams depends on how easy it is to understand the whole organisation, the purpose of each component, service or process and the interactions between them.

#### **<IP_ADDRESS> Average Number of Elements per Diagram**

The average number of elements per diagram shows how easy it is to read a diagram. Having a large number of elements in the same diagram will result in a dense diagram or in tiny elements inside the diagram, if it is scaled to a page or screen size. This makes it harder for users to read. On the other hand, having a very low number of elements per diagram could reflect a very fragmented model. We recommend between 8 and 25 elements per diagram, which is the case in the DataBio projects (see Fig. 9.8).

#### **<IP_ADDRESS> Average Number of Relationships per Element**

The average number of relationships per element reflects the congestion of associations between elements and directly affects the readability of the diagram. This number should be between 1 and 4 relationships per element. A Relationships/Elements ratio approaching 0 indicates that there are very few connections between the elements in the diagrams. On the other hand, a Relationships/Elements ratio exceeding 4 could indicate a big density of connections in the diagrams.

#### **<IP_ADDRESS> Documentation Size per Element**

One key factor for understanding diagram elements is a documentation that provides definitions and comments about the elements and how they are used in the project. This metric evaluates the average size of the textual description provided for an element. This could be considered as an indicator of how detailed the description of the element is. Figure 9.9 shows the history of measured documentation size (number of words) per element in the monitored projects, which have an acceptable average size. However, this measure does not show the disparity of documentation, where

**Fig. 9.8** Average number of elements per diagram

**Fig. 9.9** Documentation size per element

some elements are described with big paragraphs and others have no description at all.

#### **<IP_ADDRESS> Documentation Size per Diagram**

This metric evaluates the understandability of diagrams by measuring the documentation size diagram. It is similar to the previous one with the difference that it calculates the documentation size per diagram instead of the documentation size per element. This allows us to locate in more detail the diagrams that are lacking description.

#### **<IP_ADDRESS> Percentage of Documented Elements**

This metric focuses on the documented part of the models. It measures the percentage of the documented elements. Apart from the self-evident elements, which are understandable just by name, it is highly recommended to describe the remaining elements, especially the elements containing abbreviations, which are not well known to everyone. Figure 9.10 shows the percentage of the documented elements in the monitored projects. The projects, which describe the agro, fishery and forestry pilots, have few documented elements (between 15% and 24%). This is explained by the clear and detailed namings of the motivation and strategy elements, which therefore do not require further explanations. On the other hand, the technology projects deal with a lot of technological components that require documentation. Hence, the documented elements represent more than 58% of the total elements in these projects.

#### *9.3.3 Metrics for Model's Size*

The model size is an indicator of the modelling progress as it reflects the number of created diagrams and elements and their relationships inside diagrams. The model size is also an indicator of the complexity of the model. The number of non-empty diagrams reflect the actual number of the models existing in the studied organisation. In our case, the ArchiMate models contain more than 500 non-empty diagrams. This makes it more complex to understand the whole project.

**Fig. 9.10** Percentage of documented elements per project

**Fig. 9.11** Number of concepts represented in diagrams

#### **<IP_ADDRESS> Total Number of ArchiMate Concepts Used in Diagrams**

Since diagrams differ in size, the number of overall ArchiMate concepts used in diagrams add information about the size of the models. The ArchiMate concepts considered here contain the elements represented in the diagrams and the relationships between the elements. Figure 9.11 shows the evolution of the total number of ArchiMate concepts and the proportion of concepts in each DataBio project. We can see that the total number of ArchiMate concepts is very close to 10000 elements, which is an indicator of the complexity of the project.

#### **9.4 Conclusion and Future Vision**

The modelling of DataBio components and data pipelines provided more clarity to the project and helped to understand the architecture of the used software components and their integration in the pilots workflows. Moreover, the created models have also contributed to the process of requirements elicitation throughout the project period and to the efficient writing of the documentation. In order to monitor the quality of the models, we have defined a metric that evaluates the efficiency of the modelling process, the comprehensibility of the models and the model size. The metric discussed here could be applied also in other projects, where the modelling tool Modelio or the modelling language ArchiMate are in use [12]. The proposed metric indicates that the quality level in DataBio is acceptable as comes to the efficiency of the modelling process and the comprehensibility of the models. However, we note that there are some areas to be improved such as the cohesion and the completeness of the models. The analysis showed that the models are lacking a more holistic view of the DataBio project, where there is a big data platform or environment offering services and components to the different pilots. Hence, we aim at finding more metrics for evaluating the cohesion of the models and expressing the interdependency between elements and diagrams inside the project. Moreover, our analysis showed that there are many incomplete and undetailed diagrams and we need therefore a metric that expresses the completeness and the maturity of the diagrams.

**Acknowledgements** The authors would like to thank Antonio Garcia-Dominguez from School of Engineering and Applied Science at Aston University, Birmingham, UK for his support with the Hawk tool. We would like also to acknowledge the effort of ITEA3 project 14009, MEASURE Project and thank their consortium team members for their feedback on this work. Furthermore, the research leading to these results has received funding from the European Union Horizon 2020 research and innovation program under grant agreement No. 732064, Databio Project.

#### **References**

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

## **Part IV Analytics and Visualization**

## **Chapter 10 Data Analytics and Machine Learning**

**Paula Järvinen, Pekka Siltanen, and Amit Kirschenbaum**

**Abstract** In this chapter we give an introduction to data analytics and machine learning technologies, as well as some examples of technologies used in the DataBio project. We start with a short intdroduction of basic concepts. We then describe how data analytics and machine learning markets have evolved. Next, we describe some basic technologies in the area. Finally, we describe how data analytics and machine learning were used in selected pilot cases of the DataBio project.

#### **10.1 Introduction**

The goal of data analytics is to examine large quantities of data with the purpose of drawing conclusions about the data. Several techniques can be employed, each using similar methods but having a slightly different focus. The methods include, e.g., statistics, data mining, and machine learning (Fig. 10.1).

Data mining is defined as "a science of extracting useful information from large data sets or databases" [1]. Machine learning is "programming computers to optimize a performance criterion using example data or past experience" [2]. Sometimes the division between machine learning and data mining is done based on data sets. Data mining is focused on analyzing large databases, whereas in machine learning the focus is on learning patterns from data. The roots of data analysis are in statistics. The development of computers and their ability to store and manage large amounts of data has made possible large-scale statistical computation and has launched the development of new methods that would be tedious to perform manually.

A recent area of data analysis is visual data mining. Information visualization, data mining, and user interaction have evolved as separate fields in the past, but since the turn of the 2000s have become increasingly integrated as visual data mining.

P. Järvinen · P. Siltanen (B)

VTT Technical Research Centre of Finland Ltd., Espoo, Finland e-mail<EMAIL_ADDRESS>
A. Kirschenbaum Institute for Applied Informatics (InfAI), University of Leipzig, Goerdelerring 9, 04109 Leipzig, Germany

The idea of visual data mining first emerged in 1999 when Wong [3] argued that rather than using visual data exploration and analytical mining algorithms as separate tools, a stronger data mining strategy would be to couple the visualizations and analytical processes into one data mining tool. Many data mining techniques involve mathematical steps that require user intervention, and visualization could support these processes. Visual data mining is not just about using visualization to exploiting data, it is an analytical mining process in which visualizations play a major role [4].

Artificial intelligence (AI) can be defined as "a system's ability to correctly interpret external data, to learn from such data, and to use those learnings to achieve specific goals and tasks through flexible adaptation [5]."

Machine learning has been used since the 1950s by researchers in order to analyze and extract information from data. It has only been during the last decade with the rise of the generalized usage of the graphics processing units (GPUs) that enabled the true development of neural networks and in particular what is nowadays referred to as deep learning [6]. This newly found computational power gave rise to methods that are capable of solving complex, real-world problems. The capacity of modern computers not only allows for computationally intensive methods, but also facilitates the analysis of huge amounts of data, the so-called big data, in a scale that was previously intractable. In contrast to previous methods, deep learning uses multiple layers of neural networks to build architectures capable of performing a specific task, such as classification, segmentation, detection, prediction, and generation of data.

Deep learning is capable of discovering correlations in the data without the need of handcrafted features. The lack of heuristics together with the abundance of computational resources makes deep learning methods ideally suited for handling big data problems. Further to that, machine learning offers the possibility for lifelong learning where the system is capable of adapting to changing conditions. While machine learning is often portrayed as a replacement for human intelligence, it is only a tool for digitalizing human expertise into a computer model. This model is only as good as the information humans supplied it with.

#### **10.2 Market**

Data analysis has been studied intensively, and numerous algorithms exist. It has applications in different business, science, and social science domains. A wide range of tools and commercial applications is available, some of which are highly competitive in markets, such as customer relationship management (CRM). There are also several statistics programs and packages available, both for casual users and specialists (Excel, SAS, SPS, R).

Big data analysis solutions can be classified into two categories: "Data Discovery and Visualization" and "Advanced Analytics" [7]). Data discovery and visualization solutions integrate and transform big data sources using data mining algorithms to find insights into business use. Advanced analytics solutions are focused on building use case-specific predictive or descriptive solutions using advanced modeling techniques, such as deep learning or advanced statistical methods.

Frost and Sullivan estimate big data revenue at 2017 of \$8.54 billion [7]. The revenue is expected to reach \$40.65 billion in 2023. The market is expected to grow at a steady rate, as data discovery and visualization are expected to become more mainstream over this period and advanced analytics is expected to see more reallife use cases [7]. North America is expected to continue to be the largest market contributor, followed by Western Europe, having similar growth path.

Biggest user of data analytics techniques is business and finance, followed by governance and integrity (public sector), both over 15% of the market. In Frost and Sullivan estimations, bio-economy falls into the category of "Others," which in total covers 7.7% of the market.

According to the Zion Market Research [8], global machine learning market was valued at around USD 1.58 billion in 2017 and is expected to reach approximately USD 20.83 billion in 2024, growing at a compound annual growth rate (CAGR) of 44.06% between 2017 and 2024. Artificial intelligence experts have projected their idea that by 2050 all the intellectual tasks performed by the humans can be accomplished by the artificial intelligence technology. Some of the top applications of machine learning are financial services, virtual personal assistants, health care, government, marketing and sales, transportation, oil and gas, manufacturing, bioinformatics, computational anatomy, and more. The artificial intelligence (AI) market in agriculture is expected to register a CAGR of over 21.52%, during the forecast period of 2019–2024, offering services for the management of the crops yield, species breeding, disease detection.

Geographically, machine learning market is segmented into North America, Asia Pacific, Europe, Latin America, and Middle East and Africa. North America is predicted to govern the market in forecast period because of developed countries and their major focus on innovative technologies obtained from R&D sector. Asia-Pacific region is predicted to grow at the highest CAGR in forecast period due to increasing awareness regarding business productivity. In Asia, region vendors are offering competent machine learning proficiency due to which it is the highest potential region for the market. Moreover in Europe, the world-class research facilities, the emerging start-up culture, and the innovation and commercialization of machine intelligence technologies are stimulating the machine intelligence market. Among all regions, Europe has the largest share of intra-regional data flow. This, together with the machine learning technologies, is boosting the market in Europe.

#### **10.3 Technology**

#### *10.3.1 Data Analysis Process*

Data analysis is an iterative process starting with selecting the target data from the raw material and preprocessing and transforming it into a suitable form (Fig. 10.2). Data analysis uses several data types: database records, matrix data, documents, graphs, links, transaction data, transaction sequences, DNA sequence data, whole genome information, and spatiotemporal data. The quality of data may often cause problems. The data can contain noise, there may be missing values and duplicate data, and thus

**Fig. 10.2** Data mining process. Figure adapted from [1]

data cleaning phase is required before using the data. Other kinds of preprocessing may also be required, such as data aggregation, sampling, dimensionality reduction, subset selection, feature creation, and attribute transformation [1].

Next, the data is run through a data mining algorithm that creates patterns from the data. The user interprets and evaluates the results and starts a new iteration with possible modifications to the raw data, algorithm, and algorithm parameters.

#### *10.3.2 Statistical Methods*

Statistical methods are used for data exploration to gain a better understanding of the characteristics of data [1]. The central methods include, e.g., summary statistics, correlations, and visualizations. Summary statistics are numbers that summarize properties of the data. Amar et al. [9] have classified the statistical methods as

Correlation is a basic statistical method of studying two variables. The prevailing method is the calculation of the Pearson correlation coefficient (*r*), where the correlation between two variables, *xi* and *yi* is calculated with the formula:

$$r = \sum\_{i=0}^{n} \frac{(\mathbf{x}\_i - \mathbf{x})(\mathbf{y}\_i - \mathbf{y})}{n S\_x S\_y}$$

where *n* is the number of observation pairs, and *Sx*, *Sy* are the standard deviations, and *x* and *y* the means of the variables *xi* and *yi*. The correlation produces positive or negative values within the range −1 to 1. If the result is zero, there is no correlation between the variables. Values −1 and 1 indicate complete linear dependence between the variables, either negative or positive. Often the square of the correlation coefficient R2 (also known as the coefficient of determination) is calculated. This value ranges from 0 to 1 and indicates how much one variable explains the variance of the other and is often expressed as a percentage. For instance, if *R*2 is 0.32, 32% of the variance of a variable is explained by the other.

Correlations are visualized in the form of scatterplots. Exploration methods for higher dimensions use projections of data on a two-dimensional plane. These are called dimension reduction methods. They include principal component analysis (PCA) and multidimensional scaling, as well as auto-encoders for neural networks. The result of PCA can be visualized as a two-dimensional plot.

#### *10.3.3 Data mining*

The goal of data mining is to extract useful information from large data sets [10]. Data mining can be categorized into different kind of tasks, corresponding the objectives of analysis: exploratory data analysis, descriptive modeling, predictive modeling, and discovering patterns and rules.

Exploratory data analysis (EDA) explores data without clear ideas of the findings. Visualization is effective EDA techniques, especially with relatively small and low-dimensional data sets. Bar charts, boxplots, histograms, and density plots are applicable with single variable data, scatterplots with two variable data. With multidimensional data, dimension reduction methods, such as principal component analysis, (PCA) are used. They produce informative low-dimensional projections of data that can be visualized in two-dimensional space.

The goal of descriptive methods is to describe the data. The methods include density estimation, clustering and segmentation, and models describing the relationships between variables. Clustering looks for groups of objects such that the objects in a group are similar (or related) to one another and different from (or unrelated to) the objects in other groups. The similarity of objects is defined based on similarity (or distance) measures. Euclidean distance can be used if attributes are continuous; otherwise, problem-specific measures are needed. Clustering has been an active research topic, and lots of algorithms are available. Algorithms include K-means clustering and its variants, hierarchical clustering, agglomerative clustering, and density-based clustering. Market segmentation is an application of clustering.

The purpose of predictive modeling is to build models that predict the value of one variable from the known values of other variables [10]. The predicted objects are predefined. Regression and classification are two much used predictive methods. Regression predicts a value of a continuous variable based on other variables using linear or nonlinear models [1]. Linear regression is easy to visualize, often shown as a line on a scatterplot diagram. The area is studied extensively and has its origins in statistics. It has various uses, both in commerce and science. Application examples include predicting sales based on advertising expenditure, stock markets, or wind as a function of temperature or humidity. Classification creates a model for a class attribute as a function of the values of other attributes. Unseen records are then assigned to the class. Models in both methods are developed with a learning data set, and the precision and accuracy of the models are evaluated with a test set. Several techniques have been developed including decision trees, Bayesian methods, rulebased classifiers, and neural networks. Classification is a much used method, and commercial applications are also available. Examples include classification of credit card transactions as legitimate or fraudulent, classification of e-mails as spam, or classification of news stories as finance, weather, entertainment, or sports [1].

Discovering patterns and rules involves finding combinations of items that occur frequently in databases. Sequential pattern discovery finds rules that predict strong sequential dependencies among different events. Association rule mining involves the prediction of occurrences of an item based on occurrences of other items. It produces dependency rules such as "buyers of milk and diapers are likely to buy beer." One special case of pattern discovery is anomaly detection. Anomalies are observations whose characteristics differ significantly from the normal profile. Methods of anomaly detection look for sets of data points that are considerably different from the remainder of the data. The methods build a profile of "normal" behavior and detect significant deviations from it. The profile can be patterns or summary statistics for the overall population. Types of anomaly detection schemes can be graphical-based, statistical-based, distance-based, or model-based. Credit card fraud detection, telecommunication fraud detection, network intrusion detection, and fault detection are examples of application areas [1].

#### *10.3.4 Machine Learning*

In machine learning, the idea is to learn things from data. The approach is to create mathematical models and adjust model parameters with the help of data until the model matches best the modeled phenomena. Machine learning utilizes theories from statistics combined with computer algorithms [2]. It has a strong overlap with data mining. Machine learning is focused on learning patterns from data whereas in data mining focus is on analyzing large databases. Machine learning methods can be divided into unsupervised and supervised learning. In unsupervised learning, there is only input data available, and the aim is to find patterns in data. In supervised learning, there is prior knowledge of the phenomena available in addition to the input data. Clustering belongs to unsupervised methods, whereas classification, regression, and bayesian methods are supervised. Another division is parametric and nonparametric methods. The parametric methods assume that the data is drawn from some probability distribution known before, and the model is created by estimating model parameters from data. Regression and classification methods are parametric methods. The nonparametric methods do not make such assumptions of the data but are based on finding similarities. They divide the input space into local regions, defined by a distance measure. Decision trees belong to nonparametric methods.

As in data mining, model validation is an important issue in machine learning. Input data is divided into learning part and validation part. The model is developed with the learning part and validated with validation part. Measures of the validity are model accuracy and precision.

Neural networks are a specific set of algorithms inspired by biological neural networks. The current deep neural networks (deep learning) work well in problems such as computer vision, speech recognition, and natural language processing. Currently, there are many available open-source frameworks, TensorFlow, PyTorch, Cafe, etc., that can be used for developing neural network models. These include highly optimized code that can be used for both training and using a model and thus greatly simplify the development process. Architectures for building models for specific tasks get published constantly in conferences and journals very often in an open manner. This has given rise to a variety of applications escaping the confines of academic research and reaching directly the market.

#### **10.4 Experiences in DataBio**

#### *10.4.1 Data Analytics in Agriculture*

#### **<IP_ADDRESS> Classification of Land Covering**

This section describes the use of deep learning techniques for Earth observation data in the agriculture pilots in Part V of this book. The ongoing advancements in deep learning, and exemplary results obtained for different problems using spatiotemporal satellite images, have made deep neural networks quite popular for analyzing Earth observation data. The aim of the pilot was to design a pipeline based on deep neural networks to classify land cover using available satellite images from Sentinel-2A satellite. Initially, an investigation was done using only images and not taking advantage of the temporal nature of the signal. The results of this approach were not satisfying as the spatial information was not sufficient to differentiate crops with an adequate accuracy. For this reason, a new pipeline based on spatiotemporal data was designed. The new pipeline consisted of two steps: clean available training data, and then use this cleaned data for training crop classifiers. For the first step, instead of using traditional methods (based on data specific heuristics and handcrafted filters) to clean data, an RNN-based auto-encoder was trained to remove unreliable data. The encoder and decoder consisted of recurrent neural network (RNN) layers with long short-term memory (LSTM) cells [11]. The encoder learns the representations in latent space from the time series of pixels in crop parcels, while the decoder tries to reconstruct the time series. The representations are clustered in the latent space using K-means clustering. It is expected that most of the pixels will form one huge cluster while the outlier pixels will be away from this cluster. In this way, the parcels with clean pixels are selected and further used for training a pixel-level classifier network (inspired from [12] and [13]) for individual crops. Instead of training a neural network from scratch, the encoder part of the auto-encoder is used as initial layers of the classifier network. The pre-trained encoder network is appended with a dense layer and fine-tuned for the classification task. The classifier network produced a probability of being a particular crop for each input pixel. The details of the training for complete pipeline and obtained results can be found in [14].

The classifiers are trained for wheat, maize, and legumes for the data from regions in Greece, provided by NEUROPUBLIC for year 2016. Further, the classifiers are integrated in the DataBio online platform developed by Fraunhofer, where the probability of each pixel in the selected parcel belonging to a certain crop type can be obtained. This technology allows the user to identify the crop grown in a given area by using corresponding satellite imagery.

The presented pipeline shows the significance of data verification and provides an efficient way to create models by optimizing the efforts and the time of both engineers and experts. The data cleaning step done in an unsupervised manner increases the reliability of the data. An expert can further verify and refine these data groups by verifying only the boundary cases in the cleaning step. In this manner, the effort of the expert is optimized by focusing on targeted areas.

Additionally, the cleaning and classification done using time series of pixels (instead of parcels) are advantageous to us due to the following reasons:

Although the presented pipeline performed well for the available data set, the results may not be as good for the following cases:

#### **Lessons Learned**

While this solution can benefit from further developments, it has the potential to form the baseline for methods targeting global scale satellite image analysis. The proposed approach for detection and classification of vegetation types operates on the sub-parcel level and is robust to noise in both the data and the labels.

#### **<IP_ADDRESS> Crop Detection and Monitoring**

The free and open availability of Earth observation data is bringing land monitoring to a completely new level, offering a wide range of opportunities, particularly suited for agricultural purposes, from local to regional and global scale, in order to enhance the implementation of Common Agricultural Policy (CAP).

Terrasigna proposes an in-house developed fuzzy-based technique for crop detection and monitoring in Romania, based on combined free and open Sentinel-2 and Landsat-8 Earth observation data. The general methodology is based on the comparison between real crop behavior and the expected trends for each crop typology. It involves image processing, data mining, and machine learning techniques and is based on different categories of input data: Sentinel-2 and Landsat-8 SITS covering the time period of interest, farmers' declarations of intention with respect to crops types, as well as in situ/field data.

The machine learning technique used is an original one, developed taking into account the particularities of the CAP-monitoring process. The fuzzy approach allowed the use of all available scenes, provided they were not completely contaminated with clouds and shadows. The mixed time series, consisting of S2 and L8 scenes, are accompanied by relevance masks, which act as weights in the final fuzzy extraction process (i.e., drawing a firm conclusion using a series of vague and incomplete information). The strictly statistical character of the algorithm, which does not use phenology information or the intervention of a specialist with agronomic competences, makes the technique universal, being able to adapt to other regions and types of cultures, without difficulty.

The processing chain involves a series of well-defined steps:

The main goal of the approach within the DataBio project framework was to provide services in support to the National and Local Paying Agencies and the authorized collection offices for a more accurate and complete farm compliance evaluation—control of the farmers' declarations related to the obligation introduced by the current Common Agriculture Policy (CAP). The system produced three main types of results, all provided at a 10-meters spatial resolution as follows:

#### **Lessons Learned**

The technology developed by Terrasigna is able to recognize a large number of crops families, of the order of tens. For Romania, it addressed the first most cultivated 32 crops families, which together cover more than 97% of the agricultural land. In 2018, the validation of results for a full agricultural season (full phonological cycle) against independent sources revealed promising results, with an accuracy higher than 95% for more than 10 crop types. The performance is quite uniform reported to parcels size and remains high even for parcels smaller than 1 ha. The highly automated proposed approach allows the performing of big data analytics to various crop indicators, being reliable, cost-, and time-saving. It leads to a more complete and efficient management of EU subsidies, strongly enhancing their procedure for combating non-compliant behaviors.

The most serious problems that had to be solved and that served as lessons were as follows:

Geospatial services together with Copernicus data can provide a really powerful tool for monitoring agricultural dynamics. The end users, the National Paying Agencies, are able to benefit from the modern and effective near real-time service, based on the principles of sustainable agriculture and saving effort both in terms of costs and time. A continuous agricultural monitoring service based on the processing and analysis of Copernicus satellite imagery time series is not just a CAP compliance tool, but can also offer a great range of supplementary information for both public authorities and citizens.

The developed technique is replicable at any scale level and can be implemented for any other area of interest.

#### **<IP_ADDRESS> Farm Weather Insurance Assessment**

Trying to identify the parameters (weather or soil related) with the dominant impact on the crop yield such as normalized difference vegetation index (NDVI) measurements, the following approach is considered. For the first phase of this analysis k-prototypes, clustering algorithm was applied for the profile building of the parcels. Using satellite, meteorological measurements and soil characteristics are aggregated on the level of one or two months considering a full growing season. The k-prototypes algorithm is based on the k-means paradigm but removes the numeric data limitation while preserving its efficiency [15]. After this phase of analysis, each one of the parcel linear regression models [16] is trained considering only the data that belongs to this cluster. In that way after the clustering procedure, we can use historical data of a parcel in order to identify in which cluster it belongs and make predictions for the NDVI values of an upcoming period using the corresponding linear regression model.

#### **Lessons Learned**

The main challenge of this approach is that the clustering analysis cannot work with missing values, so each one of the parcels is required measurements for the same months, otherwise the parcel must be excluded from the analysis. Another challenge is the sparsity of satellite data due to weather issues (e.g., cloudy days) making it difficult to create a "complete" or usable by the machine learning algorithms data set in terms of meteorological, satellite, and soil information for the same dates. In order to deal with that issue, interpolation and aggregation of the data were applied.

#### **<IP_ADDRESS> Crop Disease Detection Using Satellite Images**

Automated crop monitoring is an essential aspect of smart agriculture, as it allows to improve yield estimation while reducing costs and environmental imprint. We conducted a study to forecast diseases in sorghum using remote sensing via satellite imagery as a proxy for crop health. Our method uses images from Sentinel-2 satellites, which regularly provide multispectral images for land monitoring. Images of a sorghum field with infected parts taken under different weather conditions, as captured by Sentinel-2 satellites, served as our training data [17]. We use the observation that there is a strong correlation between the physiological status of a plant and its chlorophyll content, i.e., diseases have a negative influence on the chlorophyll level [18] and derive NDVI from the recorded satellite images. NDVI is an indicator for vegetation vitality which measures the difference between near-infrared light that vegetation strongly reflects, and red, which vegetation absorbs. Healthy plants, that is, with a higher level of chlorophyll, reflect more near-infrared and green light compared to other wavelengths and absorb more red light.

#### **Lessons Learned**

Accurate data on disease outbreaks in the agricultural sector is usually not publicly available, e.g., due to data protection. This posed us the challenge of a small training set, which may lead to overfitting, a general problem in training machine learning methods. To overcome this, we perform data augmentation, i.e., artificially expand the training data set, to improve the ability of the learned model to generalize. Data augmentation is performed by small changes in data, in this case—image manipulation. Such operators include rotations, reflections, random excerpts, image zooming, or combinations thereof [19].

Mask region-based convolutional network (R-CNN) [20] is then used to train a model that determines which areas are infected. Mask R-CNN is a convolutional neural network that performs instance segmentation, i.e., identifies outlines of objects on a pixel level. In our case, the segmentation would be according to the NDVI values. This method showed great potential for the task at hand, and the model achieved mean average precision very close to 1.

#### *10.4.2 Data Analytics in Fishery*

#### **<IP_ADDRESS> Reducing Energy Consumption of Vessels in the Fishery Domain**

This study aims at reducing the ecological and economical costs of fishery vessels, by optimizing their route and speed and thus decreasing fuel oil consumption. This process requires analysis of many observations collected over time. We collected thousands of observations per day from two boats for three years, where each observation involves dozens of features, e.g., speed and angle of wind, engine load, speed of the vessel, and, of course, and fuel consumption. The first step was creating predictive models for consumption of fuel oil per nautical mile. To this end, we compared two modeling techniques: the extreme gradient boosting framework XGBoost [21] and polynomial regression [22] and opted for the latter as it provides better results. We then explore two use cases: One considers calculating an optimal route (TSP) connecting several points; and the other, selecting a single sailing destination which optimizes the energy consumption. In both use cases, varying travel distances and weather conditions were taken into account. The locations are assumed to be known and in GPS format. The weather conditions are extracted in near real time from the Sentinel-3 mission API [23].

To determine the optimal speed and corresponding fuel oil consumption, we employ a gradient descent algorithm for each possible route segment. The algorithm uses wind data, speed exploration values, as well as some control variables to estimate internal machinery values, which in turn are employed to estimate the consumption, and the minimal value gets selected. By applying this optimization method, a reduction of about 3% of the fuel oil consumption was obtained.

#### **Lesson Learned**

A general lesson learned in this study is the importance of data preparation to control input data quality. An observation considering the reliability of different sensors which varied across the ships that lead to many outliers, which negatively impacted the model accuracy, and the creation of a unified model. In addition, the timelines of wind data provided by the Sentinel mission posed limits on the methods, as they were provided once or twice a day, depending on the region of interest, and accurate forecast of wind for a period of over six hours turns out to be better by classic meteorological methods than by statistical approach.

#### **<IP_ADDRESS> Analyzing Historical Measurement Data**

Different data analysis methods were used, e.g., in a fishery pilot (see PartVII of this book) where measurements from several fishing ship motors were analyzed using VTT OpenVA application. The main goal was to analyze ship fuel consumption, but since we imported all the measurements available, the system can be used to analyze other variables as well. VTT OpenVA is an advanced analytics solution that was tailored to create an application where a data scientist can select different measurements and get different visualizations based on the user selection. In a DataBio fishery pilot case, there are 115 measurements from the motors four different ships that were analyzed. Measurements were stored in a 10s interval from a four-year period. More three billion measurement values were stored in a standard relational database (PostgreSQL, https://www.postgresql.org/).

An analysis application using the data was implemented. Users of the application can select measurements from different ships on the selected time period, and the VTT OpenVA proposes available analysis methods, based on the measurement type. In the pilot, 18 different analysis results were shown as visualizations, and 55 single value performance indicators were calculated.

#### **Lessons Learned**

VTT OpenVA is designed to be an interactive application, but DataBio experiences show that when the amount of measurements becomes large—billions of measurements—it is hard to achieve real-time interaction, because database query response times grow to at least several seconds. This could be mitigated by more powerful database servers and specialized commercial databases, but the goal of the pilot was to use standard servers and databases, allowing easy transfer of the system to the server maintained by the system users.

To make queries faster, VTT OpenVA automatically distributes measurements into a large number of database tables instead of making queries to one huge table. Naturally, the way users use this kind of big data analysis tool, e.g., in the fishery pilot the normal time period of the data that is in practice analyzed is about three weeks, which is the average time that a fishing ship is out from harbor. Even though querying the data takes some time, actual time taken to analyze and visualize these relative small data sets is quite short.

#### **<IP_ADDRESS> Oceanic Tuna Fisheries Immediate Operational Choices**

Exus analytics framework was integrated in the pipeline of pilot fishery to predict main engine performance and faults in advance. For the prediction of the main engine performance, a neural network was used to perform multivariate regression in order to estimate a regression model for multiple variables taking as input a considerably lower number of values. The main benefits of the neural networks are their ability to capture complex relationships between the inputs and their requirement of high number of data. The choice of this machine learning algorithm was also based on related work for fault diagnosis in engines used in vessels [24, 25].

Based on historical vessel data sets, a preprocessing of two stages is applied. First only data that corresponds to the steady state of the engine is considered. After extracting the steady-state engine data, the min-max normalization is applied for all features.

Various architectures for the number of hidden layers and units have been tested, and for the best model selection, the data set has been split into training and validation sets. The model that performed the lowest validation error is selected as the best one.

For the prediction of engine faults, the predicted variables (based on historical data) are compared to the actual values of the vessel measurements. When the variance of these differences is higher than a threshold, it is considered as an engine fault.

#### **Lessons Learned**

In this pilot, we have partial lack of knowledge about when actual faults happened or when variance on the values is due to the wear and tear. For that, only the steady data is considered for fitting the best line, so trends can be identified and when actual measurements appear different behavior from the normal trends give an early warning, even though the setting of thresholds for the identification of abnormal behavior of the vessel is challenging due to the variation of the historical data sets (e.g., different periods/years might report different statistical measurements) (Fig. 10.3).

#### **<IP_ADDRESS> Real-Time Data Classification for Automatic Fish Detection**

The main goal of the experiment was to deploy an effective classification approach, relying only on acoustic data, that can form the basis of a real-time fish detection tool.

**Fig. 10.3** Workflow of the Oceanic tuna fisheries immediate operational choices—pilot

For the study, echosounder sample output was appropriately preprocessed in order to produce the *mean volume backscattering strength* (MVBS) values for five frequencies: 18, 38, 70, 120, and 200 kHz. The problem with echosounder data is that the data set is quite unbalanced with respect to the presence of fish or not. In the samples that we used, about 5% of the measurements correspond to fish presence, while 95% measurements not. As a result, a random classifier can appear falsely effective.

To tackle this problem, the acoustic data set was resampled before being fed to the classifiers of the study. The comparison was made based on the *kappa coefficient*, which is more reliable in cases of unbalanced data sets. The methods tested were Naïve Bayes, K-nearest neighbors (K-NN), and SVM, both with linear and radial kernels. PCA was also examined as a preprocessing method. All classification approaches were tested on MVBS values for different combinations of the five frequencies measured.

#### **Lessons Learned on the DataBio Use**

From the process and the analyses carried out within DataBio and with respect to the specific pilot, the main conclusion and lesson learned are that many different classification algorithms should be tested, in order to identify the most efficient ones for the specific data set types. Because of the nature of the acoustic data sets, it was really challenging to identify the proper training subsets for the machine learning algorithms. This resulted in the need for a number of iterations with the pilot owner (SINTEF) in order to ensure that the algorithms are accurate enough.

#### **References**

1. Tan, P. N., Steinbach, M., & Kumar, V. (2006). *Introduction to data mining*, First edition, Addison Wesley.

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

## **Chapter 11 Real-Time Data Processing**

**Fabiana Fournier and Inna Skarbovsky**

**Abstract** To remain competitive, organizations are increasingly taking advantage of the high volumes of data produced in real time for actionable insights and operational decision-making. In this chapter, we present basic concepts in real-time analytics, their importance in today's organizations, and their applicability to the bioeconomy domains investigated in the DataBio project. We begin by introducing key terminology for event processing, and motivation for the growing use of event processing systems, followed by a market analysis synopsis. Thereafter, we provide a high-level overview of event processing system architectures, with its main characteristics and components, followed by a survey of some of the most prominent commercial and open source tools. We then describe how we applied this technology in two of the DataBio project domains: agriculture and fishery. The devised generic pipeline for IoT data real-time processing and decision-making was successfully applied to three pilots in the project from the agriculture and fishery domains. This event processing pipeline can be generalized to any use case in which data is collected from IoT sensors and analyzed in real-time to provide real-time alerts for operational decision-making.

#### **11.1 Introduction and Motivation**

To stay relevant and competitive, modern enterprises must continuously monitor events of interest, assess changing conditions, and make fast decisions. The continuous flow of event streams, such as customer orders, bank deposits, invoices, social media updates, market data, Global Positioning System (GPS)-based location information, signals from Supervisory Control and Data Acquisition (SCADA) systems, and temperature from sensors and IoT devices, are analysed to help enterprises respond in real-time to changing market and environmental conditions. Furthermore, with the emergence of the Internet of Things (IoT), organisations are taking advantage of the high volumes of data produced by sensors for real-time situational

F. Fournier (B) · I. Skarbovsky

IBM Research—Haifa, University of Haifa Campus, Mount Carmel, 3498825 Haifa, Israel e-mail<EMAIL_ADDRESS>
awareness and real-time insights. IoT generates a huge amount of high-speed realtime data in different formats from a vast number of sources that must be analysed quickly for timely responses. IoT sensors enable decision-makers to continuously monitor and track various parameters that help them in their day-to-day operations.

Traditionally, organisations used to store data in databases and then process and analyse it after storage using batch processing. As mentioned above, the unexpected growth in the number of events due to advanced operations, massive sensor adoption, mobile devices, and high-speed networks has resulted into an exponential increase in data volume. Moreover, organisations need to be increasingly capable of extracting insights from real-time business events, because data loses value with the passage of time. Many of today's common applications such as fraud detection, algorithmic trading, network monitoring, predictive maintenance, and sales and marketing require the processing of data in real time. *Event Stream Processing* (ESP) has evolved to cope with the analysis of real-time streaming data.

To understand the essence of ESP, let's decompose the name to its three basic terms: event + stream + processing. An *event* is an occurrence within a particular system or domain; it is something that has actually happened or is contemplated as having happened in that domain. The word *event* is also used to refer to a programming entity that represents such an occurrence in a computing system [1]. A *stream* is a constant and continuous flow of events that navigate into and around companies from thousands of connected devices, IoT, and any other sensors. An *event stream* is a sequence of events arranged in some order, typically by time. Enterprises generally have three different kinds of event streams: business transactions, such as customer orders, bank deposits, and invoices; information reports, such as social media updates, market data, and weather reports; and IoT data, such as GPS-based location information, signals from SCADA systems, and temperature measurements from sensors [2]. *Processing* is the final act of analysing all this data in real-time.

ESP is the processing of continuous event data streams in real time. It helps identify the patterns and anomalies within these data streams that are important to an enterprise, such as event correlation, causality, and timing. ESP also enables organisations to respond quickly to critical events, thus saving time, money, and resources. It is also known as real-time streaming analytics, streaming analytics, and (complex) event processing [3].

Specifically, stream analytics provided by ESP platforms [4]:

Event Processing (EP) is a paradigm where streams of events are analysed to extract useful insights of real-world events [5]. EP systems associate precise semantics with the information items being processed: these are notifications of events that happened in the external world and were observed by sources, also called event producers [6]. The EP engine is responsible for filtering and combining such notifications to understand what is happening in terms of higher-level events (aka complex events, composite events, or situations) to be notified to sinks, called event consumers. EP systems detect complex patterns of incoming items involving sequencing and ordering relationships. An example of such a situation is the flagging of a *suspicious account* that is detected whenever there are at least three events of large cash deposits within 10 days to the same account. Event processing is in essence a paradigm of reactive computing: a system observes the world and reacts to events as they occur. It is an evolutionary step from the paradigm of responsive computing, in which a system responds only to explicit service requests.

A vast number of recent applications of EP can be found in health informatics, astronomy, telecommunications, electric grids and energy, geography, and transportation [5]. In the DataBio project, event processing applications have been developed and deployed for the domains of agriculture and fisheries, as described in the pilots section. [See Parts V and VII of this book].

#### **11.2 Market**

The massive surge in data generation and the increasing demand for real-time analysis of streaming data are expected to boost the growth of the ESP market. According to the Event Stream Processing Market—Global Forecast to 2023 report from December 2018 [3], the global ESP market size is projected to reach USD 1.838 billion by 2023, growing at a compound annual growth rate (CAGR) of 21.6% during the forecast period. The market analysis by application in Europe shows that the predictive maintenance segment is expected to grow from USD 29.2 million in 2018 to USD 81.0 million by 2023, at the highest CAGR of 22.7% during the forecast period. The market analysis by verticals in Europe shows that the ESP market by vertical is expected to grow from USD 689.9 million in 2018 to USD 1838.0 million by 2023, at a CAGR of 21.6% during the forecast period. Furthermore, the market size of the banking, financial services, and insurance (BFSI) vertical is expected to have the largest market size and projected to grow from USD 37.6 million in 2018 to USD 95.8 million by 2023, at a CAGR of 20.6% during the forecast period. This can be attributed to the growing adoption of IoT-based connected devices. All the verticals are undergoing digital transformation, which has created the need for analysing real-time data to achieve a competitive advantage in the market.

Gartner [4] characterises ESP systems as transformational, meaning they have the potential to change the way organisations interact with information to such a degree that they have a demonstrable impact on organisations' business models. Three factors are driving the expansion of ESP:

From the analysts' reports covered, it's clear that ESP solutions have the potential to enable new ways of doing business; companies who have not yet adopted such systems should consider doing so in the near future. Furthermore, the bioeconomy domains investigated in DataBio (i.e., agriculture, forestry, and fishery), and not mentioned in the reports so far, have a unique opportunity to be innovative by embracing this technology.

#### **11.3 Technical Characteristics**

Event processing systems are a departure from traditional computing architectures that employ synchronous, request-response interactions between client and servers. In reactive applications, decisions are driven by events. Conventional architectures are not fast or efficient enough for some applications, because they use a "save-andprocess" paradigm in which incoming data is stored in databases in memory or on disk, and then queries are applied. When fast responses are critical, or the volume of incoming information is extremely high, application architects instead use a "processfirst" EP paradigm; here, logic is applied continuously and immediately to the "data in motion" as it arrives. EP is more efficient because it computes incrementally, in contrast to conventional architectures that reprocess large datasets, often repeating the same retrievals and calculations as each new query is submitted.

As mentioned above, the goal of an EP engine is to notify its users immediately upon the detection of a pattern of interest. Data flows are seen as streams of events, some of which may be irrelevant for the user's purposes. Therefore, the main focus is on the efficient filtering out of irrelevant data and processing of the relevant. Obviously, for such systems to be acceptable, they must satisfy certain efficiency, fault tolerance, and accuracy constraints, such as low latency and robustness.

As previously stated, EP is a technique in which incoming data about what is happening (event data) is processed more or less as it arrives to generate higherlevel, very useful summary information, known as complex events. Event processing platforms have built-in capabilities for filtering incoming data, storing windows of event data, computing aggregates, and detecting patterns. In essence, EP software is any computer program that can generate, read, discard, and perform calculations on events. A complex event is an abstraction of one or more raw input events. One complex event may be the result of calculations performed on a few or on millions of events from one or more event sources. A situation may be triggered by the observation of a single raw event but is more typically obtained by detecting a pattern over the flow of events. Many of these patterns are temporal in nature [7], but they can also be spatial, spatio-temporal, or modal [1]. Event processing deals with these functions: get events from sources (event producers), route these events, filter them, normalise or otherwise transform them, aggregate them, detect patterns over multiple events, and transfer them as alerts to a human or as a trigger to an autonomous adaptation system (event consumers). An application or a complete definition set made up of these functions is also known as an Event Processing Network (EPN) [1].

Generally speaking, complex event processing (CEP) software offers two major components: a high-level language for programmers to easily describe how to process the incoming events and an infrastructure engine for the processing of the data streams in real-time. Events of different formats are gathered from different event producers. The event producers can be of different types, including financial feeds, news feeds, weather sensors, application logs, video streams collected from surveillance cameras, etc. The EP engine is the brain that carries out multiple types of processing on event streams, based on predefined rules. The processing includes simple filtering, counting, averaging, aggregating, of simple event processing operations, as well as more complex processing, such as pattern matching and event prediction (forecasting). Event consumers are parties that are interested in mining valuable information from the event streams, e.g., software agents, users of web/mobile applications, etc. [5].

The design of event processing applications includes the design of both the functional properties and the non-functional properties. While functional requirements define what an event processing system should do, non-functional requirements place constraints on how the system will do so. The design of requirements is implementation-specific and is carried out in either hand-coded fashion or using modern dedicated event processing tools by IT developers familiar with the event processing engine and the particular way to bypass the engine's limitations.

The event logic necessary to specify the event-driven application is typically provided by domain experts who know the domain and can express the event rules. However, the task of defining the event definitions can be tedious and difficult even for experts. To alleviate this task, in some engines the event definitions can be learned in an automated way using machine learning techniques (e.g., [8] and [9]).

Non-functional requirements include scalability, usability, availability, security, and performance objectives. Not all of these requirements apply equally to all applications, so when designing an event processing application, one needs to consider which of them are important for the case in hand. A survey in the area of non-functional requirements can be found in [10].

There is no standard for event processing languages and programming models. As a result, each event processing tool uses its own terminology and semantics. For example, the IBM PROactive Technology Online (PROTON) open source tool1 applied in the DataBio project follows the semantics presented in Etzion's and Niblet's book [1].

1 https://github.com/ishkin/Proton/.

#### **11.4 Event Processing Tools**

CEP has already built up significant momentum, manifested in a steady research community and a variety of commercial and open source products [6]. Today, a large variety of commercial and open source event processing tools are available to architects and developers who are building event processing applications. These are sometimes called event processing platforms, streaming analytics platforms, (complex) event processing systems, event stream processing systems, or distributed stream computing platforms (DSCPs). DSCPs such as Amazon Web Services Kinesis2 and open source offerings including Apache Samza,3 Spark,4 and Storm5 were introduced in recent years. In particular, Apache open source projects (Storm, Spark, and Samza) have gained a fair amount of attention and interest [11, 12].

Event processing systems are general purpose development and runtime tools that are used by developers to build custom, event-processing applications. The tools allow this to be done without having to re-implement the core algorithms for handling event streams, as they provide the necessary building blocks to build the event-driven applications. In comparison, DSCPs are general-purpose platforms without full native EP analytic functions and associated accessories. However, they are highly scalable and extensible, and usually offer an open programming model so developers can add the logic to address many kinds of stream processing applications, including some EP solutions. Today, there are already some implementations that take advantage of the pattern recognition capability of EP systems along with the scalability capabilities that DSCPs offer and provide a holistic architecture. For example, the PROTON open source event processing tool applied in the DataBio project has a Storm version (ProtonOnStorm), which allows PROTON's engine to run in a distributed manner on multiple machines using the Storm infrastructure.

A recent Gartner report from 2019 [4] states that more than 40 ESP products are available on the market.

Sample vendors include EsperTech, EVAM, IBM, Microsoft, Oracle, SAP, SAS, Software AG, the Apache Software Foundation, and TIBCO Software.

#### **11.5 Experiences in DataBio**

As mentioned previously, event-driven applications were developed for the agriculture and fisheries sectors in the DataBio project. More specifically, two agricultural implementations were developed. One focuses on monitoring temperature and air pressure measurements from sensors in the field (using SensLog) and sending warnings concerning a possible upcoming freeze. This application is designed to alert

2 https://aws.amazon.com/kinesis/.

3 https://samza.incubator.apache.org/.

4 https://spark.apache.org/streaming/.

5 https://storm.apache.org/.