a web of things framework for restful applications and its...

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

IEEE SYSTEMS JOURNAL 1

A Web of Things Framework for RESTfulApplications and Its Experimentation in a Smart City

Federica Paganelli, Member, IEEE, Stefano Turchi, and Dino Giuli, Senior Member, IEEE

Abstract—The Web of Things is an active research field whichaims at promoting the easy access and handling of smart things’digital representations through the adoption of Web standards andtechnologies. While huge research and development efforts havebeen spent on lower level networks and software technologies, ithas been recognized that little experience exists instead in mod-eling and building applications for the Web of Things. Althoughseveral works have proposed Representational State Transfer(REST) inspired approaches for the Web of Things, a main lim-itation is that poor support is provided to web developers forspeeding up the development of Web of Things applications whiletaking full advantage of REST benefits. In this paper, we proposea framework which supports developers in modeling smart thingsas web resources, exposing them through RESTful ApplicationProgramming Interfaces (APIs) and developing applications ontop of them. The framework consists of a Web Resource informa-tion model, a middleware, and tools for developing and publishingsmart things’ digital representations on the Web. We discuss theframework compliance with REST guidelines and its major imple-mentation choices. Finally, we report on our test activities carriedout within the SmartSantander European Project to evaluate theuse and proficiency of our framework in a smart city scenario.

Index Terms—Internet of things (IoT), representational statetransfer (REST), sensors, smart city, smart things, web, web ofthings, web services.

I. INTRODUCTION

THE WEB OF Things is an active research area that focuseson the specific challenge of making smart things accessi-

ble and manageable through open Web standards. This visionis correlated with the broader Internet of Things (IoT) researcharea aiming at enabling communication with and among smartobjects, leveraging Internet standards and technologies [1].

As argued by the European Expert Group on Services inthe Future Internet [2], huge research and development effortshave focused on lower level networks and software technolo-gies, while “there is currently little experience with buildingapplications for this new, emerging ecosystem of IP-enableddevices and objects.” As the Web facilitated both application

Manuscript received March 24, 2014; revised July 26, 2014; acceptedAugust 28, 2014. This work was supported in part by the European Commissionthrough the SmartSantander Seventh Framework Programme-Information andCommunication Technologies project.

F. Paganelli is with the National Interuniversity Consortium forTelecommunications, University of Florence, 50139 Florence, Italy (e-mail:[email protected]).

S. Turchi and D. Giuli are with the Department of Information Engineering,University of Florence, 50139 Florence, Italy (e-mail: [email protected];[email protected]).

Color versions of one or more of the figures in this paper are available onlineat http://ieeexplore.ieee.org.

Digital Object Identifier 10.1109/JSYST.2014.2354835

development and use for the traditional Internet, it is nowexpected to “unleash the potential of the IoT by making it acces-sible and programmable by developers who are not necessarilyexperts in ubiquitous computing” [2].

The Web of Things is expected to ease the access to smartthings’ capabilities and promote novel value-added servicesbased on the combination of traditional web resources withthose representing entities from the physical world (smartthings, sensors, appliances, etc.) [3]. This has the big advantageof allowing the integration of smart things with the impressiveamount of information resources and services already on theWeb, as well as exploiting available technologies and bestpractices for web resource publishing and management.

On this perspective, the Representational State Transfer(REST) architectural style, developed as an abstract model ofthe Web architecture [4] is considered a reference paradigmfor bringing sensors, and more generally smart things, into theWeb [5]–[7]. Indeed, REST defines a set of principles for de-signing distributed hypermedia application fulfilling scalability,simplicity, and loosely coupling requirements.

Several research works have proposed approaches for im-plementing the Web of Things through REST principles, asdiscussed in the survey by Zeng et al. [8]. However, the path tothe effective realization of the Web of Things is made difficultby the widespread misunderstanding of REST basics [9] and,consequently, the lack of software development frameworksthat comprehensively support them [10], [11].

As a consequence, a main limitation of related work is thatpoor support is provided to web developers for speeding up thedevelopment of web applications for accessing, modifying, andcomposing information resources in the Web of Things domain[2] while taking full advantage of REST benefits.

In this paper, we propose an approach toward the Web ofThings based on a graph representation of web resources, whichcan be accessed and modified at the desired and meaningfullevel of granularity through a REST-compliant uniform inter-face. According to our approach, a smart thing can be modeledas a graph of individually addressable web resources whoseedges represent simple structural aggregation (i.e., contain-ment) and reference relations. Graph-based representation ofsmart things can be interlinked with other types of informationnodes to build a growing graph of globally addressable infor-mation resources that can be navigated, queried, and composedthrough a uniform REST interface.

The proposed framework consists of the following: 1) a WebResource information model for representing smart things asweb-accessible resources; 2) a middleware for handling andexposing these resources through a uniform API; and 3) a set

1932-8184 © 2014 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

http://www.ieee.org/publications_standards/publications/rights/index.html

mailto: [email protected]




2 IEEE SYSTEMS JOURNAL

of tools for easing the creation and handling of Web Resourcesas well as their web-oriented programming and publishing.

By leveraging the presented Web Resource model, mid-dleware and tools users can easily create and modify digitalrepresentations of smart things, interconnect them with simplelinks, and publish them on the Web as RESTful resources.

Finally, we report on the use of the framework in a SmartCity scenario within the SmartSantander European Project. Theexperiment consisted in the development of a web applicationfor accessing sensors deployed in the city of Santander, Spain,as well as creating new virtual sensors. We also evaluated theend-user acceptance of the provided tools.

The remainder of this paper is organized as follows. InSection II, we present related work and motivate our contribu-tion. Section III introduces the main principles of our approachand describes our framework. In Section IV, we describe theexperiment carried out within the SmartSantander EuropeanProject to evaluate the proposed approach. Section V concludesthis paper with insights on future work.

II. RELATED WORK

In this section, we briefly introduce the main principles of theREST architectural style. Then, to motivate our work, we ana-lyze state-of-the-art solutions for middleware and applicationframeworks for the Web of Things.

A. REST Architectural Style

REST was proposed by Fielding [12] in his doctoral disserta-tion as an architectural style for building large-scale distributedhypermedia systems. By the REST vision, data sets and objectshandled by client–server application logic are modeled as re-sources. REST key principles are fivefold [12].

1) URIs as resource identifiers. Resources are exposed byservers through URIs. Since URIs belong to a globaladdressing space, resources identified with URIs have aglobal scope.

2) Uniform interface. The interaction with the resource isfully expressed with four primitives, i.e., create, read,update, and delete. These operations can be mappedonto HTTP methods: GET reads the resource state, PUTupdates the resource state, DELETE deletes a resource,and POST extends a resource by creating a child resource.

3) Self-descriptive messages. Each message contains theinformation required for its management.

4) Stateless interactions. Each request from client to servermust contain the information required to fully understandit and is independent of any previous request.

5) Hypermedia As the Engine Of Application State (HA-TEOAS). A hypermedia system is characterized by partic-ipants transferring resource representations that containlinks; the client can progress to the next step in theinteraction by choosing one of these links [13].

Historically, two styles opposed in the Web services field:Service-Oriented Architecture (SOA) and Resource-OrientedArchitecture (ROA), i.e., WS-* and REST. Pautasso et al.[14] compare RESTful and WSDL/SOAP-based Web ser-vices, using architectural principles and decisions. The authors

