Collaborative Open Market to Place Objects at your Service

Transcription

1 Collaborative Open Market to Place Objects at your Service D1.3.2 Service modelling and representation Final Version Project Acronym COMPOSE Project Title Project Number Work Package WP1 COMPOSE architecture design and specification Lead Beneficiary OU Editor Luca Panziera OU Reviewer Daniel Schreckling UNI-PASSAU Reviewer Marko Vujasinovic INN Dissemination Level Public Contractual Delivery Date 30/10/2014 Actual Delivery Date 30/10/2014 Version V0.1 D1.3.2 Service modelling and representation Final Version Page 1 of 60

2 Abstract This deliverable provides the final version of models for service descriptions in COMPOSE. The models are designed with the aim of publishing the service descriptions as Linked Data for advance service discovery, recommendation and composition. Guided by requirements coming from real-world services of the project s use cases, our design approach is based on reusing and extending opportune existing ontologies in order to produce lightweight COMPOSE-specific vocabularies. The core ontology is the Minimal Service Model (MSM). MSM is a simplified and agnostic model to formally represent any kind of service and its operations including their input and output parameters. MSM enables description of WSDL-based Web services as well as RESTful APIs, which are the current trending approach to provide functionalities on the Web. For the COMPOSE project, MSM is used to represent COMPOSE application, Service Objects and external services to the platform through a unified concept of Service, in order to enable discovery, composition and recommendation of these different components in a seamless way. On top of the MSM, we use SAWSDL annotations as a standard way of attaching semantics to service descriptions. To structure the semantics, we use the WSMO-Lite service semantics ontology, which distinguishes four types of service semantics: functional, non-functional, behavioural, and information-model semantics. To enable actual invocation of Services, the service grounding information is modelled by the following ontologies. MSM-WSDL, which focuses on defining grounding of WSDL operations. The hrests microformat that provides grounding of generic Web APIs defined by plain- HTML documentation. And, MSM-Swagger that is introduced to define the grounding of RESTful APIs described according to Swagger specification. Finally, additional COMPOSE-specific vocabularies have been designed to specifiy nonfunctional characteristics of Services, such as security, reputation, trust, provider popularity, and service business terms. COMPOSE-specific vocabularies for describing non-functional characteristics are developed up to the point needed by the COMPOSE Service Recommender (Deliverable D ). D1.3.2 Service modelling and representation Final Version Page 2 of 60

3 Document History Version Date Comments V0.1 03/10/2014 Skeleton and first draft V0.2 08/10/2014 Updated examples from use cases V0.3 15/10/2014 Integration with WP5 Contribution V0.4 27/10/2014 Second draft V0.5 29/10/2014 Corrections of some typos V0.6 29/10/2014 Integration of security model V0.7 30/10/2014 Security model improvement V1.0 31/10/2014 Final Version Authors Luca Panziera, Carlos Pedrinaci, Marko Vujasinovic, Daniel Schreckling, OU OU INN UNI-PASSAU D1.3.2 Service modelling and representation Final Version Page 3 of 60

4 Table of Contents Abstract... 2! Document History... 3! Table of Contents... 4! Acronyms... 6! Namespace Prefixes... 7! 1! Introduction... 8! 1.1! Running Examples... 9! 1.1.1! Barcelona Smart Environment SOS Service... 9! 1.1.2! Shopping Scenario... 11! 1.1.3! Trentino Meteorological Sensors... 13! 1.1.4! Web APIs: source of external services for COMPOSE... 15! 1.2! Requirements Addressed in this Deliverable... 16! 1.3! Ontologies Used in this Document... 18! 2! Core Service Models and Service Description Technologies... 21! 2.1! Linked Service Models... 21! 2.2! Representation of existing service models through MSM... 27! 2.3! Static and Dynamic Metadata... 31! 3! COMPOSE Vocabularies for Service Annotation... 32! 3.1! Functional Classification of COMPOSE Services... 32! 3.2! Information Model Terms for Service Outputs... 33! 3.3! Non-functional Properties for COMPOSE services... 34! 4! Basic Service Description Metadata... 38! 5! Security- and Trust-related Aspects... 40! 5.1! Security Specifications for Services... 40! 5.1.1! Attributes modelling... 41! 5.1.2! Modelling of security policy... 42! 5.1.3! Modelling of Security Contracts... 46! 5.2! Trust-related aspects of services (INN)... 49! 6! Modelling business aspects of COMPOSE services... 56! 6.1! Linked USDL design... 57! 7! Summary and novel introductions in this deliverable... 58! 7.1! What s new in final version of service modelling?... 58! References... 59! D1.3.2 Service modelling and representation Final Version Page 4 of 60

5 Table of Figures Figure 1: Location of Sensors within Barcelona Smart Zone.... 9! Figure 2: Location of Sensors within Trentino Smart Territory ! Figure 3: Smart Territory Data Sources Description... 15! Figure 4: The Minimal Service Model Figure 5: MSM-WSDL vocabulary for WSDL grounding... 27! Figure 6: MSM and hrests concepts for RESTful services description... 29! Figure 7: MSM-Swagger vocabulary for Swagger grounding... 30! Figure 8: Stack of Service Description Models... 32! Figure 9: COMPOSE Trust Ontology... 50! D1.3.2 Service modelling and representation Final Version Page 5 of 60

6 Acronyms Acronym COMPOSE API CF DC DUL JSON MSM NFP OWL OWL-S PROV QU QUDV RDF RDFS hrests SAWSDL SKOS SOAP SOS SPARQL SSN WSDL WSMO XML XQuery XSPARQL Meaning Application Programming Interface Climate and Forecast ontology Dublin Core metadata terms DOLCE Ultra-Lite upper ontology JavaScript Object Notation Minimal Service Model Non-functional Property Web Ontology Language Semantic Markup for Web Services (not used as an acronym) Provenance Ontology Library for Quantity Kinds and Units: schema Quantities, Units, Dimensions, Values Resource Description Framework RDF Schema HTML for RESTful Services Semantic Annotations for WSDL and XML Schema Simple Knowledge Organization System (no longer an acronym, old meaning) Simple Object Access Protocol Sensor Observation Service (not an acronym) SPARQL Query Language for RDF Semantic Sensor Networks Web Service Description Language Web Service Modelling Ontology Extensible Markup Language XML Query (not an acronym) combination of XQuery and SPARQL D1.3.2 Service modelling and representation Final Version Page 6 of 60

