D3 2 Information Source Publication and Consumption ...api.ning.com/files/KZdONCIBf2AI5u9XH5uT4e690iaEE1xsjbMF9vQ... · D3.2 Information Source Publication and Consumption Framework

DELIVERABLE

This project has received financial support from the European Union Horizon 2020 Programme under grant agreement no. 688203.

D3.2 Information Source Publication and

Consumption Framework

Project Acronym: bIoTope Project title: Building an IoT Open Innovation Ecosystem for Connected Smart Objects

Grant Agreement No.

688203

Website: www.bIoTope-project.org Version: 1.0 Date: 30 August 2016 Responsible Partner: Aalto University Contributing Partners:

BIBA, Eccenca, University of Luxemburg

Dissemination Level: Public X Confidential – only consortium members and European Commission Services

D3.A Information Source Publication and Consumption

688203 bIoTope Project Partners 2 August 30, 2016

RevisionHistory

Revision Date Author Organization Description

0.1 29/06/2016 Andrea Buda Aalto University Initial draft Table of Content

0.2 08/07/2016 Andrea Buda Aalto University Introduction written

0.3 10/07/2016 Andrea Buda Aalto University Section 2.1 and 2.2 written

0.4 12/07/2016 Andrea Buda Aalto University Chapter 2 completed



0.7 05/08/2016 Andrea Buda Aalto University Figure and Reference Reviews

0.8 06/08/2016 Andrea Buda Aalto University Draft Ready for Review

0.9 19/08/2016 Annette Weilandt Eccenca Draft Comments

0.10 19/08/2016 Sebastian Tramp Eccenca Draft Comments

0.11 22/08/2016 Robert Hellbach BIBA Draft Comments

0.12 25/08/2016 Andrea Buda Aalto University Including Eccenca Feedback

0.12 27/08/2016 Andrea Buda Aalto University Including BIBA Feedback

1.0 30/08/2016 Andrea Buda Aalto University Formatting



Every effort has been made to ensure that all statements and information contained herein are accurate, however the bIoTope Project Partners accept no liability for any error or omission in the

same.



TableofContents

1. Introduction .................................................................................................................................. 5 Objectives in WP3 ................................................................................................................. 6 Objectives in Task 3.A .......................................................................................................... 6

2. IoT Vertical Silos .......................................................................................................................... 7 IoT Stack Model .................................................................................................................... 7 Vertical Silos Proliferation ................................................................................................... 8 Towards Unified Solutions ................................................................................................... 9

3. Solution for a unified IoT Ecosystem ........................................................................................ 10 Data ownership: User-centric data flow control .............................................................. 10 Web Services: Interoperability, Visibility, Friendliness .................................................. 11 Selected Technical Solution ................................................................................................ 16

4. bIoTope Core Services ............................................................................................................... 18

ListofTables

Table 1: Abstraction Layers W3C Adapted from [12] ......................................................................... 8Table 2 - Web Services implementation options, (H=human-understandable M=machine-

understandable) ............................................................................................................................. 12Table 3 - O-MI, O-DF and json-ld position in the web-of-things stack .............................................. 16

ListofFigures

Figure 1 - IoT-related standardization bodies ........................................................................................ 6Figure 2 - IoT technologies and standards landscape, adapted from [10] ............................................. 7Figure 3 - Dominant IoT Ecosystem Architecture ................................................................................. 9Figure 4 - LinkedData principle example ............................................................................................ 14Figure 5 - Relationship and Cooperation between the bIoTope and BIG-IoT EU projects ................ 17Figure 6 - Search engine and Maps Service crawling the web for indexing O-MI Nodes .................. 18Figure 7 - Search engine and Maps Service crawling the web for indexing O-MI Nodes .................. 19Figure 8 - O-MI O-DF Search Engine based OpenDataSoft platform ................................................ 20



1. IntroductionNew IoT applications and initiatives that leverage ubiquitous connectivity and analytics are emerging all across the world, offering tremendous capabilities for enhanced connectivity, device and data management across disparate IoT platforms (e.g., transportation, energy, manufacturing, healthcare and city service providers). Such cross-domain and cross-platform services open up opportunities for disruptive innovation and business models, to reduce costs for societies, increase the service level for end-users, while fostering a sustainable economic growth. As rapidly growing area, IoT has become a technological focus for academia, industry, and even government organizations [1]. The IoT envisions a world of heterogeneous objects uniquely identifiable and accessible through the Internet [2, 3], the whole forming a dynamic global network infrastructure with self-configuring capabilities [4]. Nonetheless, IoT is entering a new phase with an increased focus on how to avoid the continual emergence of vertical silos, which hamper developers to produce disruptive and added value services across multiple platforms and sectors (data is “siloed” in a unique system, cloud, domain, and stays there). The core mission of the bIoTope project is to overcome these silos by developing an ecosystem of connected services and platforms. This vision requires the mastery of protocols and standards to leverage system interoperability due to the large number of products, platforms, and competing applications that co-exist in the IoT [5, 6, 7]. In lack of standardized solutions, it is likely that a proliferation of architectures and identification schemes will develop side by side, each one dedicated to a particular or separate use, which will lead to the fragmentation of the IoT [8]. At the time of writing, [9] reports more than 250 IoT platforms available on the market. bIoTope is not the only initiative addressing this issue: several standardization bodies understood the challenge and started to build up consortia and initiatives to foster open IoT ecosystems that facilitate the discovery and combination of services provided and exposed by different platforms. Let us cite the Web of Things (WoT) initiative at W3C, the Alliance for Internet of Things Innovation (AIOTI) launched by the EU, the OneM2M global standards initiative, the IEEE Internet of Things (IoT) initiative, or still the Open Platform 3.0TM initiative at The Open Group. Some of the bIoTope partners (Aalto, EPFL, BIBA, Holonix) are deeply involved in the Open Platform 3.0TM; leading the IoT workgroup and developing the O-MI (Open Messaging Interface) and O-DF (Open Data Format) standards specification. Figure 1 provides an overview of the standardization bodies, which are currently working on IoT-related standards.