conclude that RESTful services are more suited for tactical adhoc integration over the Web (à la Mashup). Adamczyk et al.[11] evaluated some key questions regarding the real and per-ceived distinctions between the two styles and carried out athorough analysis of Web services exposed by four repositories:1) xmethods.net; 2) webservicex.net; 3) webservicelist.com;and 4) programmableweb.com reporting a very fast-pacegrowth of REST popularity. Moreover, in a study led in 2012by Guinard et al. [7] involving 69 novice developers in im-plementing IoT client applications exploiting WS-∗ and RESTapproaches, results reported that REST is statistically signif-icantly easier and faster to learn than WS-∗. In addition, aconsiderable number of volunteers agreed that REST was moresuited for Web applications requiring to integrate Web content:“[for] Web Mashups, REST services compose easily.”

Although RESTful APIs are deemed to be relatively simple,developing RESTful systems is difficult, and existing frame-works fail to support developers in conforming to REST con-straints [10], [11]. The analysis provided by Zuzak and Shreier[10] highlights some weaknesses of existing general-purposeREST frameworks, such as the lack of structural and behavioralmodels for resource types, poor support of flexible mappingbetween resource representations and stored data entities, andthe lack of support for scripting functions for read–write accessto the application state at the client side. Adamczyk et al.[11] argue that current frameworks do not support well the“hypermedia constraint” or HATEOAS principle, and most ofthem do not fully support HTTP caching.

B. Middleware and Frameworks for the Web of Things

Zeng et al. provide a survey on research works in the WoTdomain [8], where they highlight two main analysis criteria: theapproach for integrating the physical things to the Web (i.e.,direct and indirect integration) and the provision of composableservices for enabling physical–virtual mashups.

Guinard et al. [15] provide a pioneering work contributionby specifying and implementing a set of REST services thatexpose functionalities of sensor nodes as web resources and linkthem together hierarchically. In a later work, this approach isapplied in the AutoWoT project [16], a toolkit that facilitatesthe rapid integration of smart devices into the Web by offeringa general way of modeling web resources and a mechanism forbuilding web server components that expose the functionalityof these devices. If the user modifies the Web resource at a latertime, AutoWoT can semiautomatically regenerate the softwarefor the Web exposure of the device.

Also, other works adopted the REST principles for imple-menting WoT-oriented systems. WebPlug [17] is a frameworkfor the Web of Things that allows users to manage web re-sources representing sensors’ data and compose personal ser-vices based on physical objects. The representation of a webresource is enhanced using MetaURLs, i.e., textual labels thatcan be appended to the URL of the base resource to access somerelated information (e.g., collection of historic values).

Christophe et al. [18] present a prototype framework allow-ing the creation and handling of virtual objects. To validatetheir framework, they also introduce a web application that


PAGANELLI et al.: WEB OF THINGS FRAMEWORK FOR RESTful APPLICATIONS AND ITS EXPERIMENTATION 3

allows end users to access the virtual objects and compose themaccording to basic event-based rules.

Uberdust [19] is a service-oriented platform that providesstorage, sharing, and discovery of real-time and historical datafrom smart objects and sensor networks through the Web. Thesedata can be accessed using REST and WebSocket APIs.

Significant efforts are ongoing to develop a Semantic SensorWeb [20] and integrate it with the growing body of knowledgeavailable as Linked Open Data [21].

SemSense [22] is a system that collects data from physicalsensors and publishes these data enriched with semantic anno-tations on the Web. SPITFIRE [23] is a service infrastructurethat offers the semiautomatic generation of semantic sensordescriptions and efficient search for sensors and things basedon their current states. Applications can issue search requeststo SPITFIRE and then invoke retrieved services, directly.

C. Motivation of Our Work

While most works focusing on semantic descriptions ofsmart things [20], [22], [23] aim at providing efficient searchand discovery capabilities, the scope of our work is to provideusers with tools for accessing and programming the Web ofThings, in compliance with REST guidelines.

Towards this objective, some previously mentioned works[16]–[19] provide tools for speeding up the exposure of RESTAPIs for accessing smart thing capabilities.

The original contribution of our work with respect to theones mentioned earlier [17]–[19] is twofold: 1) the proposalof an information model representing web resources and theirmutual relations and 2) the provision of tools supporting usersin composing, publishing, and sharing the web representationof smart devices, which can be accessed through common webbrowsers. In the context of this study, we consider two differenttarget users: 1) developers of the WoT (developers from nowon) and 2) tech-savvy users with rudiments of web technologies(users from now on). In Section III-C, we will discuss toolscreated for both categories. Finally, the term end user will referto people without particular domain competences, e.g., ordinary“Web surfers.”

Our work shows more similarities with AutoWoT [16] sinceboth adopt a Web Resource model and provide services sup-porting the exposure of smart devices as web resources. How-ever, a significant difference exists in the modeling approach.The AutoWoT resource model relies solely on a hierarchicalrelation among resources; consequently, a physical thing isrepresented as a hierarchical collection of web resources. Weargue that a mere hierarchical relation is not fully compliantwith the REST hypermedia constraint (i.e., reference linksamong resources drive the application state evolution and shallbe advertised by the server at each interaction step). Since, as ar-gued by Vinoski, “relationships between resources and how theserver makes those relationships available to applications areat least as important to REST developers as resource naming,”our approach relies on a graph-based model that includes twomain types of relations among web resources (i.e., aggregationand reference). Purposely, these relations recall how, in fact,web resources are organized and can be navigated in traditional

web sites. In addition, InterDataNet (IDN) is natively capableof handling sets of resources, and this has the following impli-cations: 1) using the Web Resource REST resource exposed bythe middleware it is possible to perform aggregated operationson graphs, e.g. to retrieve, create or update more vertexesat the same time; and 2) the Web Resource model describessets of Nodes (at the limit, made of one element only) andis particularly suited for hosting properties which are stronglyaffected by information aggregation practices, such as privacy.Moreover, unlike AutoWOT, the IDN model offers a scriptableNode, called Activity Node (see Section III-A), which is ableto perform processing operations on other Nodes’ contents andoutput the computation result. This scenario seems to be verypromising for device virtualization. Leveraging this model, wepropose a set of capabilities supporting developers and usersin representing smart things as Web Resources and composingthem with existing web resources, to build novel applications.

III. WEB OF THINGS RESTFUL FRAMEWORK

Our work aims at leveraging Web principles for making aWeb of Things easy to access and program. Our frameworkprovides tools for easing both exposure and handling of smartdevices (and related information) as web resources. These webresources can be composed with “traditional” ones to facilitatethe creation of web applications and services. This objectiverequires a dedicated adaptation layer mediating the interactionwith sensor and actuator implementation technologies that havenot been designed with the Web exposure requirement in mind.

It is widely accepted that REST is the architectural style forthe Web, and our approach for web resource exposure is basedon its principles. Since the mere adoption of mainstream RESTframeworks does not guarantee the compliance with all RESTguidelines [10], [11], our work aims at helping developers intaking such constraints into account. More specifically, ourframework provides support to the following.

1) Resource type definition and design. We propose a graph-based information model for representing web resources,called Web Resource model.