7 Namespace Prefixes Prefix cf# compose# dc# dim# dul# geo# msm# qu# quantity# rdf# rdfs# rest# sawsdl# schema# ssn# unit# wl# wsdl# wsdlx# xsd# to# compose7sec# Prefix ex# trentino# ex7webapi# URI URI used for example terms D1.3.2 Service modelling and representation Final Version Page 7 of 60

8 1 Introduction In COMPOSE, three types of Web services need to be described: (i) service objects that act as façades for real-world smart objects in the COMPOSE infrastructure; Web-based external services, that can provide additional functionalities to the platform, such as Twitter and Google Maps; and (iii) COMPOSE applications that provide business logic, possibly by using service objects and external services. In order to avoid ambiguity in this deliverable, we simply call Services these three kinds of software components that are managed by the COMPOSE platform. The COMPOSE infrastructure distinguishes two main data stores: a service registry that contains the metadata of smart objects, service objects, and services, and an operational data repository that stores actual object data. This document provides models to be used in the object and service registry. The models described in this document are semantic, 1 meaning that data expressed with these models will be self-describing, and can support inference and reasoning using Semantic Web tools. The primary uses for service descriptions in COMPOSE are: Discovery making services and service objects reachable and understandable; Recommendation identification of the best one between similar services or service objects; Composition combining multiple services and service objects in higher-level, addedvalue services and applications. A COMPOSE service description is made out of 3 distinct portions: 1. Service structure a set of operations offered by the service, with their corresponding input and output parameters, grounded in the real-world service or smart object; 2. Service semantics a description of the domain-specific characteristics of the service, especially including its functionality; 3. Metadata domain-independent properties such as provenance, security policies and trust-related properties. The models support the principles of Linked Data: i) using URIs as names for things, ii) using HTTP URIs so clients can follow them, iii) providing useful information when the URIs are dereferenced, and iv) including links to other data. COMPOSE services and service objects are described as linked data, and it is expected that they can process and produce linked data as well. In this document, we describe the final models used by COMPOSE through examples based on the project s application scenarios. Below, Section 1.1 introduces those scenarios and the services and service objects that we use as running examples. In Section 1.2, we list the project requirements (as identified in Deliverable D1.1.1 COMPOSE requirements ) that are addressed in this deliverable. Section 1.3 briefly lists the external ontologies used in this document, as a point of reference. Sections 2 4 collect and describe the actual service description models, along the aforementioned three distinct portions of service descriptions. In particular, Section 2 starts with the core service structure and semantic annotation models, and the description languages in which the semantic models are grounded. Section 3 provides basic COMPOSE-specific vocabularies for describing the domain semantics of COMPOSE services, building on established standards. Section 4 discusses basic domain-independent metadata for 1 See for a comprehensive introduction to semantic data D1.3.2 Service modelling and representation Final Version Page 8 of 60

9 FP COMPOSE the semantic descriptions, such as time stamps and provenance. Then, Section 5 discusses modelling and representation trust-related and security-related aspects of services. The vocabulary suggested for modelling business aspects of services registered in COMPOSE is shown in Section 6. Finally, Section 7 provides a brief summary of the models described in this deliverable and new aspects modelled compared to Deliverable D Running Examples The example services presented in the following subsections are taken from the COMPOSE project use cases, and they illustrate the diversity and heterogeneity of services that are managed by the project platform Barcelona Smart Environment SOS Service The Smart City use case, titled Barcelona Smart Environment, has a number of sensors aggregated in a single publicly reachable Sensor Observation Service (SOS2). The SOS standard defines means for querying sensor observations and accessing the metadata of sensors registered in the SOS service. Figure 1: Location of Sensors within Barcelona Smart Zone. The SOS service is accessible through the SOAP protocol [7], a communication protocol that defines a simple XML format for messages and rules for their processing, to ensure either interoperability or graceful failure. Further, the SOS service is described with a WSDL description3 WSDL [8] is an XML-based format for defining the interfaces of Web services, which models services in three layers of abstraction: (i) abstract XML-based operation interfaces that tell the clients what to send and what to expect back; (ii) concrete bindings to network protocols so the clients know how to send the messages; and (iii) actual network endpoints where the services can be reached. The layering in WSDL is designed to support maximal level of late bind2 3 See The WSDL description is available at D1.3.2 Service modelling and representation Final Version Page 9 of 60

10 ing the client is built to the abstract contract of a type of service, and can adapt at run-time to the specific networking protocols and locations of concrete service instances. The currently available sensors registered in the Barcelona SOS service are mostly located on the campus of Retevision, illustrated in Figure 1 (created using Google Earth). The WSDL description of the Barcelona SOS service can be summarized in the following condensed XML listing, which will be the basis for further example listings later in this document: <wsdl:definitions## ######target7 Namespace=" +##<wsdl:types/># +##<wsdl:message#name="getcapabilitiessoapin"/># +##<wsdl:message#name="getcapabilitiessoapout"/># +##<wsdl:message#name="describesensorsoapin"/># +##<wsdl:message#name="describesensorsoapout"/># +##<wsdl:message#name="getobservationsoapin"/># +##<wsdl:message#name="getobservationsoapout"/># +##<wsdl:message#name="registersensorsoapin"/># +##<wsdl:message#name="registersensorsoapout"/># +##<wsdl:message#name="insertobservationsoapin"/># +##<wsdl:message#name="insertobservationsoapout"/># 7##<wsdl:portType#name="SosSoap"># ###+##<wsdl:operation#name="getcapabilities"/># ###+##<wsdl:operation#name="describesensor"/># ###+##<wsdl:operation#name="getobservation"/># ###+##<wsdl:operation#name="registersensor"/># ###+##<wsdl:operation#name="insertobservation"/># ###</wsdl:porttype># +##<wsdl:binding#name="sossoap"#type="tns:sossoap"/># +##<wsdl:binding#name="sossoap12"#type="tns:sossoap"/># 7##<wsdl:service#name="Sos"># ###+##<wsdl:port#name="sossoap"#binding="tns:sossoap"/># ###+##<wsdl:port#name="sossoap12"#binding="tns:sossoap12"/># ###</wsdl:service># </wsdl:definitions># Among the sensors registered in the Barcelona SOS service, there are for instance sensors for temperature, humidity, luminosity, noise, soil moisture, and parking. In COMPOSE, we should be able to view each sensor registered in a single SOS service as a separate object, and we should be able to represent and access them as logically separate service objects. This will enable us to select sensors by their location, for instance. Note that a single sensor that senses multiple properties, e.g. humidity and temperature, should not be seen as two separate objects but rather as one having multiple sensing channels. The wide range of sensor data provided by the described infrastructure enables a relevant amount of use-cases realizing some of the core concepts of the Smart City. Specifically, usecases providing services to drivers around the access to parking spaces have been specified. So, drivers getting to a specific location (such as the Smart Environment targeted here) may benefit from sensor-enabled capabilities such as monitoring and reservation of available parking spaces. D1.3.2 Service modelling and representation Final Version Page 10 of 60