Figure 1 - IoT-related standardization bodies

ObjectivesinWP3

The overall aim for bIoTope is to lay the foundation, both technologically and related to business, of open innovation ecosystems for the IoT and platforms for connected smart objects. To this end, bIoTope will develop a standard-based System-of-Systems (SoS) ecosystem. This ecosystem will not be realised as a single product, such as a unique middleware or operating system, but by a number of independent services sharing a standardized API based on the O-MI and O-DF specifications. The main objective of WP3 is to define the overall bIoTope ecosystem architecture, providing the technical solutions for information source publication and consumption using the O-MI and O-DF standards. This is also the objective of Task 3.A, which is described in this deliverable. Furthermore, WP3 includes additional task defining: new mechanisms to manage ‘Identities’ (Task 3.B), ‘Context-sensitive Security and Privacy’ (Task 3.D) of connected smart objects and people. It also develops an appropriate billing framework for enabling financial incentives to information sharing in the IoT (Task 3.C).

ObjectivesinTask3.AAs mentioned above, the main objective of task 3.A is to develop mechanisms for IoT devices and IoT-related information systems to publish their presence, and be discovered by, other IoT systems, by extending the discovery functionality provided by O-MI and O-DF standard with geo-location and semantic web discovery methods (e.g., describing meta-data about different services). Before explaining the chosen technical solutions, this report describes the core problem that the bIoTope ecosystem is supposed to overcome: the proliferation of vertical information silos, highlighting the technical solutions and business drivers leading to the current situation. Afterwards, a comparison of standards and technical solutions addressing SoS integration is provided, together with the justification for the chosen solutions. Finally, chapter 4 presents the overall architecture, its building block (in term of services) and the underlying standards and technologies of the bIoTope ecosystem and their relationship with the O-MI and O-DF standards.



2. IoTVerticalSilosBefore addressing the information silos problem, it is useful to provide a framework in which it is possible to organize the technologies and standards currently associated with the IoT. The presented model will be referenced throughout this deliverable for positioning the vertical and horizontal integration solutions discussed.

IoTStackModelIoT related standards and technologies span from cloud-based systems to embedded software and machine-to-machine (M2M) communication protocols. It is nearly impossible to give a single and unified picture of the overall IoT landscape due to its heterogeneity and complexity. A glimpse of this complexity is provided by [10] in Figure 2, depicting the technologies and standards commonly used in consumer’s smart products. Consumer’s smart products are relatively new compared to industrial M2M systems, where manufacturers have been integrating Internet connected systems into high-value asset tracking, product lifecycle management, fleet management, and so on, for more than 15 years [14]. Therefore, if a similar picture would be drawn for other domains, such as industrial automation, building automation, the number of standards to deal with (especially at the connectivity, link and transport layer) would be considerably more.

Figure 2 - IoT technologies and standards landscape, adapted from [10]

However, it is very useful to organize the technologies and standards currently associated with the IoT in a vertical stack. The modern level of sophistication reached by networks and IT systems in general is essentially due to fact that they are built in layers. Technical solutions on a given layer, rely and partially ignore the complexity of the solutions on the lower layers as long as they are encapsulated in a standardized protocol or API. The ISO/OSI is universally recognized as the conceptual model that characterizes and standardizes the communication functions of a telecommunication or computing system without regard to their



underlying internal structure and technology. Unfortunately, this model does not cover all the layers involved in an end-to end IoT application. For the IoT, a universally recognized stack model does not exist yet. The best attempt so far, covering end-to-end IoT solutions is provided by W3C and their Web of Things (WoT) initiative (see Table 1). This model is particularly interesting for bIoTope because it provides a distinction between the IoT (focusing on networking and protocols) and WoT (focusing on data and its semantics). In addition, the W3C model and overall vision are very much in line with bIoTope, both focusing on the internet-scale interoperability (what W3C calls Web-Of-Things); while leaving to other initiatives the convergence of lower layers standards.

Table 1: Abstraction Layers W3C Adapted from [12]

APPLICATION (WoT focus)

Scripts that define Thing behavior in terms of their properties, actions and events, using APIs for control of sensor/actuator hardware -- Focus on data types & APIs

THINGS (WoT focus)

Software objects that hold their state. Abstract Thing to Thing messages. Semantics and Metadata. Data models and Data.

TRANSFER (IoT focus)

Bindings of abstract messages to mechanism provided by each protocol, including choice of communication pattern e.g. pull, push, pub-sub, peer to peer etc.

TRANSPORT (IoT focus)

REST based protocols (e.g., HTTP, CoAP); Pub-Sub protocols (e.g., MQTT, AMQP, XMPP…).

NETWORK (IoT focus)

Underlying communication technology with support for exchange of simple messages (packets). Many technologies designed for different requirements (WiFi, Z-wave, ZigBee, Bluetooth…).