2) General-purpose software for exposing and handling op-erations on web resources. Our system includes a set ofmiddleware services for exposing web resources througha REST uniform interface.

3) Mapping between web resource representation andlegacy data sources. The middleware is based on alayered architecture that distinguishes the web exposurelayer (dealing with web resource model and representa-tion, content negotiation, and RESTful uniform interfaceexposure) and the layer dealing with storage of dataentities and/or the retrieval from external sources.

4) Programming and Web Publishing tools. These consist ofJava and JavaScript libraries for easing the developmentof web applications for the Web of Things, a web appli-cation allowing users to graphically access, modify, andcreate new web resources according to our model, anda plugin for their rendering and visualization in ordinaryweb browsers.



Fig. 1. First level element hierarchy of the Node data model. Vertical textsspecify whether these elements are used to implement contents or properties.

As detailed in Section III-A2, our information model repre-sents web resources as nodes (containing data and metadata)interconnected through links, to create a browsable graph ofinformation. Our model has two types of structural links: aggre-gation (i.e., containment) and reference relations. Leveragingthe modeling capabilities and programming tools made avail-able by our framework, a smart thing is modeled as a graphof individually addressable web resources handled through aREST interface, at the desired level of granularity. This graph-based representation allows to easily represent smart thingsas sets of nodes that can be interlinked and connected withother resources (e.g., information resources of the “traditional”Web of Documents) to build a growing graph of globallyaddressable information that can be navigated, queried, reused,and composed through a uniform REST interface. Hereinafter,we will consider sensors as smart thing reference examples.

A. Web Resource Model

In the following, a few definitions are given before introduc-ing the Web Resource concept.

Definition 1: A Node is a tuple N = (C,P ), where C is theset of content elements (i.e., data) and P is the set of properties(i.e., metadata) that characterize the content. A nice URI [12]associated to every node is used as a unique identifier.

Definition 2: An Aggregation link is a directed link be-tween two Nodes that represents a container-content relation.The conveyed meaning is the following: The originating nodeaggregates, and therefore contains, the destination node.

Aggregation is a transitive relation: Given two nodes n0 andn1 connected via an Aggregation link departing from n0 andpointing to n1 (n0 → n1), we are implicitly stating that n0

contains n1. As a consequence, given a third node n2 so thatn1 → n2, we can say that n0 contains n2.

Definition 3: A Reference link is a directed link betweentwo Nodes that represents a pointer toward a referred resource(i.e., the destination node). No further meanings are associatedwith Reference links. To better understand the Reference linkrole, it could be somehow compared with the HTML hrefattribute.

1) Node Data Model: The Node data model is made of fourelements, as shown in Fig. 1: ApplicationData, Application-Metadata, StructuralMetadata, and ManagementMetadata.

The ApplicationData is the section entitled to host con-tents, i.e., the information to be consumed or produced byapplications. This section includes Content, ContentSchema,ContentEncoding, and ContentType subsections which wrapthe content itself, the location hosting the related contentschema (if available), the encoding algorithm (e.g., base64),and the content type expressed in multipurpose internet mailextensions type notation [24], respectively. These subsectionsare crucial for supporting content reuse. Indeed, our paradigmis conceived to encourage information reuse, and when a client(e.g., an application) retrieves a Web Resource, it should be ableto handle its contents by choosing proper decoding and parsingalgorithms.

The information contained in the ApplicationMetadata sec-tion can be used for tracing applications’ modifications. Whena client modifies a Web Resource, the Information Historymodule (see Section III-B) runs a versioning procedure to per-sist that Web Resource latest version. These metadata provideinformation about the author of the modification such as therelated time stamp, the identifier of the application responsiblefor the creation, and the author of the resource.

The StructuralMetadata section contains references to Linkelements originating from the Node, and because of this, it takespart in the graph’s structure. For every link type, additionalinformation is provided such as a local name, description meta-data, allowed operations to support the HATEOAS paradigm,and, of course, the referred URI.

The ManagementMetadata section may contain propertiesthat further characterize the Node in terms of licensing, pri-vacy, provenance, time, and versioning. More specifically, theLicensePolicy element may be used to declare the licens-ing policy in force for the Node. The PrivacyPolicy elementbasically states whether the Node contains identifying and sen-sitive information. The ProvenanceManagement element con-tains information concerning the enforced provenance strategy[25], [26]. The TimePolicy element specifies whether the nodeshould be destroyed or invalidated after (or before) a cer-tain date. Finally, VersioningPolicy specifies which versioningpolicy should be applied to the Node.

The Activity section is dedicated to the specification of ascript for dynamically generating contents. A scripted Node iscalled Activity Node and presents special outgoing edges (Ac-tive Links) defining dependences pointing to Nodes containinginputs required for the script computation. When a request isissued for an Activity Node, its dependences are resolved beforeexecuting the script. The output of the script constitutes thecontent information for the current Node to be included in theApplicationData section. In the authors’ experience, ActivityNodes are very handy to represent Web Resources whose con-tent depends on contents of other Web Resources. A significantexample is the Virtual Sensor, which is a nonphysical sensorwhose output is a function of other feeding sensors’ outputs.This is particularly useful to increase the coverage of existingsensors or to define derived measurements, such as the HeatIndex [27] which combines temperature and humidity.

2) Web Resource Exposure: The Web Resource is theREST resource exposed by the IDN and is defined as a directedgraph R(N,LAggr), where N is the set of Nodes (with |N |≥1)



TABLE IWEB RESOURCE URI SYNTAX

and LAggr is the set of Aggregation Links. A Web Resourcehas a single Root Node nR, i.e., a Node with no incomingAggregation Links. A Web Resource representation can containa different number of Nodes, determined by dedicated URIparameters. Nodes are served by resolution levels, taking asreference the geodesic distance [28] from nR.

A URI for a Web Resource has the following syntax:

http://auth/node_name/$pinner_path/-$ccontent_path/$vversion/$rres_depth?keys=vals.

The auth fragment defines the authority as defined in theURI specifications [29], node_name is a path determiningthe name of the current Node, inner_path is an optionalfilter selector specifying which part of the Node is required(e.g., the ApplicationData or StructuralMetadata explained inSection III-A1), content_path is an optional XPath [30]expression targeting specific elements in structured contents,version is an optional parameter specifying which version ofthe Node is requested, and finally, res_depth is an optionalparameter specifying the resolution depth as the number ofhops from the current Node. The content_path parameterrequires an additional explanation: A Node can contain eitherstructured (e.g., XML or JSON) or unstructured (e.g., plain text)data. In the first case, is possible to exploit the underlying struc-ture to offer additional filtering capabilities based on contentelements (for example, if the Node contains a bookstore, it ispossible to filter authors, provided that they are represented inthe bookstore structure). Since it is not possible to make anyassumption on the adopted content format, content_pathmust use a generic syntax. To this end, we used a reduced set ofthe XPath syntax excluding XML peculiarities (e.g., attributesand namespaces). Table I summarizes the fragments’ meaning.

A Web Resource is exposed to external clients through auniform CRUD interface, made of a fixed set of operations:create, read, update, and delete. These operations can bemapped onto HTTP methods: GET reads the resource state,PUT updates the resource state if the resource already existsand creates it if otherwise, and DELETE deletes a resource.In order to keep the interaction with resources flexible, easy,and comprehensive, much effort has been put in making it fullyRESTful. Specifically, three aspects have to be highlighted:First, content negotiation is available for Nodes. The currentimplementation allows a client to request XML, JSON, andHTML representations. As explained in Section III-C4, HTMLrepresentations are produced by a JQuery plugin which requests

