IoT Semantic Interoperability: Research Challenges, Best Practices, Solutions and Next Steps. - IERC AC4 Manifesto - Present and Future

Transcription

1 Manifiesto-V1 IoT Semantic Interoperability: Research Challenges, Best Practices, Solutions and Next Steps - IERC AC4 Manifesto - Present and Future IERC AC

2 Manifiesto-V1 IERC AC4: Service Openness and Inter-operability Issues-Semantic interoperability Project Reference: Activity Cluster: Document Title: IERC AC4 Semantic Interoperability Semantic Interoperability: Research Challenges, Best Practices, Solutions and Next Steps - IERC AC4 Manifesto - Disciplinary area(s) most relevant topics: Future Internet, Internet of Things, Semantic Web. Keywords: Service Openness, Semantic Interoperability, Ontologies Editors: Martin Serrano, Payam Barnaghi and Philippe Cousin Document Id: IERC-AC Deliverable-AC41 File Name: Manifesto-V1.doc Version: V1 Organization: IERC-AC4 Date: Document type: Deliverable-AC4-1 (IERC AC4 Manifesto) Security: Confidential (CO)

3 Manifiesto-V1 EXECUTIVE SUMMARY The European Research Cluster on the Internet of Things 1 (IERC) has created a number of activity chains to initiate close cooperation between the projects addressing the IoT related topics and to form an arena for exchange of ideas and open dialog on important research challenges. The activity chains are defined as work streams that group together partners or specific participants from partners around well-defined technical activities that work on addressing the IERC objectives. As result of the organization of activity chains within the IERC and the continued collaboration and active participation between the ProbeIT, OpenIoT, IoT.est and GAMBAS projects, the managers of those projects were nominated as coordinators of the IERC Activity Chain 4 (AC4) on Interoperability. As activity cluster coordinators, we have defined two streams of activities related to Technical Interoperability: Syntactic and Semantic Interoperability. The results of the current work and collaborations on this topic are presented in this report. One of the main objectives of the IERC AC4 is to specify service openness and standardize interoperability issues when possible. Since standardization needs to ensure interoperability, AC4 not only addresses technological interoperability issues but also semantic interoperability capabilities. Semantics play an important role in many of the EU FP7 projects. The IERCAC4 has allocated efforts on semantic interoperability within the objective to offer the most to the participants in order to obtain the necessary guidance to implement semantic solutions, when it is necessary. By following the enormous interest in Semantics for IoT, as part of the contributions and efforts in the IERC AC4, we have organized and coordinated several AC4 meetings and workshops on related topics. After the IERC AC4 kick-off meeting in Poznan, Poland on 28/10/2012 the IERC AC4 ran a one-day workshop on March 26th 2012 in Paris, France. It was co-located with the PROBEIT project meeting. Short presentations of the AC4 project participants were followed by open discussions to identify challenges on service openness and interoperability issues. The next event was a two-day meeting and hands-on workshop colocated with the IoTWeek June 2012 in Venice, Italy. On October 2012 met at Mandelieu, France at the ETSI plenary meeting and the IERC AC4 co-located a two-day workshop including tutorials focused on semantic modelling, knowledge representation and ontology engineering for the IoT domain. This year IERC AC4 co-located the last meeting with the 19th European Wireless 2013 conference at Guilford, UK that included hands-on sessions on data interoperability and ontology engineering tools. We hope this document contributes to the development of interoperability solutions for the Internet of Things within the IERC AC4 EU-FP7 project members and also supports establishing effective mechanisms to find coordination in terms of semantic interoperability. IERC AC4 Coordinators August

4 Manifiesto-V1 List of Authors (non particular order): Martín Serrano Payam Barnaghi Philippe Cousin NUIG Digital Enterprise Research Institute DERI, OpenIoT UniS, Centre for Communication Systems Research CCSR, IoT.est eglobalmarket Easy Global Market, ProbeIT List of Contributors (non particular order): Manfred Hauswirth NUIG Digital Enterprise Research Institute DERI, Ireland Josiane Javier Parreira NUIG Digital Enterprise Research Institute DERI, Ireland Christian von der Weth NUIG Digital Enterprise Research Institute DERI, Ireland Myriam Leggieri NUIG Digital Enterprise Research Institute DERI, Ireland John Soldatos Athens Institute of Technology AIT, Greece Nikos Kefalakis Athens Institute of Technology AIT, Greece Stavros Petris Athens Institute of Technology AIT, Greece Dimitros Georgakopoulos CSIRO, Australia Arkady Zaslavsky CSIRO, Australia Ali Salehi CSIRO, Australia Karl Aberer Ecole Polytechnique Federale de Lausanne, Switzerland Sofiane Sarni Ecole Polytechnique Federale de Lausanne, Switzerland Reinhard Herzog Fraunhofer IOSB, Germany Panos Dimitropoulos SENSAP Microsystems SENSAP, Greece Nikos Zarokostas SENSAP Microsystems SENSAP, Greece Angele Giuliano AcrossLimits, Malta Johan E. Bengtsson AcrossLimits, Malta Pedro Malo Uninova, Portugal Cesar Viho University of Rennes I, France. Kotis Konstantinos VTT Technical Research Centre of Finland, Finland Hiroyuki Maeomichi NTT Network Innovation Laboratories, Japan Abdur Rahim Create-Net, Italy Charalampos Doukas Create-NET, Italy Davy Preuveneers KU Leuven, Belgium Franck Le Gall INNO Group, France Copigneaux Bertrand INNO Group, France Tobias Muench SAP AG, Germany Oscar Lazaro Innovalia Association, Spain Klaus Moessner UniS, CCSR, United Kingdom Nikolaos Georgantas INRIA, France Valerie Issarny INRIA, France Rob van Kranenburg The Internet of Things Council, United Kingdom Maurizio Pilu TSB, United Kingdom Richard Foggie HOIP, United Kingdom Cheng Sheng Beijing University of Posts and Telecommunications, China Ji Yang Beijing University of Posts and Telecommunications, China Marie Kim ETRI, South Korea. Michael J. Koster Open Source Internet of Things OSIoT, U.S.A. Continue...

5 Manifiesto-V1 List of Project Participants and Contributor Initiatives (non particular order): Project Acronym PROBE-IT OpenIoT GAMBAS IoT.est IoT-I IoT-A ebbits SmartAgriFood icore BUTLER IoT6 Name of Project Pursuing ROadmaps and BEnchmarks for the Internet of Things Open Source Solution for the Internet of Things into the Cloud Generic Adaptive Middleware for Behaviordriven Autonomous Services Internet of Things Environment for Service Creation and Testing Internet Of Things Initiative Internet of Things Architecture Enabling the Business-Based Internet of Things and Services Smart Food and Agribusiness Internet Connected Objects for Reconfigurable Ecosystems Internet of Things at Work Secure and Context Awareness in the IoT Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture enabling heterogeneous components interoperability Coordinator Frank Le Gall and Philippe Cousin INNO AG, France Manfred Hauswirth and Martin Serrano National University of Ireland, Galway, Ireland Sandra Kramm, Universitaet Duisburg-Essen, Germany Klaus Moessner and Payam Barnagui University of Surrey, UK Rahim Tafazolli and F. Carrez, University Of Surrey, UK Sebastian LANGE, VDI/VDE-IT Markus Eisenhauer, Fraunhofer FIT, Germany Sjaak Wolfert, Stichting Dienst Landbouwkundig Onderzoek, The Netherlands Raffaele Giaffreda, CREATE-NET, Italy Amine M. Houyou, Siemens AG, Germany Frank Le Gall, INNO AG, France Sébastien Ziegler, Mandat International, Switzerland Initiative Acronym Name of the Initiative Representative IoT Council The Internet of Things Council Rob van Kranenburg WoT China The Web of Things Cheng Sheng and Ji Yang IoT Korea Common Open semantic USN Service Platform Marie Kim IoT Japan IoT USA Open Source Internet of Things OSIoT Michael J. Koster... Continue

6 Manifiesto-V1 If you would like to endorse this document, presentation and content please send your contact details to and Document Endorsements (non particular order): Name Affiliation Project Acronym(s) IERC/Other Project Disclaimer: The objective of this document is merely informative and for dissemination activities and in any case can be considered as evaluation reports or points of reference from any research objective or implementation metrics of the EU FP7 projects. The material and content in this document does not represent any formal position of the European Commission or any Organization members or individuals. The statements included in this document are not final statements and can be modified, updated, changed according with the progress and evolution of the IERC-AC4. Copyrights: The statements included in this document represent the general opinion of the authors and their EU FP7 project consortium and its individuals. The copyrights and use of this intellectual material is for the sole use of dissemination and it is strictly restricted to IERC- AC4 members and their affiliated; if an individual, institution or any type of organization outside IERC-AC4 want to make use of them on behalf of the IERC-AC4, must be submitted for approval of the IERC-AC4 Coordinator and/or IERC-AC4 co-coordinator or at least an authorized IERC-AC4 consortium member

7 Manifiesto-V1 DOCUMENT HISTORY Date Version Status Comments 20.Jun Draft Initial ToC at IoT Week, Venice, Italy 21.Oct Draft Discussion on ETSI M2M IERC AC4 meeting Mandelieu, France 18.Apr Draft IERC AC4 meeting at EW 2013, Guilford, UK 15.May Draft External Liaison Projects 18.Jun Draft Release at IoTWeek 2013, Helsinki, Finland For comments / contributions 10.Jul Draft Data Collection contributions: Section 3.2 Update 25.Jul Draft Data Formalism and Languages in IoT: section 3.4 Update 10.Aug Draft Editors Conference Call Review on Additional Project Contributions 25.Aug Draft Final Edits / Contributions 30.Aug.2013 V.1 Final V1 Released / Circulated 1

8 Manifiesto-V1 TABLE OF CONTENTS Foreword Scope Audience Summary Structure Introduction Semantics and Interoperability Semantics and technology Semantic for interoperability Semantics why, where, how? Vocabulary and Terminology Data Model Information Model Data exchange Knowledge representation Knowledge sharing Mapping Matching and Alignment Concepts Representation Relationships Functions Instances Axioms Ontology Objects vs. Things Interoperability by Ontologies Methodologies & Tools for Data in IoT Taxonomy and Structure of the Information By its persistence:

9 Manifiesto-V By its medium: By its relevance to the service: By its temporal characteristics: By its temporal situation: Capturing the information (how information is acquired in IoT) Observation, Measurement and Actuation Resource Description Entity Description Data Publishing and consumption Publishing Consuming Data Formalisms and Languages in IoT Semantic web technologies Other alternatives Tools for Developments & Implementations in IoT Software project management tool Apache Maven Development Environment Eclipse IDE Web-Service implementation Apache CXF User Interfaces Web Clients Fat Clients Platform Management Java Management Extensions (JMX) Enterprise Application Platform JBoss Application Platform Knowledge Database RDF Database JENA Sesame Virtuoso Ontologies Sensor Domain Semantic Sensor Network Ontology (SSN)

10 Manifiesto-V Social Communities Domain Semantically-Interlinked Online Communities (SIOC) Friend Of A Friend Ontology (FOAF) Provenance Ontology (PROV) Association Ontology (AO) Context Information Modeling Domain Event Model-F Ontology (Event)) SPITFIRE Ontology (SPT) Network Components Domain SPITFIRE Ontology (SPT) Energy Domain SPITFIRE Ontology (SPT) Cloud Computing Domain IT Services Ontology (ITSO) Cloud4SOA Project UCI Project MOSAIC Project Scenarios / Use cases Smart City Student Campus Application Application Description External Interfaces Requirements Application Functionalities and Functional Requirements Non-Functional Requirements Phenonet Agriculture Application Application Description Application Functionalities and Functional Requirements Onsite sensor diagnostic tool (e.g., Android application on tablets) Domain-specific Analysis and Visualisations Non-Functional Requirements Licencing Requirements Manufacturing Application Application Description Manufacturing Environment Application Scenarios Application Functionalities and Functional Requirements Main Functionalities