VerticalSilosProliferationThe underpinning architectural choices leading to vertical silos are mainly due to business models that are increasingly data driven. Indeed, data is becoming one of the important corporate assets that can help drive revenue, a successful recipe being: attract a large user-base, be prepared to aggregate and process the collected data and sell services (based on it) to advertisers. According to the World Economic Forum: “Personal data is becoming a new economic asset class, a valuable resource for the 21st century that will touch all aspects of society” [11]. Looking at the drivers and interests of the main IoT ecosystem stakeholders (e.g., end-users, hardware/software provider, etc.) can help to better understand the dominant architectural choices, as summarized hereinafter: • End-users: They buy and use IoT devices, and usually expect (i) a flawless user interface capable

of interacting with their device(s) at anytime and anywhere; (ii) trouble-free communication and interaction among their devices;

• Device Manufacturers: Their objective is to sell their connected-devices to end-users. We can

classify such devices in three categories from a connectivity viewpoint: (i) IP: requiring an Internet access point; (ii) non-IP: requiring a gateway that translates non-IP to IP (connected to an Internet access point); and (iii) IP over mobile-network: self-sufficient. A complete package is usually complemented by either a smartphone’s App and/or Web-App connected to a Cloud endpoint, enabling end-user’s device-related data to be sent/processed in the Cloud, and to return one or more services to the end-user. Table 1 provides an overview – based on the W3C’s view [13] – of the necessary layers to deliver such end-to-end IoT services. In this respect, Cloud-based services form most of today’s vertical silos in the IoT, as each layer described in Table 1 is closed and provided by one specific vendor/platform. To respond to an increasing end-user demand for cross-service interoperability, some manufacturers open their cloud-endpoint API (Application Programming Interfaces) – see Things layer: Table 1 – or join an existing multi-vendor ecosystem.



• Ecosystem provider: As previously stated, the number of IoT devices, platforms and vendors is

steadily increasing. Within this context, having a device’s dedicated App and/or gateway (for non-IP devices) is not a viable strategy, both from a business and technological perspective (e.g., impossible to perform simple automation tasks involving different vendor devices). It becomes therefore mandatory for manufacturers to become parts of larger multi-vendor ecosystems. For example, Philips Hue lighting works with its own dedicated device- gateway or, alternately, with the Samsung SmartThings ecosystem, which usually implies using a gateway that supports a limited number of lower level IP and non-IP transport protocols (see Network layer: Table 1), while requiring that the device implements a specific API. Integration and interoperability is therefore solved at the hub-level, as emphasized in Fig. 3. How this gateway is connected to the Internet has profound implications for the control of the ecosystem. The dominant IoT communication model consists in connecting the gateway to a cloud service. To this end, there are essentially two options: (i) the ecosystem’s owner provides the cloud endpoint, or (ii) the gateway has an open API allowing anyone to create cloud-based services. The second option fosters service openness, but may lead to the fragmentation of the final user experience, which is actually the problem that an ecosystem is supposed to solve. Consequently, it is common practice that the ecosystem’s owner is also in charge of the web-endpoint. This implies that the ecosystem’s owner must be fully trusted by the other parties of the ecosystem, in terms of capability (technical and economical), responsibility (commitment to support the system in the long run) and credibility. There are a handful of companies that can meet these criteria. However, in case one will prevail and become the de facto ecosystem’s owner, a paradox is on the rise. For example, let us consider, the Samsung SmartThings ecosystem: will it enable the Internet connectivity of every appliance of every household on the planet? The data stored in their cloud endpoint would be extremely valuable for advertisers, service providers etc.

Figure 3 - Dominant IoT Ecosystem Architecture

TowardsUnifiedSolutionsAs already mentioned, several organizations and standardization bodies understood that the value of a truly unified IoT ecosystem would be much more than the sum of current existing verticals. Multi-vendor ecosystems, driven by one organization, might represents a solution for what is referred to as network (integration) layer in Table 1, but it is of the utmost importance to make sure that it will not



lead to dominant position at the Things level. This deliverable argues that the adoption of certain solutions at the Things level will play a major role in fostering truly open and unified ecosystems, and therefore unlocking the commercial potential of the IoT. Nonetheless, before discussing (in the next section) such potential technologies, standards, and IoT architectures, it is useful to distill a list of principles that we consider crucial for a successful open IoT ecosystem: 1) The web is the IoT platform: no single organization or company is in control, thus removing the

threat of a single point of failure. Everyone is able to provide any type of service and possibly make money out of it without any forced intermediary. In other words, the model to follow is more similar to what Firefox OS is trying to do for the mobile world, in opposition with the very tightly controlled iOS or the slightly more open Android ecosystems.

2) Data ownership: end-users must have control over their personal data as well as the data generated by the devices they own (e.g., deciding sharing specific data with any other partner/services of the ecosystem). This concept is similar to the permission mechanism used by smartphones apps, in which the user must explicitly allow access to his/her phone resources (storage, location, microphone, camera, calendar, contacts, etc).

3) Web Service Interoperability & Visibility: the success of an IoT ecosystem is closely related with the number of services that are available, and how easy it is to make these services communicate and interact with each other. This implies to have a universal way to both (i) describe and share/publish a service, information, and so on, and (ii) to discover relevant services depending on the stakeholder’s needs, role, activity or situation. Overall, a long-term goal is to be able to connect cloud endpoints serving data, while reducing as much as possible the need to develop custom connectors and, for the end users, to manually connect one service to another.

3. SolutionforaunifiedIoTEcosystemThe bIoTope ecosystem will be built upon the principles stated above. Fortunately, principle 1 (The web is the IoT platform) is still achievable, as no dominant players have forced their way into IoT, as it happened already in the smartphone space. While principle 2 (Data ownership) and 3 (Web Service Interoperability & Visibility) are rather the missing building blocks that need to be developed within the project, to fulfill the vision of a unified IoT ecosystem. As a result, the following sections will discuss • Data ownership and user-centric data flow control. In this deliverable, the discussion is limited to