Fig. 2. Web Resource representing a generic sensor (Virtual Sensors haveActive links to other sensors while normal sensors have not). Since the WebResource is defined as a graph of Nodes, operations on sets of Nodes areenabled. In this regard, the boxed subgraph shows the Web Resource retrievedwhen a user requests a complete sensor resolution: Not only the sensor Nodebut also all its contents (i.e., all the aggregated Nodes) are returned. Please notethat a complete resolution is triggered by issuing a GET request on the sensor’sURI followed the ending “/” character.

(via AJAX) and processes a JSON representation, generatinga human-oriented version of it. Such strategy is motivated bythe fact that a set of Nodes could have a meaningful visualarrangement that disregards the strictness of the graph structure.This can be seen as an application of the code on demand style[12]. Second, in order to avoid conflicts while updating re-sources, ETags [31] are used to represent their status. Third, asstated earlier, HATEOAS [12] is supported by including in theNode representation links to the next related resources (whetherReference or Aggregation Links) as well as instructions on howto interact with them.

3) Examples: By the Web Resource model, a smart thingcan be represented as a graph of structured information pieces.

Fig. 2 shows a simplified example of a sensor modeled as agraph of Nodes (depicted as circles). These Nodes contain thegranular information (black pins) and are connected by arrowsrepresenting relations. The sensor/id labeled vertex car-ries the content describing the sensor’s characteristics, i.e., de-scriptive information (producer and serial number), capabilitiessuch as the type of sensor (e.g., temperature sensor), and dy-namic information such as battery load percentage. This vertexhas two children (/location and/data_production).The location Node is used to identify the sensor’s geograph-ical position in terms of longitude and latitude, while thesubtree having data_production as root represents thesensor’s observations. In particular, the data_productionvertex contains information on the last measurement date time,and its direct children identified with physical_quantity(i.e., temperature, light, noise, and CO index) contain ac-tual measurement values. Please note that common sensorsand Virtual Sensors are represented by the same model, withminimal modification. In the case of a Virtual Sensor, thephysical_quantity Node is an Activity Node, and edgesto physical_quantity Nodes belonging to other sensorsare Active Links.

Table II provides an example of the uniform interface con-straint applied to the a sensor Node. The API semantics applies

http://auth/node_name/$pinner_path/-$ccontent_path/$vversion/$rres_depth?keys=vals

http://auth/node_name/$pinner_path/-$ccontent_path/$vversion/$rres_depth?keys=vals



TABLE IIIDN REST APIS FOR A SENSOR WEB RESOURCE

identically to every Node belonging to the sensor or virtualsensor Web Resource graph.

B. Middleware

The framework includes a middleware, called IDN, thatoffers capabilities for handling web resources compliant withour model (i.e., Web Resources; see Section III-A2), exposedthrough a RESTful uniform interface.

The core of the IDN middleware is the result of previousworks [32], [33], and it was applied to the development ofRESTful web services in different domains such as health care[34] and management of radio-frequency identification-relatedevents [33].

For the purpose of this work, the middleware core has beenextended in order to accomplish the following: 1) cope withexternal information sources (e.g., sensors, gateways, etc.) in-teroperability requirements and 2) improve both developer anduser support in smart things’ digital representation design andhandling, through programming APIs or web browsers.

The IDN implementation adopts a modular pattern enforcingthe separation of concerns principle. Core modules are VirtualResource, Information History, and Storage Interface.

Virtual Resource is in charge of managing and exposing WebResources. In fact, it exposes REST uniform APIs for accessingand managing smart things’ web representations. These RESTservices can be accessed by end users through web browsers(enhanced with appropriate REST-enabling plugins) or by otherweb applications. As shown in Fig. 3, different Virtual Resourceinstances dialogue as peers to realize a distributed graph of in-terconnected Nodes. In this way, it is possible to reach Web Re-sources spanning different domains from a single access point.

Information History provides versioning capabilities forNodes. This is useful for tracking the history of a resource,supporting cooperation by allowing branching and merging,and enforcing provenance by allowing a thorough inspection ofprevious states. This service is not mandatory and can be dis-abled according to specific application/publisher requirements.

Storage Interface provides data and metadata persistencecapabilities. IDN-specific metadata (e.g., the ones describedin Section III-A) are always persisted in the Storage Interfacedomain, while data can be either native or external. Nativedata are created directly in IDN and are managed by the

Fig. 3. Overall view of the IDN architecture.

Storage Interface persistence service. Conversely, external dataare owned by other sources and are never replicated on theIDN side by default. In order to cope with external data, IDNstores their references (more precisely, IDN stores the refer-ences of interchange resources exposed by the Adapter which,in turn, keeps the mapping toward the external data source).External data require the Adapter mediation to be managedas native resources. Storing references is a good strategy toavoid bottlenecks while dealing with frequently changing data(e.g., sensors’ outputs). IDN applies this strategy also to treathistorical data, whether they are provided by an external datasource or a custom ad hoc service.

Virtual Resource, Information History (which is in an ongo-ing stage of implementation), and Storage Interface have beendeveloped as Java 7 Web Applications running on an ApacheTomcat Application Server. They have been implemented lever-aging the Spring framework [35], Hibernate [36], JAXB [37],and JSP [38] technologies.

The core middleware includes also a Search Service, basedon Apache Solr [39], offering search capabilities for retrievingindexed Web Resources. The Search Service exposes a REST-based search interface for submitting queries based on key-words, time, and/or location parameters. Semantic search anddiscovery is currently under development.

The Adapter is the component that support the interworkingof the IDN middleware with external data sources. Thus, anadapter component contains ad hoc intermediation logic forexposing data and services provided by legacy systems anddevices according to our graph-based Web Resource model. Inthis way, properties enabled by the IDN resource model can beapplied to information originating from outer sources.

The Adapter is also designed with a modular approach andincludes four components: 1) a Notification Manager whichmanages the Adapter subscription to the data source, enabling apush/pull notification service; 2) a Transformer module whichrefines data served by the outer source (e.g., demultiplexing theinformation to achieve a more granular representation); 3) aWeb Resource Manager which assembles the outer informationin a graph structure compliant with the Web Resource model;



and 4) a Translator which translates requests coming from theIDN Service Architecture interface in a communication formatsupported by the data source (e.g., a PUT request to the IDNService Architecture could map to a POST request to the datasource).

Basically, the Adapter is thought to be connected to ser-vices exposed on the Web such as WS-∗, REST, RDF, and soon. However, there are no theoretical problems to connect itwith different data sources. Indeed, the Adapter is an intrinsiccustomizable component, and different configurations can besupported by different Adapter instances. The Adapter canbe semiautomatically configured in terms of communicationinterface toward the data source (e.g., by exploiting interfacedescriptions such as WSDL) and Web Resource modeling ofexternal data (e.g., by exploiting relational database schemas tobuild the graph model).

C. Programming and Web Publishing Tools