11 Manifiesto-V Sensors and Internet-Connected Objects Involved Utility to be Measured List of Functional Requirements External Interfaces Requirements Non-Functional Requirements Other Requirements Other End-user Applications Applications from other IERC projects ebbits IoT-A ELLIOT NEFFICS ( FP7 Projects interested/related with semantics icore-internet Connected Objects for Reconfigurable Eco-System A brief description of the project Interoperability related issues (focus on semantics) Semantic Interoperability of VOs/CVOs icore vision in terms of Semantic Interoperability Current approach IoT@Work (Internet of Things at Work) A brief description of the project Interoperability related issues (Semantics) Current approach Internet of Things Environment for Service Creation and Testing (IoT.est) A brief description of the project (Short Abstract) Interoperability related issues (Semantics) Current approach (Advances, Development, Solutions, etc.) Generic Adaptive Middleware for Behavior-driven Autonomous Services (GAMBAS) A brief description of the project (Short Abstract) Interoperability related issues (Semantics) Current approach (Advances, Development, Solutions, etc.) ubiquitous, secure internet-of-things with Location and contex-awareness (BUTLER) A brief description of the project (Short Abstract) Interoperability related issues (Semantics) Current approach (Advances, Development, Solutions, etc.)

12 Manifiesto-V1 6.6 Enterprise Collaboration & Interoperability (COIN) A brief description of the project (Short Abstract) Interoperability related issues (Semantics) Current approach (Advances, Development, Solutions, etc.) Open source blueprint for large scale self-organizing cloud environments for IoT applications (OpenIoT) A brief description of the project (Short Abstract) Interoperability related issues (Semantics) Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture enabling heterogeneous components interoperability (IoT6) A brief description of the project (Short Abstract) Interoperability related issues (Semantics) Current approach (Advances, Development, Solutions, etc.) SmartAgriFood (FI PPP Grant no ) A brief description of the project (Short Abstract) Interoperability related issues (Semantics) Current approach (Advances, Development, Solutions, etc.) Emergent Connectors for Eternal Software Intensive Networked Systems CONNECT A brief description of the project (Short Abstract) Interoperability related issues (Semantics) Current approach (Advances, Development, Solutions, etc.) Large Scale Choreographies for the Future Internet CHOReOS A brief description of the project (Short Abstract) Interoperability related issues (Semantics) Current approach (Advances, Development, Solutions, etc.) Collaborative Manufacturing Network for Competitive Advantage ComVantage A brief description of the project (Short Abstract) Interoperability related issues (Semantics) Current approach (Advances, Development, Solutions, etc.) External Liaison Projects Project Title: Interoperable Sensor Networks (09034 ISN) A brief description of the project (Short Abstract) Interoperability related issues (Semantics) Current approach (Advances, Development, Solutions, etc.)

13 Manifiesto-V1 8 IoT Initiatives Council, a think-tank for the Internet of Things (UK) A brief description of the project (Short Abstract) Interoperability related issues (Semantics) Current approach (Advances, Development, Solutions, etc.) Researches of architecture and key technologies of WEB based wireless ubiquitous service environment, and proof-of-concept & demonstration (China) A brief description of the project (Short Abstract) Interoperability related issues (Semantics) Current approach (Advances, Development, Solutions, etc.) COMUS - Common Open semantic Usn Service Platform (Korea) A brief description of the project (Short Abstract) Interoperability related issues (Semantics) Current approach (Advances, Development, Solutions, etc.) Future Actions / Activities Semantic technologies and IoT resource description frameworks Practical modelling and ontology engineering Interoperability evaluation Interfaces and communications The software and tools requirements Conclusions References Annex I: Other Useful References

14 Manifiesto-V1 LIST OF FIGURES FIGURE 1. THE DIMENSIONS OF INTEROPERABILITY FIGURE 2. SEMANTIC WEB TECHNOLOGIES FIGURE 3. INFORMATION MODELS ONTOLOGY ENGINEERING FIGURE 4. KIT CAMPUS AREA FIGURE 5. KITCAMPUSGUIDE AS AN HERO APPLICATION FIGURE 6. PICTURE: IOT EQUIPPED WORKPLACE FIGURE 7. ENHANCEMENT OF THE KCG WORKPLACE SEARCH WITH IOT TECHNOLOGY FIGURE 8. MAIN DATA SOURCES FOR CROP PERFORMANCE MONITORING IN THE SCOPE OF THE PHENONET PROJECT FIGURE 9. ILLUSTRATION OF LICENCING REQUIREMENTS ASSOCIATED WITH THE (RE)USE OF PHENONET IN THE SCOPE OF OPENIOT FIGURE 10. IMAGE SENSOR TO BE USED IN THE MANUFACTURING SCENARIOS FIGURE 11. OPTICAL DIFFUSION SENSOR TO BE USED IN THE MANUFACTURING SCENARIOS FIGURE 12. LASER BARCODE SCANNER (ULTRA HIGH SPEED) TO BE USED IN THE MANUFACTURING SCENARIOS (FOR PROOF OF DELIVERY) FIGURE 13. SMART PROXY ARCHITECTURE FIGURE 14. THE GAMBAS APPROACH FIGURE 15. THE OPENIOT APPROACH FIGURE 16. REFERENCE ARCHITECTURE FOR DATA- AND PROCESS-INTEROPERABILITY IN A VIRTUAL ENTERPRISE FIGURE 17. WOT SYSTEM ARCHITECTURE IN THE PROJECT FIGURE 18. ITU-T F.OPENUSN (DRAFT) FIGURE 19. RESOURCE ONTOLOGY GRAPH REPRESENTATION FIGURE 20. DOMAIN ONTOLOGY MAPPING REPRESENTATION FIGURE 21. LINKED OPEN DATA LOUD REPRESENTATION FOR SENSOR SERVICES FIGURE 22. THE ECONOMIC DIMENSION IN THE INTERNET OF THINGS LIST OF TABLES TABLE 1: IOT TECHNICAL INTEROPERABILITY CHALLENGES/REQUIREMENTS TABLE 2: IOT SEMANTIC INTEROPERABILITY CHALLENGES/REQUIREMENTS

15 Manifiesto-V1 TERMS AND ACRONYMS 6LoWPAN AAL ARM BPM BPMN BPWME CoAP CPI CRUD DOLCE DoW DSO EPC EPC-ALE EPC-IS ERP GPL GPS GSN GTIN HTML HTTP JSF ICO ICT IEEE IETF IERC IoT LGPL MRP OGC IPv6 over Low power Wireless Personal Area Networks Ambient Assisted Living Architecture Reference Model Business Process Language Business Process Modelling Notation Business Process Workflow Management Editor Constrained Application Protocol CSIRO Plant Industry CReate, Updated, Delete Descriptive Ontology for Linguistic and Cognitive Engineering Description-of-Work Decision Support Ontology Electronic Product Code Electronic Product Code Application Level Events Electronic Product Code Information Sharing Enterprise Resource Planning General Public Licence Global Positioning System Global Sensor Networks Global Trade Item Number HyperText Markup Language Hypertext Transfer Protocol Java Server Faces Internet-Connected Objects Information and Communication Technologies Institute of Electrical and Electronics Engineers Internet Engineering Task Force Research Cluster for the Internet of Things Internet of Things Lesser General Public License Manufacturing Resource Planning Open Geospatial Consortium 9

16 Manifiesto-V1 OMG ONS PDA PET QoS QR-Code RDF REST RFID SGTIN SLA SME SOA SOS SPS SSN UML WSN XML Object Management Group Object Naming Service Personal Digital Assistant Privacy Enhancing Technologies Quality of Service Quick Response Code Resource Description Format Representational State Transfer Radio Frequency Identification Serialized Global Identification Number Service Level Agreement Small Medium Enterprise Service Oriented Architecture Sensor Observation Service Sensor Planning Service Semantic Sensor Networks Unified Modelling Language Wireless Sensor Networks extensible Markup Language 10

17 Manifiesto-V1 Foreword The design of the Internet and telecommunication systems relies on the convergence of Software Engineering and Technology (infrastructure). Every day it is a common practice to think/design cross solutions between software and infrastructure in order to provide integrated solutions for some of the complex problems in the current and future Internet systems. In Information Technologies and Communications (ITC) systems this convergence is evident, however the conceptual realization is far from achieving a full deployment of converged services and technology. Current ITC research is focused on the integrated solutions and primarily on the feature that enable convergence named as Interoperability. Interoperability can be generalized as the feature for providing seamless exchange of information to, for example, personalize services automatically or simply exchange information that other systems can use for improving performance, enable and create services, control operations and information processing. This type of scenarios requires increased interoperability in service management operations. Scope In this document we review recent trends and challenges on interoperability, discuss physical versus virtual and while addressing technology interoperability challenges in parallel, discuss how, with the growing importance of data understanding and processing, semantic web and their technologies, frameworks and information models can support data interoperability in the design of the Future Internet. Internet of Things (IoT) is taken as reference example in enterprise applications and services and their importance of the economic dimension. Audience This document addresses the following audiences: Researchers and engineers within the IERC-AC4 community, which will take into account the various requirements in order to research, design and implement the architecture of the OpenIoT platform. Researchers on IoT systems at large, given that the present deliverable could be a useful reading for researchers studying alternative IoT technologies and applications, along with indications and requirements towards building/establishing AIT architectures. Members of other Internet-of-Things (IoT) projects (such as projects of the IERC cluster), which can find in this document a readily available requirements analysis for utility-based IoT applications. For these projects the document could provide insights into requirements and technological building blocks enabling the convergence between utility/cloud computing and the Internet-of-Things. 11

18 Manifiesto-V1 Summary Internet of Things (IoT) is an emerging area that not only requires development of infrastructure and software Engineering development but also the design and deployment of new services capable of supporting multiple, scalable and interoperable (multi-domain) applications. In the race of designing the IoT as part of the Future Internet architecture, academic and ICT s (Information and Communication Technology) industry communities have realized that a common IoT problem to be tackled is the interoperability of the information. In this document we review and summarize recent trends and challenges on interoperability, and discuss how semantic technologies, open service frameworks and information models can support data interoperability in the design of the Future Internet, taking the IoT and Cloud Computing as reference examples of application domains. In addition this document compile the European and world-wide initiatives for the Internet of things in the framework of the IERC (European Research Cluster for the Internet of Things) and particularly the Activity Cluster on Service Openness and Inter-operability Issues/Semantic Interoperability (AC4) Structure This IERC-AC4 document/deliverable is structured as follows: Section 1 contains this introductory section with references aiming for common understanding about service openness and interoperability, traditional interoperability is explained and two additional dimensions proposed and discussed. Section 2 describes important terminology for the Internet of Things domain aligned with (ontology engineering) semantics. Section 3 analyses the overall methodologies to classify, consume and publish data. Section 4 introduces most useful tools in the Internet of Things for enabling interoperability, while this list is preliminary and can be extended, it aim for including the most common tools used amongst the IERC EU FP7 projects related with Semantic interoperability. Section 5 identifies key scenarios/use cases for the Internet of Things, while the diversity of use cases for the Internet of Things applications is wide, in this document three distinct use cases in the areas of e-science, smart cities and manufacturing highlight are explained in fair detail. These scenarios / use cases can be considered as generalization in the area. Section 6 organize the EU FP7 interested/related with semantics, the objective is to joint activities by the entire IERC AC4 project participants, which will support and facilitate individual exploitation about the technologies and solutions developed and establish the first linkage between the IERC project member participants and at the same time promote collaboration. Section 8 includes those external to IERC / FP7 programs in the area of Internet of Things and with close relation to Semantics and service openness. Section 9 goes beyond the boundaries of Europe and includes those world initiatives in the area of Internet of Things or similar. Section 9 draws conclusions about key factors that the design of the Internet of Things must address in terms of semantic interoperability in order to meet business requirements. Finally the references and other useful references are included. 12

19 Manifiesto-V1 1 Introduction Internet of Things (IoT) is an emerging area that not only requires development of infrastructure but also deployment of new services capable of supporting multiple, scalable (cloudbased) and interoperable (multi-domain) applications. In the race of designing the IoT as part of the Future Internet architecture, academic and ICT s (Information and Communication Technology) industry communities have realized that a common IoT problem to be tackled is the interoperability of the information. In this paper we review recent trends and challenges on interoperability, and discuss how semantic technologies, open service frameworks and information models can support data interoperability in the design of the Future Internet, taking the IoT and Cloud Computing as reference examples of application domains. Extensible discussed the Internet of Things (IoT) refers to things ( objects ) and the virtual representations of these objects on the Internet. IoT defines how the things will be connected through the Internet and how those things talk amongst other things and communicate with other systems in order to expose their capabilities and functionalities services. Internet of Things is not only linking connected electronic devices by using the Internet; it is also web-enabled data exchange in order to enable systems with more capacities smartness. In other words IoT aims for integrating the physical world with the virtual world by using the Internet as the medium to communicate and exchange information. Technically speaking IoT is mainly supported by continuous progress in wireless sensor networks software applications and by manufacturing low cost and energy efficient hardware for sensor and device communications. However, heterogeneity of underlying devices and communication technologies and interoperability in different layers, from communication and seamless integration of devices to interoperability of data generated by the IoT resources, is a challenge for expanding generic IoT solutions to a global scale. In this article we present various parallel and inter-related interoperability challenges ensuring that technologies deliver information in a seamless manner while this information is understood whatever the context and efficiently processed to deliver the potential of innovative services we are looking for. To make everything simpler in our life tomorrow in using any object, any information, anywhere we need to solve complex interoperability issues today. 1.1 Semantics and Interoperability First we need to understand interoperability. The main objective of this article is not to produce a new definition on interoperability but explore the different roles and functionality interoperability plays in the Internet of Things today. In this sense there are many definitions of interoperability but for instance in the context of the 3rd Generation Partnership Project, 3GPP, interoperability is: "the ability of two or more systems or components to exchange data and use information" 13

20 Manifiesto-V1 This definition is interesting as provide many challenges on how to: Get the information, Exchange data, and Use the information in understanding it and being able to process it. A simple representation of interoperability can be seen as follow: Syntactical Interoperability Technical Interoperability Semantic Interoperability Organisational Interoperability Figure 1. The Dimensions of Interoperability In a white paper on interoperability [vanderveer 2008], we can get the following definition(s): Technical Interoperability is usually associated with hardware/software components, systems and platforms that enable machine-to-machine communication to take place. This kind of interoperability is often centred on (communication) protocols and the infrastructure needed for those protocols to operate. Syntactical Interoperability is usually associated with data formats. Certainly, the messages transferred by communication protocols need to have a well-defined syntax and encoding, even if it is only in the form of bit-tables. However, many protocols carry data or content, and this can be represented using high-level transfer syntaxes such as HTML, XML or ASN.1 Semantic Interoperability is usually associated with the meaning of content and concerns the human rather than machine interpretation of the content. Thus, interoperability on this level means that there is a common understanding between people of the meaning of the content (information) being exchanged. Organizational Interoperability, as the name implies, is the ability of organizations to effectively communicate and transfer (meaningful) data (information) even though they may be using a variety of different information systems over widely different infrastructures, possibly across different geographic regions and cultures. Organizational interoperability depends on successful technical, syntactical and semantic interoperability. 14

21 Manifiesto-V1 We can add two other dimensions: Static and dynamic interoperability We should not also forget that two products couldn t interoperate if they don t implement the same set of options. Therefore when specifications are including a broad range of options, this aspect could lead to serious interoperability problem. Solutions to overcome these aspects consist of definition clearly in a clear document the full list options with all conditions (e.g. defined as PICS in [ISO 9646]) as well as to define set of profiles. In the later case, defining profile would help to truly check interoperability between two products in the same family or from different family if the feature checked belong to the two groups. We could consider this aspect as static interoperability using approach of the well-known OSI overall test methodology ISO 9646 [ISO9646], where there is definition of static conformance review. Conformance testing consists of checking whether an IUT (Implementation Under Test) satisfies all static and dynamic conformance requirements. For the static conformance requirements this means a re- viewing process of the options (PICS) delivered with the IUT. This is referred to as the static conformance review. This aspect could appear easy but that represent serious challenge in the IoT field due the broad range of applications. In the meantime, in front of growing complexity we also noticed many solutions to adapt to non-interoperability leading to be able to communicate and understand. One interesting research as presented by eternal interoperability here in one of the section below consists to accept differences and potential non-interoperability for instance between two different protocols but to adapt on the fly. We see also such features in intelligent gateways and middlewares. This can be called dynamic interoperability and should be a continuous important research area in particular with the growing complexity and heterogeneity of IoT environments Semantics and technology IoT environments for Internet-connected objects will greatly facilitate the deployment and delivery of applications, since they will enable businesses and citizens to select appropriate data and service providers rather than having to deploy physical devices commonly called sensors. At the same time, they will provide capabilities (such as on-demand large scale sensing), beyond what is nowadays possible. It is important to highlight the origins of IoT are found in the area of (Radio Frequency IDentification) RFID domain where RFID tags are extensively used for data collection. The static information a group of RFID tags can generate motivated the quick development of RFID middleware frameworks to the extent that nowadays FID frameworks provides functionality for RFID data collection, filtering, event generation, as well as translation of tag streams into business semantics. Several initiatives have produced several open-source RFID frameworks, such as Mobitec [MOBITEC], AspireRFID [ASPIRE] as well as the fosstrak project [FOSSTRAK] which provide royalty-free implementations of RFID middleware stacks. The evolution has 15

22 Manifiesto-V1 continued and the generators of data are now generally named sensors by their capacity to produce data and their flexibility to create cells or groups of them by using embedded wireless technology. In this sense several middleware platforms have also been devised in the area of WSN (Wireless Sensor Networks). Specifically, there are platforms addressing only the level of the sensor network, whereas other deal also with devices and networks connected to the WSN. Some middleware platforms are characterized as sensor databases, other as virtual machines, whereas there are also publish-subscribe approaches. Systems such as Moteview [BULLSEYE] and ScatterViewer [SCATTERVIEWER] are examples of WSN development and monitoring systems, which however provide limited extensibility (tightly coupled approach). Other environments such as Hourglass [HOURGLASS], SenseWeb [SENSEWEB], jwebdust [JWEBDUST] and GSN [GSN] provide more complete development and/or programming environments for WSN applications. Beyond the limits of physical devices known as sensors there is also a notion of Virtual Sensor that refers to a core representation of an element of the IoT platforms representing new data sources created from live data. These virtual sensors can filter, aggregate or transform the data. From an end-user perspective, both virtual and physical sensors are very closely related concepts since they both, simply speaking, measured data. The Semantic Sensor Network (SSN) ontology, providing the most important core vocabulary for sensing data, defines the notion of sensor and physical devices in general, therefore formally the concept of a virtual sensor as a subclass of the sensor concept as defined in the SSN ontology. Due to the rising popularity of IoT technologies and applications the emergence of a wide range of platforms that enable users to build and/or use IoT applications is unavoidable. In general there is a clear trend towards the convergence of physical worlds and virtual solutions by using IoT technologies. In all cases either Physical or Virtual sensors, a middleware framework is the core element to be used for providing baseline sensor functionalities associated with registering and looking up internet-connected objects, exchanging messages between objects, as well as fusing and reasoning data from multiple-objects. Some features of these implementations are: 0 integrate ontologies and semantic structures, in order to enable semantic interactions and interoperability between the various objects, which will be a significant advancement over the existing syntactic interactions. 1 provide Open Linked Data interfaces (e.g., SPARQL (SPARQL Protocol and RDF Query Language) over ontologies for internet-connected objects within the physical world middleware to interact with virtual world). 2 Define techniques for the automated data configuration of filtering, fusion and reasoning mechanisms, according to the problems/tasks at hand Semantic for interoperability The overall challenges in interoperability is first to stabilize the foundation of the real world, ensuring technical interoperability from technologies to deliver mass of information and then complementary challenges are for the information to be understood and processed. Before entering into details we will in the tables below present a summary of the challenges for technical and semantic interoperability. 16

23 Manifiesto-V1 Table 1: IoT Technical Interoperability Challenges/Requirements Requirement(s) Best practices awareness Avoid spreading effort in addressing interoperability for worldwide protocols Validation of specifications Reduce ambiguities in specifications and development time Rationale & Remarks Coordinate worldwide interoperability initiatives on market support specifications or protocols Develop market acceptance roadmap Use clear specifications development and testing methodologies leading to improve quality while reducing time and costs in a full chain optimized development cycle Define if needed profiles to improve interoperability Specifications development time could be too long Ambiguities in specifications could lead to major non interoperability issues Quality, time and cost factors lead to the needs of models and automation Tests specifications Provide market accepted test specifications ensuring minimum accepted level of interoperability No test specifications lead inevitably to different specifications implementation and interoperability issues Development test specifications is often too expensive for limited set of stake holders and effort should be collectively shared Tools processing and automation are only way to reduce time and market (e.g. use of MBT) Tools and validation programmes Develop market accepted and affordable test tools used in market accepted validation programs Development of test tools are expensive Available test tools developed spontaneously by market forces can have test scopes overlapping and even not answering to all tests needs. Full chain of specifications to tool development not considered Providing final confidence to end users with consistent tests not always considered The following table/ lists summarize the main requirements associated with the development of the IoT service(s) / application(s) in reference to semantic interoperability requirements and moreover, it provides the main rationale that has led to these requirements. 17

24 Manifiesto-V1 Table 2: IoT Semantic Interoperability Challenges/Requirements Requirement(s) Integration Support multiple ICOs (sensors, actuators) and relevant types of data sources (independently of vendor and ICO location). Rationale & Remarks Enable scalable sharing and integration of distributed data sources. All IoT applications involve multiple heterogeneous devices. Orchestrate ICOs in order to automatically formulate composite workflows as required by end-user applications. Annotation Enable the (automated) linking of relevant data sources. Linking of data sources facilitates application integration and reuse of data. Enable interactions between ICOs and between IoT services. Built on the standards i(.e. W3C SSN standard ontology) for description of sensors and ICOs. Management Enable the creation and management of virtual sensors and virtual ICOs based on the composition and fusion of streams stemming from multiple (ICO) data sources. Application development and integration involves multiple distributed and heterogeneous data sources to be processed in parallel. The definition and management of virtual sensors eases applications integration. Discovery Provide the means for discovering and selecting ICOs and data sources pertaining to application requests (according to their capabilities). Analysis and Reasoning Provide analytical and reasoning tools on top of semantic level capabilities. End users need a high-level interface to be accessed. Provide the means for describing/formulating IoT services and applications according to high-level descriptions. Provide (configurable) visualisation capabilities of multiple integrated data sources (in a mashup fashion). IoT addresses large-scale environments with numerous ICOs featuring different functionalities and capabilities. End-user applications involve the monitoring of virtual and/or Physical sensors Visualisation Optimise usage of resources (storage, computing cycle, sensor utilisation) across multiple users sharing these resources. Several applications involve object-to-object (e.g., M2M) interactions or interactions between services; such interactions could be either defined explicitly (i.e. by end users) or derive implicitly (based on the application context). 18

25 Manifiesto-V1 1.2 Semantics why, where, how? Taking a broad view of state of the art and current development of interactions for interoperability in converging communications, many of the problems present in current Internet will remain in the Internet of Things systems and mainly generated by interoperability problems, thus there are three persistent problems: 1. Users are offered relatively small numbers of Internet services, which they cannot personalise to meet their evolving needs; communities of users cannot tailor services to help create, improve and sustain their social interactions; 2. The Internet services that are offered are typically technology-driven and static, designed to maximise usage of capabilities of underlying network technologies and not to satisfy user requirements per se, and thus cannot be readily adapted to their changing operational context; 3. Network operators cannot configure their networks to operate effectively in the face of changing service usage patterns and rapid networking technology deployment; networks can only be optimised, on an individual basis, to meet specific low-level objectives, often resulting in sub-optimal operation in comparison to the more important business and service user objectives. As the move towards Internet of Things, the convergence of communications and a more extended service-oriented architecture (SOA) design gains momentum, worldwide there is an increasingly focussing on how to evolve communications technologies to enable the Internet of Things. The aim is directed mainly by pervasive deployment of Internet protocol suites and VoIP is a clear example of this... In this sense we believe that addressing evolution of networking technologies in isolation is not enough; instead, it is necessary to take a multidomain adaptable holistic view of the evolution of communications services, their societal drivers and the requirements they will place on the heterogeneous communications infrastructure over which they are delivered. By addressing information interoperability challenge issues, Internet of Things systems must be able to exchange information and customize their services. So Future Internet can reflect changing individual and societal preferences in network and services and can be effectively managed to ensure delivery of critical services in a services-aware design view with general infrastructure challenges. Figure 2 courtesy of chain-reds project. Figure 2. Semantic Web technologies 19

26 Manifiesto-V1 2 Vocabulary and Terminology 2.1 Data Model One of the most difficult aspects in the Internet of Things is the dynamism of the data. Changes in the data must be detected in real time, and the applications must quickly adapt to such changes [Dey01]. The nature of the information is the most important feature to consider when data is being handled, IoT systems needs data to process instructions and generate outcomes; if IoT applications can fully exploit the richness of de data, services around data management will be dramatically simplified [Brown98]. Other important challenges in the Internet of Things in relation with data include: (1) how to represent and standardize the data, (2) if the data is correctly collected (trust and validity) and represented, and (3) if the information can be translated to a standard format (information model), then different applications can all use the information. Finally, some types of data also depend on user interfaces (which can make retrieving data much easier), or the type of technologies used to generate the information. 2.2 Information Model Modelling data is one of the major challenges in the Internet of Things services deployment, without having a defined, clear and at same time flexible information model, applications will not be able to use such information in an efficient way for taking advantage of all of the benefits that the context information can provide for the service as well as for the provisioning of that service. The information model must be rich and flexible enough to accommodate not only the current facets of information, but also future ones [Dey01]. It has to be based on standards as much as possible and moreover, the model should scale well with respect to the associated technology and the applications. This introduces a great challenge for managing this information in a consistent and coherent manner. Storage and retrieval of this information is also important. Another important aspect to consider in the information model is the continuous evolution in technology and the Internet of Things services offering towards mobility. This mobility demand the integration of information in heterogeneous, distributed technologies and systems. By adding descriptions to the data, the transformation to valuable Information plays an important role in next generation Internet and IoT systems which. Since the incorporation of the mobility concept and recently, each day more popular, cloud computing systems the information require the development of extensible context models that enable the efficient representation for handling and distribution of the information in the information systems 20

27 Manifiesto-V1 2.3 Data exchange The model in the Internet of Things for exchanging data is based on simple concepts and its relationships, as syntactical descriptions, between those concepts, for example an object or entity is composed of a set of intrinsic characteristics or attributes that define the entity itself, plus a set of relationships with other entities that partially describe how it interacts with those entities. The objects/entities can represent anything that is relevant to the management domain [Chen76] (in this case IoT). Moreover, the relations that can exist between the different model entities can represent many different types of influence, dependence, links and so on, depending mainly on the type of entities that these relationships connect. The model s objective is to describe the entity and its interaction with other entities by describing the data and relationships that are used in as much detail as is required. This abstraction enables the model to be made more comprehensible by different applications. Since this format is machine-readable, the information can be processed by applications much easier than an equivalent, free-form textual description. 2.4 Knowledge representation In the Internet of Things the knowledge modelling depends on the point of view of the application definition and scope. The information model is a first approximation on how to structure, express and organize the information [Dey00a][Dey01] the knowledge representation is the information associated to the service. The information model is based on the concepts of entity and relationship and derived from the definition of entity in [Chen76] the knowledge model is derived from the service or application. The concept of the local context of an entity can be defined as the information that characterizes the status of the entity. This status is made up of its attributes and its relationships. Moreover, the relationships that can exist between the different entities inside the model, as well as the entities themselves, can represent many different types of influences, dependencies, and so on, depending on the type of entities that these relationships connect. With this type of model, one can construct a net of entities and relationships representing the world surrounding the activity of a context-aware service and thus the models can influence the development of the activity or service. This enables a scenario made up of many different types of information, and the influences or nexus that links one with the others. The local context enables the service to select and use context information from this scenario that is considered relevant in order to perform its task and deploy its service. 2.5 Knowledge sharing The tools that could be used to represent and implement data model, and the way to integrate this information model inside the general IoT system architecture, need to be identified and tested, as they are potential tools for representing the context information. RDF is a flexible and platform-independent tool that can be used in different stages of the information representation, which makes implementation consistent and much easier. The use of RDF is increasing every day; however, it is by definition generic. Therefore, new languages that are based on RDF have been developed that add application-specific features as part of the language definition. For example, to customize services, languages must have concepts that are related to the operational mechanisms of that service. 21

28 Manifiesto-V1 It is in this context that we propose the RDF/XML Language to represent the context information models. XML has the following advantages: XML is a mark-up language for documents containing structured information. The use of RDF (Resource Data framework Definition) facilitates the validation of the documents created, even in a more basic but in some way also functional the use of DTDs (Document Type Definition) is also an alternative for validation. This validation can be implemented in a JAVA program, which can be the same used for creating and maintaining these RDF/XML Schemas and/or documents. The use of XQuery, as a powerful search engine, to find specific context information inside the XML documents that contain all the information related to a specific entity. These queries can select whole documents or sub-trees that match conditions defined on document content and structure. Once the data is expressed in RDF, the use of SPARQL, as query processor engine, to find specific knowledge information is extensible effective. These queries can go from simple to more complex and select whole documents or sub-trees that match conditions defined on document content and structure. 2.6 Mapping The information model is not the data, instead it provides a powerful abstraction of the information needed by the IoT applications and, in general, the pervasiveness required by such applications. The mapping of IoT information can be seen as a distributed data base model (relational or spatial), where the data entities contain only their own information and also the type of relationships with other data entities. This enables an entity to use the attributes of these other entities if needed. This method of representation acts as a suitable scenario description without reference to any specific element or object, and hence is applicable to many different applications. The mapping of the entity model can be thought of as a general-purpose way of represent, store and exchange context information throughout the network, and for this reason, this concept is used to model context information for mapping purposes. In the Internet of Things the use of abstract models can be adopted so that if it is necessary to add new information to the model, it is not necessary to modify the existing entities; all that is required is to create a new entity and establish suitable relationships with the existing entities. This ensures the scalability of the information model. 2.7 Matching and Alignment Ontologies are used to describe and establish semantic commitments about a specific domain for a set of agents, with the objective that they can communicate without complicated translation operations into a global group. Examples of those commitments are present in [Crowcrof03]. The idea of semantic commitment can be thought of as a function that links terms of the ontology vocabulary with a conceptualization. Those agreements can represent links between concepts form different domains or concepts from the same domain, as is exemplified in [Khedr03]. In particular, ontologies enable the system to describe concepts involved in the applications, process or tasks (a domain of discourse) without necessarily operating on a globally shared theory. Knowledge is attributed to agents that do not need to know where the commitments were done; all they need to know is what those commitments are, and how to use them. An agent knows something if it acts as if it had and understood that information, so that it can 22

29 Manifiesto-V1 act rationally to achieve its goals. Then, conditions that agents can use to operate with actions of the agents can be defined; this can be seen as a functional interface to tell the agents how to operate for sharing, reuse, verification and reasoning. An application of these concepts focused in communications using context concepts can be studied in [Khedr02]. A slightly different viewpoint is an ontology mapping process is based on the identification of similar concepts present in the ontologies to be aligned, and then if those similarities exist a merging process is valid, as described in [López03c]. The alignment of ontologies, then, consists of the definition of agreements between two or more ontologies, where an agreement is a link that exists between two (or more0 concepts in the ontologies. These agreements then allow the exchange of information between applications at the same and/or different levels of abstractions that have created the agreements. The semantic commitments defined in the ontologies are used to delineate in each case the knowledge that can be shared with agents that commit to the ontologies. Likewise, the ontologies provide the semantic structures necessary to allow gathering, managing and storing efficiently context information in services and applications. 2.8 Concepts Concepts are the abstract ideas that represent entities, behaviour, and ideas that describe a particular managed domain. Concepts can represent material entities such as things, actions, and objects, or any element whose concepts and/or behaviour needs to be expressed by defining its features, properties and relationships with other concepts. Such concepts can be represented and formalized as object classes. The classes are used and managed by computing systems for performing operations or simply for sharing information. 2.9 Representation The representation is a formal or informal way to understand and situate the idea in reference to certain properties or features in the domain where the idea is created. The representation can be created using formal tools or mechanisms for depicting the ideas or concepts, or the representation can be informal, such as using a simple graph or set of symbols depicting the ideas of the concept Relationships Relationships represent the interaction between the concepts of a domain. These include structural agreements (e.g., subclass-of and connected-to in the field of pervasive computing) as well as semantic descriptions (e.g., synonyms, antonyms, and is-similar-to) that can be used to express how a concept interacts with other concepts in the managed domain Functions Functions are a specific type of relationship in which an element is identified as the result of a process or activity. Functions are not necessarily limited to mathematical functions, and can for example include logic functions for defining relationships in form of conditionals or aggregations. 23

30 Manifiesto-V Instances Instances are used for creating specific objects already defined by a concept, and can represent different objects of the same class (e.g., person1 instance-of and person2 instanceof). Instances enable objects that have the same properties, but are used to represent different concepts, to be realized, and that can be described as sub-components of concepts that have already been modelled Axioms Axioms are the logic rules that the ontology follows. Axioms are theorems that contain the logic descriptions that the elements of the ontology must fulfil. The axioms act as the semantic connectors between the concepts integrating the ontology, and they support the logic operations that create a dynamic interaction between the concepts. In pervasive computing, the axioms act as conditions for linking the concepts and create the functions between concepts in an ontology Ontology In the Internet of Things, an important aspect is the identification of the data to collect, gather and store accordingly to a defined information model. The format to contain the information is work of the model to be followed. The information model can be used not just to model information in services, but also to manage the services provided. The information model must be rich in semantic expressiveness and flexible enough to consider the variations of current status of the object being managed [McCarthy93]. The model should scale well with the IoT technology and accordingly with the application which it is implemented. If the information models are expressive enough, pervasive systems can use that information to provide better management service operations. In order to formalize the information contained in the information model, ontologies appear to be a suitable alternative. However, this does not mean that other approaches are unsuitable for different applications. In the Internet of things ontologies, appears as a suitable alternative to exchange knowledge as per the result of providing the required semantics to augment the data contained in the information model in order to support service management operations Objects vs. Things There is a misconception each time objects and things terms came across even some times they are used indistinctly, frequently objects refers to the technology rather than the application while thing is a more generic term and applies to software associations of objects. In other terms, towards enabling a new range of large-scale intelligent Internet connected objects (ICO) services and applications, the Internet of Things (IoT) applications and the cloud computing delivery models play a crucial role. The IoT area therefore serves as a blueprint for non-trivial ICO scalable applications, which will be delivered in an autonomic fashion and according to cloud-based utility models. It has been extensively discussed Internet of things (IoT), will be an integral component of the Future Internet. Indeed, the proliferation of applications involving Internet-connected objects, has recently given rise to the notion of networks of internet-connected objects, which are promoted as large-scale networks of spatially distributed physical devices or entities 24

31 Manifiesto-V1 called sensors with scalable processing and storage capabilities. However, there is still no easy way to formulate and manage networked environments of internet-connected objects i.e. environments comprising sensors and offering relevant utility-based (i.e. pay-as-you-go) services Interoperability by Ontologies Ontologies were created to share and reuse knowledge [Gruber93b][Guarino95] and recently, applications have concentrated on avoiding the interoperability problems (e.g., the inability to exchange and reuse data) when different systems that use different knowledge representations and languages interact with each other. Ontologies not only provide enrichment to the information model and provide semantic expressiveness to the information [Gruber93b], they also allow the information exchange between applications and between different levels of abstraction, which is an important goal for the Internet of Things. Typically Ontologies are used to provide semantic augmentation, addressing the cited weaknesses of data models [López03a] and beyond with ontologies the integration of information and interoperability is achieved, resulting in improved Internet of Things system control and management. The cognitive relationships are shown in figure 3, where the ontologies are used for making ontological commitments in form of cognitive relationships (i.e., an ontological commitment is an agreement to use a vocabulary in a way that is consistent to different domains of application). Figure 3. Information Models Ontology Engineering. In most current SOA applications, different data models are embedded in each application, and as result complex systems need to be developed to translate between data defined by different applications. This is due to many reasons; perhaps the most important is because different management applications require different management data to accomplish different tasks, or to represent information from a different point of view. Often, each application uses different tools, since the use and manipulation of those data requires different functions. For example, the simple text-based functionality of LDAP (for directories) is not sufficient for more complex tasks that require (as an example) SQL. This is the trap which developers fall into when they use an application-specific data model instead of an application-independent information model. Furthermore, the complexity increases when end user applications use information models that need to interact with information models from devices in the networks, as the difference between user and network data is significant. 25

32 Manifiesto-V1 3 Methodologies & Tools for Data in IoT 3.1 Taxonomy and Structure of the Information The classification of the Internet of Things information is not an easy task, due to its extreme heterogeneity. Therefore, this taxonomy could be defined in multiple ways and from multiple perspectives. To identify the information that could be relevant to IoT applications, the different aspects required by IoT services are usually classified based on IoT service provisioning. A review of the different kinds of classifications (most of them orthogonal and compatible) with IoT services and management operations is presented [Serrano05]. In a first approximation, IoT information can be classified by the following characteristics: By its persistence: Permanent (no updating needed): Data, which does not evolve in time, that remains constant for the length of its existence (e.g., name, ID card), or Temporary (needs updating): Context information that does not remain constant. (e.g., position, health, router interface load) By its medium: Physical (measurable): Context information that is tangible, such as geographical position, network resources, and temperature (it is likely that this kind of information will be measured by sensors spread all over the network), or Immaterial (non-measurable by means of physical magnitudes): Other context information, such as name or explanatory meta-data (it is likely that this kind of information will be introduced by the users) By its relevance to the service: Necessary: Context information that must be retrieved for a specific service to run properly, or Optional: Context information which, although it is not necessary, could be useful for better service performance or completeness By its temporal characteristics: Static: Context information that does not change very quickly, such as temperature of a day, or Dynamic: Context information that changes quickly, such as a person s position who is driving. 26

33 Manifiesto-V By its temporal situation: Past: Context information that took place in the past, such as an appointment for yesterday, which can be thought of as a context history, or Present: Context information that describes where an entity is at this particular moment, or Future: Context information that had been scheduled and stored previously for future actions, such as a meeting that has not yet occurred. 3.2 Capturing the information (how information is acquired in IoT) The information can be captured and collected using sensory devices (e.g. networked-enabled sensor nodes, mobile devices), online sensors (e.g. real world data repositories) or they can be extracted from social media or submitted directly by human users (i.e. citizen sensing). The information can be captured on continuously and published as data streams or can be submitted as individual items based on single measurements and observations. In some cases a sensory device can sample and report the data in a specific periods of time and in other cases, the information can be sent only when a certain criteria is fulfilled; e.g. measurement value is higher than a threshold, or when an event has occurred Observation, Measurement and Actuation IoT data usually originates from a device or a human, and refers to attributes of a phenomenon or an entity in the physical world. The data can be combined with other data to create different abstractions of the environment, or it can be integrated to the data processing chain in an existing application to support context and situation awareness. The data can be sensed values or observed occurrences related to a real world phenomena or an object. The observation and measurement process is performed via a sensory resource (e.g. device, human observation). The actuation process enables interaction with the physical world. The actuators can make changes in the real world, control a device and provide a feedback loop for cyber-physical systems Resource Description A resource, in IoT, is referred to as a device or entity that can provide data or perform actuation (e.g., a sensor or an actuator [De 2011]. A resource is the core software component that represents an the real world objects and devices entity in the cyberspace. There are several existing works that provide description models for IoT resources. Here we briefly describe some of recent works. 27

34 Manifiesto-V1 The W3C Semantic Sensor Networks Incubator Group has developed an ontology for describing sensors and sensor network resources, called the SSN ontology [Compton 2012]. The SSN ontology provides a high-level schema to describe sensor devices, their operation and management, observation and measurement data, and process related attributes of sensors. [De 2011] describe a resource description model that is used in the IOT-A project. The model describe different attributers of the IoT resources including functional, thematic and spatial features and provide links to other Entity and Services models in the same project. The models and interfaces provided by the Sensor Web Enablement (SWE) group at Open Geographical Consortium (OGC) also define a set of common models for dealing with sensor data in heterogeneous environments. The primary representation models in SWE are encoded in XML, which has significant limitations in semantic interoperability and defining associations between different elements. A service model also describes common interfaces and exposes the functionality of a device by accessing its hosted resources [De 2011]. The resource/service modelling can be also extended to business processes. An approach for modelling of business processes by using semantically annotated resources that take dynamicity of the IoT environments into account is described in [Meyer 2011] Entity Description An Entity is a virtualisation of things in IoT and could be a person, animal, car, a physical location or any other object in the physical world. The entity is the main focus of interactions by user and software agents in the IoT world. In the IOT-A project is model for describing the IoT entities is proposed [De 2011]. In addition to the profile properties such as name and identifier, the IOT-A entity model includes properties to describe location of an entity, and description elements for features of interest for an entity (features that can be observed by a sensing mechanism or can be changed/controlled by an actuation process). More details and specifications of the model are provided in [De 2011]. 3.3 Data Publishing and consumption Data access in IoT can be implemented at low-levels (e.g., device or network levels) by the use of low-level programming languages and operating system level access [Corcho 2010]. The heterogeneity of the devices and (sensor) networks in IoT makes data publishing and access across the networks a difficult task. Service oriented principles, which allow complex software systems to be represented as subsystems or services, have been used to integrate the IoT data with enterprise services [Spiess 2009]. The idea of sensing as a service represents a scalable way to publish and access the sensor data through standard service technologies and has received consensus from the community. The middleware components and services can also act as intermediaries to allow publishing the IoT data and presenting it to the consumer applications and users. The data can be published directly as raw data or it can be associated with the metadata and semantic descriptions. However, often there is no direct association to the domain knowledge in the core models that describe the IoT data [Barnaghi 2012]. 28

35 Manifiesto-V1 Different resources, including observation and measurement data, also need to be associated with each other to add meaning to the IoT data Publishing Effective reasoning and processing mechanisms for the IoT data, and making it interoperable through different domains, requires accessing domain knowledge and relating semantically enriched descriptions to other entities and/or existing data (on the Web). An effective approach for publishing and consuming the IoT data can be using Linked-data model. Linked-data is an approach to relate different resources and is currently adopted on the Web. The four principles, or best practices, of publishing data as linked data include [Berners-Lee 2006]: 1. Using URI s as names for things; everything is addressed using unique URI s. 2. Using HTTP URI s to enable people to look up those names; all the URI s are accessible via HTTP interfaces. 3. Providing useful RDF information related to URI s that are looked up by machine or people; 4. Linking the URI s to other URI s. Publication of data as described above can be performed by submitting/publishing data as linked data or it can include other semantically described forms or it can be only submitting raw observation and measurement data. In any case, common interfaces and/or service models are required to enable publishing the data and integrating it into the existing data or enabling consumers to access the data Consuming IoT data consumption can be considered from two different perspectives. The first view is discovery and accessing the data. The IoT data can be accessed by subscribing to a resource or a set of resources. The data access and consumption can be also on ad-hoc based and a user can refer and access the data when it is required. The send view is query processing and discovery of the data. IoT envisions very large heterogeneous environments; so finding and discovery of the data and to make it ready for use involves several issues such as interface matchmaking, data interoperability as well as the search and discovery. The consumption of the IoT data can be also based on integrated resources. A user or an application can request for a complex type of data that can be a composition of a set of data that are collected from various resources. Heterogeneity and complexity of providing resources and dynamicity and volatility of the IoT environments can make data discovery and consumption in challenging task especially in large-scale dynamic IoT environments. 29

36 Manifiesto-V1 3.4 Data Formalisms and Languages in IoT In the Internet of Things (IoT) sensors and actuators are connected via wired or wireless networks to the Internet. Collecting and analyzing data from this interconnected devices allow a better understanding of the events involving the sensor measurements. However, due to the heterogeneous nature of such diverse data sources, data integration is a difficult and labor-intensive task, which currently requires a lot of hand-crafting. Common formalisms for data representation and languages for data processing would facilitate data interoperability and enable a faster development of applications involving IoT objects. In a different context, the Semantic Web has been promoting common data formats for data integration on the World Wide Web. Give its widely adoption in the recent years, Semantic Web technologies show great potential that can also be explored in the IoT. Moreover, such technologies can also bridge the gap between sensor and more static data sources. However, the differences between IoT objects and Web documents prevent Semantic Web technologies to be directly applied in the IoT context. In this section we describe the Semantic Web technologies and the on going work dedicated to adapt the Semantic Web idea to the context of IoT. We highlight the main achievements and existing open problems. We also discuss other alternatives for formalisms and languages for IoT. One of the key issues in representing and describing the IoT data is semantic interoperability. Semantic interoperability means that different stakeholders can access and interpret the data unambiguously. The IoT resources need to exchange data and provide unambiguous data descriptions in a way that can be processed and interpreted by machines and software components. Semantic annotation of the IoT data can provide machine-interpretable descriptions on what the data represents, where it originates from, how it can be related to its surroundings, who is providing it, and what are the quality, technical, and non-technical attributes [Barnaghi 2012]. Semantic descriptions can support interoperability between different sources; however, analysis and mapping between different semantic description models could be still required to facilitate the IoT data integration with other existing domain knowledge. The Semantic Web languages and standards in recent users have been used to describe the IoT data and resource/entity descriptions Semantic web technologies According to the W3C, "The Semantic Web provides a common framework that allows data to be shared and reused across application, enterprise, and community boundaries."2 Within the Semantic Web, the idea of Linked Data was introduced as set of guidelines to describe and publish structured data so that it can be interlinked and become more useful. The four principles of publishing data as linked data are3: Use URIs to identify things

37 Manifiesto-V1 Use HTTP URIs so that these things can be referred to and looked up ("dereferenced") by people and user agents. Provide useful information about the thing when its URI is dereferenced, using standard formats such as RDF/XML. Include links to other, related URIs in the exposed data to improve discovery of other related information on the Web. The success of Linked Data in terms of flexibility and data interoperability has uncountable efforts in both transforming existing data and generating new one, in many different areas. IoT was not an exception: applying the Linked Data principles would facilitate the data integration among heterogeneous IoT objects, and enable a vast range of new, real-time applications in the areas of smart cities, green IT, e- health, to name a few. Using semantic annotations in the IoT domain provides machine-readable and machine-interpretable metadata to describe the IoT resources and data. The main Semantic Web technologies that are used in the IoT domain include the Resource Description Framework (RDF), RDF Schema and the Web Ontology Language OWL). These common languages and frameworks are used for describing and representing the IoT data and entity/resources. There are also query languages such as SPARQL and also repository, processing and reasoning engines and mechanisms that allow accessing and inferring the semantic descriptions. The W3C SSN group provide a detailed survey of the existing models and techniques and also provide a report on semantic annotation (The report is available at: Incubator/ssn/XGR-ssn /) SWE standards at OGC also provide a set of specifications and languages for describing common interfaces and representing sensor data (i.e. SensorML). However, the current representation of the SWE models in in XML. The IoT data can be also represented as raw data or it can be stored in/accessed from relational databases that internal schema description for the data. The data for example can be also provided as Comma Separated Values (CSV). However to provide interoperable data and to make it possible for the data to be autonomously processed and integrated by different consumers, there should be a mechanism to describe different attributes of the data and these descriptions should be represented in a machine-readable/interpretable and interoperable format Other alternatives There is one aspect common to IoT which is not covered in the original concept of Linked Data, which is data usually is output in the form of streams. With the increasing demand for real-time applications, stream data is also becoming popular in sources other than sensors. In the Web for instance, services delivering real-time information, like Facebook or Twitter, are increasingly popular. Recently, there have been efforts to lift sensor, or more generically stream data, to a semantic level (Eric Bouillet, 2007), (Amit P. Sheth, 2008), (Kamin Whitehouse, 2006). For example, the W3C Semantic Sensor Network Incubator group (SSN- 31

38 Manifiesto-V1 XG) defined an OWL 24 ontology to describe the capabilities and properties of sensors, the act of sensing and the resulting observations (Michael Compton, 2012). The goal is to make stream data available according to the Linked Data principles a concept that is known as Linked Stream Data (Juan F. Sequeda, 2009). As Linked Data facilitates the data integration process among heterogeneous collections, Linked Stream Data has the same goal with respect to data streams. Moreover, it also bridges the gap between stream and more static data sources. Linked Stream Data is usually represented as an extension of RDF the most popular standard for Linked Data representation. Assigning URIs to RDF streams not only allows accessing the RDF streams as materialized data but also enables the query processor to treat the RDF streams as RDF nodes, such that other SPARQL query patterns can be directly applied. The extensions made to the standard RDF account for handling the temporal aspects of stream data. For that, new data models and query language have been proposed. Stream elements of Linked Stream Data are represented as RDF triples with temporal annotations. A temporal annotation of an RDF triple can be an intervalbased or point-based label. An interval-based label is a pair of timestamps which commonly are natural numbers representing for logical time. The pair of timestamps, <start, end>, is used to specify the interval that the RDF triple is valid. The point-based label is a single natural number representing the time point that the triple was recorded or received. Streaming SPARQL (Bolles, 2008) and EP- SPARQL (Anicic, 2011) use interval-based labels for representing stream items, whereas point-based label is supported in C-SPARQL (Barbieri, 2010), SPARQLstream (Calbimonte, 2010) and CQELS (Phuoc, 2011). The query languages for Linked Data processing were also adapted to deal with Linked Stream Data. Linked Data queries are pull based and one-time, i.e., the data is read from the disk, the query is executed against it once, and the output is a set of results for that point in time. In contrast, in Linked Stream Data, new data items are produced continuously, the data is often valid only during a time window, and it is continually pushed to the query processor. Queries are continuous, i.e., they are registered once and then are evaluated continuously over time against the changing dataset. The results of a continuous query are updated as new data appears. For defining semantics of continuous query languages, stat-of-the-art approaches, like EP-SPARQLE, Streaming SPARQL, C-SPARQL and CQLES, extend the query operators introduced in SPARQL query language (Jorge Pérez, 2009). In the semantics of the SPARQL query language, the concept of mapping is introduced to represent the each output of query operators. Similarly, continuous query languages introduce window operators over RDF streams to output sets of mappings to be used as inputs to other query operators

39 Manifiesto-V1 4 Tools for Developments & Implementations in IoT In the Internet of Things there are various common use libraries, platforms and development tools that are applicable. By using them it will be easier for the advanced users and developers to get involved and to move from one IoT module system to another system without having to develop new skills to get involved. Some of the open source libraries, platform and development tools are listed below. 4.1 Software project management tool Apache Maven5 It can manage a project's build, reporting and documentation from a central piece of information. It will be used in OpenIoT code as a library and build management tool. 4.2 Development Environment Eclipse IDE6. It is one of the most popular open source Integrated Development Environments and will be used as the main development environment in the OpenIoT project. 4.3 Web-Service implementation Apache CXF7. Apache CXF is an open source services framework. CXF helps you build and develop services using frontend programming APIs, like JAX-WS and JAX-RS. These services can speak a variety of protocols such as SOAP, XML/HTTP, RESTful HTTP, or CORBA and work over a variety of transports such as HTTP, JMS or JBI. Mainly the JAX-RS implementation of Apache CXF will be used for the web service implementations at the OpenIoT project. 4.4 User Interfaces Web Clients Java Server Faces (JSF)8: JavaServer Faces technology establishes the standard for building server-side user interfaces. With the contributions of the expert group, the JavaServer Faces APIs are being designed so that they can be leveraged by tools that will make web application development even easier

40 Manifiesto-V1 PrimeFaces 9 : Prime Technology is not a software vendor but a software development house along with the consulting and training activities. A framework that's not even used by its own creators can easily miss vital points regarding usability and simplicity, a major difference compared to vendor products is that we use PrimeFaces in all of our clients' projects as the front end framework. This helps us to view the project from an application developer's point of view so that we can easily realize the missing features and quickly fix the bugs. This significantly differs PrimeFaces from other libraries. JavaServer Pages (JSP) 10. The JavaServer Pages (JSP) technology provides a simplified, fast way to create dynamic web content. JSP technology enables rapid development of webbased applications that are server- and platform-independent Fat Clients Eclipse Rich Client Platform (RCP) 11. While the Eclipse platform is designed to serve as an open tools platform, it is architected so that its components could be used to build just about any client application. The minimal set of plug-ins needed to build a rich client application is collectively known as the Rich Client Platform. 4.5 Platform Management Java Management Extensions (JMX). The JMX technology provides the tools for building distributed, Web-based, modular and dynamic solutions for managing and monitoring devices, applications, and service-driven networks. The JMX technology could be used to monitor and manage the different OpenIoT modules from the OpenIoT Configuration/Monitor console. 4.6 Enterprise Application Platform JBoss Application Platform JBoss Application platform to serve as an Enterprise Server container to host the various OpenIoT modules. As the developments evolve, different needs may occur and this decision may change to something lightweight. JBoss Application Platform 12. The JBoss Application Platform was created with the cloud in mind. It is based on a services-driven set of components and is running OSGi and the Java EE application server side by side

41 Manifiesto-V1 4.7 Knowledge Database RDF Database RDF database is used to store semantically annotated data. Three of the most popular Open- Source solutions are listed below. The OpenIoT platform will not be dependent to any of these databases since the transition from one to another is easy so a user will not be restricted to a single solution JENA Jena 13 Java framework for building Semantic Web applications Sesame Sesame 14. Framework for querying and analysing RDF data. This includes parsing, storing, inferencing and querying of/over such data. It offers an easy-to-use API that can be connected to all leading RDF storage solutions Virtuoso Virtuoso 15. (Open-Source Edition). Virtuoso is a middleware and database engine hybrid that combines the functionality of a traditional RDBMS, ORDBMS, virtual database, RDF, XML, free-text, web application server and file server functionality in a single system. Virtuoso is a commercial product which offers an open source version. The license of Community Virtuoso version is LGPL V Ontologies Internet-of-Things systems make high demands on the data they use. These demands can be expressed in terms of a variety of requirements for Internet Connected Objects services. This section summarizes the requirements. 1) End User: In context-aware ubiquitous services, the context information sources are highly distributed. This means that quite often it is necessary to create and maintain context information from other pieces of context that have been created in different locations and different epochs. Clearly, we assume that we don t have a central management system to do the above-related task. An IoT information model, exhibiting the property of ICO s composition, must support this

42 Manifiesto-V1 2) Systems Integrator: The complexity of contextual inter-relationships makes any modeling approach error prone. Therefore, it is highly positive to be able to validate the contextual information against the context model in use, as soon as the context is gathered. 3) Services Provider: The quality of context information is in essence one of the main goals to have in mind in ubiquitous service environments. The context model for ubiquitous services should support properties and indicators of quality. Context information quality may be expressed in terms of precision, probability of correctness, trust-worthiness, resolution and validity period. The most relevant modeling approaches are presented in this section. The ontologies (vocabularies) considered here, have been chosen with respect to their support for creating a platform architecture that integrates Internet of Things. Ontologies have the ability to support the management and description of dynamic information. Thus this classification is presented from the point of view of the data structures used to exchange the collected data, i.e. domains and/or systems; thus distinguishing between ontologies for sensor, social communities and context information modeling, in addition to ontologies for network components and energy domains Sensor Domain Sensor Domain: Sensors - or sensing devices in general - are the most relevant instances of Internet-Connected Objects (ICO) in the focus of our interest. It is then relevant to base our Cloud-based IoT platform architecture, on concepts describing sensor data and sensor-related information Semantic Sensor Network Ontology (SSN) The W3C Semantic Sensor Network (SSN) Incubator Group, realized an ontology [12], based on SensorML. This ontology aims at providing cross-domain concepts for sensors, and was inspired by several domain-specific ontologies that existed before. It supports annotating sensor-related features, e.g., deployment, observations and measurement capabilities. Thus, it enables the automation of further tasks like fine-grained discovery (e.g., search for sensors which are observing wind direction with a specific accuracy level) and maintenance scheduling. Several research projects have followed the Semantic Sensor Web vision and are currently using the SSN ontology [Compton 2012] Social Communities Domain Cloud computing inherently involves the implicit and explicit formation of online communities. The Cloud is a common platform where different parties provide resources, such as data or services, and other parties consume these resources. For participating, users have to register an account, create and establish a user profile, and can exchange messages, and so on. 36