addressing the challenges and listing the ongoing initiatives for solving this issue. An in depth description of technologies and the translation of this principle into a concrete service of the bIoTope ecosystem is left to task 3.B.

• Web Services: Interoperability, Visibility, Friendliness. Section 3.2 will compare and discuss in great detail the different options available for exposing data (especially IoT-related) on the web. This topic is extremely relevant for Task 3.A as it justifies the selected method (based on O-MI and O-DF) for publishing, discovery and consuming IoT data on the web. In addition, chapter 4 will describe how a service exposed via O-MI/O-DF can join the envisioned bIoTope ecosystem.

Dataownership:User-centricdataflowcontrolIn the introduction we reported a statement of World Economic Forum, elevating personal data as one of the most valuable resources for the 21st century. At a first glance, data generated from IoT devices might not seem to fit the description of personal data, but in reality IoT data can be very personal. Let us consider the example of the energy consumption of a household, from which it is possible to determine whether residents are at home or not, which may then be exploited for a variety of purposes. It might also be possible to correlate this finding with other datasets (e.g. householder inhabitant’s name), giving away his/her position at a given point in time. There is an increasing concern that the combination of massive data collection and innovative uses of big data analytics might violate privacy.



The EU is currently working on making more stringent legislation regarding the treatment and protection of personal data (see e.g. General Data Protection Regulation – GDPR [4]) although it is not yet clear how this directive could be implemented in practice and how it will affect the current web service market. One of the justified fears is that this could potentially lead to severe restrictions over the possibility of analyzing and sharing data. The companies participating in bIoTope, especially the ones providing data-platform (OpenDataSoft, CitizenData and Eccenca) shared also the similar concern. However, it is also obvious that the common “I have read and agree to the terms” acceptance mechanism is no longer appropriate, as it is often skipped by end-users because it is usually long and complicated, which makes it difficult to understand the true privacy implications of the consensus. Beside the measures adopted at European level, some governments and local vendors are also focusing on the development of new infrastructure-level approaches to reduce privacy risks. For example in Finland the MyData [14] initiative started from a concern expressed within a local section of the Open Knowledge Foundation (http://fi.okfn.org/), found its way up to the Finnish Ministry of Transport and Communications. The proposed model is based on a simple core idea: put end-users in control of their data by enforcing the following principles: • Human centric control & privacy: Individuals are empowered actors, not passive targets, in the

management of their personal lives (both online and offline) and, as a result, must have the right and practical means to manage their own data and privacy;

• Usable data: It is essential that personal data is technically easy to access and use (accessible in machine readable open formats via secure and standardized APIs). This is discussed further in the next section;

• Open business environments: “MyData”-like infrastructures enable decentralized management of personal data, improve interoperability, make it easier for companies to comply with tightening data protection regulations, and allow end-users to change service providers without proprietary data lock-ins.

Of course, this model is not a truly brand new concept; any smartphone owner is already familiar with providing permissions (storage, location, microphone, camera, calendar, contacts, etc.) for a newly downloaded application. However, on the Web, more advanced protocols and frameworks are required to enable end-users to link personal data from multiple services. Major ICT players such as Google, IBM, Microsoft, Amazon, Deutsche Telekom, salesforce.com are already moving towards initiatives such as OpenID and the related OpenID Connect protocol [15]. OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol, designed to use an existing account to sign in to multiple websites, without needing to create new passwords. An OpenID account is associated with a number of information (basic user profile, email, etc.); the user can decide which information he/she is willing to share with the website that is requiring authentication. The protocol can be used not only for authentication but also for authorization. For example, Google uses this mechanism to authorize third party to access its web services API. Web API automation services, such as Zapier (zapier.com) and IFTTT (ifttt.com), already leverage on this mechanism, enabling quite interesting workflows, such as “if my General Electrics Connected Fridge triggers a door open alarm, then blink my Philips Hue lights”. This kind of services demonstrates the power of the System-of-System approach. Unfortunately, this type of services requires the development of point-to-point connector to communicate with the supported systems. The next section discusses in detail the importance of open, and preferably standardized APIs, along with existing implementation technologies, for building a coherent ecosystems, which would minimize the need to develop custom connectors.

WebServices:Interoperability,Visibility,FriendlinessAPIs have been elevated from a development technique (Service Oriented Architecture – SOA, micro services) to business assets that are carefully planned and aligned with the overall company business strategy. Internet companies manage their API as a product, extending the reach of existing services and providing new revenue streams. What a few years ago was considered the realm of Internet



companies, is now spreading to a wider spectrum of industries (media, finance, telecommunications, travel/tourism, real estate, etc.), which are all embracing the so-called “API Economy” [16]. Interesting enough, not only the commercial sector is moving in this direction, but cities and nations are making their budget, public work, crime, legal, and other agency-related data and services available through API initiatives (see e.g. US Food & Drug Administration’s open FDA API program). At the time of writing this paper, programmableweb.com – a popular API directory service – counts over 15.000 public APIs, which is roughly doubling every 18 months. At first sight, relating this API phenomenon to IoT might seem far-fetched: many believe that IoT is mostly related with technologies at the Network and Transport layer (cf. Table 1), and “stops” when Internet interoperability (namely TCP/IP and HTTP) is achieved. Obviously, in bIoTope we do not share this view, because we believe that interoperability efforts are necessary at each layer of the stack presented in Table 1. This vision is increasingly shared by hardware manufacturers, too, as quoted e.g. by Raine Bergstrom (VP/GM Software and Services Products at Intel): “APIs are one of the fundamental building blocks on which the Internet of Things will succeed” [17]. However, as previously stated, a large number of vendors are today including in their offer an end-to-end IoT platform, resulting in a battleground for IoT platforms. These platforms are the root cause of the silos problem, and the best candidates to solve systems-of-systems integration towards a unified IoT are open and preferably standardized APIs.

Table 2 - Web Services implementation options, (H=human-understandable M=machine-understandable)

There are a number of solutions available to expose data and services on the Web, as summarized in Table 2. This table categorizes which approach is machine-(M) or human-(H) interpretable from a protocol operation and payload point of view. Furthermore, it evaluates how friendly it is, from a developer perspective, to expose and consume a web-service (see last two columns). Two clusters emerged from this table: (1) grey cluster: the web service payload is essentially interpreted by a human (i.e., API consumer-developer), and (2) green cluster: the web service payload can be interpreted by a machine. Although the vast majority of existing APIs fall into cluster (1), both clusters are discussed in greater detail in the following section. (1) Human interpretable: A decade ago, SOAP (Simple Object Access Protocol) and WSDL (Web Services Description Language) were the most widely used approaches to describe the methods and parameters exposed by a web-service. More recently, HTTP APIs have become the preferred choice for exposing an API. In many cases, legacy SOAP-endpoints are replaced with this kind of API. For the sake of correctness, this paper did not refer to these APIs as REST (Representational State Transfer)



[9] because, as pointed out by Roy T. Fielding [10]: there is a tendency to advertise any HTTP-based API that is not SOAP, as REST even if they follow only partially its principles. REST has become (erroneously) a synonym of performing CRUD (Create, Read, Update, Delete) over HTTP. First of all, REST is protocol-independent and thus not coupled to HTTP, even though it fits nicely with most of the principles of this architectural style. Having said that, today’s APIs fail to be truly REST because they are not hypertext-driven1. A REST client does not require any prior knowledge about how to interact with any particular service beyond a generic understanding of a standardized URI scheme. It acts just like a web-browser, once landed on the API home, each call provides a reference to related calls, allowing the client to literally browse the API. Although REST and SOAP cannot be directly compared – the first being an architectural style while the second is a standard – a core difference can be pointed out, notably related to the level of coupling between a client and service: updating a SOAP-based (and related WSDL) service, often leads to broken clients. Since the large majority of the publicly available APIs do not follow the REST hypertext-principle, initiatives are emerging to automatically generate browsable documentations for HTTP-APIs, such as OpenAPI (Swagger), RAML, and API Blueprint. Such machine-readable documentations essentially describe the HTTP verbs, as well as the URI and parameters to send in order to receive either a JSON or XML object. In conclusion, it seems that service developers are hand-picking what they find useful and converging to the simplest solutions that solve their problems. This often leads to negative impact over long-term maintenance of their system, and on the overall interoperability of the services. However, in such a competitive, fast-changing market, it is no surprise that pragmatism leading to quicker delivery has priority over long-term goals. Yet, even with these suboptimal solutions, the web-infused API Economy is flourishing. Nevertheless, the lack of a longer-term “ecosystem view” requires plenty of ad-hoc work for API consumers because there are largely inconsistent conventions on how an HTTP-API should be implemented and, as a consequence, the API consumer must read carefully the associated documentation and understand unique nuances of each API provider. The most telling examples are companies such as Zapier and IFTTT, who have a team of developers fully dedicated at implementing ad-hoc bindings for the supported third party services, reacting rapidly in updating their code whenever an external API is updated.

1 The hypertext-driven constraint is the non-negotiable cornerstone of REST because it allows decoupling between the client and service provider, thus enabling highly evolvable services with virtually no changes required on the client side.



(2) Machine interpretable: Since its conception, the mission of the World-Wide-Web is the standardized access to information and data. In [20], Tim Berners-Lee and the W3C first introduce the semantic-web concept, describing their vision for a machine-processable web of data. The original vision still remains largely unrealized, as the underlying standards for the semantic-web have been relegated to the academic world, while drifting away from the web-developer community. However, the underlying idea did not simply died out; the semantic-web has been revised and re-launched as the so-called LinkedData concept [21], focusing more on a web of data than on semantics. Unfortunately, the stack of standards remains largely the same as the ones prosed originally, which received little interest from the Web-developer community. What has changed is the maturity of the Web that is by far the number one medium for sharing data, thus making the Web-of-data concept more relevant and realistic than a decade ago. The API Economy is a clear sign of this transformation. The core idea of LinkedData is based on the principle of describing data items as URLs, which means that a machine can follow that link and discover additional data related (linked) with the original data-item. Even though the purpose is different, this resonates with the hypertext-driven principle of REST, once again highlighting the power of URLs linking. A very simple LinkedData example is depicted in Figure 4, where the simple pattern <subject-predicate-object> is how most western languages create basic sentences. In the LinkedData world, this type of relationship is serialized using RDF (Resource Description Framework), and can be queried using a standardized language called SPARQL (Protocol and RDF Query Language). Explaining the details of these standards is outside the scope of this deliverable. Instead it is interesting to investigate the relationship between semantic technologies and the dominant API approach for achieving interoperable ecosystem.

Figure 4 - LinkedData principle example

As already mentioned above, SPARQL is a query language for graph data (as much SQL is for relational databases) and theoretically, it could replace a large number of the existing HTTP APIs designed for accessing/reading data. In other words, we can say that for accessing data if you have a standardized query language there is no need for APIs. Instead, shared vocabulary schemas, so called OWL ontologies, can act as an interface for accessing the data. For example, any developer give for granted that he/she can interact with a relational database using SQL. While for other type of storage (big-data, documents etc.), he/she needs to comply with a specific API defined by the vendor. In conclusion it should be an obvious choice to select SPARQL (and RDF) as ultimate interoperability mechanism to access data on the web, but unfortunately this is not what is happening in reality. There is no well-known scientific study that explains the underlying reasons for this situation, however there are few known situations that can be experienced when deploying a SPARQL endpoint: Being a rich and expressive querying language, it is straightforward to write highly inefficient queries, leaving the endpoint exposed to very primitive DoS (Denial of Service) attacks. Even properly formed queries often require a quite a lot of computing power, which translate in poor scalability, and if a large number of (1000+) frequent consumers of data need to be supported, which is a typical scenario when creating subscription to events happening in external services, acceptable response time (< 500ms) and reasonable availability (>99%) are very hard to meet. Being able to subscribe to events happening on third party services is a very important functionality that the bIoTope ecosystem must be able to support. Currently services like IFTTT and Zapier, leverage on this mechanism (in some cases called WebHooks) for pretty much all their third party connectors. By putting in charge the third party service to notify the subscribers whenever a given event is fired, it is possible to save a considerable amount of resources, in terms of unnecessary http-connections used by traditional long-polling methods. SPARQL has not been designed for this type of use, and even if we are pretty sure it



will eventually find its way the preferred method to discover and retrieve open data, it will not work as ideal endpoint interface for the bIoTope ecosystem. Table 2 made a distinction between protocol operation and payload. This corresponds to SPARQL and RDF in the semantic technologies domain. Even though we ruled out SPARQL (in favor of Web-APIs), being able to process and understand the payload is crucial for interoperability. The quest for machine-interpretable information must deal at some point with the existence of a shared vocabulary, in which applications can look up and identify a specific data-item (a subject, a predicate or an object). This concept is the main driver for what is referred to as standardized API in Table 2. Existing standards such as oBIX (Open Building Information Xchange) or ebXML (Electronic Business XML) precisely define the payload structure and items in conjunction with the operations for retrieving them. These types of standards usually address interoperability challenges within a given vertical domain or industry. As a result, this approach lacks generality but when it comes to machine interpretable interfaces, it is essentially the dominant option. Within the realm of standardized API, there are also some hybrid general approaches, e.g. O-Data (Open Data Protocol) [22] or Open Messaging Interface (O-MI) and Open Data Format (O-DF) [23] that define operation semantics and basic skeleton structure for the returned payload (i.e., for describing the service resource), leaving freedom regarding the semantics of the single data-items. One way to get around this limitation is to enrich these data-items with external controlled vocabularies. A successful example, that has been proven to work at an Internet scale is schema.org, which is an initiative sponsored by Google, Microsoft, Yahoo and Yandex to develop, maintain, and promote schemas for structured data. Following the LinkedData principle, the creation and extension of these vocabularies is a community-driven collaborative activity. Currently, over 10 million sites use schema.org to semantically enrich their web pages and email messages. The process simply consists in marking-up content with controlled – by schema.org – metadata that can be recognized by search engine crawler and other parsers, which leads to a better indexing and classification. This win-win situation between webmasters and search engines is the main reason of the success of this initiative. Even though schema.org is probably the most successful example of controlled vocabulary, the web is full of similar, complementary and sometimes competing initiatives, such as FOAF, SKOS or more related to IoT like SSN (Semantic Sensor Network Ontology) just to mention some. For bIoTope what is interesting to notice is that it is possible to apply the exact same semantic enrichment mechanism to the payload returned by APIs. In fact, initiative such as JSON-LD (JavaScript Object Notation - LinkedData) are already proposing solutions in this direction. Besides its serialization format (being RDF or JSON-LD), semantic interoperability at the data-item level is a tough problem to solve. Controlled vocabularies organized in taxonomies or ontologies, have a long history and their usability is usually hampered by their complexity (number of concepts and taxonomy levels). For example, from a statistical point of view, finding a specific term in a very deep taxonomy organized in tree-like structure (supposing a 90% chance of hitting the correct branch at every tree level) leads to the following: after 10 levels, the joint probability of being in the right branch is 35%, after 20 levels it is 0.12%, after 30 levels it is only 0.04%. Besides this mathematical diversion, it is quite intuitive that agreeing on the usage of a small term-set for limited domains (as traditional standards do) is much easier than converging to a generalized taxonomy. Looking for one large unified ontology encompassing the wide range of sectors (smart industry, health, building/living, transport, energy, environment, etc.) in which IoT finds application will most likely fail. An additional prove is provided by a survey conducted over 1500 popular ontologies [24] reported that on average the vast majority of ontologies are also small and quite flat (the ontology hierarchy is in average very small - Avg Num. of Classed = 36.11, Avg Num. of Root Classes = 6.69, Avg Num. of Leaf Classes= 27.46, Explicit Depth of Subsumption Hierarchy = 2.54). Despite these challenges, we believe that the most promising approach to Internet-scale machine-interpretable interfaces will include a combination of a set of controlled vocabularies following the LinkedData principles for describing the data-items served via standardized APIs.



The designated solution must lead to a win-win situation, where developers and businesses have a clear incentive in joining an ecosystem by following its principles and guidelines (e.g. automated APIs search and discovery, plug & play integration with popular workflow automation services, etc.).

SelectedTechnicalSolutionIn the previous section, we justified the selection of standardized APIs approach in combination with controlled vocabularies, without mentioning one in particular. Naturally for bIoTope, the preferred standardized API will be O-MI with O-DF as payload, as its usage has been promised in the bIoTope project application. Table 3 highlights the position of the O-MI and O-DF in the Web-Of-Things stack introduced in Table 2. It is important to notice that O-MI does not necessarily impose O-DF as payload. This is a significant advantage because even if O-DF has been mentioned in the funding application it does not mean that new and maybe more appropriate serialization format will emerge in the future.

Table 3 - O-MI, O-DF and json-ld position in the web-of-things stack

O-DF JSON-LD

O-MI

APPLICATION (WoT focus)

Scripts that define Thing behavior in terms of their properties, actions and events, using APIs for control of sensor/actuator hardware -- Focus on data types & APIs

THINGS (WoT focus)

Software objects that hold their state. Abstract Thing to Thing messages. Semantics and Metadata. Data models and Data.

TRANSFER (IoT focus)

Bindings of abstract messages to mechanism provided by each protocol, including choice of communication pattern e.g. pull, push, pub-sub, peer to peer etc.

TRANSPORT (IoT focus)

REST based protocols (e.g., HTTP, CoAP); Pub-Sub protocols (e.g., MQTT, AMQP, XMPP…).

NETWORK (IoT focus)

Underlying communication technology with support for exchange of simple messages (packets). Many technologies designed for different requirements (WiFi, Z-wave, ZigBee, Bluetooth…).

In fact, in bIoTope we are already investigating how O-MI can transport JSON-LD as one of the supported payload, as it is specifically designed for semantic enrichment of data-item via controlled vocabularies following the LinkedData principles. This decision has also been reinforced by a collaboration agreement found with another H2020 EU project, namely BIG-IoT. This project, has many points in common with bIoTope, as they are both striving for the emergence of a cross- standard, cross-platform, and cross-domain IoT services and applications towards an open IoT ecosystem. We are already looking into selecting and aligning shared vocabularies, which would be helpful to describe the use-cases of the projects. Currently we are investigating a new iteration of SSN (Semantic Sensor Network) ontology, which will support actuators in addition to sensors; and the IoT-Lite ontology, which has been developed by the EU FP7 FIWARE project and currently by EU H2020 FIESTA-IoT project. In addition to these general ontologies, some of bIoTope partners (Eccenca, BMW and BIBA) are working in parallel to the definition of domain specific vocabularies, such as MobiVoc (open vocabulary for future-oriented mobility solutions), or yet again Datex where it is possible to find the Linked Data porting of the DATEX II standard for intelligent transportation systems on European roads.



Figure 5 - Relationship and Cooperation between the bIoTope and BIG-IoT EU projects

Figure 5 depict the relationship and area of clear cooperation between bIoTope and BIG-IoT. Obviously, even though we have a clear idea regarding the method and core technologies we are going to use, there is still quite a lot of work to do (both in bIoTope and BIG-IoT) before defining the exact payload structure and compulsory and optional data-items that must contain. Hopefully, in bIoTope the use-case requirements described in deliverable 2.1, will provide additional insight on this topic.



4. bIoTopeCoreServices

To join the envisioned bIoTope ecosystem, a service simply need to describe its offering using the methods and technologies described above. At this point, any service is able to exchange data with this endpoint, defining new and innovative workflows. The only missing bit of this scenario is for the other services in bIoTope to become aware of the presence of this new endpoint. In simpler words they need to discover or being notified of a new URL, which has joined the ecosystem. Ideally, if the bIoTope ecosystem will be successful, it will be possible to discover running services, simply using the preferred search engine and/or maps service. As any search engine crawler will know how to index a bIoTope a service, a simple illustration of this (hopefully) future scenario is depicted in Figure 6. Currently search engine index only public HTML pages, but in a foreseeable future they will start to index APIs, especially if they are able to understand what type of content the API has to offer. The semantic enrichment process described in the previous sections is crucial in allowing search engines to understand and properly index any digital content. This is already happening for webpages and e-mail (e.g. automatic clustering provided in G-Mail), and eventually it will happen for APIs.

Figure 6 - Search engine and Maps Service crawling the web for indexing O-MI Nodes



When it comes to discovery, there are essentially two model to be considered: (1) Pull: it consist in proactively discover resources by crawling systematically browsing the web

for new content. (2) Push: when a search engine becomes popular as Google, websites owner want their website to

be indexed and be ranked among the top for a given search query. In this case webmaster notify and semantically enrich their sites according to the guidelines provided by the selected search engine (e.g. for Google https://developers.google.com/search/docs/guides/intro-structured-data).

Currently for public APIs there is only a directory service, such as http://www.programmableweb.com/, in which APIs providers proactively (push) describe their service, which in turn becomes searchable by simple keyword matching (see Figure 7).

Figure 7 - Search engine and Maps Service crawling the web for indexing O-MI Nodes

The scenario depicted in Figure 6 is a look into the future of discovery of IoT web services. Search engines will eventually do it, only in case the bIoTope ecosystem will become a world-wide success. Clearly, it makes little sense to assume the “success of the bIoTope ecosystem” as pre-requisite for the discovery mechanism; some intermediate actions must be taken. In order to boost adoption it is necessary to develop a service that would showcase the envisioned behaviour, acting as discovery entry point for the entire ecosystem. Fortunately, in bIoTope we have the right partners to implement, maintain and run (in real production environment) such a service. OpenDataSoft has been selected exactly for this kind of task. Their platform is based on a well-known open source search engine (ElasticSearch) and their UI web-components are also open source. This means that once the necessary components will be developed for the OpenDataSoft platform, a large portion of the code developed can be reused by other services, increasing dramatically the chance of success of the entire ecosystem.



Figure 8 - O-MI O-DF Search Engine based OpenDataSoft platform

Figure 8 depict the overall behaviour of version 1 of this service: 1) An O-MI endpoint, advertise its URL (push) in the OpenDataSoft platform. 2) The platform will perform a ReadALL operation, which will retrieve all the objects and their