To fully exploit the features provided by IDN, we also devel-oped a set of tools for easing the use of the Web Resource modeland REST APIs as well as the development of web applicationson top of them. To this end, we provided four tools: 1) a Javalibrary for server-side programming, called IDN Java Library;2) IDN.js, a client-side JavaScript programming library; 3) aweb application providing a graphical interface for designingand managing Web Resources, called IDN-Studio; and 4) IDN-Viewer, a highly customizable jQuery plugin that automaticallyrenders HTML views from Web Resources returned by the IDNmiddleware.

While our Java and JavaScript libraries are thought fordevelopers and provide APIs for easing the interaction withthe middleware as well as Web Resource instance handling,IDN-Studio and IDN-Viewer are conceived to lower the effortrequired by users for creating, modifying, and publishing newresources to be shared with other users and end users.

1) IDN Java Library: The IDN-Java Library providesfeatures for easing the server-side programming of web ap-plications that handle Web Resources exposed by the IDNmiddleware. Its main components are the following:

1) it.unifi.idn.webresource package providing ajava-based internal representation of the Web Resourcemodel;

2) it.unifi.idn.IdnElement class that exposesmethods for manipulating the Node;

3) an IDN client implementation in charge of interactingwith the IDN middleware for performing CRUD opera-tions on Web Resources.

2) IDN JavaScript Library: This library provides a set offunctions for client-side programming easing the interactionwith the middleware and the handling of the returned WebResource representations.

The it.unifi.IDNjs.Manager class defined in thislibrary handles the RESTful invocations to the IDN middle-ware to retrieve, delete, and write single-Node or multiple-Node Web Resources, while the it.unifi.IDNjs.Nodeclass represents the Node and exposes methods for internallymanaging the content, links, and metadata. The offered APIs

Fig. 4. Mock-up of the IDN-Studio application.

are not significantly different than the ones discussed for theJava Library and therefore will not be detailed here. The libraryhas been implemented by leveraging JQuery [40] as a helperlibrary, JSON-js [41] for (un)marshalling document resources,and an AJAX [42] client.

3) IDN-Studio: IDN-Studio is a JavaScript web applicationfor the visual management of Web Resources, providing theuser with a full control over the graph structure and data. IDN-Studio interacts with the middleware through the REST APIsexposed by the Virtual Resource and allows users to create newWeb Resources and delete or modify existing Web Resourcesby adding or removing Nodes, contents, and properties. Asearch form is also available for querying the IDN SearchService in order to retrieve indexed Nodes.

Fig. 4 shows a mock-up of the IDN-Studio GUI that em-phasizes the main operations available (e.g., a search form,buttons for reading, writing, and loading Web Resources, andediting tools displaced on the dashboard). A running instance isavailable at http://idn.dinfo.unifi.it:20282/idnstudio.

4) IDN-Viewer: While IDN-Studio provides a human-oriented representation of Web Resources conceived for easingtheir management, IDN-Viewer addresses the problem of theirrendering on a web browser. Its main task consists in parsing theresources returned by the middleware and, depending on theirstructure, generating rich HTML web pages.

IDN-Viewer is able to choose the proper visualization fordifferent types of content by inspecting the ContentType sectionof the ApplicationData and selecting the appropriate widget.For example, structured contents such as JSON or XML arerendered as tables, images (jpeg, png, etc.) are rendered asclickable thumbnails, and plain text is rendered as is.

More specifically, for each resource to be displayed, theplugin takes its URI as a key parameter and performs an AJAXrequest to retrieve it from the middleware. Then, the returnedrepresentation is parsed, and proper transformation rules areapplied. Moving from the Root Node, an algorithm is run toanalyze the graph of interlinked Nodes. Resources referredby Reference links are organized as menus. The algorithminterprets Aggregation relations differently, depending on thegeodesic distance dj , i.e., the length of a shortest path evaluatedon Aggregation edges between the Root Node nR and the Nodenj . We define a configurable threshold D. Nodes for which

http://idn.dinfo.unifi.it:20282/idnstudio



Fig. 5. Mapping rules in IDN-Viewer. (a) Web Resource representing the “Universidad de Cantabria” PoI, including descriptions, location-related data, and nearsensors. (b) According to information formats, data are rendered as different types of widgets. (c) Contents are finally arranged in the canvas to meaningfully fitthe available space.

dj < D are organized in container elements (e.g., 〈div〉 HTMLelements) and shown on the canvas. If there exists at least onenode nj such that dj ≥ D, a “show more” button is includedin the layout. As the button is pressed, a (configurable) amountof remaining Nodes are loaded and displayed on the canvas.This strategy helps in keeping the Web Resource’s HTMLrepresentation clean, supporting human-friendly inspection byincrementally filling the canvas space.

IDN-Viewer has been implemented as a plugin for the popu-lar JQuery [40] JavaScript framework. It is highly customizableand configurable and is not coupled with any cascading stylesheets framework.

Fig. 5 shows the rationale behind the HTML rendering ofa Web Resource representing the “Universidad de Cantabria”Point of Interest (PoI) [see Fig. 5(a)]. Nodes constituting theWeb Resource are inspected to generate a widget that betterpresents their contents [see Fig. 5(b)]. Finally, elements andwidgets are arranged on the canvas to produce a meaningfulrepresentation of the original Web Resource [see Fig. 5(c)].

IV. EVALUATION

In this section, we describe the experiment carried out in thecontext of the SmartSantander European Union (EU) Project.This experiment, previously introduced in [43], aimed at evalu-ating how our proposed approach supports developers and usersin taking advantage of Web of Things resources and, morespecifically, in designing and developing web applications thatmediate the end-user interaction with these resources.

The main objective of the SmartSantander project [44], [45]was to create a primary European test facility for the researchand experimentation of architectures, services, and applica-tions for the IoT [45]. It consists of a real-world smart citydeployment in Santander (Spain) that offers a large varietyof sensors (e.g., temperature, CO, noise, light intensity, andparking occupancy). Owing to the SmartSantander facility, ourexperiment exploited real-world sensor data.

The experiment description is structured as follows. First, weintroduce MySmartCity, a web application that we developedexploiting our Java and JavaScript libraries. It served as ademonstration of a rich web application that can be imple-mented by developers on top of our middleware. Second, weshow how IDN-Studio and IDN-Viewer enable a user to create,handle, compose, and extend Web Resources that representSantander’s sensor facility. Then, we describe the testing activi-ties aimed at evaluating the user acceptance of the implementedfeatures. Finally, we report on further testing activities forevaluating the performance of IDN.

As an experiment prerequisite, we developed an Adapter forinteracting with the push/pull HTTP-based APIs exposed bythe Santander facility. The Adapter can execute an initializationroutine that does the following: 1) queries Santander APIsfor sensor-related information and parses it; 2) generates agraph of Nodes (i.e., a Web Resource) for each sensor; and 3)commits it to the middleware. These Nodes are stored in thesystem as metadata specifying their characteristics and relationsalong with a reference to the actual real-time measurementprovided by Santander APIs. Once the initialization phase isover, sensors’ data are exposed as a set of URI-addressableNodes, accessible through REST APIs (called IDN SantanderAPIs). In the normal operating phase, the Adapter retrieves up-to-date measurement values from the Santander facility whenrequired by the Virtual Resource/Storage Interface layer (upona request). The Adapter also handles notifications sent by theSantander facility as some events of interest occur (e.g., a newmeasurement value and a new registered sensor).