43 Manifiesto-V Semantically-Interlinked Online Communities (SIOC) The SIOC initiative (Semantically-Interlinked Online Communities) aims at enabling the integration of online community information and it consists of the SIOC ontology; of SIOC metadata producers for a number of popular blogging platforms and content management systems; of storage and browsing/searching systems for leveraging this SIOC data. It models interactive products - data from Internet-Connected Objects (ICO) devices and related services - around which communities can grow and feedback can be collected, as a quality measurement of the provided content. SIOC provides methods for interconnecting discussion tools, e.g., blogs, forums and mailing lists Friend Of A Friend Ontology (FOAF) FOAF integrates both social networks of human collaboration, friendship and association; representational networks that describe a simplified view of a universe in factual terms; and information networks that use Web-based linking to share independently published descriptions of this inter-connected world. Main FOAF terms describe characteristics of people and social groups that are independent of time and technology; in addition to classes for Project, Organization and terms for use when describing Internet accounts, address-books and other Web-based activities Provenance Ontology (PROV) One of our major goal is that providers can make their sensor deployment easily accessible for others over the Cloud. End users use services to discover sensors and sensor deployments that match their requirements. Besides technical requirements (e.g. temperature sensors with a minimum accuracy in a specific area), this might also include requirements towards the provenance of the sensor data, for example, the manufacturer of the hardware or the owner of the sensor deployment. Provenance is defined as a record that describes the people, institutions, entities, and activities, involved in producing, influencing, or delivering a piece of data or a thing in the world. The W3C Provenance data model4 focuses on 1) entities, activities and the time at which they were created, used or ended; 2) agents bearing responsibility for entities that were generated and activities that happened; 3) derivations of entities from entities. Additionally, a set of constraints is provided [Moreau 2012], that provenance descriptions are expected to satisfy Association Ontology (AO) The Association Ontology provides features from the social/community context, associate any kind of comment, rate or feedback from each community member, with any other kind of artefact, e.g., in our scope, individual sensors, complete deployments, services, other users, etc. 37

44 Manifiesto-V Context Information Modeling Domain With sensors typically streaming data into the Cloud, not only one-shot queries (e.g. "What is the current temperature at Sensor A?") are of relevance but particularly continuous queries, e.g., to observe the development of a temperature value over time. In these cases, typically not the stream of each individual measurement is of interest for end users, but the event when the value, for example, exceeds a predefined threshold. Events in turn can fire other events, leading to complex relations between events, following specific patterns. The Event Model-F ontology allows describing such complex event inter-relationships Event Model-F Ontology (Event)) The Event Model-F ontology is robust and easily extendible because of both being made of design-patterns and being based on the upper level ontology Dolce+DnS Ultralite [Gangemi 14]. It provides comprehensive support for all the structural aspects of events: 1) Constitutive Aspect, i.e., living and non- living objects participating in an event; 2) Temporal Aspect; 3) Spatial Aspect; 4) Structural Aspect, i.e., the arrangement of events in metrological, causal, and correlative relationships; 5) Event Interpretations SPITFIRE Ontology (SPT) The SPITFIRE ontology7 (SPT) aligns the SSN, Event, FOAF, SIOC and AO ontologies according to a well-defined Linked Sensor Data model, and extend them with concepts related to Network Components and Energy that - since related with other domains - will be described in different paragraphs. The meaning of a connection that justifies its existence, is highly dependent on contextual information, e.g., two cloud resources might be interlinked because they are monitoring the same category of activities. Then, a proper modeling that aligns contextual information with sensor data, is needed. Here sensors and sensor data are linked with the agents they are related with, the activities they have sensed and the specific role played by any of the entities participating in these activities. To support also relations between different events, i.e., causality, correlation and participation patterns, SPT are also aligned [Leggieri2012] with the Event ontology. Any spt:activity is considered as an association of different entities to an event, described by following the participation pattern. To enable receiving rating and feedback for this association, from social communities, this ontology is also aligned with the Association one Network Components Domain The role of network components and the dynamic structure of a sensor network are relevant for energy efficiency, since data propagation algorithms can then decide which node to rely on, depending on its role, its position and link quality. 38