description offered by the endpoint. 3) The returned payload (serialized in JSON-LD) will be parsed and transformed into an

ElasticSearch insert query. Once again, it is crucial to select and support the most relevant vocabularies (see Figure 5) for IoT applications, as they can be used as facets (also known as search refiner: like AQI Category and PM(24h) in the left-hand side of Figure 8 map).

Future version might also include a pulling mechanism and smarter way to authenticate with a given endpoint, such as the MyData model described in section 3.1. These topics will probably be addressed in future deliverables, while for now we will focus our efforts in developing:

1) A connector for the O-MI protocol. 2) A general parser for the O-DF data model in JSON-LD format. Our intention is to develop a

so-called river for ElasticSearch and publish it as open source for the ElasticSearch community. 3) Design and develop a set of open source UI Web-Components (such as maps, graphs, search

refiners, etc.) that can guide the user in the discovery IoT devices, data and services.



References 1. C. Wang and N. Kato, “Inaugural editorial,” IEEE Internet of Things Journal, vol. 1, no. 1, pp. 1–

2, 2014. 2. K. Ashton, “Internet things – mit, embedded technology and the next internet revolution” in

Baltic Conventions, The Commonwealth Confer- ence and Events Centre, London, 2000. 3. K. Främling, J. Holmström, T. Ala-Risku, and M. Kärkkäinen, “Product agents for handling