A. MySmartCity Application

MySmartCity is a web application that allows end users tobrowse sensors, create new Virtual Sensors (such as an HeatIndex sensor close to the end user’s home), and store themin the system for later access. End users can also create WebResources representing PoIs (such as the one introduced inSection III-C4) and enrich them with descriptive information



Fig. 6. Interaction of MySmartCity application with the middleware. Allthe framework components are visible: IDN middleware, Java and Javascriptlibraries, IDN-Viewer, and IDN-Studio. At the bottom is shown the Adaptercomponent interfacing with the SmartSantander facility.

and references to sensors in geographical proximity. Eventually,they can also share them with other end users. A PoI can bepublic (a tourism location and a public transport station) orhave meaning in a user’s personal scope (e.g., user’s home).Both Virtual Sensors and PoIs can be made public by theadministrator, upon a request of the owner.

MySmartCity application logic runs both the client sideand server side. Apart from application-specific details,MySmartCity contacts the IDN middleware to retrieve, update,and manage Web Resources whether they are Sensors, VirtualSensors, or PoIs. To this end, the tools described in Section III-Cproved to be quite handy. Indeed, the Java and JavaScriptlibraries have been used for programming the server and client,respectively, while IDN-Viewer has been used to display ahuman-oriented representation of PoIs, enriching significantlythe user experience. In this context, IDN-Studio played alsoa very important role in redesigning and adjusting Web Re-sources, created through the application GUI. In fact, to modifythe model used for a certain information object (e.g., a PoI), auser can load it in IDN-Studio and visually edit it. With a fewclicks, modifications are committed to the architecture, and theobject is redesigned. Fig. 6 provides a detailed outline of howthe application interacts with the middleware. Programmingand publishing tools are also represented.

B. User-Centric Creation of Web of Things Applications

MySmartCity application allows end users to create andshare new web contents, in a smart city scenario. However, thetype of information that they can add is predetermined by thedeveloper who designed the Virtual Sensor and PoI informationmodels and the related client- and server-side logic.

Hereinafter, we describe how IDN-Studio and IDN-Viewertools enable a user-centric creation of a personal Web of Thingsapplication, by allowing end users to freely modify and handle

their custom Web Resources (i.e., Virtual Sensors, PoIs, andalso new resources defined by the user), publish them on theWeb, and access them through an ordinary web browser.

Through IDN-Studio, a user can access the model of a givenWeb Resource and browse the graph of Nodes by exploringAggregation and Reference links. Leveraging the features pro-vided by the tool, the user may modify the Web Resource’srepresentation, for example, by editing the ApplicationData,creating new links or deleting existing ones. The process ofuser-centric creation of Web Resources for a personal Web ofThings is completed when the “write” button in the dashboardis clicked. This action triggers a sequence of REST operationsfor committing the changes to the middleware (e.g., PUT formodifications to an existing resource).

For instance, a user might be interested in creating a PoIthat aggregates some noise and parking sensors close to hishome. He might also create another PoI at a different location(for instance, his relatives’ home with surveillance and healthsensors) and create a third Node that aggregates these twoPoIs. The URI of this new Node can be seen as the root pageof a personal web application created to easily access andmonitor personal information. Indeed, the newly created andmodified Web Resources are now accessible from standard webbrowsers and can be navigated as plain web pages that havebeen automatically generated by the IDN-Viewer plugin.

C. Evaluation With Users

We conducted testing activities focused on evaluating theuser acceptance of implemented features. More specifically,our objective was threefold: 1) Evaluate the perceived ease ofuse and effectiveness of IDN-Studio and IDN-Viewer tools;2) analyze potential disadvantages, and qualify them (e.g.,major usability problems and technical bugs); and 3) gathersubjective user satisfaction evaluation and possible suggestionsfor future improvements. Please note that Java and JavaScriptlibraries have not been tested in this session, so we are inter-ested in the user profile (see Section II-C).

The evaluation session has been organized as a half-dayworkshop and was conducted with 20 users. Users were se-lected among our colleagues in the Department of InformationEngineering at the University of Florence. The majority ofthem (80%) work in the field of Radar, Remote Sensing andSignal Processing fields and, to our purposes, can be consideredaverage users, while a minority of them work in the fields ofmiddleware and application protocols (10%) and are also expertweb developers. None of them work in the field of IoT or WoTnor have previously used the tools under evaluation. All usersare aged within 30–44 years.

In the first part of the workshop, a member of the experimentteam presented the SmartSantander project, briefly introducedthe tools to be evaluated, and explained the meaning of Virtualsensors and PoI resources.

In the second part of the workshop, the users were asked touse the MySmartCity application and IDN-Studio to customizean existing PoI through IDN-Studio (e.g., by enhancing itsrepresentation with a picture and historic information) andevaluate its rendering performed by IDN-Viewer.



TABLE IIIEVALUATION RESULTS FOR IDN-STUDIO AND IDN-VIEWER

User feedbacks have been collected through interviews anda questionnaire at the end of the evaluation session. Table IIIshows feedbacks provided on the use of IDN-Studio for mod-ifying and enriching the description of a PoI. Users succeededin completing the assigned tasks, and 40% considered the appli-cation intuitive and easy to use. The majority of users providedpositive comments on the visualization of the changes that theyapplied to the PoI on the web browser. Some suggestions weremade to enhance the interface with help texts to guide a first-time user in the use of the tool.

Although these evaluation activities are preliminary, resultsare encouraging and provided useful suggestions for correctingour applications. Since assessing user acceptance is considereda key topic to be investigated toward the Future Internet [46],a more in-depth evaluation of factors relevant to user accep-tance, such as those analyzed by Lizcano et al. [47], wouldbe worthwhile in the near future involving a wider and moreheterogeneous user group.

D. Performance Evaluation

We also carried out testing activities to analyze the perfor-mance of the IDN middleware implementation.

The test environment was deployed on two virtual machines,both equipped with 1-GB RAM and running the Debian 6distribution. These Virtual Machines (VMs) were installed onan HP ProLiant ML350 server with two Intel Xeon quad-core processors, 17-GB RAM, and Debian 6 OS. One VMhosted the IDN Middleware, while the second VM hosted theMySmartCity and IDN-Studio applications.

The objective was to assess the time required by the fol-lowing two main operations: 1) creation of a Web Resource(HTTP PUT request) 2) retrieval of a Web Resource (HTTPGET request). Each operation was performed on resourceswith varying size (i.e., composed by 1, 10, 30, and 50 Nodes)whose application content was stored in the IDN middleware(no requests to external information systems were required). Weiterated each test ten times and measured the elapsing time fromrequest delivery to response reception at the server side.

Table IV shows the truncated mean value of the obtainedmeasurements. It is worth observing that the time required

TABLE IVPERFORMANCE RESULTS FOR THE IDN MIDDLEWARE

for creating or retrieving a Web Resource grows linearly withthe number of aggregated nodes. This behavior was expectedsince sets of Nodes belonging to the same Web Resourceare managed sequentially by the middleware components inthe current prototype implementation. Such behavior can beimproved by implementing parallel processing tasks.

V. CONCLUSION

In this paper, we have proposed a framework for modelingand turning smart things into web-addressable resources thatcan be accessed and handled through a REST uniform interface.The framework is composed of a general-purpose model forweb resources and a middleware that implements RESTful ser-vices for handling these resources through open Web standards.