45 Manifiesto-V SPITFIRE Ontology (SPT) SPT includes a Network Components Module which includes representations of all the components of a Sensor Network, their role in the network, the network topology and specific management areas in which it has been divided. In this way, whenever the node distribution in a sensor network changes, the system can detect the change and update the semantic representation accordingly. For instance, if a node with the highest processing capabilities of the network, while moving, enters the scope of another area of the topology where aggregator nodes are needed, it could acquire the role of aggregator, temporarily. Then a data distribution algorithm, instead of relying on a fixed set of aggregator nodes, will rely on this new one, too, and even assign to it more work than to the others, because of its higher capabilities. Such capabilities, together with semantic metadata about the sensor itself and the sensor data, are described using the SSN ontology, with which the SPT is aligned. Also, network links are defined, so that a semantic representation of the interlinking structure between the nodes can be described. The activity of the link and the quality of the communication, are important factors. Link quality degradation influences the confidence of an observation made, while the link activity can be used to identify underused nodes which should be either used more or put into stand- by, according to the energy-saving policies applied Energy Domain The Internet-of-Things largely relies upon resource-constrained devices like sensors, as the main information source. Consequently an energy-wise usage of the ontology-based applications is required. In particular, distinguishing between the different kinds of energy sources and their power can support the data distribution algorithms, prioritizing those devices who are equipped with renewable energy batteries and have a longer battery life. A part from the Energy Module of the SPITFIRE ontology, other energy modeling ontologies is mentioned in papers but have never been openly published SPITFIRE Ontology (SPT) SPT allows, through the concepts defined in the Energy Module, to describe the amount of Energy that has been saved in a Network, as depicted in Figure 3. By the term Energy we refer to the Energy provided by Electricity. In particular Saved Energy is an estimation of the quantity of Electrical Energy that has been saved by applying Energy Saving initiatives. A possible way to calculate it is to subtract the total amount of Energy consumed in one year, with the total amount of Energy that would be consumed if all the energy-consuming devices were never either switched off or disabled. This module directly matches with the SSN Energy Module, as this was meant, indeed, to be a plug-in point to facilitate the extension of the SSN ontology Cloud Computing Domain With the Cloud as the central component of our aspired platform bridging IoT and Cloud Computing, Cloud concept modeling ontologies, particularly related to the life cycle of services, provide fundamental input. Of such ontologies, only the IT Services Ontology (ITSO) has been published [Joshi 2009], 39

46 Manifiesto-V1 while others have only been mentioned in publications. Most approaches are limited to exploring a single aspect of the lifecycle like service discovery, service composition or service quality. In addition, most of the work is limited to the software component of the service and does not cover the service processes or human agents which are a critical component of IT services IT Services Ontology (ITSO) The ITSO ontology allows to express IT service lifecycles concepts on the Cloud, as divided into five phases: 1) Requirements, i.e., the consumer details and the technical and functional specifications that a service needs to fulfill; 2) Discovery, i.e., discovery of service providers whose offered services match specifications, e.g., functional and technical attributes, budgetary, security, data quality and agent policies of the consumer; 3) Negotiation, i.e., discussion between service provider and consumer, regarding service data, delivery mode, agent details, compliance policy, quality and cost of the service; 4) Composition, i.e., one or more services provided by one or more providers are combined and delivered as a single service; 5) Consumption, i.e., the service is delivered to the consumer, while monitoring performances, based on the delivery mode (synchronous/asynchronous, real-time, batch mode etc.) agreed upon in the negotiation phase Cloud4SOA Project The Cloud4SOA project aims at allowing both PaaS providers to formally describe their cloud platform offerings, and developers to describe applications developed in a Cloud platform; while enabling semantic interoperability between different PaaS platforms. An ontology has been defined though not yet available, whose entities are categorized as follows: 1) Infrastructure layer, i.e., terms related to the infrastructure (hardware and software) in use; 2) Platform layer, i.e., terms related to a cloud-based plat- form; 3) Enterprise layer, i.e., terms related to the enterprises involved in the cloud and their role, i.e., the offering of Cloud infrastructure and Cloud platforms; 4) Application layer, i.e., terms related to a Cloud-based application; 5) User layer, i.e., terms related to the users of a Cloud platform (mainly, in this case, developers) UCI Project The Cloud Computing Interoperability Forum9 has the goal to create an open and standardized cloud interface for the unification of various cloud APIs. They defined a semantic model10 to achieve a unified representation of multi-cloud resources and to abstract the usage of any cloud API; so that IaaS interactions are enabled. The corresponding ontology is not yet published since still under development MOSAIC Project The MOSAIC Project aims at providing a platform which enables interoperability among Cloud systems, eases the portability of developed services on different platforms, enables semantics-driven searches of Cloud services and resources, enables services composition and management of SLA. The corresponding ontology [Moscato 2011] describes services at three models of Cloud Computing, i.e., IaaS, PaaS, SaaS, but has not been yet released. MOSAIC inherits the main actors definition from the National Institute of Standards and Technology (NIST) s proposal. 40

47 Manifiesto-V1 5 Scenarios / Use cases Currently exist a diversity of use cases for the Internet of Things applications, however three distinct use cases in the areas of e-science, smart cities and manufacturing highlight. In the scope of the present document these use cases are presented in fair detail, so that the main functional and non-functional requirements from end-users perspectives are derived. The presentation of the applications illustrates its pertinence to the Internet of Things in general, however note that the validation of them is based on OpenIoT generic scenarios, based on multiple inputs (rather than a single) application scenarios, allows the project to explore different functionalities, applications contexts and deployment options (including both public and private cloud deployments). Each application is presented in terms of the main sensors and Internet-connected objects/devices involved, the nature of the utility (and utility metrics) of interest, the main scenarios and functionalities entailed in each use case, as well as the main non-functional requirements associated with the use case. Furthermore, requirements in terms of external interfaces to other systems and applications are provided. It should be noted that emphasis is given in the IoT aspects of the applications, rather on other readily available functionalities. 5.1 Smart City Student Campus Application Application Description The vision of a Smart City provides the background for one of the validation scenarios of the OpenIoT project. In general, this scenario is about the integration of indoor and outdoor environments, in a unified cloud infrastructure. It shall be a support platform for collaborative decision-support processes for people, communities and authorities, with an enhanced situational awareness. This very abstract scenario will be exemplified in a more concrete application in order to provide an experimentation and evaluation framework. This framework will be the project Human Enabled EnviRonmental Observation (HERO) (Abeck 2010) of the research group Cooperation & Management of the Karlsruhe Institute of Technology (KIT), which aims at providing a set of reusable software services to support everyday activities of university students, lecturers, employees and guests. In order to achieve this goal, environmental data is to be observed and processed by the services and presented to service users to provide personalised guidance and assistance to specific tasks. As an example application in the context of HERO, a service-oriented application named KITCampusGuide was developed. This provides a navigation support to persons within the campus area. It enables the search for points of interest (POI) on the campus including rooms and buildings, as well as persons offices, addresses and events, such as lectures. The appropriate data to be searched for is provided by software services of different university units such as facility management, human resources and event management units. The searched POIs and relevant information are presented to the user graphically using a map of the campus and floor plans of buildings. Additionally, the application allows the routing across the campus and inside a building by calculating a route from a start position to the requested destination. The KITCampusGuide is to be extended with additional functionality targeted specially at students to allow them to search for and rent free workplaces for single or group work, which is a prominent requirement. The workspaces should self-manage their allocation status and 41

48 Manifiesto-V1 additional features, such as available tools at the workspace, e.g., video projector, whiteboard, tables, chairs, etc., as well as environmental information, such as locations on the campus, etc. This information should be made available to students through the KITCampusGuide interface so that for the work task adequate workplaces can be found and rented for a specific period of time. If a group rented a workplace, group participants who later join a group at the workplace should be able to search for the names of the other group participants and find them using the existing routing functionality of the KITCampusGuide. The sensors that are expected to be involved in the deployment of the services at the KIT- CampusGuide include: Facility management objects (like access control, occupation sensor, etc.), tagging labels (QR-Code, RFID), localisation sensors (indoor, outdoor) The utility and on-demand nature of the services are manifested in the following requirements: (Smart City) Requirement: Service requests shall be handled in near real time. (Smart City) Requirement: Services shall be available on demand. (Smart City) Requirement: Application and resource usage shall be based on a utility model (only the actual usage shall be accounted). (Smart City) Requirement: Resource usage may be managed in terms of time and usage of resources. Figure 4. KIT Campus Area 42

49 Manifiesto-V1 Figure 5. KITCampusGuide as an HERO application External Interfaces Requirements In terms of external interface requirements, the following requirement should be fulfilled: (Smart City) Requirement: Sensor and status information may be posted into Social Network Services (like Facebook, Google+, Google Latitude, etc.) Application Functionalities and Functional Requirements In terms of the functionalities of the applications, the following requirements should be met: (Smart City) Requirement: Workplace objects (like building, room, laboratory, work station, cubicle, whiteboard, terminal, etc.) must be identifiable (unique identifier and type). (Smart City) Requirement: Workplace objects must be linked to each other (relations with defined semantic, like containment, assignment, etc.). (Smart City) Requirement: Workplace objects must have status information (like occupied, closed, reserved, etc.). (Smart City) Requirement: Workplace objects must have location information (directly geo-referenced, plan layout assignment). (Smart City) Requirement: Workplace objects must be assignable to facility management objects (like air conditioning, access control elements, etc.). (Smart City) Requirement: Workplace objects must be assignable to social collaboration objects (like learning group, lecture course, working group, etc.). (Smart City) Requirement: Different type of authentication objects must be supported (like RFID-Card, NFC-Device). (Smart City) Requirement: Interactions between things, or associated services, shall be possible. (Smart City) Requirement: Interactions between things shall be defined by interaction protocols/models (e.g., by defining a communication act or pattern) 43

50 Manifiesto-V1 (Smart City) Requirement: Interacting partners must be typed and defined by interaction protocols. Furthermore, self-organisation between things shall be possible by using these interaction models. For example, a thing may be triggered by some observation (likely, but not necessarily by itself) and initiate a communication act with another thing (typically in its environment). Sensors and actuators for monitoring and controlling infrastructure RFID tags for inventory purpose with sensor to detect occupation status Display for visual interaction with the user Activity-field for social interaction or collaboration purpose. RFID/NFC reader with defined and marked range. Figure 6. Picture: IoT equipped workplace A student is looking for a workplace He opens the KCG app on his smartphone According to his current position and real time allocation status of workplaces the system determines a list of optimal workplaces The student chooses from a result list his desired workplace. At the same time the workplace is marked as reserved and the information is displayed at sight The student is navigated to his chosen workplace Figure 7. Enhancement of the KCG workplace search with IoT technology Non-Functional Requirements In terms of non-functional requirements, the following requirement is crucial to end users: (Smart City) Requirement: The handling of personal information, like resource usage, location-based information, etc., must always be transparent and traceable. 44

51 Manifiesto-V1 5.2 Phenonet Agriculture Application Application Description The Phenonet wireless sensor network is a distributed sensor network designed and commissioned in collaboration with the ICT Information Engineering Lab and the Distributed Sensor Networks TCP. These sensors comprise thermopile temperature sensors for capturing crop surface temperature data, ambient temperature and humidity and soil parameters at up to 6 depths. The goal of this WSN is to monitor crop performance at remote field locations in a highly time-resolved manner and log these data via the 3G phone network back to a base. Deployments for the grains industry have occurred at two sites: in New South Wales (NSW) this year by Phenomics, and at another site in Queensland (QLD) by CPI (CSIRO Plant Industry) Brisbane. This will expand to at least five sites over the next two years. It is envisaged that these sensors will increase in complexity to imaging and multispectral sensors as bandwidth improves and costs of each unit can be reduced. To interrogate these sensors and extract biologically meaningful results, both real-time checking systems and data mining solutions must be put in place. The four data sources used in the Phenonet project are depicted in Figure 5. Figure 8. Main data sources for crop performance monitoring in the scope of the Phenonet project In particular, the data sources include: 1. Wireless sensor network (WSN) returning continuous time series measurements 2. Non WSN data where measurements are uploaded from: Hand-held PDA devices (e.g., discrete time points made weekly or fortnightly). Some instruments are very good but must be operated manually, for example, neutron moisture meters. 45

52 Manifiesto-V1 Manual observation in the form of text files, excel spread sheets or again from PDA. This may be a biological observation about developmental stages that can inform other sensor data. 3. Phenomobile: Typically deployed two or three times per year on each experiment Equipped with four RGB cameras, three LIDARs, one hyperspectral reflectance unit (single pixel), three infrared temperature sensors Equipped with GPS (OmniStar subscription) to geo-reference measurements to a particular experimental unit (~2 m x ~6 m plot). Currently, Phenomobile data are stored in a Dell T7500 workstation onboard the unit under a standard SQL server schema which stamps all data with ~10 cm accuracy GPS and wheel encoder positions. These data are downloaded to a local server via Ethernet. 4. UAV: Typically a RGB or NIR or FIR camera typically mounted on a helium blimp or helicopter Images are acquired to SD cards or a wireless down link. Images are post-processed, segmented; biologically meaningful information are extracted by utilising geospatial data and meteorological data. Ideally the collected data would be stored locally and processed by an image analysis pipeline in a cloud environment Application Functionalities and Functional Requirements The functionalities of the application along with relevant functional requirements, concern two main functional areas, as outlined in the following paragraphs Onsite sensor diagnostic tool (e.g., Android application on tablets) As part of using the application as a sensor diagnostic tool, the following functionalities will be supported: (Phenonet) Requirement: Sensor troubleshooting or to view data when walking through the field experiment, for use in the field of a sensor deployment. (Phenonet) Requirement: Local connectivity to the WSN via the tablet to enable realtime checks of a sensor status and network health. This would be used during the deployment, when troubleshooting deployments and when making manual observations of the experiment manual observations may be entered into the tablet (e.g., this plot is flowering now, this plot has stripe rust). (Phenonet) Requirement: Tablet with GPS connectivity to overlay the deployment on a map and trial plan (plant science specific). (Phenonet) Requirement: Capacity to query sensors via bar code using the integrated camera of tablets. This will be used useful for geo-referencing the sensors during deployment, and troubleshooting the sensors and maintaining records of sensors histories. 46