information about physical objects,” Report of Laboratory of information processing science series B, TKO-B, Tech. Rep. 03, 2003.

4. M. Blackstock and R. Lea, “Iot interoperability: A hub-based approach,” 4th IEEE International Conference on the Internet of Things, 2014.

5. D. Miorandi, S. Sicari, F. De Pellegrini, and I. Chlamtac, “Internet of things: Vision, applications and research challenges,” Ad Hoc Networks, vol. 10, no. 7, pp. 1497–1516, 2012.

6. Z. Panga, L. Zhengb, J. Tianb, S. Kao-Walterc, E. Dubrovab, and Q. Chenb, “Design of a terminal solution for integration of in-home health care devices and services towards the internet-of-things,” Enter- prise Information Systems, 2013.

7. J. Stankovic, “Research directions for the internet of things,” IEEE Internet of Things Journal, vol. 1, no. 1, pp. 3–9, 2014.

8. D. Bandyopadhyay and J. Sen, “Internet of things: Applications and challenges in technology and standardization,” Wireless Personal Communications, vol. 58, no. 1, pp. 49–69, 2011.

9. IoT Analytics, List of 260+ IoT Platform Companies, Available online at: https://iot-analytics.com/product/list-of-260-iot-platform-companies/

10. O. Vermesan, and P. Friess, Internet of Things – From Research and Innovation to Market Deployment, River Publishers, 2014.