The proposed model is based on two simple relations(Aggregation and Reference), chosen for their relevance in theWeb domain. Through these relations, a graph of browsable in-formation nodes can be built and extended via a REST uniforminterface. The node can contain locally stored information, datafrom external sources, or content dynamically generated uponscript-based processing.

We showed how digital representations of sensors, VirtualSensors and Points of Interest can be designed and published onthe Web by leveraging our framework capabilities. We providedusers with a set of tools for creating, modifying, and composingthese resources, to build a Web of interlinked “smart” objects.Our target users are developers, who are provided with Java andJavaScript libraries for easing server-side and client-side pro-gramming, and nonexpert users who are provided with the IDN-Studio and IDN-Viewer plugin for creating, composing, andpublishing new Web Resources for their own application needs.

We also discussed the compliance of the current middle-ware implementation with REST constraints, particularly withHATEOAS.

We presented the results of an experiment carried out withinthe SmartSantander FP7 EU project for validating the proposedWeb of Things framework with qualitative and quantitativeevaluations. Users who tested the IDN-Studio and IDN-Viewertools provided good overall feedbacks. Based on these re-sults, some conclusive reflections have been drawn. First, theWeb Resource model has proved to be effective in modeling,handling, and combining smart thing digital representations.



Nodes can be created from scratch with ease and immediatelymade available by the middleware through IDN-Studio or begenerated from external sources (sensors or sensors’ gateways)through an adapter component. Owing to the provided program-ming and Web publishing tools, these Nodes can be managedand further refined, by drawing aggregation and reference linkswith other Nodes, thus updating the corresponding Web Re-source representation served by the middleware.

In the future, we are planning to take into account users’suggestions to improve the ease of use and intuitiveness ofIDN-Studio. It will be also worth extending the IDN-ViewerJQuery plugin for supporting additional rendering models. Sub-sequently, a more comprehensive and in-depth assessment willbe performed with a wider user base.

Another direction for future work would comprise the ex-tension of our middleware with adapter components capable ofinteracting with existing semantic sensor web implementations[20] and the extension of our model to support semantic an-notations specifications, e.g., Semantic Annotations for WSDLand XML Schema (SAWSDL) [48] and Semantic Annotationsfor REST [49]. These extensions are required to enable liftingand lowering mechanisms, opening up our resource graph toadvanced reasoning, discovery, and search services.

To conclude, it is worth noticing that our services willbe kept running for at least three years after the completionof the SmartSantander project. Thus, programmatic access tothe REST APIs and web-based access to the applications foraccessing the existing Santander Smart City resources andcreating new Smart City applications will be made availableupon registration.

ACKNOWLEDGMENT

The authors would like to thank A. Failli and L. Capannesifor their technical support.

REFERENCES

[1] L. Atzori, A. Iera, and G. Morabito, “The Internet of things: A survey,”Comput. Netw., vol. 54, no. 15, pp. 2787–2805, Oct. 2010.

[2] F. E. Group, “Services in the future internet,” Feb. 2011.[Online]. Available: http://cordis.europa.eu/fp7/ict/ssai/docs/softwareconsultationreportfeb2011.pdf

[3] E. Wilde, E. C. Kansa, and R. Yee, “Web services for recovery.gov,”School Inf., Univ. Calif., Berkeley, CA, USA, Oct. 2009.

[4] R. T. Fielding and R. N. Taylor, “Principled design of the modern webarchitecture,” ACM Trans. Internet Technol., vol. 2, no. 2, pp. 115–150,May 2002.

[5] D. Guinard, V. Trifa, and E. Wilde, “A resource oriented architecture forthe web of things,” in Proc. IOT , 2010, pp. 1–8.

[6] C. Pautasso and E. Wilde, “Why is the web loosely coupled?: A multi-faceted metric for service design,” in Proc. 18th Int. Conf. World WideWeb, 2009, pp. 911–920.

[7] D. Guinard, I. Ion, and S. Mayer, “In search of an Internet of thingsservice architecture: Rest or WS-∗? A developers’ perspective,” in MobileUbiquitous Syst., Comput., Netw., Serv., 2012, pp. 326–337, Springer.

[8] D. Zeng, S. Guo, and Z. Cheng, “The web of things: A survey,”J. Commun., vol. 6, no. 6, pp. 424–438, Sep. 2011.

[9] I. Zuzak, I. Budiselic, and G. Delac, “A finite-state machine approachfor modeling and analyzing restful systems,” J. Web Eng., vol. 10, no. 4,pp. 353–390, Dec. 2011.

[10] I. Zuzak and S. Schreier, “Arrested development: Guidelines for designingrest frameworks,” IEEE Internet Comput., vol. 16, no. 4, pp. 26–35,Jul./Aug. 2012.

[11] P. Adamczyk, P. H. Smith, R. E. Johnson, and M. Hafiz, “Rest and webservices: In theory and in practice,” in REST: From Research to Practice.New York, NY, USA: Springer-Verlag, 2011, pp. 35–57.

[12] R. T. Fielding, “Architectural styles and the design of network-basedsoftware architectures,” Ph.D. dissertation, Univ. Calif., Irvine, CA, USA,2000.

[13] L. Richardson and S. Ruby, RESTful Web Services. Sebastopol, CA,USA: O’Reilly, 2008.

[14] C. Pautasso, O. Zimmermann, and F. Leymann, “Restful web services vs.big’web services: Making the right architectural decision,” in Proc. 17thInt. Conf. World Wide Web, 2008, pp. 805–814.

[15] D. Guinard, V. Trifa, T. Pham, and O. Liechti, “Towards physical mashupsin the web of things,” in Proc. 6th INSS, 2009, pp. 1–4.

[16] S. Mayer, D. Guinard, and V. Trifa, “Facilitating the integration andinteraction of real-world services for the web of things,” in Proc.UrbanIOT/IoT , Tokyo, Japan, 2010, pp. 1–6.

[17] B. Ostermaier, F. Schlup, and K. Romer, “Webplug: A framework for theweb of things,” in Proc. 8th IEEE Int. Conf. PERCOM Workshops, 2010,pp. 690–695.

[18] B. Christophe, M. Boussard, M. Lu, A. Pastor, and V. Toubiana, “The webof things vision: Things as a service and interaction patterns,” Bell LabsTech. J., vol. 16, no. 1, pp. 55–61, Jun. 2011.

[19] A. Orestis, A. Dimitrios, and C. Ioannis, “Towards integrating IoT deviceswith the web,” in Proc. IEEE 17th Conf. ETFA, 2012, pp. 1–4.

[20] A. Sheth, C. Henson, and S. S. Sahoo, “Semantic sensor web,” IEEEInternet Comput., vol. 12, no. 4, pp. 78–83, Jul./Aug. 2008.

[21] C. Bizer, T. Heath, and T. Berners-Lee, “Linked data—The story so far,”Int. J. Semantic Web Inf. Syst. (IJSWIS), vol. 5, no. 3, pp. 1–22, 2009.

[22] A. Moraru et al., “Exposing real world information for the web of things,”in Proc. 8th Int. Workshop Inf. Integration Web, Conjunction WWW,2011, p. 6.