53 Manifiesto-V Domain-specific Analysis and Visualisations As part of the domain-specific analysis and visualisations the following functionalities are envisaged (which are associated with application requirements): (Phenonet) Requirement: Capacity to filter data according to manual observations or non-wsn data (e.g., only compare plots where NDVI (Normalised Difference Vegetation Index) is > x). (Phenonet) Requirement: Rank the performance of each genetic variety by aggregating replicate data for a specific time period and calculating mean and standard deviation (e.g., all measurements from 11:00 to 13:00 between two specific dates for plots with NDVI exceeding a certain value X and for all varieties at depth x, when did soil suction become > x). (Phenonet) Requirement: Enable high level decision support for experiments where the scientist wishes to utilise a crop simulation model and information from a local automatic weather station and historical climatic data. This would involve integration of the near real-time WSN and non-wsn measurements into the APSIM crop simulation model ( to create APSIM live. This system would have greater capability than Yield Prophet ( including improved rigor and capacity to test and validate the model Non-Functional Requirements Licencing Requirements The reliance of the use case on the Phenonet and GSN project implies a set of licencing requirements, which have to be taken into account in the scope of the OpenIoT open-source project establishment. In particular, as GSN is licenced under GPL, it requires any software, which ships along with it to be also open source under GPL licence. In order to address the IP requirements of CSIRO, we can provide the network-based integration of our software components and GSN. Using this approach, CSIRO doesn t need to provide the software for free nor release the source code. This relationship is depicted in Figure 6. In other words, any part of Phenonet, which is not directly related to OpenIoT s use cases, will not be open source, for instance, data modelling algorithms to predict crop performance, implementation of crop performance indicators. Figure 9. Illustration of licencing requirements associated with the (re)use of Phenonet in the scope of OpenIoT. 47

54 Manifiesto-V1 5.3 Manufacturing Application The third validating use case of OpenIoT will focus on the manufacturing domain, focusing on traceability (track and trace) and performance monitoring. The use of a scalable virtualised infrastructure for automatically orchestrating sensors and other industrial automation devices in a manufacturing plant can contribute to its operational efficiency. Indeed, even a mid-sized plant can nowadays have more than 10,000 sensors, actuators and other devices, which have a significant total cost of ownership (TCO). OpenIoT can enable the deployment of multiple services sharing this infrastructure in order to increase the automation of the plant and empower knowledge-driven processes Application Description Manufacturing Environment The OpenIoT manufacturing application will showcase the ability of the project s platform to deploy and execute multiple on-demand utility-based services over a sensor and actuator infrastructure within a manufacturing plant. For the purposes of the use case, SENSAP will consider a manufacturer that maintains warehouses of source and second materials, as well as manufacturing plants. The basic setting considers that within each manufacturing plant, there are multiple production lines. Each of the production lines executes a production phase or a task of the production processes. Each production line involves certain machines, which feature a specific serial number. In the scope of the production process, different production resources (e.g., tools) are associated with the machines of the production lines for specific time intervals. This association concerns the production of specific numbers/units of finished products. A production process comprises multiple production tasks, which are executed on the basis of a pre-defined order. In each production phase (a) source and second materials are added in each production unit and (b) production units, as well as units of source and second materials undergo certain processing. It is generally considered that source and second materials are tagged/labeled on the basis of RFID and/or barcode labels. Production processes take as input materials, and make use of specific processes and assets (e.g., machines) in order to produce semi-finished and finished products. Semi-finished products are stored in the warehouse, while finished products are shipped (as prescribed by a production order) Application Scenarios In this environment, a private cloud infrastructure will be deployed (by SENSAP) to hold and manage data from multiple plants and warehouses. Over this infrastructure the OpenIoT middleware will be deployed and tailored to the needs of the application. The validation will be performed in the SENSAP labs, as well as using the infrastructure of one of SENSAP s clients (notably in the packaging sector). SENSAP will focus on two (related) application scenarios, which involve OpenIoT functionalities and deployments. Both scenarios emphasise the on-demand formulation of IoT services based on requests of the manufacturer or plant operator. The two scenarios concern plant performance monitoring and production process traceability. 48

55 Manifiesto-V Application Functionalities and Functional Requirements Main Functionalities In the area of plant performance monitoring, the OpenIoT deployment will be used to: Submit performance monitoring requests concerning one or more KPIs (Key Performance Indicators) associated with the plant operation. On-demand calculation of KPIs associated with multiple sensors and Internet-connected objects of the plant. The KPIs to be specified in the scope of the performance monitoring requests will have the following characteristics: o They will be composite, i.e., they will combine information from multiple devices and/or other indicators (such as material consumption rates, production rates etc.). o They will be virtual and reusable by other KPIs (services). o They will be, in general, decided by the plant operator on the fly and on-demand (i.e., they will not be known beforehand). o They will be connected to actionable logic and M2M interactions e.g., enabling the configuration of machines in case some thresholds are exceeded. o They will be application/plant-specific i.e. customizable to the manufacturer s needs. o They could span multiple plants and warehouses. Generate dashboards for automatically displaying the KPIs and their evolution. These dashboards will be based on OpenIoT s HMI/mashup capabilities. Figure 10. Image Sensor to be used in the manufacturing scenarios Likewise, in the area of production process traceability, the OpenIoT deployment will be used to: o Submit requests for tracing specific production orders, task or steps and report on their correctness and quality; the request will have the following characteristics:they will make use of multiple industrial automation sensors and Internetconnected objects within the plant. o They will be able to trace production orders, steps or tasks (i.e. different granularities). o They will be able to connect to actionable logics including M2M interactions (e.g., tagging of a lot, configuration of a machine or tool). 49

56 Manifiesto-V1 As part of each request, the process and its quality characteristics will be visualised (e.g., based on appropriate mashups) Sensors and Internet-Connected Objects Involved The realisation of these scenarios will involve a variety of plant sensors including: Radio Frequency Identification tags and readers, given that source/second materials, machines, tools and finished products (lot/palette level) will be tagged on the basis of RFID tags. Likewise, barcode labels and scanners will be supported as well. Laser Barcode scanner (Figure 12), which will be used for quality control of finished products. In particular, based on scanning of barcode labels (e.g., 2D barcodes labels) this scanner can provide proof of delivery for finished products. Optical Diffusion Sensors (Figure 11), which will be used to calculate several differential rates associated with the production operations such as material consumption rates, production rates, change rates etc. Weight Sensors, in order to check the (lot level) weight of the materials before and after the completion of the production process, which will accordingly allow for the calculation of the amount of utilised materials. Temperature sensors, which will be used in the scope of quality control KPIs (e.g., in order to flag a given material or lot). Image Sensors (Figure 10), which (along with pattern matching algorithms) are also used for quality control of the finished products (e.g., based on their barcode, colour, or appearance). Figure 11. Optical Diffusion Sensor to be used in the manufacturing scenarios 50

57 Manifiesto-V1 Figure 12. Laser barcode scanner (ultra high speed) to be used in the manufacturing scenarios (for proof of delivery) Utility to be Measured The on-demand requests for performance monitoring and track/trace of production processes will be also utility-driven. Each service request will be metered based on the number and type of sensors used, the read cycles employed, the volume of data exchanges, the type, nature and volume of actionable logic invoked, the complexity/sophistication used and more. SENSAP will explore how these utility meters could be later used for charging manufacturers and plant operators List of Functional Requirements On the basis of the above descriptions, the following requirements can be deduced: (Manufacturing) Requirement: The OpenIoT platform should enable the composition of virtual sensors based on the rule-based combination of the outputs of one or more physical sensors. (Manufacturing) Requirement: The OpenIoT should enable interactions between different devices and Internet-connected objects. (Manufacturing) Requirement: The manufacturing application should enable the configurable visualisation of different dashboards on the basis of the outputs of different Internet-connected objects, including virtual sensors. (Manufacturing) Requirement: OpenIoT should enable the modeling and tracking of aggregations of Internet-connected objects comprising traceable entities such as orders, finished products etc External Interfaces Requirements The manufacturing IoT systems and services to be developed should interface to the following external systems: (Manufacturing) Requirement: OpenIoT should interface to Enterprise Resource Planning (ERP) and Manufacturing Resource Planning (MRP) systems of the manufacturers in 51

58 Manifiesto-V1 order to access information about products, materials, production processes, quality thresholds, resources and assets utilisation etc. Typically, OpenIoT services should both get/read information from these systems (e.g., to access product and materials description) and write information calculated by the IoT system (such as asset utilisation factors) to these systems. (Manufacturing) Requirement: OpenIoT should interface to EPC-IS (Electronic Product Code Information Sharing) databases, where information from EPCGlobal compliant RFID systems will be stored/managed. Note that SENSAP s deployments (based on its S- BOX product suite) are compliant to EPC-IS and the EPCGlobal architecture, hence they can be used in the scope of the manufacturing use case. To this end, EPC-IS databases could be integrated to the OpenIoT platform as virtualised high level sensors Non-Functional Requirements Typical non-functional requirements that should be supported by the OpenIoT middleware include: (Manufacturing) Requirement: Interoperability across different sensors and devices (including M2M interactions) given the multi-vendor nature of the plant. (Manufacturing) Requirement: Ability to implement safety measures for some types Internet-connected-devices. (Manufacturing) Requirement: Scalability and elasticity in terms of the number and size of manufacturing plants, production lines, production processes, sensors and devices supported. (Manufacturing) Requirement: Basic compliance with (relevant) manufacturing standards (such as ISA95), at least in relation to the data collection part of these standards Other Requirements In the scope of this use case, compliance with technologies and platforms supported by SEN- SAP s S-BOX product is also a requirement, given that this product will be used to deploy and support the above scenarios. S-BOX is a JavaEE compliant application, which implements part of the EPCGlobal standards. 5.4 Other End-user Applications The three use cases outlined above provide a good initial set of requirements for OpenIoT in terms of: Types of sensors and devices that should be supported by OpenIoT. Number and data volumes of sensor (and ICO) streams. Properties of ICO that should be supported and managed in the scope of OpenIoT applications. Integration, linking and sharing of information stemming from ICO towards complete applications. On-demand services that should be provided by OpenIoT. Utility metrics and their use within OpenIoT applications. 52

59 Manifiesto-V1 While the three use cases outlined above will receive the primary focus during the development of the OpenIoT platform, our intension is to keep the platform general in terms of its ability to support additional applications and service requested beyond the use cases to integrated in the scope of WP6 of the project. To this end, we can consider functionalities and requirements associated with similar IoT applications in areas such as supply chain management, logistics, meteorological monitoring, climate modelling, building management systems (smart metering), energy production monitoring, traffic management, e-health, smart spaces and ambient assisted living. In addition to the experience and the activities of the project partners in these domains, a good set of requirements, target functionalities and applications can be derived from other EC co-funded projects on IoT, which are building/deploying similar applications. In the sequel, we provide a set of representative applications in several areas, based on a brief survey of other projects of the IERC cluster. While it is not realistic to claim full support for all these applications, the respective functionalities could be taken into account in the development of the OpenIoT platform in order to enhance its scope and applicability. Deliverable D2.2 will provide further insights on the type of applications that could and will be supported by the OpenIoT platform, in addition to the use cases outlined earlier in this section Applications from other IERC projects ebbits The ebbits project aims to develop an architecture, technologies and processes, which allow businesses to semantically integrate the Internet-of-Things into mainstream enterprise systems and support interoperable real-world, online end-to-end business applications. The ebbits platform will be based on a service-oriented architecture, transforming every device into a service. (ebbits Consortium, 2010). ebbits main objectives are to: Provide the platform for interconnecting energy control and energy monitoring equipment. Provide the platform for continuous connectivity and on-line monitoring of consumer products The ebbits-supported scenarios are: Automotive manufacturing domain Sustainability management: making certain that a plant is working at its optimum in terms of energy consumption. Instantaneous response and predictive maintenance: in the plant, collisions between moving mechanical parts no longer happen; this substantially reduces downtime. Moreover, the plant will alert the maintenance staff when deviations are occurring before it is too late to remedy. Food traceability in the agricultural domain Food traceability scenario: the ebbits project aims to unify the agricultural domain become an integrated IT platform where data floats between the different sub-domains. All cows and pigs are uniquely identified; all ingredients in feeding stuff have become traceable, as well as every piece of meat in the stores. Animal identification is based on RFID tags. 53

60 Manifiesto-V IoT-A IoT-A aims to develop a socially and business relevant architecture reference model for heterogeneous entities. It proposes the creation of an architectural reference model together with the definition of an initial set of key building blocks. Together they are envisioned as crucial foundations for fostering a future Internet-of-Things. Using an experimental paradigm, IoT-A will combine top-down reasoning about architectural principles and design guidelines with simulation and prototyping to explore the technical consequences of architectural design choices. (Edward Ho (HSG), 2010). The IoT-A supported scenarios are: Multidimensional, automated, trustworthy, and seamless distribution monitoring for assuring a globally sustainable healthcare systems. o Challenges: Costs need to be limited to a moderate level Offer healthcare services in any location Manage the challenges of a distributed value chain o Main components of this value chain to be considered are: Production and production logistics Transport and transport logistics Distribution of pharmaceuticals and distribution logistics Intra-clinical and home care logistics o Technological challenges that will be addressed for every component in the value chain are: Status/context monitoring Efficiency enhancement through automatisms Security and privacy Safe Smart City o Common smart cities applications are: Traffic management CCTV General announcement screens o Use case: Open and flexible description of object capabilities (Example 1: Closed Circuit TeleVision (CCTV) camera has a given codec, is Pan-Tilt-Zoom (PTZ) capable, has a specific definition and frame rates, is at particular location. Example 2: a traffic light is at such location, is currently green/orange/red, is in activity since such time...). Objects can be aggregated into more complex objects (Example: a street is a collection of crossroads, traffic lights, CCTV cameras, speed meters, gates to buildings, parking meters...). ehealth o Use cases: Remote patient monitoring (RPM) Patient provider secure messaging Measurement of very low voltage body signals Automotive Applications in M2M capable networks o Use cases: Electric vehicle charging Fleet management / theft tracking Vehicle-to-infrastructure communications 54

61 Manifiesto-V1 Collaborative City o Business processes and applications: Provide services to the different communities in the city and make them collaborate to reach a common goal and make our future city a collaborative city Mobility is central to the life in the city. People need to enter and access all areas of the city Heating and transportation are the two activities which impact the most in terms of pollution Products suggest the owners how to achieve their individual needs (commands) with also the maximum optimisation of community and macro level objectives (directives). Electric Vehicle lifecycle services o Application areas: Manufacturing ( beginning of life ) Logistics Usage (charging), maintenance / other services ( middle of life ) End-of-life of components (battery) and vehicle o Use case executable actions: Understand the need of energy and autonomy on an individual level Understand the need of energy and autonomy on a community level Understand the availability of energy and charging stations with respect to the charging mode (fast/home) Drive and route to charging and swapping station Charge and swap battery Diagnose battery and vehicle Recharge or dispose battery Dispose vehicle (understand final status of vehicle) Future Retail o use case: Use a RFID tag on the products in the store to enable the following application: Identify the product Trace it in the supply chain and store for the inventory, reception and management Offer product information in the store and at home (nutrition, cross products ) Enable automatic payment Antitheft system Automatic replenishment when sell by date or disposed in bin ELLIOT The ELLIOT (Experiential Living Lab for the Internet-of-Things) project aims to develop an Internet-of-Things (IoT) experiential platform where users/citizens are directly involved in co-creating, exploring and experimenting new ideas, concepts and technological artifacts related to IoT applications and services. (elliot consortium, 2010) ELLIOT use cases focus on three different sectors, namely well-being, logistics, and environment. More specifically these are: 55

62 Manifiesto-V1 City of the Future: It is split into four different scenarios: (a) media (TV for pediatrics), (b) personalised services (innovative vending machines), (c) tourism services (tourism and physical activity web portal) and (d) public transport (services related to the San Raffaele automatic metro line). Logistics: It focuses on the design and use of intelligent product applications in an IoT environment. Intelligent logistics objects that are capable of detecting formerly defined risk situations. Green Services: A flow of data is collected from various mobile sensors ("green watches" and "green vehicles"), and fixed sensors (city devices, inhabitants' balconies, for instance) and used by the stakeholders either to improve transportation and/or health/well-being. Retail: The retail use case demonstrates an intelligent shopping environment, where userfriendly customer experience is achieved using diverse IoT technologies RFID, barcode, NFC centered upon a personal information terminal. The new shopping and payment concept encompasses diverse functionality, including product information, loyalty program, promotional programs coupons, and payment. Remote Patients Assistance: The purpose is to provide medical services to patients being away from a medical centre. The patient has to be equipped with one or a few smart medical sensors. Somewhere in the Internet (possible as a Cloud computing service), a Web intelligence system has to exist, which will collect the sensor information, will analyse them and, if necessary, to involve a doctor for advising appropriate actions. The doctor has to react accordingly preventing the patient from possible or increasing illness. Energy Efficient Office: This scenario is aimed at implementing the energy efficiency, goal-driven, intelligent application of a Smart Office. The aim is to support semantic interoperability of devices and sensors in the building as well as ICT devices (e.g. smart phones or s) used by people/employees by means of a semantic middleware NEFFICS ( NEFFICS considers the Internet as a universal business system which enables value generation in enterprises by collaborating in open knowledge innovation zones (i.e. networked enterprises). Traditional IT, and in particular ERP, does not adequately support transformation, management of knowledge work and participation in or management of networked enterprises. A new class of IT platforms, so-called Business Operation Platforms (BOP) is emerging, and is better suited for these tasks. A BOP provides real-time connectivity in distributed environments, based on Service-oriented Architecture (SOA) in an Internet-of-Services context of the Future Internet. Such infrastructures open up new value proposition and business opportunities for enterprise networks, which NEFFICS will address. (NEFFICS consortium, 2011) NEFFICS consortium Website, 2011, available at: NEFFICS will provide two case studies which are: The Virtual Factory Network o Development of a connected retail network (CR) in the cloud supporting the value chain of a company in the fashion industry. The connected retail makes use of cloud techniques to establish the connection between customer and supplier, pushing the concept of ECR to its very edge and complementing retailers flow of information. Retailers and suppliers will also use cloud services to complement traditional enterprise resource planning systems (ERP) or merchandise information systems (MIS) already in place. 56

63 Manifiesto-V1 o Collaboration within the CR will be supported by extended use of Web 2.0 technologies. Business process innovation will be integrated part of the CR solution. The Connected Retail Network o Development of a virtual extended factory (VEF) in the cloud supporting the (networked) value chain of a company in the manufacturing industry. The virtual extended factory makes use of cloud techniques to integrate business processes of the companies that participate in this VEF. o Collaboration within and between companies will be supported by extended use of Web 2.0 technologies. o Chain-wide business process innovation will be integrated part of the VEF solution IoT@Work IoT@Work focuses on harnessing IoT technologies in industrial and automation environments. It will use the FIAT Research Centre facilities to develop an IoT-based plug-and-work concept centered on industrial automation. The project aims at designing an IoT architecture that takes the industry and factory automation systems and their networking and communication needs into account, while focusing on the auto-configuration and security to allow for true flexibility and reliability through what we call plug-and-work IoT. The outcome will be open interface specifications and protocols, which will be validated through a proof-ofconcept prototype implementation applied on a small-scale industrial process that will reflect many of the challenges faced in large-scale factory processes. (IoT@Work consortium, 2010). IoT@Work scenario Clusters: (Rotondi, 2010) Agile Manufacturing o Is a production approach heavily based on the availability of manufacturing support technology that can be easily reconfigured to quickly respond to market changes, still providing full control of production costs and quality. o Agility can be required at many different levels from the network level (adapting network resources for network faults or increased load), to the process level (adapting processes to new requirements). Large Scale Manufacturing o Is representative of large production arrangements where many different production sites have to be co-ordinated and integrated. o Is used in scenarios where the automation network is structured into multiple, physically (and in many cases also administrative) separated networks. Remote Maintenance o This scenario helps analysing situations in which external providers (e.g. robots/tools providers) have direct access to devices or data within the production sites to assure production continuity, for example doing preventive maintenance. 57

64 Manifiesto-V1 6 FP7 Projects interested/related with semantics 6.1 icore-internet Connected Objects for Reconfigurable Eco-System A brief description of the project icore (Internet Connected Objects for Reconfigurable Ecosystems) is an industry driven integrated project (IP) whose consortium is composed of 20 partners including 13 industrial partners spread across 12 countries in Europe, besides including partners from China and Japan. It is a challenging innovative research and development project which main goal is to empower the Internet of Things (IoT) through virtual objects and cognitive technologies. icore will realise the principle that any real objects and digital objects, which are available, accessible, observable or controllable, can have a virtual representation in the Internet of Things (IoT). The virtual representation or virtual objects (VOs) are primarily targeted to the abstraction of technological heterogeneity. VOs accomplish their role through the cognitive management and handling of real-world or digital objects (e.g., sensors, actuators, devices, etc.). Composite virtual objects (CVOs) will be using the services of virtual objects. A CVO is a cognitive mash-up of semantically interoperable VOs that renders services in accordance with the user/stakeholder perspectives and the application requirements icore will produce a cognitive control and management framework that conceals the technological heterogeneity, comprising the perspective of users/stakeholders, and facilitates context-awareness and higher reliability. For more information on icore, please click here: Interoperability related issues (focus on semantics) Interoperability approaches are classified into two main categories. The first is the approach of standardizing everything, i.e. all parts must use technologies that conform to preagreed standards (e.g. communication protocols, OS platforms, metadata). The second is the approach of standardizing some level of technology (e.g. W3C Web protocols and formats) and at the same time using intelligence for the non-standardized part of the involved technology (e.g. intelligence through semantic technologies, for instance ontologies). icore clearly follows the second approach since it is not realistic to assume that all icore stakeholders (e.g. users, vendors, information brokers) will be willing to adapt their technology to one common pre-agreed standard. From the vendors point of view, as recently reported in CES 2012 (Las Vegas), a need for openness (cross-vendor interoperability, open APIs) has been identified, but the level of companies support towards this goal is still unclear. Regarding connectivity of devices through gateways (special hardware to solve interoperability issues at the network-communication level), the next step would be to do the job in a gateway-free manner, i.e. based on intelligence spread in devices and applications. Semantic technology is about making computers act in an intelligent way. The modern approach (in contrast to the traditional AI one that tried to make computers so clever that they would be able to process the information about the world in its full complexity, e.g. understand human language) is about simplifying the description of the world to a level that even stupid computers will be able to act intelligently based on it. The main goal of the semantic technology is to make the meaning of data as explicit as possible, as unambiguous as possible and as context-independent as possible. Also, to link data sources globally i.e. provide more 58

65 Manifiesto-V1 meaning with same data (small messages, fetch the rest from Web). To achieve this goal it uses W3C standard technologies: the Semantic Web data model, URIs, and Ontologies. Semantic interoperability is the ability of information systems to disambiguate information/data so that receiver and transmiter agents can understand each other and collaborate i.e. mapping of information from one system to another in a meaningful way for their agents. Adding this ability to icore agents living in smart environments and IoT, can be seen as meaningful information exchange or integration between agents that manage (Composite) Virtual Objects in smart environments (smart homes, cities, IoT) seamless querying and access of distinct and disparate virtual objects under common views. Most of the projects in the area of IoT address semantics mainly as a means for interoperability. Key topics in most of these projects (e.g. SOFIA, DIEM) are a) the creation of a semantic interoperability platform for new services which enables and maintains crossindustry interoperability and b) the semantic interoperability between devices from different domains and platforms. Going beyond the use of semantics for interoperability, an important, envisaged innovation of icore is the specification and development of mechanisms for the high-level description, registration, discovery and access/invocation of existing VOs and CVOs and the services that these provide. The icore project will contribute to the specification of VOs and CVOs semantics that will allow for the efficient, distributed, scalable registration and discovery of VOs and CVOs that may be re-used outside the context of which these were created. In general, interoperability is the one of the main requirements for icore system. Interoperability in icore project is placed in different dimensions i.e. technical interoperability, syntactic/semantic interoperability and organizational interoperability. Technical interoperability in icore is related to the requirement for enabling the integration of several heterogeneous technologies to be used in one system. The requirement here is to identify ways for the virtual objects to be interoperable with different underlying technologies. In the application level, the requirement is for icore resources to be able to be accessed by different application layers. Other issues also are related to the requirement of icore-based systems being able to be executed in different platforms, with a variety of operating systems. Due to huge diversity of devices and their different software and hardware capabilities, it is difficult to find a set of common technologies that could be used in each device. Also each selection of technology limits the number of potential icore devices and thus lowers the general interest towards icore technology. So the challenge is how to welcome all the sensor and actuator devices as icore devices. In this setting there are two classes of icore devices. There are class A devices that can execute icore software and those of class B that cannot execute icore software. For class A devices the design and implementation of the software need to enable technical interoperability and dependencies between communication mechanisms (e.g. BT,LAN, WLAN), communication protocols (e.g. TCP, UDP), communication models (e.g. connection oriented, connection-less) operating systems (e.g. TinyOS, Linux, Windows) programming languages (e.g. C, Java, Ruby) programming models (e.g. threads, events, callbacks) Clearly the software that utilizes all above is not possible in practice. The software that uses only one from each dependency category above is not interoperable. For class B devices 59

66 Manifiesto-V1 icore system needs a service that mediates conversation between class B device and icore system. Organizational interoperability is mainly about the way a system is organized, wholepart relations and how the roles of the system are defined among multiple stakeholders. The owners of the system have their own ways of executing icore as a domain specific system. Parts of one icore system could be temporarily or permanently also parts of other icore systems. Temporal inter-system relation possibilities arise naturally with moving icore systems when they move and meet other moving or non-moving systems. The proximity of two systems can be used for enriching the total performance, quality or behavior of the whole. For example the sensors of the icore-vehicle could be used for sensing the environments of roads and parking slots. The whole-part relations are related ownership, where different business models and security requirements may control intersystem relations. The formation of whole system and the reduction into parts is an organizational challenge. Yet another challenge arises simultaneously at the semantic level. How different icore systems in different domains understand each other? Semantic Interoperability of VOs/CVOs For true interoperability within the icore setting i.e. the ability of the icore VOs and CVOs to unambiguously convey the meaning of data they communicate (device to device or device to application communication) over Web protocols, semantic interoperability is the key solver (given that syntactic interoperability has been already achieved). A trend in IoT research area is to attempt to integrate things seamlessly with the existing Web infrastructure and to expose connected things uniformly as Web resources, resulting in what is called the Web of Things. Semantic Web technology can be used to extend the Web of Things, shaping consequently what is sometimes referred to as the Semantic Web of Things (SWoT). The aim is to reuse the architectural principles of the Semantic Web and apply them to the connection with the real world objects via their virtualization, i.e. with Virtual Objects (and CVOs) e.g. smart engines, smart packages, smart rooms, thereby making them first-class citizens of the Web [1, 2]. Such an approach is a great facilitator of interoperability and will be able to enable realization of use cases as the following: Two temperature sensors are both delivering measurements over HTTP GET as JSON, but of different structure and with different object/property names. Two heater devices are accepting commands over HTTP PUT as JSON, but of different structure and with different object/property names. A motion detector and light switch control software (one integrated application) is communicating messages (accepting measurements data and delivering commands in XML) with the related devices (communicating in JSON format) using heterogeneous vocabularies (e.g. app:motion and dev:movement). The application must be able to understand motion detection events and issue commands to the switch actuator e.g. for switching on/off the attached device (lamp). The switch actuator must be able to understand commands issued by the application. The process must be automatic or at least semi-automatic with minimal human involvement. A package with an RFID or UCODE attached to it sent by a post office in origin-a can be automatically managed and forwarded by the intermediate destination-b to the next destination-c, without the current requirement that all post-offices (origin and destinations) share the same database or even the same semantic repository. 60

67 Manifiesto-V icore vision in terms of Semantic Interoperability Except for UPnP and DLNA-based media sharing, today any IoT solution must follow one of the following: Buy all the devices from one vendor Connect smart devices (phones, TVs) from different vendors through installing a particular software client (from one vendor) on each of them (limited list of supported platforms) Use a particular gateway box, then can connect devices from different vendors (from a limited list of supported by the gateway). In all three cases, a single vendor is responsible for all of the interoperability. The work reported in this paper is particularly motivated by a vision of an open and interoperable IoT, where the following four related requirements are satisfied: Ability to have gradually growing IoT environments, contrasted to installing and interconnecting all IoT devices and software at once. Ability to automatically interconnect devices from different vendors. Ability of 3rd parties to develop software applications for IoT environments, contrasted to applications coming only from the devices vendors. Ability to develop applications that are generic in the sense of running on various IoT device sets (different vendors, same purpose), contrasted to developing applications for a very particular configuration of devices. Different companies have in the current single use situation their own sensors and applications. The vision of icore is that organizations could benefit from sensors of other parties provided the sensor data can be found easily by the potential user (requires a SWoT based discovery mechanism), have an associated SLA for the potential user (service quality guarantees), can be opened to potential users selectively by the owner (requires an inter-domain access rights mechanism), brings some benefit to the owner (requires support of billing for access to sensor data). In the icore vision there is a business case for organizational interoperability because for the user: using the icore concepts will make it attractive to use the sensor network of another party instead of building a sensor network yourself; for the provider: using the icore concepts opening up your sensor data to other parties is safe and cost-effective. The business case for sensor data sharing between organizations, i.e. organizational interoperability, is an economic driver. Since semantic interoperability is one of the requirements for organizational interoperability, semantic interoperability shares this business case support for the SWoT Current approach As already stated, icore aim is to specify and develop mechanisms for the high-level description, registration, discovery and access/invocation of existing VOs and CVOs and the services that these provide. The icore project has already started the contribution towards a shared and agreed specification of VOs and CVOs semantics with the aim to support the efficient, distributed, scalable registration and discovery of VOs and CVOs that may be re-used 61

68 Manifiesto-V1 outside the context of which these were created. Nevertheless, icore does not aim to restrict the representation of VO/CVOs using only a standard ontology, since this may not be realistic for IoT world. On the contrary, the aim of the project is to allow also for heterogeneous descriptions of VOs and CVOs via the support of the automatic computation of alignments between them. The requirements and the design of the Semantic Smart Gateway Framework towards supporting semantic interoperability of smart entities in the IoT is reported. The framework is designed to support the dynamic (semi-)automated translation process of Smart Entities data (at runtime), with minimum human involvement, by computing their ontology definitions alignments. Specifically, the Semantic Smart Gateway Framework (SSGF) provides: A semantic way for registering smart entities, their ontology definitions and their computed alignments, in a medium-to-small gateway-oriented scale, so their discovery and retrieval can be performed in an intelligent manner (using common views of their data and utilizing their alignment axioms). An ontology alignment component to support the discovery of similarities between smart entities profiles and ontology definitions, in order to be able to i) support the retrieval of similar smart entities in a common view, ii) support the clustering of smart entities into domain-specific clusters, iii) to support the merging of similar smart entities towards a more efficient network organization, iv) to support the interoperability of smart entities with smart applications that also carry ontology definitions of their input/output parameters. An ontology learning component to support the (semi-)automated semantic description of smart entities that are not pre-equipped with ontology definitions but instead they carry simple metadata e.g. an RDBS schema or JSON. Transform (example) messages (data/commands) to ontology definitions for both device-side (hardware) and application-side (software). A first prototype architecture of a smart proxy that implements 2 and 3 of the above list is depicted below. There are still open issues that need to be treated: Where and how to place human involvement for the refinement of ontology definitions that cannot be fully automatically shaped from raw data (see Figure 1, domain expert labeled grey face icon) Where and how to place human involvement (or other means of detecting and correcting erroneous alignment decisions e.g. wisdom of network) for the validation of the computed alignments between ontology definitions since a 100% accuracy of a fully automated method is not realistic (see Figure 13, validator labeled grey face icon) Figure 13. Smart proxy architecture 62

69 Manifiesto-V1 Smart Proxy architecture for the (semi-)automated alignment of smart entities (VOs), meeting both syntactic and semantic interoperability of exchanged data between agents (in this case, device and application) A similar approach, based on the SSGF proposal and the smart proxy architecture, will be followed for solving icore semantic interoperability issues. More specific, we plan to utilize the presented approach to (semi-)automatically align and integrate information at VO and CVO level, for: Automatically register new (C)VOs (for heterogeneous (C)VOs) in a (C)VO registry (C)VO to registry alignment Identify similar (C)VOs (for clustering VOs and shaping clusters based on different criteria, e.g. domain, location, capabilities ) (C)VO to (C)VO alignment Identify similarities of (C)VOs with application requirements (C)VO to Apps alignment Support the automatic creation of CVOs - services matchmaking between CVO and VO service descriptions, CVO to VO alignments Use alignment information for semantic adaptations. (C)VOs can adapt to preferred domain ontology. It is important to state that in this paper we have aligned the notion of a smart entity with the one of icore s virtual object (VO). It is also important to state that a smart entity/vo must be somehow linked to or carry a domain-specific ontology definition [REF 4] for describing their input/output data, profile properties, etc. 6.2 IoT@Work (Internet of Things at Work) A brief description of the project The IoT@Work project aims at designing an IoT architecture that takes the industry and factory automation systems and their networking and communication needs into account, while focusing on auto-configuration and security to allow both true flexibility and reliability through what we call plug and work IoT. The vision of IoT@Work is to be able to configure large numbers of intelligent devices in an automatic manner similar to the way you plug and play a USB stick today. The device is just physically plugged in the system through the network. The network, then, takes care of configuring the device and collecting its semantics and capabilities. Based on this embedded intelligence, the corresponding designed applications and service parameters can be adapted to /optimised for the physical devices. An important constraint of automation systems today is that they are heavily engineered and rely on detailed pre-configured physical components and protocols, making the system very rigid to changes, let alone allowing multiple services or applications to be adapted or added on the fly. 63

70 Manifiesto-V Interoperability related issues (Semantics) In the automation scenario envisaged by devices can dynamically connect to, or disconnect from, the production network, or be replaced and reconfigured to adapt the production device to new products, processes, faults, etc. All these dynamics imply having high needs of information availability both about devices and events, as well as of meta-information to properly interpret those dynamic occurrences and configure or reconfigure devices and production systems. The above needs have obvious impacts on interoperability both from the point of view of the formats and services to make available the required information and meta-information in a way that can be processed by production applications without any previous specific knowledge (as is done today, cabling this knowledge into the applications), and on assuring that devices can actually be dynamically deployed within a production environment without redoing the production engineering The wide deployment of semantics and ontologies is the way to face those dynamic situations Current approach Currently the factory automation makes use of different devices features description formats (EDDL, FDT/DTM, GSD/ GSDML, OPC UA Data Model, ). These formats can normally be processed by applications that have specific logic in them, therefore heavily limiting the adapatability of the production systems. In IoT@Work we are currently developing features to make available semantics information via a common service to both human users and applications. We envisage the need to promote the development of suitable ontologies for managing dynamics and devices in manufacturing contexts and be able to: collecting and making available semantically enhanced information about things, services, roles, promoting the use of semantic reasoning for solving (or reduce complexity) of interoperability issues in production systems, therefore fostering the deployment in manufacturing of: devices used in other contexts, semantic-based device discovery and configuration, semantic reasoning for dynamically manage interoperability issues, Semantic Web of Things 6.3 Internet of Things Environment for Service Creation and Testing (IoT.est) A brief description of the project (Short Abstract) The IoT.est project will develop a framework for service creation, composition and test for IoT enabled environments and will evaluate the results for exploitation towards future IoT service creation, deployment and testing products. 64