11. The World Economic Forum, Personal Data: The Emergence of a New Asset Class, January 2011 – Available online: http://www3.weforum.org/docs/WEF_ITTC_PersonalDataNewAsset_Report_2011.pdf

12. Raggett D., Using semantics and rich metadata to bridge IoT silos — W3C’s work on the Web of Things - ETSI M2M Workshop - 9 December 2015 https://www.w3.org/2015/12/09-wot-m2m.pdf

13. European Union, Reform of EU data protection rules, Available online at: http://ec.europa.eu/justice/data-protection/reform/index_en.htm

14. Poikola A., Kuikkaniemi K., Honko H., MyData – A Nordic Model for human-centered personal data management and processing, 2014, Finnish Ministry of Transportation and Communication; Available at: http://www.lvm.fi/-/mydata-a-nordic-model-for-human-centered-personal-data-management-and-processing-860616

15. The OpenID Foundation, OpenID Connect Official Website: http://openid.net/connect/ 16. Deloitte, API economy, From systems to business services, Available

online:http://www2.deloitte.com/content/dam/Deloitte/us/Documents/financial-services/ us-fsi-api-economy.pdf

17. Deloitte, The fusion of business and IT, Available online: http://www2.deloitte.com/content/dam/Deloitte/ch/Documents/technology/ch-en-technology-tech-trends-2015.pdf

18. Fielding R.T., “Architectural styles and the design of network-based software architectures”, PhD thesis: University of California, 2000.

19. Fielding R.T., REST APIs must be hypertext-driven, October 2008, Available online at: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven



20. Berners-Lee, Tim, James Hendler, and Ora Lassila. "The semantic web." Scientific american 284.5 (2001): 28-37.

21. W3C, LinkedData Standards Official Website: https://www.w3.org/standards/semanticweb/data 22. OASIS, Open Data Protocol, Available at: https://www.oasis-

open.org/committees/tc_home.php?wg_abbrev=odata 23. The Open Group, Internet of Things (IoT) Work Group, Available at:

http://www.opengroup.org/getinvolved/workgroups/iot 24. Rodriguez D., Sicilia M.A., Garcia E. - Empirical Findings on Ontology Metrics - Department of

Computer Science University of Alcala