[23] D. Pfisterer et al., “Spitfire: Toward a semantic web of things,” IEEECommun. Mag., vol. 49, no. 11, pp. 40–48, Nov. 2011.

[24] N. Freed and N. Borenstein, Multipurpose Internet Mail Extensions(MIME) Part One: Format of Internet Message Bodies, 1996.

[25] G. T. Lakshmanan, F. Curbera, J. Freire, and A. Sheth, “Provenance inweb applications,” IEEE Internet Comput., vol. 15, no. 1, pp. 17–21,Jan./Feb. 2011.

[26] Y. Theoharis, I. Fundulaki, G. Karvounarakis, and V. Christophides,“On provenance of queries on semantic web data,” IEEE InternetComput., vol. 15, no. 1, pp. 31–39, Jan. 2011.

[27] L. P. Rothfusz, “The heat index equation (or, more than you ever wantedto know about heat index),” Nat. Ocean. Atmosp. Admin., Nat. WeatherService, Office Meteorol., Fort Worth, TX, USA, pp. 90–23, 1990.

[28] J. Bouttier, P. Di Francesco, and E. Guitter, “Geodesic distance in planargraphs,” Nucl. Phys. B, vol. 663, no. 3, pp. 535–567, Jul. 2003.

[29] T. Berners-Lee, R. Fielding, and L. Masinter, “Rfc 3986: Uniformresource identifier (uri): Generic syntax,” The Internet Society, 2005.

[30] J. Clark, S. DeRose et al., Xml Path Language (xpath) Version 1.0, 1999.[31] R. Fielding et al., Hypertext Transfer Protocol—HTTP/1.1, RFC 2616

(Draft Standard), Internet Engineering Task Force, Jun. 1999, updated byRFCs 2817, 5785, 6266, 6585. [Online]. Available: http://www.ietf.org/rfc/rfc2616.txt

[32] M. C. Pettenati, L. Ciofi, F. Pirri, and D. Giuli, “Towards a restfularchitecture for managing a global distributed interlinked data-content-information space,” in The Future Internet. Berlin, Germany: Springer-Verlag, 2011, pp. 81–90.

[33] F. Paganelli et al., “An information-centric and rest-based approach forEPC information services,” J. Commun. Softw. Syst., vol. 9, no. 1, p. 14,Mar. 2013.

[34] L. Bianchi and , “Design of a restful web information system for drug pre-scription and administration,” IEEE J. Biomed. Health Informat., vol. 18,no. 3, pp. 885–895, May 2014.

[35] R. Johnson, J. Hoeller, A. Arendsen, and R. Thomas, Professional JavaDevelopment With the Spring Framework. Hoboken, NJ, USA: Wiley,2009.

[36] C. Bauer and G. King, Hibernate in Action. Shelter Island, NY, USA:Manning Greenwich, 2005.

[37] E. Ort and B. Mehta, “Java architecture for xml binding (jaxb),” SunDeveloper Network, 2003.

[38] H. Bergsten, Java Server Pages. Sebastopol, CA, USA: O’reilly, 2003.[39] D. Smiley and D. E. Pugh, Apache Solr 3 Enterprise Search Serve.

Birmingham, U.K.: Packt Publ., 2011.[40] J. Resig et al., “jquery: The write less, do more, javascript library,”

Disponıvel em http://jquery.com/, Acesso em, vol. 18, no. 4, p. 2009, 2009.[41] D. Crockford, Json in Javascript, Nov. 2010. [Online]. Available: https://

github.com/douglascrockford/JSON-js

http://cordis.europa.eu/fp7/ict/ssai/docs/softwareconsultationreportfeb2011.pdf

http://cordis.europa.eu/fp7/ict/ssai/docs/softwareconsultationreportfeb2011.pdf

http://www.ietf.org/rfc/rfc2616.txt

http://www.ietf.org/rfc/rfc2616.txt

https://github.com/douglascrockford/JSON-js

https://github.com/douglascrockford/JSON-js



[42] J. J. Garrett, “Ajax: A New Approach to Web Applications,” SanFrancisco, CA, USA, Feb. 2005.

[43] S. Turchi, L. Bianchi, F. Paganelli, F. Pirri, and D. Giuli, “Towards a webof sensors built with linked data and rest,” in Proc. IEEE 14th Int. Symp.WoWMoM, 2013, pp. 1–6.

[44] J. M. Hernández-Muñoz and L. Muñoz, “The smartsantander project,”in The Future Internet. Berlin, Germany: Springer-Verlag, 2013,pp. 361–362.

[45] L. Sanchez et al., “Smartsantander: IoT experimentation over a smart citytestbed,” Comput. Netw., vol. 61, pp. 217–238, Mar. 2014.

[46] G. Tselentis, Towards the Future Internet: A European ResearchPerspective. Amsterdam, The Netherlands: IOS Press, 2009.

[47] D. Lizcano, F. Alonso, J. Soriano, and G. López, “End-user develop-ment success factors and their application to composite web developmentenvironments,” in Proc. 6th ICONS, 2011, pp. 99–108.

[48] J. Kopecky, T. Vitvar, C. Bournez, and J. Farrell, “Sawsdl: Semanticannotations for wsdl and xml schema,” IEEE Internet Comput., vol. 11,no. 6, pp. 60–67, Nov./Dec. 2007.

[49] J. Lathem, K. Gomadam, and A. P. Sheth, “Sa-rest and (s) mashups:Adding semantics to restful services,” in Proc. ICSC, 2007, pp. 469–476.

Federica Paganelli (M’07) received the Ph.D. de-gree in telematics and information society from theUniversity of Florence, Florence, Italy, in 2004.

She is a Senior Researcher at the National In-teruniversity Consortium for Telecommunications(CNIT), University of Florence. Her research inter-ests include context-aware systems, service-orientedcomputing and communication, and next-generationnetworks.

Stefano Turchi received the M.S. degree in com-puter engineering and the Ph.D. degree in infor-matics, systems and telecommunications from theUniversity of Florence, Florence, Italy, in 2010 and2014, respectively.

He is currently with the Department of Informa-tion Engineering, University of Florence. His presentresearch interests include distributed architectures,Web applications, information security and privacy.

Dino Giuli (SM’84) received the M.S. degree inelectronic engineering from the University of Pisa in1970 and is a Full Professor in Telecommunicationat the Department of Information Engineering of theUniversity of Florence, Florence, Italy. Since 1996,he has been the Promoter and Scientific Coordinatorof the Ph.D. program in Telematics and InformationSociety. His research activities are focused in thedomain of telematics and environmental monitoringsystems.

Prof. Giuli is an Associazione ElettrotecnicaItaliana member.

本文献由“学霸图书馆-文献云下载”收集自网络，仅供学习交流使用。

学霸图书馆（www.xuebalib.com）是一个“整合众多图书馆数据库资源，

提供一站式文献检索和下载服务”的24 小时在线不限IP

图书馆。

图书馆致力于便利、促进学习与科研，提供最强文献下载服务。

图书馆导航：

图书馆首页文献云下载图书馆入口外文数据库大全疑难文献辅助工具

http://www.xuebalib.com/cloud/

http://www.xuebalib.com/

http://www.xuebalib.com/cloud/


http://www.xuebalib.com/vip.html

http://www.xuebalib.com/db.php

http://www.xuebalib.com/zixun/2014-08-15/44.html