71 Manifiesto-V1 To overcome technology & sector boundaries and therefore dynamically design and integrate new types of services and generate new business opportunities requires a dynamic service creation environment that gathers and exploits data and information from sensors and actuators that use different communication technologies/formats. To accelerate the introduction of new IoT enabled business services (in short IoT services) an effective dynamic service creation environment architecture needs to provide: 1. Orchestration, i.e. composition, of business services based on re-usable IoT service components, 2. Self-management capable components for automated configuration and testing of services for things, 3. Abstraction of the heterogeneity of underlying technologies to ensure interoperability. IoT.est will develop a test-driven service creation environment (SCE) for Internet of Things enabled business services. The SCE will enable the acquisition of data and control/actuation of sensors, objects and actuators. The project will provide the means and tools to define and instantiate IoT services that exploit data across domain boundaries and facilitate run-time monitoring which enables autonomous service adaptation to environment/context and network parameter (e.g. QoS) changes Interoperability related issues (Semantics) The IoT.est project uses and extends existing IoT service description models to construct a test-aware IoT service description framework. The IoT.est semantic description framework will enable associations of IoT services to resource, environment, network capabilities and other domain knowledge in service platforms. The existing semantic service descriptions are adapted and extended to support testability and evolvability of services. The framework will also provide means to define service templates for different business use-cases that can be instantiated with relevant service components and IoT resources during the construction process. The main semantic interoperability are providing test-aware IoT service descriptions and information representation models than can support knowledge-driven and goal oriented IoT service composition in a global framework. IoT.est focuses on defining a semantic description framework for test-aware IoT services and the work-flow between different components and resources that construct a service. We also work on developing and reusing different internal and external knowledge resources to support association of IoT service descriptions to different network, domain and environment concepts. However, the key challenge is how to link and relate several existing models in a coherent description framework that as many as possible existing IoT data and resource descriptions can be integrated into the system and how domain knowledge and annotation can be effectively provided in the framework Current approach (Advances, Development, Solutions, etc.) We are currently using and extending IoT-A information model and W3C Semantic Sensor Network Ontology (SSN) to describe the IoT descriptions. We also use linked data approach 65

72 Manifiesto-V1 and in particular Linked Open Data concepts to integrate domain knowledge into the semantic descriptions. 6.4 Generic Adaptive Middleware for Behavior-driven Autonomous Services (GAMBAS) A brief description of the project (Short Abstract) The overall objective of the GAMBAS project is the development of an innovative and adaptive middleware to enable the privacy-preserving and automated utilization of behavior-driven services that adapt autonomously to the context of users. With the advent of powerful personal mobile devices an increasing number of Europeans have constant access to information on the Internet. Nowadays, these devices are causing a drastic paradigm shift in the way people deal with information. Yet, the technical means to access information have only changed marginally. In most cases, information is accessed via the web which requires persons to memorize long URLs, click through web pages or browse through search results. In contrast, ubiquitous computing envisions services providing distraction-free support. To realize this vision, services themselves must adapt to the user s situation, behavior and intents at runtime. This requires services to gather and process the user's context. Personal mobile devices provide a promising basis for determining user context in an automated manner on a large scale. The vision of ubiquitous computing, however, extends beyond the boundaries of a single service as it envisions seamless support for everyday tasks. To close the resulting gaps, the GAMBAS project has the following scientific and technical objectives: 1. Development of a generic adaptive middleware for behavior-driven autonomous services that encompasses: a. Models and infrastructures to support the interoperable representation and scalable processing of context. b. Frameworks and methods to support the generic yet resource-efficient multi-modal recognition of context. c. Protocols and tools to derive, generalize, and enforce user-specific privacy-policies. d. Techniques and concepts to optimize the interaction with behavior-driven services. 2. Validation of the middleware and its components using lab tests and a prototype application in the public transportation domain Interoperability related issues (Semantics) Interoperability among heterogeneous Internet-connected objects (ICOs) and the data they produce is crucial within GAMBAS, given that behavior-driven services often base their decisions on data coming from multiple sources. For that, it is important that data produced in the context of ICO can be discovered and processed by any connect object to which that data might be relevant. However, data produced by sensors and smart mobile devices is often ar- 66

73 Manifiesto-V1 chived or streamed as raw data, but rarely associated with enough metadata describing its meaning. The meaning of data can include the feature of interest, accuracy, measuring condition, time point, location, etc. Such metadata is essential for efficient search and discovery when a connected object is confronted with a large number of data sources. The lack of metadata also makes the integration with other data sources available on the Internet a difficult and labor-intensive task. There have been a lot of efforts in employing Semantic Web technology to semantically enrich sensor data. In order to allow easy integration with other data sources available in Linked Open Data (LOD) cloud, they suggest that sensor data sources should be published following the Linked Data principles. The advantages of such an approach are manifold. Not only would it support the direct integration of sensor data with the large amounts of already available Web and enterprise data, but it can also benefit from a large body of work and infrastructure from existing research areas such as LOD, Web and Data Base Management Systems (DBMS). However, the state-of-the-art in Semantic Web technologies is inadequate for sensor-generated data, due to the highly dynamic and temporal aspects of this data. Moreover, the data representation suggested by Semantic Web technologies typically is not suitable for devices with limited data storage. Existing query processing of Semantic Web data can also not be directly applied to the context of data generated by smart mobile devices. There has been work on extending Semantic Web technologies for stream data, but none of them have looked into distributing the query processing among (possibly resource-constrained) devices Current approach (Advances, Development, Solutions, etc.) The GAMBAS middleware will enable the development of novel applications and Internetbased services that utilize context information in order to adapt to the behavior of the user autonomously. A more detailed view of the GAMBAS approach is given in Figure 14. The middleware will provide the means to gather context in a generic, yet resource-efficient manner and it will support the privacy-preserving sharing and scalable processing of the acquired data. Data interoperability will be achieved by means of a unified representation of the heterogeneous data and their data sources, following the Linked Open Data principles. This has many advantages, since it will support the direct integration among the data generated by the ICOs. The unified view will consist of basic vocabularies and ontologies that will cover all aspects of the data gathered in the data acquisition phase and their sources. Special care will be taken to represent dynamic and temporal aspects. The goal is to have the ICOs themselves store their generated data locally in the form of Linked Data, by using the vocabularies and ontologies developed. Therefore, special care has to be taken with the amount of data that needs to be stored, since storage in connected objects is limited. Descriptions have to be complete, yet compact, so efficient summarizations are very important. 67

74 Manifiesto-V1 Figure 14. The GAMBAS Approach Once descriptions for the generated data and their data sources are available, the framework will construct and maintain a directory of descriptions, which will be accessible to every ICO and will be constantly updated to incorporate changes in the network, whilst respecting the communication cost for that ICO. The directory will enable data discovery, and its implementation will also harvest the storage capacities of the connected objects. To support both data interoperability and discovery, the framework will develop Linked Data storage capabilities for the connected objects. This will improve scalability and also privacy, since each ICO will be responsible to storing its own data and it can therefore decide which data can be disclosed and to which ICOs. There are many Linked Data storage frameworks available but none of them are designed for resource-constrained devices. In the GAMBAS project we will build a data storage framework based on state-of-the-art approaches but that will also comply with limitations imposed in terms of memory, processing power, battery life, etc. A query processing framework will also be developed following the same guidelines. Even though the query processing capability at each device will be limited, distributed query processing techniques will be explored for providing a more powerful processing framework among the ICOs. 6.5 ubiquitous, secure internet-of-things with Location and contexawareness (BUTLER) A brief description of the project (Short Abstract) Recent ICT advances are bringing to reality a world where sensors, actuators and smart portable devices are interconnected into an Internet-of-Things (IoT) ecosystem reaching 50 Billion devices by The IoT major challenges are, from a systemic viewpoint, smart resource management and digital security; and from a user/service perspective, the pervasiveness (uniformity of performance anytime and anywhere) and awareness (inversely proportional to the degree of knowledge required from users). 68

75 Manifiesto-V1 BUTLER will be the first European project to emphasise pervasiveness, context-awareness and security for IoT. Through a consortium of leading Industrial, Corporate R&D and Academic partners with extensive and complementary know-how, BUTLER will integrate current and develop new technologies to form a bundle of applications, platform features and services that will bring IoT to life Interoperability related issues (Semantics) One of the objectives of the BUTLER project is to integrate and develop a new flexible smartdevice-centric network architecture where platforms (devices) function according to three well-defined categories: smartobject (sensors, actuators, gateways), smartmobile (user s personal device) and smartservers (providers of contents and services), interconnected over IPv6. On each of these devices, we will create and improve enabling technologies to implement a well-defined vision of secure, pervasive and context-aware IoT, where links are inherently secure and applications cut across different vertical scenarios (Home, Office, Transportation, Health, etc.). Obviously, the stakes on interoperability are high. We are exploring semantics and Semantic Web technologies to deal with: Semantic discovery of content, resources and services on all smart devices Scalable and unified access to semantic annotations Data interoperability and fusion (e.g. in joining heterogeneous wireless sensor networks) Semantic augmentations for localization/context to support situational awareness across different technologies and vertical scenarios Resource limitations for semantic reasoning on smart objects Current approach (Advances, Development, Solutions, etc.) We are exploring and extending existing upper OWL ontologies like SUMO and Cyc, and domain specific ontologies that serve a common purpose, such as the Semantic Sensor Net and FOAF and many context ontologies (including those developed by the involved partners [1]), as well as domain specific ontologies that fit well within the scope of particular vertical scenarios (e.g. SmartHome: DomoML and DogOnt, and SmartHealth: HL7). Another aspect to support horizontal semantic interoperability across vertical scenarios is ontology alignment, or the analysis of how we can map the various concepts in these ontologies to one another. From an architectural point of view, we are investigating scalability aspects (both up and down) of state-of-the-art semantic reasoning tools (e.g. OWL Pellet, HermIT, and many others), query language toolkits (e.g. SPARQL) and semantic databases (e.g. S3DB) for deployment on our smartdevices. Amongst other, we are extending prior work on middleware solutions for semantic interoperability on resource constraint devices to truly support interoperability in the IoT [2][3]. The proposed solutions address performance issues of semantic reasoning on low end devices (targeting even 8 bit 16 MHz microprocessors). While it compromises on the expressiveness of SHOIQ - the description logic underlying OWL DL - for significantly faster semantic matching, it maintains the typical open world assumption with support for selective import of semantic background knowledge. 69

76 Manifiesto-V1 [1] Davy Preuveneers, et al.: Towards an Extensible Context Ontology for Ambient Intelligence. EUSAI 2004: [2] Davy Preuveneers, Yolande Berbers: Encoding Semantic Awareness in Resource- Constrained Devices. IEEE Intelligent Systems 23(2): (2008) [3] Davy Preuveneers, Yolande Berbers: µc-semps: Energy-efficient semantic publish/subscribe for battery-powered systems. In Proceedings CD of the 7th International ICST Conference on Mobile and Ubiquitous Systems: Computing, Networking and Services, pages 1-12, Sydney, Australia, 6-9 December Enterprise Collaboration & Interoperability (COIN) A brief description of the project (Short Abstract) COIN Project 2020 Vision Statement By 2020 enterprise collaboration and interoperability services will become an invisible, pervasive and self-adaptive knowledge and business utility at disposal of the European networked enterprises from any industrial sector and domain in order to rapidly set-up, efficiently manage and effectively operate different forms of business collaborations, from the most traditional supply chains to the most advanced and dynamic business ecosystems COIN Motto Enterprise Interoperability and Enterprise Collaboration are the two sides of the same coin COIN Metaphor The COIN coin metaphor is also useful to describe the 5 major research topics of the project: The SIDE A of the COIN: Enterprise Collaboration. COIN developed innovative services for Enterprise Collaborative in Product Development (c-pd), Collaborative Production Planning (c-pp), Collaborative Project Management (c-pm), as well as in Human Centric Collaboration (c-hi). The SIDE B of the COIN: Enterprise Interoperability. In the COIN context, EI services provide functionality for applying IT solutions that overcome interoperability gaps between two or more enterprises and thus enabling them to set-up and run collaborations. The COIN Project provides innovative integrated-unified-federated solutions for bridging interoperability gaps at the level of data, service, process and knowledge. The main goal of the EI services is to reduce the costs of data reconciliation, systems integration and business processes synchronization and harmonization. The COIN project adopted the ATHENA EI reference framework which addresses interoperability at different levels, by using two main approaches (i.e., model-driven and semantics-based). Interoperability at the information/data level is related to the exchanging and sharing business documents among organizations, by filling interoperability gaps related to the format and content and to the messages and/or structures to be exchanged. Interoperability at the service level is concerned with discovering, ranking, selecting, composing, orchestrating and executing various applications implemented as a service. Interoperability at the process level is the capability to make proper external views of 70

77 Manifiesto-V1 enterprise internal processes synchronised by a collaborative inter-enterprise business process. Interoperability at the knowledge level should be seen as the organisational and operational ability of an enterprise to co-operate with other, external organisations in spite of e.g., different working practices, legislations, cultures and commercial approaches. The Metal of the COIN: Generic Service Platform. The COIN Project develops a pervasive, adaptive service delivery platform to host COIN services for Enterprise Collaboration and Enterprise Interoperability. A generic Semantically Enabled Service Architecture has been customised for the EI/EC domain and empowered with peer-to-peer, trust & security and intelligent reasoning / negotiation capabilities. Here the objective of COIN is to develop an open-trusted federation of service delivery platforms, namely the ISU (Interoperability Service Utility) aimed at making accessible, browsable, composable and executable from a single one-stop-shop the myriad of EI/EC services developed not only in COIN but in any other research project or standardisation/commercial initiative. The Value of the COIN: Software as a Service Utility. The COIN project supports the establishment of business models for interoperability service utilities that will match current market condition and completion. In conformity with the vision and mission of COIN, the research is particularly concerned with market developments and trends with reference to the themes of Software as a Service (SaaS) and Interoperability Service [as] Utility (ISU). SaaS is a market reality while ISU is a research challenge premised upon a re-structuring of the current Internet. The Market of the COIN: Manufacturing Enterprises, mainly SMEs. The COIN original project encompasses six industrial test cases in different domains (Automotive, Space, Aeronautics, Healthcare, ICT, Plants Engineering). The test cases have been extended to twelve, by adding new six domains coming from the so-called Enlarged Europe (Marine Shipping, Railways Components, Agro-food, Civil Construction, Logistics & Transport, Media). All the developed constituents of the COIN metaphor need to be deployed and adopted in realistic business scenarios and carefully evaluated in their business benefits and exploitation potential. To achieve this objective, specific attention is being spent in COIN to cover the different industrial sectors, European Countries, application domains, EI/EC heterogeneous requirements and legacy systems and applications Interoperability related issues (Semantics) The COIN project addresses interoperability from several standpoints: Theoretical-methodological. What is it interoperability and what is it Enterprise Interoperability (IEEE definition, the ability of two or more systems to exchange data and to mutually understand the information which has been exchanged)? What is it an Interoperability Reference Framework (ATHENA framework)? How to identify and fill interoperability gaps (INTEROP NoE cube)? How many kinds of IT-supported interoperability solutions do exist (integrated-unified-federated)? What is it semantic interoperability and what are the means available now to achieve semantic interoperability (reference ontologies are just one of the numerous ways to semantically fill interoperability gaps)? What are the most innovative ways to achieve semantic interoperability (crowdsourcing, the wisdom of the network, semantic interoperability spaces)? 71