11 1.1.2 Shopping Scenario The shopping scenario is targeting the design and implementation of an augmented shopping experience, which will be based on various interactions between customers and products in a store. The main driver for this scenario is represented by the indoor localization of both customers and products, together with the possibility of interacting with products in order to access related information and services. The combination of these two elements will allow to (i) model customers by anonymously analysing their in-store behaviour, and (ii) deliver personalised services, which will eventually lead to a better and more efficient shopping experience of customers. The scenario is organised around three use cases, each targeting a different stakeholder: Indoor Customer Behavioural Profiling: by tracking the indoor mobility of shopping carts, we will provide retailer analytics dashboard that can be used to improve the store management. This use case is addressing store managers; Augmented Mobile Retailing Experience: this use case is targeting the realisation of a COMPOSE-empowered mobile application for customers, that will assisted them during their shopping sessions. In this case, the addressed stakeholder is represented by the customer; Enhanced Product Interaction: in this case we are targeting the smartphone-mediated interaction between customers and products. By interacting with a product (e.g., through a QR code), customers can access product-related information and services. In this case, the use case is targeting the Brands as the key stakeholder. This scenario requires three kinds of services: (i) service objects based on location-tracking sensors for carts or baskets; (ii) product information services; and (iii) services that provide notifications about basic product information based on a specific location. For this deliverable, in order to provide example of different service modelling approaches, we consider the first kind of services. The service objects are represented as Swagger-based RESTful Service in ServIoTicy 4 APIs. Swagger [12] is a JSON-based specification to describe RESTful services. This specification is becoming very popular and adopted on the Web due to the availability of: The availability of APIs that support automatic generation Swagger descriptions by annotating service source code; APIs that support semi-automatic invocation of services that provides Swagger descriptions; A web application, called Swagger-UI, that allows service providers to build interactive documentation of services by exploiting their Swagger descriptions. For these reasons, Swagger is adopted in COMPOSE to provide grounding to service objects. A Swagger portion of grounding description of service object is provided below. Swagger specification of a service object functionality provided by ServIoTicy APIs - the description of the operation {# ##"apiversion":#"1.0",# ##"swaggerversion":#"1.2",# 4 D1.3.2 Service modelling and representation Final Version Page 11 of 60

12 ##"basepath":#" ##"resourcepath":#"/ be c27b07e748b ",# ##"apis":#[# ####...# ####{# ######"path":#"/streams/{streamid",# ######"produces":#[# ########"application/json"# ######],# ######"consumes":#[# ########"application/json"# ######],# ######"operations":#[# ########{# ##########"method":#"put",# ##########"summary":#"store#(and#process)#new#data#associated#to#the###### ######################stream#streamid#of#the#serviceobject",# ##########"nickname":#"updatestream",# ##########"type":#"string",# ##########"parameters":#[# ############{# # # ##"name":#"streamid",# # # ##"description":#"identifier#of#the#stream#to#retrieve.",# # # ##"type":#"string",# # # ##"paramtype":#"path"# # #,# # # {# # # ##"name":#"body",# # # ##"description":#"the#channels#update.",# # # ##"type":#"string",# # # ##"paramtype":#"body"# # # # ##########],# ##########"responsemessages":#[# ############{# ##############"code":#403,# ##############"message":#"access#was#denied!",# ##############"info":#"docs.servioticy.com"# ####### # ##########]# # ###,# # ###{# # # "method":#"delete",# # # "summary":#"clear#all#data#associated#to#the#stream#streamid########### #######################of#the#serviceobject#soid",# # #...# # ###,#...# The above listing shows the description of the operation to store a data stream of a sensor defined as a service object, which ID is provided in the resourcepath property. Swagger specification provides definition of resource paths, operations available for each resource, input parameters response messages and media type of input and output. In addition, Swagger allows service providers to specify data models of input and output messages, as shown in the example below. D1.3.2 Service modelling and representation Final Version Page 12 of 60

13 Swagger specification of a service object functionality provided by ServIoTicy APIs - description of data models of input and output messages {# ##"apiversion":#"1.0",# ##"swaggerversion":#"1.2",# ##"basepath":#" ##"resourcepath":#"/ be c27b07e748b ",# ##"apis":#[# ####...# ##]# ##"models":#{# ####"Stream":#{# ######"id":#"stream",# ######"description":#"stream#field#of#a#service#object",# ######"properties":#{# ########"name":#{# ##########"type":#"string",# ##########"description":#"human#oriented#name#for#the#service#object"# # ####,# # ###"description":#{# # #####"type":#"string",# # #####"description":#"human#oriented#description## ##########################of#the#service#object."# # ###,# ########"type":#{# ##########"type":#"string",# ##########"description":#"the#type#of#stream."# ########,# ########subscriptions":#{# ##########"type":#"string",# ##########"description":#"subscriptions#of#this#service#object."# # ###,# # # ###"channels":#{# # #####"$ref":#"channel",# # #####"description":#"channels#of#this#stream."# # #### ####### ####,# ####"Channel":#{# #####...# ####,#...# Details on the functionalities of service objects that are provided through the ServIoTicy object registry are available in the Deliverable D Trentino Meteorological Sensors The Smart Territory use case makes use of services and data sources available for the Trentino region. Recently, an initial batch of meteorological data sources was made available at with sensors of weather and snow, and human-oriented D1.3.2 Service modelling and representation Final Version Page 13 of 60

14 FP COMPOSE weather bulletins and forecasts, both local and region-wide. In this deliverable, we will use the sensor registry service called Anagrafica stazioni meteo (stazioni automatiche). The Anagrafica service is similar to the Barcelona SOS service, and currently has 189 temperature/wind/precipitation sensors scattered throughout the Trentino region, as depicted in Figure 2 (also created using Google Earth). Figure 2: Location of Sensors within Trentino Smart Territory. Effectively, the Anagrafica service is a downloadable XML document that lists the sensors by name and location. Each sensor makes its readings (temperature, wind and precipitation) from the last 24 hours available as a separate downloadable XML document. Both the Anagrafica registry and the sensors themselves use custom XML formats that haven t been (internationally) standardized. The screenshot in Figure 3, shortened to leave only the relevant parts, shows the description of the Trentino meteorological data sources, including the Anagrafica stazioni meteo service, and the Dati recenti delle stazioni set of links that provide actual sensor readings. D1.3.2 Service modelling and representation Final Version Page 14 of 60

15 Figure 3: Smart Territory Data Sources Description In this COMPOSE use case, each sensor station is currently available as service object in ServIoTicy and it available as a Swagger-based service, as well as for services in the shopping scenario Web APIs: source of external services for COMPOSE Web APIs, also called RESTful services, have emerged as a very popular means for serviceoriented systems on the Web. ProgrammableWeb 5, the one of the most popular Web API repository, listed 12,200 Web APIs in October 2014, a 500% increase in just 3 years. The biggest companies on the Web, such as Google, Twitter and Yahoo!, provides functionalities of their 5 D1.3.2 Service modelling and representation Final Version Page 15 of 60

16 Web applications and services through Web APIs. These services can be exploited to create advanced COMPOSE applications by combining them with service objects. This newer breed of services has shaken a good deal of the technological foundations that have traditionally been at the core of most service-oriented approaches to date. For instance, Web APIs are seldom described by means of some Interface Definition Language, instead they just rely on humans interpreting HTML documentation. For this deliverable, we consider the Twitter REST API 6 and its HTML documentation as an example of external services. 1.2 Requirements Addressed in this Deliverable This document directly and indirectly addresses a number of COMPOSE requirements identified in deliverable D1.1.1 COMPOSE requirements. Below, we list the relevant requirements and we discuss in what way and to what extent, the deliverable addresses them. US 4 Easy developer interaction with the platform to create services To ensure the usability and simplicity of COMPOSE, the models developed in this document are designed to be very lightweight, following the principle of minimal ontological commitment. US 8 Support service discovery to the extent possible SM 3 Services and applications semantic description SMT 1 Service model Service discovery is the dominant purpose of semantic service descriptions, and in COMPOSE, we use semantic technologies to support service discovery, therefore US 8 and SM 3 are key motivators for this deliverable. SMT 1 is addressed in this deliverable, to the extent of its overlap with SM 3. SM 2 Manual service objects semantic description SM 4 Semantic information should be made accessible to platform users SM 5 Semantic information should be published SM 6 Semantic matchmaking DP 5 Efficiently support both data and metadata stores These five requirements effectively list the types of tools that need to be built or adopted by the COMPOSE project to create and process semantic service descriptions: authoring tools (SM 2), a registry (SM 4, SM 5, DP 5) with search and discovery functionalities and APIs (SM 5, SM 6, DP 5). As such, they define the intended use for the models selected and devised in this deliverable. HT 1 Integrate a Number of different object technologies into the platform The example services introduced in Section 1.1 show part of the technological diversity faced by the COMPOSE project. We have services that use the SOAP protocol for communication, and are described in WSDL, as well as RESTful services that are described in human-oriented HTML documentation or by Swagger specification. DP 4 Data lifecycle management Section 4 discusses how service descriptions can be annotated with update timestamps, in order to support the evaluation of freshness of service/object metadata. 6 D1.3.2 Service modelling and representation Final Version Page 16 of 60

17 DP 7 Provenance Information Section 4 shows basic provenance metadata for service/object descriptions. However, this provenance metadata is aimed to be informative for service description consumers, rather than to support security policies and their enforcement within the COMPOSE platform. Section 5 discusses the security aspects related to service and object descriptions. DP 14 Support for Data Composition and Linked Data SMO 6 Smart object identification The models presented in this deliverable are semantic models and thus they support data composition; the service descriptions that use these models follow the Linked Data principles, in particular including unique identification of service objects (SMO 6). Indeed, the iserve registry [2], which has been significantly extended and improved to meet COMPOSE platform requirements, publishes service descriptions as Linked Data. Therefore, this deliverable directly supports these requirements. ME 1 Support service objects joining and leaving the system ME 2 Support services joining and leaving the system These requirements have direct bearing on the APIs of the service and object registry within the COMPOSE platform. As objects and services may re-join the system after having temporarily left, some metadata can be retained by the system. A support for modelling the presence of services and objects is discussed in this deliverable in Section 2.3. SEO 2 Service object smart object relationship By using the dc:subject#property on service object descriptions, as discussed in Section 4, this requirement is covered. SEO 6 Semantic enhancement As service objects directly represent smart objects, the semantic descriptions of service objects, covered in Sections 2 and 3, will pertain to the smart objects themselves. Only where a service object presents a transformed or incomplete view of the underlying smart object, the semantic description may reflect the transformation or functionality subset implemented in the service object. This also implies that a single smart object can be represented by multiple service objects and that their semantic descriptions may give different account of the capabilities of the smart object. SEO *, SER * (other than those mentioned explicitly) Many of the SEO requirements mirror earlier requirements on service representation and on functionalities around service descriptions, and this document addresses them accordingly. STD 2 Contributions to existing standard ontologies Section 3 and 5 cover vocabularies specific to COMPOSE. These may be input to the project s standardization activities. USC 1 Service and data model This requirement is covered under earlier requirements. USC 14 Support for Spatial and Temporal Queries The location non-functional properties described in Section 3.4, and the timestamp properties described in Section 4, support spatial and temporal metadata queries. D1.3.2 Service modelling and representation Final Version Page 17 of 60

18 USC 16 Integration with existing Sensor Network Technologies The sensor descriptions in this document are based on the Semantic Sensor Network Ontology, which was part of the final output of the W3C Semantic Sensor Network Incubator Group, and was informed by a wide body of existing technologies. 1.3 Ontologies Used in this Document This deliverable puts together a number of external ontologies and vocabularies. Here we list them to serve as a point of reference. RDF, RDFS: The semantic models presented in this deliverable are built on the Resource Description Framework (RDF) graph data model, which heavily relies on URIs to identify concepts and objects. RDF Schema (RDFS) is a basic ontology definition language for RDF. RDF: RDFS: SAWSDL: The standard language for formal descriptions of Web services is WSDL (version 2.0), an XML language. On top of WSDL, the first standard for semantic description of Web Services is the lightweight annotation layer called Semantic Annotations for WSDL and XML Schema (SAWSDL, [3]), which defines not only XML attributes for use in WSDL, but also an RDF form for its annotations. WSDL: SAWSDL: SOA4All vocabularies: The SOA4All project developed a number of vocabularies for semantic descriptions of Web services, importing SAWSDL terms. The vocabularies consist of the Minimal Service Model (MSM, [2]), WSMO-Lite [4] as the ontology for service semantics, and hrests/microwsmo microformats [5] that enable the semantic description of RESTful services that do not have a formal WSDL description. These vocabularies are further described in Section 2. Semantic Sensor Networks: The W3C Semantic Sensor Network (SSN) Incubator Group, concluded in 2011, reviewed a large number of sensor-related ontologies, and produced an exhaustive final report [6] and a formal ontology, the SSN ontology, which we intend to use for describing the sensor aspects of COMPOSE services. From the final report: The SSN ontology can be used for a focus on any (or a combination) of a number of perspectives: 1. A sensor perspective, with a focus on what senses, how it senses, and what is sensed; 2. A data or observation perspective, with a focus on observations and related metadata; 3. A system perspective, with a focus on systems of sensors; or, 4. A feature and property perspective, with a focus on features, properties of them, and what can sense those properties. SSN XG Final Report: SSN Ontology: Quantities and Units: The OMG SysML Quantities, Units, Dimensions and Values (QUDV) working group, in cooperation with the Semantic Sensor Network group, produced a set of on- D1.3.2 Service modelling and representation Final Version Page 18 of 60

19 tologies for common quantities and units (QU). On top of these ontologies, the SSN group added a Climate and Forecast (CF) ontology that lists a number of meteorology-related quantities and units. We use these ontologies whenever quantities and units are required in service descriptions. QU Quantity Kinds and Units: CF Climate and Forecast ontology: These ontologies define the namespaces dim, qu, quantity, unit, and cf. DOLCE Ultra-Lite: The SSN Ontology is aligned with the DOLCE Ultra-Lite (DUL) foundational ontology. According to the SSN report: the alignment between the SSN ontology and the DOLCE Ultra Lite upper ontology has helped to normalise the structure of the ontology to assist its use in conjunction with ontologies or linked data resources developed elsewhere. DUL: Dublin Core: The Dublin Core Metadata Initiative (DCMI) has been maintaining terms for basic metadata, used in various places in this deliverable. Dublin Core terms: Geolocation: The W3C Semantic Web Interest Group has produced a basic geolocation vocabulary using the WGS84 datum shared with the GPS system. Geo: Schema.org: Bing, Google and Yahoo! defined a collection of schemas that webmasters can use to markup HTML pages in ways recognized by major search providers. Its RDF representation is available at: We use this model to provide a high level functional classification of services and service objects, and to describe service providers. Schema: DBpedia: DBpedia is a cross-domain knowledge base build by extracting structured information from Wikipedia. It is the core and most used reference of the Linked Open Data cloud. We use DBpedia to define gross grain classification of service objects. DBpedia: SIOC: The SIOC (Semantically-Interlinked Online Communities) Core Ontology defines concepts and properties to describe on-line communities, such as blogs, wikis and forums. We reuse terms of this ontology to model service forums to support developers issues. SIOC: USDL-SEC ( Unified Service Description Language - Security Part (USDL-SEC) is a vocabulary for semantically describing the high-level security features of services. SKOS: The Simple Knowledge Organization System (SKOS) vocabulary is an ontology used by Linked USDL to model classification or taxonomies of service types and business entities. SKOS: Time: The time ontology models temporal properties of services. Linked USDL reuses terms of this vocabulary. Time: D1.3.2 Service modelling and representation Final Version Page 19 of 60

20 vcard: The vcard ontology represents a RDF mapping to the vcard specification. It is reused by Linked USDL to provide contact information for people and organizations. ccard: GoodRelations: GoodRelations is a vocabulary for product, price, store, and company data that can be used to markup existing Web pages and processed by other computers. Its aim is to increase the visibility of products and services in the latest generation of search engines and recommender systems. Linked USDL reuses Good Relations terms to model business entities, offerings, and products. GoodRealtions: D1.3.2 Service modelling and representation Final Version Page 20 of 60

21 2 Core Service Models and Service Description Technologies The SOA4All project developed Linked Services, a framework for dealing with services on the Web [1]. It extends notions around Linked Data, a relatively recent effort derived from research on the Semantic Web, whose main objective is exposing and interlinking data previously enclosed within silos. The resulting Web of Data is based upon four simple principles, known as the Linked Data principles [9]. The principles essentially dictate that every piece of data should be given an HTTP URI which, when looked up, should offer useful information using Web standards such as RDF for representing data and SPARQL to support online data queries. Importantly, data should be linked to other relevant resources thereby allowing humans and computers to discover additional information. Linked Services build upon Linked Data and govern the way data sources and services are described, discovered, invoked, and integrated. In a nutshell, Linked Services are services that can consume and produce Linked Data and whose descriptions (such as their functionality and input/output data types) are also published as Linked Data. Linked Services simplify the integration of heterogeneous services by relying on a common means for representing data. Linked Services can easily be integrated with existing Linked Data sources as both data and service interfaces are semantically described according to shared vocabularies. The data from the Web of Data can be directly used to invoke services. Combining Linked Services with Linked Data also enhances service discovery due to the provision of semantic descriptions that include links to/from other datasets and that are exposed using standards for data access and querying (esp. HTTP, RDF and SPARQL). For example, based on the types of data in an application s workspace, it is possible to exploit the semantic description of service inputs in order to obtain only services that can process the available data. COMPOSE deals with COMPOSE applications, service objects (Web service façades for smart objects) and external services, and it requires semantic descriptions of these services. From the point of view of semantic models for services, as shown below, there is no conceptual difference between these three entities, therefore this section does not make any such distinction. 2.1 Linked Service Models The Linked Services approach uses the Minimal Service Model (MSM) as its core conceptual model [2]. The Minimal Service Model, driven by Semantic Web best practices, builds upon existing vocabularies, namely SAWSDL [3] and WSMO-Lite [4], depicted in Figure 4 with the sawsdl and wl, namespaces respectively. In a nutshell, MSM is a simple RDFS integration ontology based on the principle of minimal ontological commitment; it captures the maximum common denominator between existing conceptual models for services, covering the core semantics of both Web services and Web APIs in a common model, homogeneously supporting publication, discovery and invocation. MSM, shown in white and denoted by the msm namespace, defines Services that have a number of Operations, which in turn have input, output and fault (error) MessageContent descriptions. MessageContent may be composed of mandatory or optional MessageParts. The intent of the message part mechanism is to support finer-grained input/output discovery, as available in OWL-S and WSMO, especially including support for optional parts. The msm:isgroundedin property defines the grounding of elements defined existing service models define by MSM terms (e.g., the location of a WSDL operations defined by the D1.3.2 Service modelling and representation Final Version Page 21 of 60

22 msm:operation term). On the one hand, the grounding enables the matchmaking between services described by heterogeneous service models mapped through MSM, which is necessary to perform, discovery, composition and recommendation. On the other hand, grounding information allows users to invoke properly services by accessing parts of the original service descriptions. Figure 4: The Minimal Service Model MSM descriptions can be annotated with human-readable labels, comments and documentation, using existing RDF properties rdfs:label, rdfs:comment, and dc:description. These properties enable support for full-text search capabilities that complement the semantic matchmaking algorithms for service discovery. Example: the Barcelona SOS service s WSDL description would translate to the following MSM triples (with example instance URIs): ex:barcelonasos#a#msm:service#;# # rdfs:label#"sos"#;# * msm:hasoperation#ex:bsop1,#ex:bsop2,#...#.# ex:bsop1#a#msm:operation#;# # rdfs:label#"getcapabilities"#;# # msm:hasinput#ex:bsop1i#;# # msm:hasoutput#ex:bsop1o#.# ex:bsop1i#a#msm:messagecontent#;# # rdfs:label#"getcapabilitiessoapin"#.# ex:bsop1o#a#msm:messagecontent#;## # rdfs:label#"getcapabilitiessoapout"#.#...## SAWSDL, shown in yellow, is a W3C recommendation that defines three properties for attaching semantic annotations to service descriptions: modelreference points from any service description element to its concrete semantic description, and will be illustrated in examples below; while liftingschemamapping and loweringschemamapping refer to data transformations that lift messages or data from an underlying syntactic form (e.g. JSON or XML) into a semantic form (RDF), or lower data or message from the semantic form back to the underlying syntactic form. D1.3.2 Service modelling and representation Final Version Page 22 of 60

23 Example: Since both the Barcelona SOS service is a sensor registry, its data should be lifted from its respective custom XML form into the common semantic forms. Presuming a XQuery file, where the data lifting transformation logic is, the service would be annotated like this: ex:bsop1#a#msm:operation#;# # rdfs:label#"getcapabilities"#;# # msm:hasoutput#ex:bsop1o#.# ex:bsop1o#a#msm:messagecontent#;## # rdfs:label#"getcapabilitiessoapout"#;# # sawsdl:liftingschemamapping** **********< project.eu/res/d1.3.1/bcasosop1lifting.xq>*.* Section 3.2 contains further discussion about lifting and lowering mappings in COMPOSE. WSMO-Lite, shown in blue, allows service providers to describe their service offerings so that a client can make an up-front decision on whether and how to consume the service's functionality. It defines a top-level vocabulary for semantic descriptions that can be pointed to by model references. WSMO-Lite distinguishes four core types of service semantics: 1. Information Model semantics the meaning of the data communicated by the service; 2. Functional semantics what the service does for its clients; 3. Behavioural semantics how clients should communicate with the service; and 4. Non-functional semantics any incidental details pertaining to the implementation or running environment of the service. The non-trivial distinction between functional and non-functional semantics can be illustrated as follows: if two services have the same functional semantics, they should be effectively interchangeable, except that one service can be better (faster, closer, cheaper etc.). On the other hand, if two services have the same non-functional semantics, it can be seen as a coincidence without importance: if one service is a sensor and another one an actuator, it is unlikely to be significant in discovery and composition that they have the same location, response time, and price. Functional semantics is the primary type of service description for supporting service discovery a client specifies what needs to be done, and a service registry find services that may be able to do it. WSMO-Lite supports two ways of defining functional semantics: through hierarchical classifications of known functionality, and through explicit preconditions and effects of service invocation. Hierarchical classifications are intended to express coarse-grained stakeholder consensus, while preconditions and effects enable fine-grained expression of service functionality, useful in specialized settings. Example: The cart location sensors from the shopping scenario are classified as a tracking service, according to Schema.org, and a Position sensor according to DBpedia. compose:serviceobject specifies that the service is a service object. ex:cartlocation#a#msm:service#;# sawsdl:modelreference*compose:serviceobject#;# sawsdl:modelreference*schema:trackaction#;# # sawsdl:modelreference*dbpedia:position_sensor#.# D1.3.2 Service modelling and representation Final Version Page 23 of 60

24 Information model semantics can also be used by a service discovery the registry may find services that can process the type of data available to the client, or services that can produce the type of data the client requires. Information model semantics is especially important when composing services it guides the data flows from one service to another. WSMO-Lite, as a framework, accepts any ontology and schema languages as means of expressing information model semantics, as long as their entities can be pointed to by SAWSDL model references. Example: as the Barcelona SOS service is a sensor registry, and sensors are viewed as individual services in COMPOSE, the GetCapabilities operation is annotated as returning services: ex:barcelonasos#a#msm:service#;# # rdfs:label#"sos"#;# # msm:hasoperation#ex:bsop1#.# ex:bsop1#a#msm:operation#;# # rdfs:label#"getcapabilities"#;# # msm:hasoutput#ex:bsop1o#.# ex:bsop1o#a#msm:messagecontent#;## # rdfs:label#"getcapabilitiessoapout"#;# # sawsdl:modelreference*msm:service#.* * * * Example: Let assume a service object for one of the air temperature sensors registered in the SOS service - its output can be marked on this way: ex:tempsensor1#a#msm:service#;# # msm:hasoperation#ex:ts1op1#.# ex:ts1op1#a#msm:operation#;## # rdfs:label#"getobservation"#;# # msm:hasoutput#ex:ts1op1o#.# ex:ts1op1o#a#msm:messagecontent#;# # sawsdl:modelreference*aws:temperaturesensor*.** See Section 3.2 for discussion of the information model for common sensors. In WSMO-Lite, behavioural semantics focuses on the interaction between the service and its clients. This semantics is considered by the service composition service (see Deliverable D1.2.2) in order to provide coherent COMPOSE application based on composite services. WSMO-Lite models behavioural semantics by describing the functionality of service operations (as above, through hierarchical operation functionality classifications, or through logical preconditions and effects of operation invocation), enabling clients to dynamically select suitable operations for invocation. D1.3.2 Service modelling and representation Final Version Page 24 of 60

25 Example: to illustrate how functional annotations of operations can serve as a description of behavioural semantics, we will use an important part of the architecture of the Web: safe interactions. On the Web, it is prescribed that information retrieval with the HTTP GET method is safe in terms that it should not have any applicationsignificant side effects, and that the client cannot be blamed for blindly dereferencing (retrieving) URIs with GET. Safety enables services such as search engines and client-driven polling (including following-your-nose crawling in Linked Data) because the client knows the behaviour of some operations is constrained in this way. In the Barcelona SOS service, the operations GetCapabilities, DescribeSensor and GetObservation are safe in this sense. To describe this, we use the class wsdlx:safeinteraction from WSDL 2.0 as a SAWSDL annotation: ##the#getcapabilities#operation#on#the#sos#service#is#safe# ex:bsop1#a#msm:operation#;# # rdfs:label#"getcapabilities"#;# # sawsdl:modelreference*wsdlx:safeinteraction#.# # ##also#the#getobservation#operation#on#any#sensor#is#safe# ex:ts1op1#a#msm:operation#;## # rdfs:label#"getobservation"#;# # sawsdl:modelreference*wsdlx:safeinteraction#.# Preconditions and effects can assume literal values that specify how service behaviour is managed by the COMPOSE platform. For instance, the following example defines preconditions and effects to guarantee secure access to service operations (details are available in section 5). These preconditions and effects are defined by a security contract in JSON, which is exploited by the Security module of COMPOSE to allow specific users, service objects and COMPOSE applications to access functionality of a Trentino weather sensor. Definition of security lock to access service operations of a Trentino weather # trentino:t0454#a#msm:service#;# # sawsdl:modelreference#compose:serviceobject,# ######################aws:snowgauge,########### ############################ws:temperaturesensor,# #####################security:trentino.# security:trentino#a#wl:condition#;# # rdf:value#"$.contracts.properties.# ################################effects[@.object.id#=#'t0542']"*.* Non-functional semantics mainly serves as a discriminator among multiple potentially suitable services. If two or more services can functionally fulfil the client s requirement, the client may want to consider properties such as security policies, QoS (Quality of Service metrics such as performance and reliability), location, various types of cost, or provenance. Here we speak of filtering suitable services based on client s non-functional requirements, and ranking the services based on client s preferences. As is the case with information semantics, WSMO-Lite accepts any ontology as means of expressing non-functional properties. D1.3.2 Service modelling and representation Final Version Page 25 of 60

26 Example: a typical non-functional property on sensors is location. For instance, one of the Trentino region s sensors is located by the Galileo Galilei Scientific Lyceum in Trento, which can be described as follows: trentino:t0454#a#msm:service#;# # rdfs:label#"trento#(liceo#galilei)"#;# # sawsdl:modelreference#compose:serviceobject,# ######################aws:atmosphericpressuresensor,## ######################aws:snowgauge,#aws:temperaturesensor#;# msm7nfp:haslocation#trentino:t0454loc#.# # trentino:t0454loc# geo:lat##" "^^xsd:float#;# # #############geo:long#" "^^xsd:float#.# WSMO-Lite provides a minimal vocabulary for distinguishing the four types of semantics when they are pointed to by model references: 1. wl:functionalclassificationroot is a class that marks the root concepts of hierarchical functional categorizations (such as RDFS class hierarchies, or SKOS concept schemes). When a member of a hierarchical categorization marked with this class is used in a model reference on a Service, it is interpreted as a piece of the service s functional semantics; on an Operation, it becomes a piece of the service s behavioural semantics. 2. wl:condition and wl:effect are two classes that mark logical expressions that convey the preconditions and effects, either for use on an msm:service (for functional semantics) or on an msm:operation (for behavioural semantics). 3. wl:nonfunctionalparameter is a class that marks pieces of non-functional semantics, sometimes also called non-functional properties. Particular instances of non-functional parameters are pointed to by the service model references. 4. wl:ontology is a WSMO-Lite class that may be used to mark semantic models especially intended as information models for service message exchanges. The use of this class is optional in service descriptions because model references from msm:messagecontent and msm:messagepart instances are naturally understood as information model semantics. Ontologies registered in a system may be marked as wl:ontology for the benefit of tools that will then recommend these ontologies for information model annotations. WSMO-Lite is used in Section 3 to define the semantic terms used in the examples above. D1.3.2 Service modelling and representation Final Version Page 26 of 60

27 2.2 Representation of existing service models through MSM The design of MSM was inspired by WSDL standard, therefore the modelling WSDL-based services is straightforward. The following table shows the mappings between MSM terms and WSDL 1.1 and 2.0 elements. Table 1: Mapping between MSM concepts and WSDL terms MSM WSDL 1.1 WSDL 2.0 msm:service# wsdl:service# wsdl:service# msm:operation# wsdl:operation# wsdl:operation# msm:messagecontent# (msm:hasinput property)# msm:messagecontent# (msm:hasoutput property)# msm:messagecontent# (msm:hasfault property)# msm:messagecontent# (msm:hasinputfault property)# msm:messagecontent# (msm:hasoutputpart property)# wsdl:input# wsdl:output# wsdl:input# wsdl:output# wsdl:fault# 7# 7# wsdl:infault# 7# wsdl:outfault# Msm:MessagePart# wsdl:part# 7# To provide WSDL grounding in MSM descriptions we defined a specific MSM extension called MSM-WSDL (shown in Figure 5). This extension provides one simple property, msm7 wsml:isgroundedin, which enables service modellers to capture the grounding of elements of a service description into the actual WSDL element that defines it. Essentially, this property is a link that provides back and forth navigation from MSM service descriptions into WSDL files. In MSM-WSDL, the WSDL element should be specified according to a WSDL 1.1 [13] or 2.0 [14] IRI-references syntax defined by a XPointer expression [15]. Figure 5: MSM-WSDL vocabulary for WSDL grounding D1.3.2 Service modelling and representation Final Version Page 27 of 60

28 An example of MSM representation of WSDL-based service is provided below. Example: WSDL grounding of the GetCapabilities operation from the Barcelona SOS scenario. ##the#getcapabilities#operation#on#the#sos#service#is#safe# ex:bsop1#a#msm:operation#;# # rdfs:label#"getcapabilities"#;# # sawsdl:modelreference#wsdlx:safeinteraction#;# msm7wsdl:isgroundedin#" #############WSDL#wsdl.interfaceOperation(SosSoap/GetCapabilities)"# #############^^msm7wsdl:xpointer#.# For services that are not described in WSDL, such as RESTful Web APIs available as external servics, the lack of a standardized machine-readable service description format is an obstacle to attaching semantic descriptions. To address this issue, our approach targets the HTML documentation of such services with two microformats 7 that can express the MSM and SAWSDL annotations on top of it: 1. hrests is a microformat that gives HTML documents the MSM structure: a document may describe a Service, which offers a number of Operations, each with input and output messages made up of distinct parameters. In addition to the service model, hrests also provides basic properties for grounding information about the service s network location and access protocol. In particular, this is embodied in the rest:hasaddress and rest:hasmethod properties, which may be specified for each operation of a service. 2. MicroWSMO extends hrests with the SAWSDL properties for model references, and for lifting and lower schema mappings. Example: This listing shows relevant excerpts of the source code of a Twitter API webpage 8, with highlighted hrests/microwsmo # <body>#...# <h3>resource#url</h3><div#class="operation"># </div>#...# <h3>parameters</h3><div#class="input"># # <span#class="param">count</span># <p>specifies#the#number#of#records#to#retrieve.#must#be#less#than# or#equal#to#200.#defaults#to#20.</p># </div># #...# 7 Microformats are a way of annotating human-oriented HTML documents such that machine-readable structured data can automatically be extracted from them. 8 D1.3.2 Service modelling and representation Final Version Page 28 of 60

29 Figure 6: MSM and hrests concepts for RESTful services description Figure 6 shows how hrests extends MSM to describe RESTful services. More details of mapping between RESTful services and MSM are available in [5]. An example of RESTful API mapping is provided below. MSM representation of the service described by the HTML portion above trentino:listastazioni#rdf:type#msm:service#;# # rdfs:label#"anagrafica#stazioni#meteo#(stazioni#automatiche)"# msm:hasoperation#trentino:listastazioniop1#.# # trentino:listastazioneop1#hr:hasaddress## ######" # msm:hasoutput#trentino:listastazioniout1#.# # trentino:listastazioniout1#sawsdl:modelreference#msm:service#;## # sawsdl:liftingschemamapping# " The mapping is more straightforward for RESTful APIs described by Swagger because descriptions are provided by structured JSON-based documents. MSM, hrests and Swagger terms are mapped as specified by the following table. Table 2: Mapping of MSM and hrests concepts to Swagger terms MSM and hrests concepts msm:service# msm:operation# hr:uritemplate# (hr:hasaddress property)# hr:method# hr:mediatype# (hr:producescontenttype property)# hr:mediatype## (hr:acceptscontenttype properties)# Swagger terms Resource listing Operation item BasePath for msm:service Path for msm:operation Method Produces Consumes D1.3.2 Service modelling and representation Final Version Page 29 of 60

30 msm:messagecontent## (msm:hasinput property)# Parameter listing Mandatory#msm:MessagePart# (of input msm:messagecontent)# Mandatory msm:messagepart# (of input msm:messagecontent)# msm:messagecontent# (msm:hasoutput property)# msm:messagecontent# (msm:hasfault property)# Mandatory#msm:MessagePart# (of output and fault msm:messagecontent)# Optional#msm:MessagePart## (of output and fault msm:messagecontent)# Required Parameter Not Required Parameter Response Message (with HTTP status code < 400) Response Message (with HTTP status code >= 400) HTTP status code and message Response model The grounding of Swagger description is defined by an extension vocabulary, called MSM- Swagger (in Figure 7). This ontology provides grounding to Swagger descriptions through the msm7swagger:isgroundedin property. Swagger elements, which are defined as JSON portion, are specified through JSONPath [16] expressions. Figure 7: MSM-Swagger vocabulary for Swagger grounding MSM modelling of a service object operation specified through Swagger so:updatestream#rdf:type#msm:operation#;# # hr:hasmethod# # rdfs:label#"updatestream"#;# # rdfs:comment#"store#(and#process)#new#data#associated#to#the# ####################stream#streamid#of#the#serviceobject"#;# # msm:hasinput#so:updatestream_in#;# # msm:hasoutput#so:updatestream_out#;# # msm7swagger:isgroundedin## # "$[?(@.resourcepath#==## '/ be c27b07e748b ')]# #######.apis.operations.[?(@.nickname#==#'updatestream')]"# #######^^msm7swagger:jsonpath# # D1.3.2 Service modelling and representation Final Version Page 30 of 60

31 2.3 Static and Dynamic Metadata In the settings of services for Internet of Things, such as COMPOSE, it is necessary to support services and service objects dynamically entering and leaving the system (requirements ME-1, ME-2). A service object or a service that has left the system and is re-joining should have its description appropriately updated. Clients that did not directly attempt to use the service while it was not available should not be affected. Moreover, service objects cannot be available and executable because of issues in the service deployment module of COMPOSE. This document proposes a non-functional property called isexecutable (instance of wl:nonfunctionalparameter) to be used for specifying if the service or service object can be invoked. Example: a particular sensor in the Barcelona use case can be marked as inactive simply by adding the appropriate property value: ex:tempsensor1#a#msm:service#;# # msm7nfp:isexecutable# false ^^xsd:boolean#.# Currently, the service recommendation engine provides functionalities to filter services according specific properties (details in Deliverable ). This filtering can be applied to provide only executable services to users. When an object or a service rejoins the system, it is possible that some of its properties will be changed. For instance, a mobile sensor may rejoin the system in a new location and with a different network address. Both the location (a non-functional property) and the network address (part of the grounding information in the service description) should then be changed, before or at the same time as the inactivity flag is removed. The formal definition of this property will be provided in section 3.3. D1.3.2 Service modelling and representation Final Version Page 31 of 60

32 3 COMPOSE Vocabularies for Service Annotation All the models covered by the deliverable are shown in Figure 5. The bottom level contains underlying service descriptions we discussed before (whether in WSDL, HTML annotated with hrests and Swagger). The middle layer is the core semantic models from the Section 2. The top level refers to COMPOSE-specific vocabularies for capturing three types of semantics. More particularly, it refers to vocabularies for: 1. Functional classification for COMPOSE services and objects (Section 3.1) 2. Information model terms for describing service outputs (Section 3.2) 3. Non-functional properties for COMPOSE services and service objects (Section 3.3) Figure 8: Stack of Service Description Models 3.1 Functional Classification of COMPOSE Services Functional classification of services and operations can be defined by any kind of vocabulary provided by users that want to register services and objects in the COMPOSE platform. However, we strongly recommend to users who register services to the platform to associate at least one Action defined by Schema.org hierarchy as sawsdl:modelreference to each msm:service and msm:operation. Schema.org [17] is a set of generic cross-domain terms defined by the most popular search engines (Bing, Google and Yahoo!). These terms can be used by webmasters to markup their pages in order improve the display of search results. The Schema.org Action hierarchy specifies a classification of generic actions, such as find, inform, and track actions. The usage of these actions as model reference implements a high-level functional classification of services and operations, which enables a generic and cross-domain service discovery. In order to provide a gross grain classification of service objects, we suggest using elements of actuators 9 and sensors 10 categories from DBpedia. DBpedia is a generic knowledge base availa D1.3.2 Service modelling and representation Final Version Page 32 of 60