78 Manifiesto-V1 IT-Technical. Following the ATHENA 4 levels, we distinguish data interoperability (e.g. data formats and data payload, unstructured-semistructured-structured data, integrated-unified-federated approaches also semantically-based); service interoperability (e.g. functional and non-functional properties, generic service delivery platform, Web Services and REST, SLA interoperability, orchestration, monitoring, AAA issues end-to-end); process interoperability (e.g. private processes and public views, crossorganisational business processes, human-centred workflows, complex event processing and service oriented architectures); organisational interoperability (e.g. enterprise models for decision-information-physical process models, human competencies interoperability, knowledge interoperability, virtualisation of tangible and intangible assets, horizontal and vertical interoperability). Business Model. COIN claims that interoperability services will soon become a commodity and together with other essential business services they will form the Universal Business System through which enterprises and SMEs in particular could openly conduct their business in the Internet of the Future. The distinction between Utility Services and Value Added Services is well present in the current FI implementation of FI-WARE project, where Generic Enablers (utilities) will support the development of domain specific platforms and applications (value added). Different business and revenue models should drive this twofold aspect of the FI: utility services, such as interoperability services, will become an adjunct to current FI IaaS and PaaS layers, becoming an integrated part of it (available to all in the open Internet, at a very low cost, not owned by any single private entity), while value added services, such as business and/or social applications, will be consumed in a pay-as-you-go mode (SaaS) being them available in professional private-public clouds or in the Internet Web as user generated services. This trend will stimulate also in the ICT domain the generation of hybrid businesses, similarly to what already happened in the Media domain with the free-mium models Current approach (Advances, Development, Solutions, etc.) The COIN project (January 2008 December 2011) developed several models and solution for Enterprise Interoperability, most of them available freely in the public domain ( and some of them implementing semantic technologies for data-service-processorganisation interoperability. 6.7 Open source blueprint for large scale self-organizing cloud environments for IoT applications (OpenIoT) A brief description of the project (Short Abstract) The OpenIoT project focus on providing an open source middleware framework enabling the dynamic formulation of self-managed environments for IoT (Internet-of- things) applications, which will be delivered in an autonomic fashion and according to an utility model based on clouds infrastructures. OpenIoT brings together multidisciplinary first class academic research and industrial expertise, the members of the OpenIoT project, believe that addressing evolution of Internet- Connected objects and emerging models for service management can enable the realisations of Internet connected infrastructures. 72

79 Manifiesto-V Interoperability related issues (Semantics) The OpenIoT middleware infrastructure supports flexible configuration and deployment of algorithms for collection, and filtering information streams stemming from the internetconnected objects, while at the same time generating and processing important business/applications events. OpenIoT is perceived as a natural extension to cloud computing implementations, which will allow access to additional and increasingly important IoT based resources and capabilities. In particular, OpenIoT will research and provide the means for formulating and managing environments comprising IoT resources, which can deliver on-demand utility IoT services such as sensing as a service. OpenIoT architecture (Figure 15) is pertinent to a wide range of interrelated scientific and technological areas spanning: (a) Middleware for sensors and sensor networks, (b) Ontologies, semantic models and annotations for representing internet-connected objects, along with semantic open-linked data techniques (c) Cloud/Utility computing, including utility based security and privacy schemes. Figure 15. The OpenIoT Approach OpenIoT follows an inter-disciplinary approach to the specification of artefacts including models, algorithms, processes, methodologies and architectures that will collectively constitute a middleware framework that can guide the realisation of cloud environments to effectively provide IoT applications and services discovery and, in doing so, support interactions between various IoT systems. 73

80 Manifiesto-V1 6.8 Universal Integration of the Internet of Things through an IPv6- based Service Oriented Architecture enabling heterogeneous components interoperability (IoT6) A brief description of the project (Short Abstract) The IoT6 project aims at exploiting the potential of IPv6 and related standards (6LoWPAN, CORE, COAP, etc.) to overcome current shortcomings and fragmentation of the Internet of Things. Its main challenges and objectives are to research, design and develop a highly scalable IPv6- based Service-Oriented Architecture to achieve interoperability, mobility, cloud computing integration and intelligence distribution among heterogeneous smart things components, applications and services. Its potential will be researched by exploring innovative forms of interactions such as: Information and intelligence distribution. Multi-protocol interoperability with and among heterogeneous devices. Device mobility and mobile phone networks integration, to provide ubiquitous access and seamless communication. Cloud computing integration with Software as a Service (SaaS). IPv6 - STID Information Service (STIS) innovative interactions Interoperability related issues (Semantics) IoT6 will concentrate on a architecture for the integration of heterogeneous sub-systems of the Internet of Things (sensors, tags, wireless devices, actuators, etc.) using different communication protocols, into an open IPv6-based service-oriented architectural framework. It will take especial attention to interoperability with sensor technologies like: - Sensor networks, with a focus on ZigBee, 6LoWPAN; - Building automation devices & smart lightings, with a focus on three major standards: KNX, BACnet and DyNet; - RFID tags - Analyzing and comparing emerging IPv6-related standards: IoT6 will analyse and compare several IPv6 related standards or adaptations, such as 6LoWPAN, CoAP, SMAP, Contiki, etc. Special attention will be given to optimizing the architecture scalability and data transmission volume Current approach (Advances, Development, Solutions, etc.) One of the key elements to provide the interoperability will be the design of a service layer based on an overlay network that provide a semantic integration into an abstract layer will facilitate the translation towards other protocols. This architecture can aggregate the information generated at the periphery from heterogeneous devices using different communication protocols, into a shared and coherent semantic framework easily translatable into other protocols. This scheme enables intelligence distribution and can benefit from the IoT6 smart rout- 74

81 Manifiesto-V1 ing feature and IPv6 header options for instance to adequately forward data strings to corresponding translation web services. 6.9 SmartAgriFood (FI PPP Grant no ) A brief description of the project (Short Abstract) The SmartAgriFood project addresses the food and agribusiness as a use case for the Future Internet. The intelligence, efficiency, sustainability and performance of the agri-food sector can be radically enhanced by using information & decision support systems that are tightly integrated with advanced internet-based networks & services. Concurrently, the sector provides extremely demanding use cases for Future Internet design from physical layer all the way up to the service layer. This project will focus on three sub systems of the sector - smart farming, focussing on sensors and traceability; smart agri-logistics, focusing on real-time virtualisation, connectivity and logistics intelligence; and smart food awareness, focussing on transparency of data and knowledge representation. Using a user- centred methodology, the use case specification will be developed with a particular focus on transparency and interoperability of data and knowledge across the food supply chain. For further details please consult: Interoperability related issues (Semantics) The agri-food sector while being one of the largest industrial sectors is highly heterogenous with a very complex and fluid supply chains. There are a great many farmers, fewer intermediaries, a small number of supermarkets, and a very large number of shoppers and final consumers. To enhance food safety, food awareness, sustainability, social responsibility, and consumers satisfaction, each of the supply chain partners needs data about individual (lots of) products to be delivered by other partners. The sector has substantial pressures to increase transparency and make the collection, integration and consumption of data more efficient. These pressures come from regulatory sources, from the demands of consumers for greater food awareness (origin, ingredients, environmental impact) and from the need of the sector to find ways to reduce waste for economic and environmental reasons. There is a need to develop standards and tools to achieve interoperability between all actors along the supply chain. The complexity and cost of capturing information at each stage of the supply chain is considerable with a number of proprietary solutions available but few standards that are widely adopted. The issue of interoperability is most apparent when trying to achieve farm to fork data integration. Currently there exist no attempts to achieve this, most ICT technology is directed to specific sub- areas of the supply chain. The use of standard vocabularies would ensure both interoperability and IERC AC4: «Service openness and interoperability issues / semantic interoperability» absence of ambiguity. Semantic Web services would be provided by third parties to enable data aggregation, reasoning in some cases, and publishing in specific formats e.g. semantic mashups or end-user smartphone apps. Actors could easily enter the agri-food data market (whether as read world actors or as added-value data processors) allowing small farmers or retailers to easily integrate into the over-arching agri-food supply web. New players would be able to come up with new services. 75

82 Manifiesto-V Current approach (Advances, Development, Solutions, etc.) There is in the agri-food world an established standard (GS1) which provides the barcodes on all food products. However, GS1 standards allow uni-directional information access (from the barcode to the data) and there are a number of barriers to uptake (cost, complexity, data hosting,...). There is also a standard for farm machinery called ISOBUS. Our work builds on these and other existing standards. In the SmartAgriFood project, a number of partners are working on the application of semantic technologies (Semantic Web, Linked Data, ontologies etc.) to the agri-food context, placing product information at the core. There already exist a number of relevant standards in SW formats (e.g. AGROVOC, AGRORDF) but there are still many gaps to be filled between farm and fork, for example in the logistics area. In addition, we are currently investigating the suitability of repurposing an e-commerce focussed ontology like GoodRelations for food retail. Both within SmartAgriFood and its planned successor projects, we are trying to put together an appropriate stack of technologies which allow full integration from farm to fork with full capture of a large variety of relevant data in a way that is ridiculously easy Emergent Connectors for Eternal Software Intensive Networked Systems CONNECT A brief description of the project (Short Abstract) The pervasive computing vision is hampered by the often-extreme level of heterogeneity in the underlying infrastructure, which in turns impacts on the ability to seamlessly interoperate. Further, the fast pace at which technology evolves at all abstraction layers increasingly challenges the lifetime of networked systems in the digital environment. Overcoming the interoperability challenge in pervasive computing systems is at the heart of the EU Future and Emerging Technologies project CONNECT, which aims to overcome interaction protocol heterogeneity at all layers, on-the-fly, by using a revolutionary approach that dynamically generates the necessary interoperability solution to connect two heterogeneous systems. We term this new style of middleware: Emergent middleware. Emergent middleware aka CON- NECTors are developed through a comprehensive dynamic process, which is supported by dedicated enablers that: Extract knowledge from, Learn about, and Reason on the interaction behaviour of networked systems, so as to: Synthesize new interaction behaviours out of the ones exhibited by the systems to be made interoperable, and further: Generate and deploy corresponding CONNECTor implementations to actually realize networking of the involved systems; and Analyse dependability and security exposed by the realized networking, both at predeployment time and at runtime. The above raises a set of unique challenges in the area of software systems engineering, from theoretical foundations for specifying the interaction behaviour of networked systems to runtime methods and tools for turning specifications into running protocols, and vice-versa. It is overcoming these challenges that CONNECT concentrated on. 76

83 Manifiesto-V Interoperability related issues (Semantics) Interoperability is the ability for two systems to exchange, understand and use each other s data, and is a long-standing problem in the field of distributed systems. However, the emergence of pervasive computing and the Internet of Things have brought about new challenges to achieving universal interoperability. Extreme heterogeneity and spontaneous interactions are characteristics of today s complex distributed systems. Computational devices ranging from embedded devices, sensors, and smartphones through to cluster machines and the Cloud use a wide range of communication networks and middleware protocols to communicate with one another. However, as soon as two systems adhere to heterogeneous protocols (from application down to network layers) to interact with each other, interoperability is impossible. Standards are a well-established approach to rectifying these types of problems. Where two systems agree upon a standard, interoperability can be guaranteed. However, systems may encounter one another spontaneously where no such agreement is possible, and hence where the communication protocols differ they cannot interoperate. Emergent middleware ensures interoperation between two networked systems by combining message interoperability, i.e., the ability to interpret messages from/toward networked systems and behavioural interoperability, i.e., the ability to mediate the interaction protocols run by the communicating networked systems, under specified non-functional properties, e.g., reliability, performance and security. The CONNECT architecture then introduces the necessary enablers for on-the-fly production of emergent middleware, which leverage semantic technologies for reasoning about the systems behaviour Current approach (Advances, Development, Solutions, etc.) First prototypes of the CONNECT solutions are made available under open source license. Detail, including publications and software may be found at Large Scale Choreographies for the Future Internet CHOReOS A brief description of the project (Short Abstract) The key goal of CHOReOS is enabling service-oriented computing in the Future Internet through a dedicated Integrated Development and Runtime Environment (IDRE) and its service choreography approach. In contrast to traditional orchestration-driven approaches, the CHOReOS model focuses on enabling choreographies of services. Thus, these services can vary over time and be organized without a single point of control or failure; they can also allow for an equal distribution of responsibility among the system actors. Moreover, CHOReOS addresses the crucial issues of scalability and heterogeneity in the management of current and future Systems of Systems (SoS) that aggregate business as well as Thing-based services. The CHOReOS consortium offers tangible solutions to SoS managers and demonstrates the efficiency of the choreography approach in coordinating large and fast-growing numbers of services. 77

84 Manifiesto-V Interoperability related issues (Semantics) One of CHOReOS major objectives is to enable large-scale dynamic compositions of services and things in the Future Internet and one of its fast developing constituents, the Internet of Things. Besides scale, CHOReOS solutions have to accommodate the extreme heterogeneity of such compositions. Inria s research within CHOReOS has resulted into an extensible SOM (xsom) for the Future Internet, where extensibility refers to scalability and interoperability. xsom supports two major functionalities: (i) a protocol bus-based solution to seamless integration of heterogeneous interaction paradigms for services and things; and (ii) a solution to discovery, access and data fusion over large populations of things. Regarding (i), we have introduced a protocol interoperability solution comprising representative abstract connector types for the client-server, publish-subscribe, tuple space, and data streaming paradigms, as well as their mapping to an enhanced bus paradigm, the extensible Service Bus (XSB). XSB features richer interaction semantics than common service bus implementations and incorporates special consideration for semantics preserving crossintegration of the heterogeneous paradigms and related protocols. We further provide templates for systematic and highly facilitated building of adaptors for heterogeneous systems (services and things) that are plugged into the XSB. We have applied our approach to interconnect widely applied service and thing interaction middleware platforms. Regarding (ii), we support data queries over large populations of things, notably smartphones, which are getting increasingly ubiquitous and embed a rich collection of sensors. xsom enables: (a) thing discovery and access dealing with large numbers of networked things; and (b) semantic, ontology-based, on-the-fly composition of such things and fusion of their data in response to queries. In target settings, e.g., at the scale of a city, not all phones need to register for reporting their data (e.g., ambient sound level); some smartly distributed sampling is sufficient. This enables efficient scalable coverage of the entire city with only a subset of the large phone population being registered. The probabilistic registration decision is based on the actual density of already registered phones, the coverage quality requirements, and the coverage of the estimated path that the user will take for the next few minutes. We have implemented a demonstrative application enabling a user to know how lively is this city spot at this moment based on retrieving and aggregating smartphone ambient sound level data Current approach (Advances, Development, Solutions, etc.) First prototype of the CHOReOS middleware solutions is being released open source. Detail, including publications and software may be found at Collaborative Manufacturing Network for Competitive Advantage ComVantage A brief description of the project (Short Abstract) ComVantage envisions an inter-organisational collaboration space turning today s organisation-centric manufacturing approach into a product-centric one. Manufacturers will benefit from a flexible, efficient platform that helps them to operate as one virtual factory and thus gain competitive advantages in their markets. Based on best practises of Web 2.0 technologies 78

85 Manifiesto-V1 the collaboration space will be an extension to existing business and engineering software. It will allow to share, administrate and monitor focused information throughout a product s life cycle in a de-centralised manner. The close collaboration on the B2B and B2C levels will foster existing trends such as Open Innovation or Crowd Sourcing. The framework of the virtual factory will encompass a secure access control that is founded on dynamic workflow models and flexible user roles accounting for large enterprises, SMEs and for end-customers. It will enable temporary and de-centralised access management for adhoc collaboration between geographically distributed experts. To adhere to changing working situations, to efficient communication, and to rich interaction technologies ComVantage will focus on mobile devices. Intuitive and trustful mobile apps shall support users in fast decision-making and problem solving. Information from different sources across the organisations is provided and maintained via Linked Data. The integration of sensor data allows for products to be members of the collaboration space Interoperability related issues (Semantics) In order to master the competition in a global market, companies do not only have to operate more efficient but need to be much better cross-linked among each other. The execution of business processes across organisational boundaries as well as cross-linking data sets of collaboration partners are key success factors and initiate the transformation of isolated individual companies towards an integrated, agile virtual enterprise. The main challenges, from a semantic interoperability perspective to be faced by ComVantage are: Individual partners using specific workflows and local data sources need a uniform interface for applications to access these data sources and be integrated into the collaboration network. Applications in most cases need substantial modifications, even if only a new data source is added. All relevant entities and relations in the domain of the application partner should be described to generate a domain data model. Each partner has to understand the meaning of the data residing in the other partners systems. Entities that occur in the systems of several partners, but are referenced by different names have to be identified and matched so that all information about this entity can be obtained upon request. Accessing this data must possible using just one access point, and all pieces of data returned in a common format, independent of the system they originate from. Different data sources have to be read, the underlying data models understood, the data matched and consolidated, before finally presented to the user Current approach (Advances, Development, Solutions, etc.) The ComVantage ( project has the goal to develop a reference architecture (see Fig. 1) as well as a working prototype of a distributed collaboration infrastructure for virtual enterprises. In the following, the key characteristics are described. Even in a heterogeneous and distributed collaboration environment, companies want to continue running their legacy systems and want to keep full control of their valuable enterprise 79

86 Manifiesto-V1 data. Our fully decentralized approach proposes a separation into Domains where each domain is operated by one partner of the collaboration network. Within a domain, the partners are running their own collaboration infrastructure and their data sources. Major design-time activities in setting up a domain are: First, definition of local access control policies in order to decide, which data should be shared with partners among the network. Second, ontologies (Domain Data Model) to describe the data model of each domain are needed to enable the semantic data harmonization. A specification of the used methodology and the developed meta-models can be found in the public deliverable D4.1.1 and D4.1.2 of the ComVantage project (see Major difficulties of inter-organisational collaboration consist in heterogeneous data models (structuring and naming of entities) and incompatible interfaces based on different technologies. In ComVantage we decided to use semantic data harmonization based on RDF, Linked Data and ontologies. RDF is used as uniform data format based on the Linked Data design principles. Within each domain of the collaboration network, a single point of access is provided by the Domain Access Server (Fig 1). It exposes a uniform interface for applications based on SPARQL and provides an interface for enforcing access control policies. The Data Integration Layer is responsible for distributing requests to the connected data sources of the domain and merges all results to a combined result set. The Domain Configuration Layer provides components for a domain specific configuration of the Domain Access Server. Integration of heterogeneous data sources is crucial to data harmonization. The ComVantage approach is based on Linked Data adapters that will perform a mapping of syntactic data to RDF. The adapters are provided as generic components which will be configured with the Domain Data Model of the actual domain in order to connect to a specific data source. Using adapters offers the advantage of integrating legacy systems without modifications. Hence, the ComVantage approach can be used on top of an existing IT infrastructure and in parallel to already existing business applications. The adapters are provided for several technologies which are most common in micro-company environments. First, the Linked Data adapter for databases is based on the open source project D2RQ. The adapter translates SPARQL queries to SQL and returns results based on a domain-specific mapping. While the mapping is defined at design-time, the content is lifted to RDF on demand at run-time which avoids the problem of keeping redundant data in sync. Since the database doesn t contain the semantic information that is required for this transformation, it is provided in a mapping file. Second, an adapter for Excel spread sheets based on the project XLWrap is used. Third, an adapter for connecting to machine middleware solutions was developed within the project. In order to allow for inter-organisational interlinking of models and data sets, the tool chain of the Silk project will be leveraged in ComVantage. Inter-organisational collaboration relies on trust between partners and the fact that information from heterogeneous nature is accessible to authorized members only. An access control model is required that supports decentralized decision-making and that enables policy negotiation, establishment, management, monitoring and enforcement for a multi-domain access to Linked Data sources. We propose an authentication process based on SAML, identity federation and security credentials interchange. Afterwards, a multi-tiered authorization process takes place to provide multi-domain access control for Linked Data at two levels: (1) Rewriting of SPARQL queries by adding control checks related to the requesters user role. (2) Struc- 80

87 Manifiesto-V1 turing of information in views for each data source to physically protect data that is not visible for a specific user role. Figure 16. Reference architecture for data- and process-interoperability in a virtual enterprise 7 External Liaison Projects 7.1 Project Title: Interoperable Sensor Networks (09034 ISN) A brief description of the project (Short Abstract) The ISN project studies interoperability issues related to emerging Wireless Sensor Network (WSN) standards. The aim of the project is to create an interoperability platform which will be tested and validated in a selected set of vertical applications such as environmental monitoring and control, renewable energy, building automation and so on Interoperability related issues (Semantics) The ISN project has carried out an analysis on interoperability issues in some emerging WSN standards, such as IPv6 over Low power Wireless Personal Area Networks (6LowPAN), ZigBee, WirelessHART, etc. The study has highlighted that 6LowPAN is the standard which better guarantees interoperability and therefore it is considered the most future proof. In particular, 6LowPAN enables the use of embedded web technologies which further facilitates interoperability. In addition, the use of embedded web technologies facilitates the integration of WSN with web applications. 81

88 Manifiesto-V Current approach (Advances, Development, Solutions, etc.) The ISN project has developed a platform which is able to seamlessly integrate WSNs with Web applications. The platform is based on an end-to-end Representational State Transfer (REST) architecture. The REST architecture in the WSN is guaranteed by using the Constrained Application Protocol (CoAP), a web transfer protocol which includes several Hypertext Transfer Protocol (HTTP) functionalities re-designed for small embedded devices such as sensor nodes. In a REST/CoAP WSN, the sensor motes become web servers which expose resources identified by Universal Resource Identifiers (URIs). The resources can be represented by means of various standard formats, such as JavaScript Object Notation (JSON) or Extensible Markup Language (XML). CoAP provides the same methods for resource manipulation as HTTP (GET, POST, PUT, etc.). The project has developed a middleware system which has two main functionalities: Transparent WSN resource access guaranteed by a proxy module: The proxy is a dual HTTP-CoAP stack which translates HTTP requests/responses into CoAP ones and vice versa. The transparent resource access simplifies IoT architectures. In fact, in case of WSN applications which are not developed using standard REST based architectures, the WSN resources can only be accessed by means of complex application gateways which have complete knowledge of the internal mechanisms of the WSN application. In case of a CoAP based WSN, WSN resources can be accessed by means of standard HTTP requests, which are automatically intercepted by the proxy and translated into CoAP requests. Since HTTP and CoAP are both based on the same REST functionalities, the protocol translation taking place in the proxy is significantly less complicated than the operations executed in an application gateway. Web based WSN resource discovery: Embedded web technologies facilitate the way in which resources are discovered from web applications. CoAP includes a technique for discovering resources based on the common web linking mechanism. CoAP server motes provide a resource description available via the well-known URI /.well-known/core. Since in several IoT scenarios resource discovery is not practical, we have implemented the Resource Directory (RD), a repository in which the CoAP server motes store the resource descriptions. Instead of exploring resources by directly accessing the CoAP servers, a client can discover resources by querying the RD. The middleware system enables a tighter integration of WSNs with web applications and simplifies the overall Internet of Things architecture. A first prototype of the middleware prototype has been developed, tested and demonstrated. Project publications [1] Walter Colitti, Kris Steenhaut, Niccolò De Caro, Bogdan Buta, Virgil Dobrota, Evaluation of Constrained Application Protocol for Wireless Sensor Networks, 18th IEEE Workshop on Local and Metropolitan Area Networks LANMAN 2011, October 13-14, 2011, Chapel Hill, North Carolina, USA. [2] Walter Colitti, Kris Steenhaut, Niccolò De Caro, Bogdan Buta, Virgil Dobrota, REST Enabled Wireless Sensor Networks for Seamless Integration with Web Applications, IEEE 8th International Conference on Mobile Adhoc and Sensor Systems (MASS), October 17-22, 2011, Valencia, Spain 82

89 Manifiesto-V1 [3] Walter Colitti, Niccolò De Caro, Kris Steenhaut, Jelmer Tiete, Ha Phung Kris Steenhaut, Abdellah Touhafi, Demo Abstract: Enabling Transparent WSN Resource Access via RESTful Web Services, 9th European Conference on Wireless Sensor Networks (EWSN 2012), February 15-17, 2012, Trento, Italy. 8 IoT Initiatives 8.1 Council, a think-tank for the Internet of Things (UK) Council is not an official EU project. The founder, Rob van Kranenburg is expert for the EG IoT of the Commission and as a subcontractor os involved as Stakeholder Coordinator in IoT- A ( and as author of a task on Ethcics in IoT-I ( He is Chairing the Working Group Societal of the IOT Forum A brief description of the project (Short Abstract) The goal of "making the computer disappear (Weiser, 1991) can happen in different ways and disappearance can take different forms. The EU Disappearing Computer Initiative started in Its mission was "to see how information technology can be diffused into everyday objects and settings, and to see how this can lead to new ways of supporting and enhancing people's lives that go above and beyond what is possible with the computer today." The forerunner to DC was I3: Intelligent Information Interfaces6. The Call for I3 in 1996 read: "The Connected Community calls for investigative research leading to new interfaces and interaction paradigms aimed at the broad population. As its focus it takes interfaces for the creation and communication of information by people, and for people and groups in a local community. Links to the Web sites of all the i3 Projects: AMUSEMENT, CAMPIELLO, COMRIS, CO-NEXUS, erena, escape, HIPS, LIME, MAYPOLE, MLOUNGE, PERSONA, POP- ULATE and PRESENCE, can no longer be found on The third research iteration of this approach was Convivio ( ), a thematic network of researchers and practitioners from many backgrounds (computer science, human sciences, design, business) developing a broad discipline of human-centred design of digital systems for everyday life. De Michelis (coordinator of Convivio): "this (design and arts) community our community - still has little influence either on governmental and super-national policies or on industrial strategies. As a result, it also has little impact on the quality of ICT in public and private life." Council was set up by people from the arts and design community with the express purpose to learn from this lack of impact on quality of IT in real life, in the next iteration of HCI in Internet of things. Its purpose was to build an varied and diverse environment that people would find when searching for 'internet of things'. This variety in technological issues, design, humanities, arts and citizen science ensures variety but also a kind of neutral space where all positions in the debate hype, anti, pro, idiosyncratic, bottom up and top down, are represented. It is a loose organisation that only exists on the web. It has no legal status. 83

90 Manifiesto-V Interoperability related issues (Semantics) In the current reactive framework we are used to dealing with three groups of actors: citizens/end users industry/sme governance/legal These all are characterized by certain qualities, '1' for citizens, '2' for industry, and '3' for governance. In our current Models and Architectures we necessarily build from and with these actors an mind. In the proactive vision the data flow of IoT will engender entities consisting of different qualities taken from the former three groups. There will thus be no more 'users' who need to secure 'privacy' as the concept of privacy has to be distributed over the qualities of the new actor. So where we are used to setting up models with entities: E 111 (end users/citizens) E 222 (industry) E 333 (governance/government) In this conceptual space we have build notions of privacy, security, assets, risks and threats; Culminating into a model of relational behavior, financial foundations and business models. In IoT these relational situations with and for these new entities: E 123, 132 etc E 231, 213 etc E 312, 321m etc will be rethought. The actors who will be open to this, will have the advantage. Council is involved in modelling this new space. It can be thought of as a kind of interoperability on an ontological level. At the same time we acknowledge that this view is not mainstream and that a lot of work is needed on privacy, security, adoption by a large audience and citizen involvement Current approach (Advances, Development, Solutions, etc.) Council is a Knowledge Partner in different events such as the industry Conference Forum Europe IoT, for the fourth time. We co program, propose speakers and report. In this way we try to bring in a design/lone entrepreneur and SME perspective. The same for Picnic (Amsterdam), Open World Forum (Paris), IOT China 2010 (Beijing) and 2012 (Shanghai). Council launched in 2009 with a series of workshops and an evening program in Brussels. Since then we act as a kind of daily newspaper. We have about 5500 unique visitors a month, 50% from the USA. Recently we are receiving more requests for interviews and questions from companies on IoT related issues. We therefore have decided to set up a related environment, theinternetofpeople.eu, Internet of People (IoP), a regular consultancy with colleagues from IBM, Philips and egov consultancy, fuelled by Council but focussing beyond Innovation to real projects inside large institutions, governance and big industry. 84

91 Manifiesto-V1 8.2 Researches of architecture and key technologies of WEB based wireless ubiquitous service environment, and proof-of-concept & demonstration (China) A brief description of the project (Short Abstract) This project is one of the New Generation Broadband Wireless Mobile Telecommunication Networks National Key Projects funded by MIIT (the Ministry of Industry and Information Technology) of China. In 2010, BUPT (Beijing University of Posts and Telecommunications) suggested MIIT to launch the significant national project Ubiquitous-Web of Things to address the issues related to architecture, applications, industrial chains, and business model. This project was accepted by MIIT at 2011, and it is started in 2012 with a strong partnership of BUPT, CATR (China Academy of Telecom Research), China Telecom, ZTE, and CQUBT (ChongQing Univ. of Posts and Telecommunications). As the platform level project of IoT China, this project aims to do researches and developments on 7 tasks (Figure 17): 1) Business innovation, business model and industry morphological characteristics; 2) Wireless ubiquitous service environment system architecture; 3) Wireless ubiquitous service environment resources management platform; 4) WoT middleware at WoT gateway and platform; 5) WoT Security and privacy protection; 6) Service aggregation and application generation platform; 7) About 10 Proof-of-concepts and demonstrations on Campus, Community, Smart Home and Industries; In summary, the project mainly focuses on platforms, middleware and demonstration applications. And the demonstration applications should be enabled with semantics and interoperability capabilities by using uniform defined resources (URI based identification)and resource access methods (HTTP/REST based API), i.e. mush-up applications shall be able to optionally access all the resources, include sensor data and actuator commands, by the URI and REST API under the semantically defined processes Interoperability related issues (Semantics) In smart home scenario, the air condition shall be started when the temperature reached a predefined degree; the lamps will be lighted when the luminance is low and the time slot is suitable, or the curtain will be closed when the luminance is relatively higher than a predefined value. In the agriculture scenario, there are cameras deployed in the green houses, the camera takes one photo in every 10 seconds in the day time, but every 10 minutes in the night time; if the temperature and humidity reaches a predefined maximum value, the green house will be opened by a remote controlled actuator and a short message will be sent to the owner of the house Current approach (Advances, Development, Solutions, etc.) 1. The project defined the sensor data and actuator command as Web based resources identified by URIs, and the access methods are defined by HTTP/REST operations, i.e. GET, PUT, DELETE, POST method, which are also called REST APIs. 85

92 Manifiesto-V1 2. The gateway or the resource management platform will enable web services, which are separately called Gateway based WoT, or Platform based WoT. 3. Define interoperability activities and methods according to the scenarios and environments. A procedure will be generated by the definition. 4. The procedure will access the internet connected sensors or the actuators by using the REST APIs. WoT$Portal$ (Browser)$ 3G/GPRS,$ SMS,$WiFi,$ WoT$Service$Provider$(SP $ WoT$Applica9on$ Server REST/HTTP Mobile$Networks$/ Internet WoT$Client$ WoT Applica9on REST/ HTTP REST/HTTP ADSL$/$LAN$/$GPRS/3G$/$WiFi WoTMall$ (Pad/Phone/PC) AppStore Service$Aggr.$and$Appl.$ Genera9on$PlaBorm $WoT$Service$Platform Resource$Management$ PlaBorm WoT$inside Service' Domain Sensor' Domain Sensor$Node CM Transmi>er $Sensor WiFi,$ ZigBee,$ RF433 Trans. Sensor $$$$$WoT$Service$ $$$$$$$$$ GaaS WoT Wireless$ Sensor$ Networks Trans. Actuator Wire$line$ Sensor$ Networks Trans. Sensor Trans. Actuator REST/HTTP WiFi/LAN WoT$ Middleware Serial$232/485,$$ LAN/PLC Local$Appl. ID/Addressing$$ Data$parser/storage$$$$$$$$$$$$$$ Log/Statistics$$ ConIiguration$$ Communications$Security$ Figure 17. WoT system architecture in the project. 8.3 COMUS - Common Open semantic Usn Service Platform (Korea) A brief description of the project (Short Abstract) COMUS project aims at providing semantic-based USN service platform which integrates all (possibly) heterogeneous sensor networks and provides context-aware and personalized services by using semantic technology (Figure 18). 86

93 Manifiesto-V1 Application Open USN service platform Interface FE Semantic query FE LOD LOD linking FE Semantic inference FE Semantic USN repository FE Resource management FE Adaptation FE Adaptation FE1 Adaptation FE2... Adaptation FEn USN middleware1 USN middleware2... USN middleware3 Sensor or sensor network Figure 18. ITU-T F.OpenUSN (draft) This project uses declarative descriptions of USN resources (sensors, actuators, node, gateway and sensor network) and sensed data. This is to promote sharing and integration of USN resources and sensed data and to resolve the difficulties of installing, querying and maintaining complex and heterogeneous sensor networks. In order to make it real, COMUS models the USN resource, sensed data, real world event, context, service and develops a semantic translator to transform data into RDF format and a context reasoner to deduce context information Interoperability related issues (Semantics) - There needs a way to classify types of USN resources operations and a way to specify USN resources and sensed data. - Values of sensed data themselves are fixed but can be interpreted in many different ways according to the given situations or context such as location and services. Therefore, there needs a way to draw contextual semantic from shared heterogeneous USN resources and sensed data. - There needs a way to express relationships over different USN resources and sensed data. Currently, each USN resource and each sensed data exist as themselves. But if there is a way to associate several USN resources and sensed data, associated USN resources and sensed data could generate much more contextual meaning over the detected circumstances Current approach (Advances, Development, Solutions, etc.) COMUS builds USN resource ontology (Figure 19), context ontology, domain service ontology and etc. This approach enables resolution of USN resource heterogeneity and efficient context derivation from given data. 87

94 Manifiesto-V1 - Modelling USN resource ontology Figure 19. Resource Ontology Graph Representation - Modelling real world event ontology and domain service ontology to promote USN resources interoperability (Figure 20). Figure 20. Domain Ontology Mapping Representation 88

95 Manifiesto-V1 - Developing LOD sensor service (COMUS sensor data) that is published in the LOD. Figure 21. Linked Open Data loud representation for Sensor Services 9 Future Actions / Activities Internet of Things (IoT) features an increasingly large number of diverse devices and resources that provide observation and measurement data, report occurrences and events in the physical world, interact with the real world objects and communicate with other resources or other applications. The distributed and heterogeneous nature of the IoT makes interoperability among Things and their data a challenging task and it requires techniques that can facilitate automated machine processing of the services that represent IoT resources, IoT resource descriptions and the IoT data. The use of semantic technologies for domain modelling and knowledge representation has been seen as a promising approach to address these challenges. There are several existing well-known models and resource descriptions that are designed for the IoT environments such as W3C SSN Ontology 16, IoT-A models 17, and IoT.est service description model 18. In previous Interoperability events we have discussed and reviewed some of the common IoT models and discussed the design principles for IoT resource modelling, find more details at

96 Manifiesto-V1 In the semantic interoperability events we try to provide a framework for the IoT community and experts to describe the modelling and representation frameworks, communalities between different approaches. The events also attempt to provide practical and hands-on experiences on evaluating and testing the interoperability between different models and try to provide online tools and API to enable IoT system designers to test their representation models against the common frameworks and get feedback to enhance their interoperability. The semantic interoperability issues and challenges in the IoT interoperability events are usually discussed from the following perspectives: 9.1 Semantic technologies and IoT resource description frameworks Reviewing the state-of-the-art research and developments on IoT related ontology engineering. Discussing modelling and knowledge representation for the IoT domain and some of the best practices in ontology engineering for IoT. The main objective/outcome is making progress on IERC-AC4 IoT Semantic Interoperability Manifesto with the existing contributions and best practices. 9.2 Practical modelling and ontology engineering Practical ontology design and processing by introducing to the IoT community useful tools for ontology engineering, compatibility checking, data processing and visualisation. The interoperability tests and evaluations are mostly based on semantic models and also hands-on experiment on testing and evaluating interoperability between gateway and sensor nodes components in IoT experimental environments. Demonstrations developing ontologies and semantic models in the IoT domain and getting people involved in developing modules and practicing interoperability evaluations between different models. For this purpose, interoperability of existing ontologies or models developed with some of the common ontologies such as W3C SSN ontology or IoT-A models can be tested. 9.3 Interoperability evaluation Online tools and development of APIs to enable users to submit their description in different representation formats and test their resource/data descriptions interoperability with the existing models (e.g. to test interoperability with SSN ontology, UK TSB IoT projects IoT data description model). The description frameworks can be based on RDF/OWL, JSON, XML and other forms. 9.4 Interfaces and communications Hands-on sessions to evaluate interface and interaction interoperability between higher-level application requests and gateway/nodes that handle the requests. 9.5 The software and tools requirements The practical interoperability tests requires online tools that check the model schema, find the similarities, provide mapping between different models and also provide feedback to the user regarding the interoperability issues of their submitted model and the ways to enhance the interoperability. A common vision can be providing online tools such as W3C HTML and RDF 90

97 Manifiesto-V1 validators 19. Modelling and design practices can be performed using common software tools such as Protégé and representation frameworks such as RDF/OWL and JSON. As part of the interoperability activity, currently the IERC AC04 has developed a preliminary tool for interoperability tests based on the W3C SSN model that is available at: The current tool is only limited to RDF/OWL representations of the W3C SSN model and it is necessary to extend this to other common model such has UK TSB Hub models, IoT-A models and also different serialisation formats such as JSON and XML. The feedback and comments to the user also need to be improved to offer more feedback to the developers to test the interoperability of their model with well-known models and receive feedback to resolve the possible issues. Data (i.e. IoT Observation and Measurement Data) interoperability is also another aspect of the semantic interoperability that needs to be included in the interoperability tests in addition to the resource and service interoperability evaluations. The common current models are based on OGC SWE Observation and Measurement model or are described as liked data models20. The data interoperability between different data providers and/or interoperability evaluations with a common reference model should be also included in the interoperability evaluation online tool to give a feedback to a user that to what extent a submitted data that be read/interpreted with a parser that is designed based on a different (or a reference) model. 10 Conclusions As for the IoT, future networks will continue to be heterogeneous, multi-vendors, multiservices and largely distributed. Consequently, the risk of non-interoperability will increase. This may lead to unavailability of some services for end-users that can have catastrophic consequences regarding applications related for instance to emergency or health, etc. Thus, it is vital to guarantee that network components will interoperate. The main way among others is to provide efficient and accurate test suites and associated interoperability testing methodology (with associated test description/coding languages) that help in testing thoroughly both the underlying protocols used by interconnected things / machines / smart objects and the embedded services / applications. It is really important that these new testing methods consider the real context of future communicating systems where these objects will be deployed. Indeed, contrary to most of the existing testing methods, interconnected things / machines / smart objects in the IoT are naturally distributed. As they are distributed, the usual and classical approach of a single centralized testing system dealing with all these components and the test execution is no more applicable Barnaghi et al., "A Linked-data Model for Semantic Sensor Streams", Proc. of IEEE IntlConf..on Internet of Things, August

98 Manifiesto-V1 Researching in semantic and dynamic interoperability must have equal importance but research is already smoothly progressing due to the nature of the topics, which look more integrated into Internet research portfolio. Interoperability will not be improved without the motivation and support of market stakeholders. Motivating and involving market forces cannot be done without taking account economic dimensions. Without proper consideration of these factors, we will not succeed improving interoperability and this is often the reason why some technology stays isolated without world wide support as nobody as answer the questions of cost of testing, time to market, cost of tools, etc Cost of testing: Money spent on testing a product is an investment for a company. When they invest money on something, they normally expect a good return on investment. Investment on testing will impact on the market price of product. This cost includes money spent on certification programs, test house fees, purchase of test tools, etc. It also includes the money spent on correcting errors found during testing. Time of testing has impact on the time to market and market price of a product. Time of testing is the time spent on testing a product. Using test tool to automate the test will considerably reduce the time spent on testing. We can also consider the time to develop the tests which is often under estimated Test tool: Cost of developing of test tool is often very expensive and can rarely be beared by one single company. There is therefore need to share such development but for that, there is a strong needs to do so within an independent organisation, which should also itself be motivated to provide such support. Such conditions are not always met and collective actions to improve interoperability, in such case, stay in a dormant stage. There is a need to find a global solution which satisfy all stake holders: how to invest to the right level of test and tool, reduce my time to market and ensure the level of interoperability I need for the market and the final users (Figure 22). Figure 22. The Economic Dimension in the Internet of Things If we use the Project Management Triangle [34] (called also Triple Constraint or the Iron Triangle) approach, we could argue that only automated, cost effective approach with standardized methodologies and optimization/automation tools can help to find the right balance between the three dimensions. In doing so we will provide the only technical solutions to address these important economic factors. 92

99 Manifiesto-V1 In the sequel of open issues for technical and semantic interoperability in the IoT domain a set of open issues in the form of actions to do are listed in the form of bullets and could be considered in the scope of the early requirements in the evolution of IoT. These requirements concern protocol testing and characteristics of various aspects (Linked-Data, Performance, Deployment, Scalability and Extensibility) associated with IoT applications and services. Technical interoperability Provide confidence on IoT products to market with market-accepted level of interoperability Coordinate worldwide interoperability initiatives on market support specifications or protocols Develop market acceptance roadmap Use clear specifications development and testing methodologies leading to improve quality while reducing time and costs in a full chain optimized development cycle Define if needed profiles to improve interoperability Use some best practices specifications development methods Organize interoperability events to validate specs Use some best practices tests specifications development methods Considered full chain specs to tool development and use methods and best practices (eg MBT) to automate and optimize development of tests and tools automatically Develop world wide validation programmes Pursue research in testing methodologies for IoT Facilties meaning and expressions by using W3C standard Resource Description Framework (RDF) Enable interactions between ICOs and between IoT services. Linked-Data Linking of data sources for facilitating application integration and reuse of IoT source data. Ontology mapping / matching for re-using of semantic annotation techniques (based on Ontology Engineering) enabling descriptions of ICOs and operations. Open linked data for building on the standards i(.e. W3C SSN standard ontology) description of sensors and ICOs. Extension on Ontology Web Language (OWL) for extensive usage on data analytics and reasoning operations. Enable live data analytics for processing of ICOs stream data. Performance Focused on Mobile Application(s) / Service(s) ICO-related information must be handled within interactive mobile application(s). Information updates provided either by sensor devices or external applications shall be available within the IoT middleware / application / solution in the order of minimal time of response. 93

100 Manifiesto-V1 There should not exist stringent latency constraints in monitoring operations for ICOs. IoT application / service should facilitate the «Hot» deployment of sensors i.e. once an infrastructure provider deploys a new sensor, this should become available to the IoT system. Deployment Dynamic establishment and reservation of services IoT application(s) should support the on-demand establishment of services, including the reservation of the required resources (for the service delivery). IoT application(s) should support the undeployment of a service, including the release of the relevant resources. Depends on the size/scale of the IoT system(s) involved. The calculation of Key Performance Indicators (KPIs) across multiple stakeholders in the IoT system can increase the geographical and administrative scope of the application. Scalability Discovery should be enabled based on multiple criteria IoT system(s) should support the discovery of subsets of devices that can contribute to an IoT service i.e. devices that meet certain criteria pertaining to the requested service. IoT system should be scalable and elastic in terms of the computational and storage resources that are associated with the delivery of IoT services. The discovery could be based on a multitude of criteria including type, geographic region, sensor type, measured phenomenon, range of measurement, availability, owner or responsible party, and manufacturer and other user-defined criteria, but also combinations of all the above. The system should be extensible in terms of computational and storage resources required to deliver IoT service(s). Extensibility Computational and storage resources based on Cloud infrastructures The system should be scalable and extensible in terms of the supported ICOs. The system should support services that leverage (potentially) thousands of ICOs distributed in tens/hundreds/thousands of different administrative domains. The system should enable the definition / classification of new types & classes of ICOs. 94

101 Manifiesto-V1 11 References [Abowd97] Abowd, Gregory D., Dey, Anid K., Orr, R., Brotherton, J. Context-awareness in wearable and ubiquitous computing. 1st International Symposium on Wearable Computers. p.p , [Amit 2008] Amit P. Sheth, C. A. (2008). Semantic Sensor Web. IEEE Internet Computing. [Anicic 2011] Anicic, D. F. (2011). EP-SPARLQ: a unified language for event processing and stream reasoning. 20th International Conference on World Wide Web, (pp ). [Barbieri 2010] Barbieri, D. B. (2010). An execution environment for C-SPARQL queries. 13th International Conference on Extending Database Technology, (pp ). [Barnaghi 2012] P. Barnaghi, W. Wang, C. Henson, K. Taylor, "Semantics for the Internet of Things: early progress and back to the future", International Journal on Semantic Web and Information Systems (special issue on sensor networks, Internet of Things and smart devices), September [Berners-Lee 2006], T. Berners-Lee, Linked data, available at: DesignIssues/LinkedData.html [Bolles 2008] Bolles, A. G. (2008). Streaming SPARQL: extending SPARQL to process data streams. 5th European semantic web conference (ESWC) (pp ). Springer-Verlag. [Bouillet 2007] Eric Bouillet, M. F. (2007). A semantics- based middleware for utilizing heterogeneous sensor networks. 3rd IEEE international conference on Distributed computing in sensor systems (pp ). Springer-Verlag. [Brown98] Brown, P. J. Triggering information by context, Personal Technologies, Vol. 2, Num. 1, p.p. 1-9, September [Calbimonte 2010] Calbimonte, J. C. (2010). Enabling ontology-based access to streaming data sources. 9th International Semantic Web Conference (pp ). Springer-Verlag. [Chen04] Chen, H., Finin, T., and Joshi, A. An Ontology for context-aware pervasive computing environments Special issue on Ontologies for Distributed Systems, Knowledge Engineering review [Chen03a] Chen, H., Finin, T. and Joshi. A. An Ontology for Context-Aware Pervasive Computing Environments. In IJCAI workshop on ontologies and distributed systems, IJCAI'03, August, [Chen03b] Chen, H., Finin, T., and Joshi, A. An Intelligent Broker for Context-Aware Systems. In Adjunct Proceedings of Ubicomp 2003, Seattle, Washington, U.S.A., p.p , October [Chen03c] Chen, H., Finin, T., and Joshi, A. Using OWL in a Pervasive Computing Broker. In Proceedings of Workshop on Ontologies in Open Agent Systems (AAMAS 2003), [Chen00] Chen, G., Kotz, D., A survey of context-aware mobile computing research, Technical Report, TR , Department of Computer Science, Dartmouth College, November [Compton 2012] M. Compton, P. Barnaghi, L. Bermudez, R. Garca Castro, O. Corcho, S. Cox, J. Graybeal, M. Hauswirth, C. Henson, A. Herzog, V. Huang, K. Janowicz, W. D. Kelsey, D. Le Phuoc, L. Lefort, M. Leggieri, H. Neuhaus, A. Nikolov, K. Page, A. Passant, A. Sheth, and K. Taylor. The SSN Ontology of the Semantic Sensor Networks Incubator Group. JWS,

102 Manifiesto-V1 [Compton 2012a] Michael Compton, P. B.-C. (2012). The SSN Ontology of the Semantic Sensor Networks Incubator Group. Journal of Web Semantics. [Corcho 2010] O. Corcho, R. Castro, "Five Challenges for the Semantic Sensor Web", Semantic Web Journal, [Crowcrof03] Crowcroft, J., Hand, S., Mortier, R., Roscoe, T., Warfield, A., Plutarch: An argument for network pluralism, ACM SIGCOMM 2003 Workshops, August [De 2011] S. De, T. Elsaleh, P. Barnaghi, S. Meissner, "An Internet of Things Platform for Real- World and Digital Objects", Journal of Scalable Computing: Practice and Experience, vol 13, no.1, [Dey01] Dey, A. K., Understanding and using context, Journal of Personal and Ubiquitous Computing, Volume 5, Num. 1, p.p. 4-7, [Dey00a] Dey, A. K., Abowd, G. D., Towards a better understanding of context and context awareness. In Workshop on the What, Who, Where, When and How of Context-Awareness, affiliated with the 2000 ACM Conference on Human Factors in Computer Systems (CHI 2000), April 2000, The Hague, Netherlands. April 1-6, [Dey00b] Dey, A., K., Providing Architectural Support for Building Context-Aware Applications, PhD thesis, Georgia Institute of Technology,2000. [Gruber95] Gruber T., Towards Principles for the Design of Ontologies Used for Knowledge Sharing, International Journal of Human-Computer studies, Vol. 43 Num 5 of 6, p.p , [Gruber93a] Gruber, T. R. A translation approach to portable ontology specifications. Knowledge Acquisition, Vol. 5 Num. 2, p.p , [Gruber93b] Gruber. T. R. Toward principles for the design of ontologies used for knowledge sharing. Presented at the Padua workshop on Formal Ontology, March [Moreau 2012] L. Moreau and P. Missier. PROV-N: The Provenance Notation. http: // n/. [Gangemi] A. Gangemi. Ontology:DOLCE+DnS Ultralite. http: //ontologydesignpatterns.org/wiki/ontology:dolce%2bdns_ultralite. [Joshi 2009] K. P. Joshi, T. Finin, and Y. Yesha. Integrated Lifecycle of IT Services in a Cloud Environment. In Proceedings of The Third International Conference on the Virtual Computing Initiative (ICVCI 2009), [Khedr03] Khedr, M. and Karmouch, A. Exploiting SIP and agents for smart context level agreements, 2003 IEEE Pacific Rim Conference on Communications, Computers and Signal Processing, Victoria, BC, Canada, Aug [Khedr02] Khedr, M., Karmouch, A., Liscano, R. and Gray, T. Agent-based context aware ad hoc communication. In proceedings of the 4th International Workshop on Mobile Agents for Telecommunication Applications (MATA 2002), Barcelona, Spain, p.p , Oct 23-24, [Leggieri2012] M. Leggieri, A. Passant, and M. Hauswirth. A contextualised cognitive perspective for linked sensor data. In SSN Workshop co-located with ISWC, [López03a] López de Vergara, Jorge E., Villagrá, Víctor A., Berrocal, Julio, Asensio, Juan I., Semantic Management: Application of Ontologies for the Integration of Management Information Models. In Proceedings of the 8th IFIP/IEEE International Symposium on Integrated Management (IM 2003), Colorado Springs, Colorado, U.S.A., [McCarthy97] McCarthy, J., and Buva Cˇ. Formalizing context (expanded notes). In Working Papers of the AAAI Fall Symposium on Context in Knowledge Representation and Natural 96

103 Manifiesto-V1 Language (Menlo Park, California, 1997, American Association for Artificial Intelligence, p.p [McCarthy93] McCarthy, J. Notes on formalizing contexts. In Proceedings of the Thirteenth International Joint Conference on Artificial Intelligence, San Mateo, California, 1993, R. Bajcsy, Ed., Morgan Kaufmann, p.p [Meyer 2011] S. Meyer et al. Towards modeling real-world aware business processes, In Proceedings of Web of Things, [Moscato 2011] F. Moscato, R. Aversa, B. Di Martino, M. Rak, S. Venticinque, and D. Petcu. An Ontology for the Cloud in mosaic. CRC Press, [Perez 2009] Jorge Pérez, M. A. (2009). Semantics and complexity of SPARQL. ACM Transactions on Database Systems. [Phuoc 2011] Phuoc, D. D.-T. (2011). A native and adaptive approach for unified processing of linked streams and linked data. 10th International Semantic Web Conference, (pp ). [Sequeda 2009] Juan F. Sequeda, O. C. (2009). Linked stream data: A position paper. SSN Workshop. [Serrano08] Serrano, J. M.., Serrat, J., Strassner, J., Ó Foghlú, Mícheál. Facilitating Autonomic Management for Service Provisioning using Ontology-Based Functions & Semantic Control 3rd IEEE International Workshop on Broadband Convergence Networks (BcN 2008) in IEEE/IFIP NOMS April 2008, Salvador de Bahia, Brazil. [Serrano07a] Serrano, J. Martín; Serrat, Joan; Strassner, John, Ontology-Based Reasoning for Supporting Context-Aware Services on Autonomic Networks 2007 IEEE/ICC International Conference on Communications ICC 2007, June 2007, Glasgow, Scotland, UK. [Spiess 2009] P. Spiess. et al,"soa-based Integration ofthe Internet of Things in Enterprise Services", In Proceedings of the 2009 IEEE International Conference on Web Services (ICWS '09). IEEE Computer Society, Washington, DC, USA, , [vanderveer 2008] H. van der Veer, A. Wiles, "Achiveing Technical Interoperability the ETSI Approach", ETSI White Paper No.3, 3rd edition, April 2008, 20final.pdf [Whitehouse 2006] Kamin Whitehouse, F. Z. (2006). Semantic Streams: A Framework for Composable Semantic Interpretation of Sensor Data. European Workshop on Wireless Sensor Networks. [ISO 9646] ISO 9646: Conformance Testing Methodology and Framework [MOBITEC] ( [ASPIRE] ( [FOSSTRAK] [BULLSEYE] [SCATTERVIEWER] ide.pdf [HOURGLASS] [SENSEWEB] [JWEBDUST] [GSN] 97

104 Manifiesto-V1 Annex I: Other Useful References [AKARI] Architecture Design Project for New Generation Network, [Barnaghi 2011] S. De, P. Barnaghi, M. Bauer, S. Meissner, "Service modelling for the Internet of Things", in Proceedings of the Conference on Computer Science and Information Systems (FedCSIS), pp , Sept [Barnaghi 2010] P. Barnaghi, M. Presser, K. Moessner, "Publishing Linked Sensor Data", in Proceedings of the 3rd International Workshop on Semantic Sensor Networks (SSN), November [Bennaceur 2012] A. Bennaceur, V. Issarny, R. Spalazzese, S. Tyagi. Achieving Interoperability through Semantics-based Technologies: The Instant Messaging Case. Proc. of ISWC th International Semantic Web Conference (2012). [Blair 2011] G. Blair, A. Bennaceur, N. Georgantas, P. Grace, V. Issarny, V. Nundloll, M. Paolucci. The Role of Ontologies in Emergent Middleware: Supporting Interoperability in Complex Distributed Systems. Proc. of Middleware th International Middleware Conference (2011). [Compton 2012] Michael Compton, Payam Barnaghi, Luis Bermudez, Raul Garcia-Castro, Oscar Corcho, Simon Cox, John Graybeal, Manfred Hauswirth, Cory Henson, Arthur Herzog, Vincent Huang, Krzysztof Janowicz, W. David Kelsey, Danh Le Phuoc, Laurent Lefort, Myriam Leggieri, Holger Neuhaus, Andriy Nikolov, Kevin Page, Alexandre Passant, Amit Sheth, Kerry Taylor. The SSN Ontology of the W3C Semantic Sensor Network Incubator Group, Journal of Web Semantics, [Haller 2010] Stephan Haller, "The Things in the Internet of Things", in Proceedings of the Internet of Things 2010 Conference, Tokyo, Japan, [Henson 2009] Cory Henson, Josh Pschorr,Amit Sheth, Krishnaprasad Thirunarayan, 'SemSOS: Semantic Sensor Observation Service', In Proceedings of the 2009 International Symposium on Collaborative Technologies and Systems (CTS 2009), Baltimore, MD, May 18-22, [Horridge 2004] Horridge, M., Knublauch, H., Rector, A., Stevens, R., Wroe, C., A Practical Guide to Building OWL Ontologies using the Protégé-OWL Plugin and CO-ODE Tools Edition 1.0 Manchester University, August [Issarny 2012] V. Issarny, A. Bennaceur. Composing Distributed Systems: Overcoming the Interoperability Challenge. Lecture Notes on HATS International School on Formal Models for Objects and Components Available. To appear (2013). [Issarny 2011] V. Issarny, A. Bennaceur, Y-D. Bromberg. fulltext access Middleware-layer Connector Synthesis: Beyond State of the Art in Middleware Interoperability. 11th International School on Formal Methods for the Design of Computer, Communication and Software Systems: Connectors for Eternal Networked Software Systems. LNCS Springer (Ed.) (2011). 98

105 Manifiesto-V1 [Meyer 2011] S. Meyer, K. Sperner, C. Magerkurth, and J. Pasquier, Towards modeling real-world aware business processes, In Proceedings of Web of Things, [NSFInnitiative] NSF-funded initiative to rebuild the Internet, Clean Slate program, Stanford University, [Serrano 2009] M. Serrano, J. Strassner and M. ÓFoghlú, A Formal Approach for the Inference Plane Supporting Integrated Management Tasks in the Future Internet 1st IFIP/IEEE ManFI International Workshop, In conjunction with 11th IFIP/IEEE IM2009, 1-5 June 2009, at Long Island, NY, USA. [Soldatos 2012] J. Soldatos, M. Serrano and M. Hauswirth. Convergence of Utility Computing with the Internet of Things, International Workshop on Extending Seamlessly to the Internet of Things (esiot), collocated at the IMIS-2012 International Conference, 4-6 July, 2012, Palermo, Italy. [Suparma 2011] Suparna De, Payam Barnaghi, Martin Bauer, Stefan Meissner, Service modeling for the Internet of Things, 3rd Workshop on Software Services: Semantic-based Software Services, [Tslenis 2010] G Tselentis et al. editors, Towards the Future Internet: A European Research Perspective, 2010, IOS Press 2009, ISBN (print), ISBN (online). [W3C-SSN] W3C Semantic Sensor Network Incubator Group Report [Wang 2012] Wang W, De S, Toenjes R, Reetz E, Moessner K, "A Comprehensive Ontology for Knowledge Representation in the Internet of Things", International Workshop on Knowledge Acquisition and Management in the Internet of Things in conjunction with IEE IUCC, June, [Wang 2010] W. Wang, S. De, G. Cassar, K. Moessner, "Knowledge Representation in the Internet of Things: Semantic Modelling and its Applications", special issue on Knowledge Acquisition and Management in the Internet of Things, Automatika [Zorzi 2010] Michele Zorzi, Alexander Gluhak, Sebastian Lange, and Alessandro Bassi. From today's intranet of things to a future Internet of Things: a wireless- and mobility-related view, Wireless Commun. 17, 6 (December 2010), 44-51, IERC AC