Advances in electronics nowadays facilitate the design of smart spaces based on physical mash-ups of sensor and actuator devices. At the same time, software paradigms such as Internet of Things (IoT) and Web of Things (WoT) are motivating the creation of technology to support the development and deployment of web-enabled embedded sensor and actuator devices with two major objectives: (i) to integrate sensing and actuating functionalities into everyday objects, and (ii) to easily allow a diversity of devices to plug into the Internet. Currently, developers who are applying this Internet-oriented approach need to have solid understanding about specific platforms and web technologies. In order to alleviate this development process, this research proposes a Resource-Oriented and Ontology-Driven Development (ROOD) methodology based on the Model Driven Architecture (MDA). This methodology aims at enabling the development of smart spaces through a set of modeling tools and semantic technologies that support the definition of the smart space and the automatic generation of code at hardware level. ROOD feasibility is demonstrated by building an adaptive health monitoring service for a Smart Gym. For example, a United Nations report  estimateSmart Dust paradigm [etc.). In particular, in this paper we refer to smart object as “a computationally augmented tangible object”, that is “aware” of its own situation as participant of an ecosystem . This “minimum intelligent unit” is characterized by a set of behaviors, communication capabilities and interaction methods with peers and real-world entities, and may play many different roles within those smart spaces, performing individual or collective objectives.Among the many technological challenges involved in the evolution of smart spaces, the roadmap for Micro-Electro-Mechanical (MEMS) technologies is especially relevant; in the last decades, they have evolved towards a wide and inexpensive catalogue of small nodes equipped with wireless interfaces as well as sensor and actuator devices, although they are still far away from the ideal paradigm . In any Together with the increasing availability of sensor and actuator embedded devices, novel software paradigms to facilitate the integration of these devices in collaborative environments are handling both “horizontal” and “vertical” planes. The “horizontal” plane is characterized by Machine-to-Machine (M2M) interactions that refer to the communication between devices’ functionalities. These M2M interactions are being supported by a recently research field that tries to solve the communication according to IP-based networks, that is, the Internet of Things (IoT) . The IoTreal-world services. Thus next steps require developing sound methodologies to improve some links in the development chain of IoT and WoT and to optimize the cost of spreading smart spaces. In particular, there is still a need for technologies that enable the deployment of real-world services by abstracting the specificities of the enabling devices: up to now, any developer who wants to address the deployment of a smart space still needs to have strong knowledge on general and specific technology aspects as communication protocols , platforms of wireless sensor and actuator networks (WSANs), specific programming languages, service discovery mechanisms, or security procedures, among others.Nowadays, both IoT and WoT concepts are being developed under researches in diverse fields  with the final purpose of developing technology to allow isolated “islands” of sensor and actuator devices to be part of a connected network of heterogeneous smart spaces. In a future, smart spaces composed of hundreds, even thousands, of Web-enabled smart objects, will become omnipresent entities providing resource that was defined at the beginning of the 2000s in [Some Internet-oriented approaches facing the problem of facilitating device-layer abstraction include the use of Web Services (WS-*) based on Service-Oriented Architectures (SOA). This orientation is often used for stand-alone infrastructure-based designs, but it reduces its performance and functionalities when applied to resource-constrained devices . Newer 2000s in , support2000s in ,14.The ROA client-server design principles are characterized by their simplicity and versatility due to its technological base, highlighting addressability of resource through the Universal Resources Identifier (URI) scheme, and Hypertext Transfer Protocol (HTTP) to define methods to access and interact with resources. Despite its promising characteristics, existing platforms do not still fully decouple the device layer from the service layer.abstracting every part of the system through high-level models independently of the underlying software and hardware technologies.decoupling consumers and providers of contextual resources , enabling a real reuse of model artifacts and software components.providing a modeling framework to facilitate rapid and agile prototyping of complex deployments even for non-expert developers.For this reason, some research works are addressing domain-specific development frameworks based on patterns and models since they can reduce costs and deployment time and increase scalability in large deployments of smart spaces. A recent trend on this field is betting on the Model Driven Engineering (MDE) principles –17 with i.e., interactions, participants, resources, and platforms. The ROOD methodology involves two models that are instances of the SsML: the Smart Object Model (SOM) and the Environment Context Model (ECM). The ECM is focused on describing high-level behaviors, interactions and context information of the entire smart space. On the other hand, the SOM model defines the processing aspects related to the sensing and actuating capabilities of the smart objects, as well as the context model they manage; moreover, SOM models encapsulate these concepts into RESTful resources [Smart Space Ontology (SSO) includes every concept needed to conceptualize a smart space populated of smart objects according to their sensing and actuating capabilities, that are offered through RESTful interfaces.The research presented in this article takes advantage of the MDE principles to build a holistic development methodology involving a common, semantically expressive abstraction model, to specify a smart space with its specific services. The initial motivation was to provide a versatile solution to facilitate the development of different smart spaces service scenarios, to be composed of heterogeneous sensors, actuators and logic processors interacting among them through a variety of mechanisms. From that ambitious point of view, we propose the Resource-Oriented and Ontology-Driven Development (ROOD) methodology, which improves traditional MDE-based tools through semantic technologies for rapid prototyping of smart spaces according to the IoT and WoT paradigms. With the aim of providing expressivity to the ROOD's models, we have designed a Unified Modeling Language (UML) profile , so callesources . Both moThe rest of the paper is structured as follows. Section 2 gathers relevant works on approaches for modeling services and resources in IoT and WoT. Section 3 presents major research challenges analyzed from related work and how they are tackled by our proposal. Section 4 describes an overview of the major features of the ROOD methodology, focusing on its design principles. Section 5 presents the guidelines of ROOD methodology along its different stages. Section 6 describes first results from an early implementation of ROOD based on a Smart Gym deployed on a Smart Hotel. Section 7 concludes the paper with future work.2.The analysis of the state of the art of development methodologies shows some interesting proposals providing applicable ideas to construct a holistic methodology for smart spaces. However, to the best of our knowledge, no one addresses the development of specific Model-Driven methodologies to support the design and deployment of smart spaces by modeling from the scenario context to its business logic, and ready to be subsequently deployed on a ROA. Additionally, with regard to semantics, few authors have integrated ontological technologies to support model transformations or validations in Model-Driven approaches, even if there is an increasing interest on the topic. Trends that integrate ontologies with Software Engineering   MDE-based methodologies for integration with service oriented architectures, semantic models, and model transformation; (ii) ontology-driven approaches for software engineering and semantic approaches to model smart environments; and (iii) Resource-Oriented approaches to develop and deploy REST resources within the WoT paradigm.As it was described in the previous Section, our proposal needs to consider synergies among different technological and research topics. This way, we have organized the following review of the 2.1.open and vendor-neutral approach to tackle complex business systems. The MDA specification places emphasis on a layered process, using different viewpoints. In MDA, a viewpoint on a system is a technique that provides a way of representing functionalities of a system through interfaces and specific design patterns, which characterizes the behavior and business processes of any application deployed on a platform without concern for technical details. A platform is a system or set of subsystems in which software artifacts are launched on. MDA proposes three kinds of viewpoints stratified in three models: (i) Computational Independent Model (CIM), (ii) Platform Independent Model (PIM) and (iii) Platform Specific Model (PSM). These models have to be machine-readable so that they are successively transformed into code stubs, schemas, test harnesses, and deployment scripts for diverse platforms [Model-Driven Engineering (MDE)  is a genlatforms . OMG prolatforms . Domain triggers to express the stimulation of responses and transactions that corresponds to partition activities in UML. This characteristic of MARTE is very useful to model behavioral aspects of smart spaces, including actions to collaboratively carry out an objective.The design of our SsML is inspired by some UML profiles supported by OMG. Some features of the SoaML (Service-oriented architecture Modeling Language) , which sbusiness view of the system, and a PIM, that models the information system view. SOD-M defines a complete methodological approach to define mappings with the aim of detecting errors and inconsistencies on models that allow supporting an enhanced alignment between CIM and PIM. Although this approach clearly defines the phases of a MDA methodology, it is not suitable for a WoT-based system since SOD-M is constrained to SOA for Web-based information systems that, as previously said, contravene some requirements of embedded environments such as lightness in information transactions.Apart from stand-alone tools for modeling system artifacts, MDA's development principles have motivated some research works considering the whole development process, from CIM to PSM; these works involve meta-models and transformations between the three modeling stages. In  a model-Few MDA approaches are focused on improving model-driven development through semantic technologies for supporting heterogeneous deployment scenarios and platforms definition. The authors of  state thet al. [Katasonov et al.  propose et al. [Walter et al.  present Other MDA-based approaches ,31 take et al. [et al. [In line with MDA approaches, and closer to WoT field, Rauf et al.  propose  [et al.  propose The Model-Driven approaches previously analyzed are generalist and their major foundations can be taken into account when designing new MDE-based approaches. However, regarding modeling of smart spaces, there are many drawbacks that need to be tackled through specific solutions, which solve semantic descriptions and mechanisms to achieve the integration of smart spaces into the WoT paradigm. These major issues are analyzed next.2.2.i.e., regarding standards, data formats, protocols, etc.) to semantic interoperability.Several works support the use of semantic technologies to overcome the limitations of contemporary standard-based and embedded devices for smart spaces  of semantic models is their ability to be reused and shared: to date, several works modeling smart spaces include standard (or well-known) ontological models. For instance, OWL-Time  and Geo-i.e., systems, sensors, devices or services). In this research area, the Open Geospatial Consortium (OGC) is building momentum. The OGC founded the Sensor Web Enablement (SWE) initiative with the aim of designing a set of standards for the development of a geo-located and interoperable Sensor Web. Some of its results are already considered as standards, e.g., SensorML for describing processes within sensors and observation processing systems. A research work related to OGC's approach is the Semantic Sensor Network (SSN) ontology [et al. [It is important to highlight the results generated from standardization groups that are focused on semantically modeling specific concepts which may be applied to smart spaces  into a WoT perspective. This framework specifies the semantics of connected objects supporting flexible configurations for different scenarios. This feature allows creating Web-enable objects by exposing their functionalities as RESTful services, as well as composing sets of objects in order to offer advanced services. They also provide an object browser whose major features consist of discovering objects and requesting associated services via PC or Smartphone.In the line of our previous works, Christophe et al.  propose Some other Resources-Oriented Frameworks are based on toolkits that facilitate the development and deployment of RESTful applications for the WoT. AutoWoT  aims at 3.challenge 1)Reusability and importability Modeling constraints and semantics Role coordination Integration into IoT and WoT User-centric programming  tool focused on increasing the productivity while decreasing the learning effort of a DSL.challenge 6)Assistance to verification procedures  when developing and deploying large and complex smart spaces. To integrate previous works, we analyzed the existing literature in order to show how the considered challenges have been addressed to date. The result of this analysis has been gathered in a comparative table see .et al. [et al. [challenge 3).From the comparative analysis, it is noted that related works do not provide a holistic approach we aim at delivering through our proposal. The works of Walter et al.  and Kata [et al. , which achallenge 1). On one hand, these DSLs allow defining the behavior and contextual activities of smart objects from a high level point of view. On the other hand, they enable modeling tools to define functional aspects of business processes from a low level point of view, associated to the previously modeled behaviors.In order to design a canonical MDA approach, we specified a set of novel DSLs to model different aspects . This feature is supported by means of an ontological resource: the Smart Space Ontology (SSO). The specification of SSO was inspired on previous works as OWL-S or SSN. Specifically, SSN was used as upper ontology to define an essential part of SSO; a novel technique has been used in order to merge already defined ontological resource in SSN and new semantic structures in SSO. Essentially, our approach uses SSO with the purpose of describing specific smart space domains and verifies ECM and SOM models according to those semantic descriptions. This approach differs from other ones trying to extend meta-metamodels, metamodels and, even, models with semantic technologies  to verichallenge 4). This feature facilitates the convergence between embedded pervasive networks previously disconnected among them [Another improvement provided by ROOD methodology with regard to previous MDE-based approaches . The main processes performed by the ROOD toolkit consist of user guidance during modeling, both at CIM and PIM levels, that ensure well-formed models according to the restrictions and constraints defined by metamodels . Besides, it allows verifying the consistency of models according to the domain specification stored in the KB of the smart space. The following Section provides a detailed overview of the ROOD methodology.Finally, ROOD methodology provides a toolkit based on graphical modeling , that makes easier the development and deployment of smart spaces independently of their dimension and device heterogeneity : the methodology has to provide the guidelines and tools to model the workflows that characterize the behavior of the smart system from their high-level description, to the subsequent alignment of those models into information and processing ones, closely related to the sensing and actuator platforms currently available at the market .The improvement of traditional MDE approaches, particularly of those focused on MDA, by semantically supporting each development phase : the methodology has to provide a set of models extending from CIM level to PIM and PSM levels, and specific semantic technologies based on ontological resources that allow conceptualizing different aspects of the system to be developed, in order to verify the consistency and integrity of models in each stage, as well as supporting bilateral transformations.The integration of smart spaces based on Internet of Things principles  into the Web of Things  : the methodology has to be able to automatically generate the artifacts providing RESTful services, that are to be deployed on embedded networked devices or gateways encapsulating specific embedded platforms.ROOD methodology provides the guidelines to develop smart spaces under an Internet-connected resource-oriented approach (following the paradigm of the WoT). In ROOD, a Successfully addressing these objectives implies applying concepts from a number of different technical fields related to software engineering, semantic technologies, and pervasive embedded networks, among others.contextual activities, which specifies the behavior of the resources  used within a smart space and the relationships among them, and (b) the smart object, which provides a deployment perspective of the system involving information and processing models characterizing sensor and actuator entities within the smart space and its association with RESTful services. These views can be linked to the CIM and PIM levels of a typical MDA-based approach, respectively. The ROOD methodology includes models related to both levels that encompass the mentioned features: (a) The Environment Context Model (ECM), and (b) The Smart Object Model (SOM). These models are instances of a DSL, the Smart Space Modeling Language (SsML) that was designed as an UML profile. Additionally, the modeling processes concerning those models are enriched through semantic technologies; concepts represented both in ECM and SOM are aligned to semantic contents that are stored in Knowledge Bases (KB) and defined according to an ontology called Smart Space Ontology (SSO). In that way, the ROOD methodology takes advantage from ontological resources to verify the completeness and consistence of ECM and SOM models according to the semantic description of the domain system; consequently the verification mechanism optimizes the model-to-model transformation processes from ECM to SOM.The ROOD methodology addresses the development of smart spaces from two different perspectives: (a) the In the following sections, an overview of the principles and architecture of the ROOD methodology is firstly provided by means of an explanation of every part of its architecture as well as the phases involved in it. Firstly, the model-driven foundation of the ROOD methodology is explained, including the UML profile, in which the SsML is based, as well as its instances, ECM and SOM. Secondly, an explanation of how semantic (ontology-based) technologies are used along ROOD methodology is provided. Finally, a complete description of the stages of the ROOD methodology is given.4.1.In this section we give a brief description of the features of the Smart Space Modeling Language (SsML). The SsML is a UML 2 profile whose major objective is to support the two main models of an MDA-based methodology, CIM and PIM that, in ROOD, correspond to the aforementioned ECM and SOM, respectively.OMG has standardized some UML profiles that deal with real-time embedded devices ,53 and sThe definition of SsML depends on the MDA architecture that is stratified in four abstraction levels (M0 through M3). M0 contains instances of data for a specific platform; M1 is where the system's models are defined; M2 specifies the DSLs that take part in the definition of models at M1. Finally, M3 defines the Meta-Object Facility (MOF), that establishes the basis for different modeling languages.In summary, ECM and SOM provide a set of modeling tools enabling ROOD methodology to build complex smart spaces from two different viewpoints. As said before, the viewpoints defined in both ECM and SOM correspond to the CIM and PIM of the MDA. From those viewpoints, instances of the smart space can be defined through models that are represented in the form of diagrams with a specific notation. In ROOD methodology, the drawing schema of the diagrams is restricted by the constraints specified in specific viewpoints. Moreover, domain concepts represented in those diagrams are validated through semantic technologies supported by ontological resources that determine what can be represented according to the participants belonging to the smart space  and to the functionalities they can provide or consume . Such semantic information will be stored in Knowledge Bases and will depend on an ontological resource, as shown in Section 4.4. In the following sections we describe the ECM and SOM and all the pieces of the SsML metamodel, which establishes some modeling constraints for each one of them.4.2.the sequence and conditions for coordinating lower-level behaviors [According to the MDA specification, CIM models are used to represent the environment and the requirements of the system they model, without referencing any detail about the implementation of the internal processes and tasks . The ROOehaviors . They arehaviors .i.e., the modeling of interactions between business processes and the interchanged data involved in the environment to be modeled, independently of the platform which will be used to deploy the defined processes. We consider that the activity diagram, as it is defined in UML 2.2 Superstructure [Anyway, the characteristics of UML activity diagrams do not properly tackle the objectives of CIM as established in the MDA specification, tructure  does nottructure , in ordestereotype is the most common extension mechanism provided by the UML 2 specification. Stereotypes are used to expand the core elements of UML in order to extend and classify associations, inheritance relationships, classes, and components. In this case, the extension of the activity packages, as it is shown in package merge. The usual method for defining UML profiles extends language units residing at L2. However, SsML extends language units residing both at L1 and L2 in order to gather all the required elements to define enriched activity models.The extension shown in Graphic Nodes, Graphic Paths and Other Graph Elements.A brief description of every stereotype shown in The enhanced semantic provided by SsML is mapped over a visual modeling language that we have named Environment Context Model (ECM). From the UML extension described previously, SsML establishes the foundations for the definition of the ECM, including its syntax and elements involved in an activity diagram for a smart space based on REST communication mechanisms. ECM's viewpoint of the concepts in SsML has been defined in order to establish the constraints that drive the modeling of ECM diagrams. This viewpoint is shown in 4.3.The next stage, according to MDA architecture , correspi.e., it does not modify the existing metamodels. The aim of the SsML profile is to adapt existing metamodels of UML for the particularities of smart space environments. The extension defined by SsML for this purpose is shown in SsML uses UML's general profile mechanisms  in orderStereotypes defining the required concepts for creating SOM are described in i.e., instantiations of the stereotypes are defined in SsML, which in turn defines a specific semantic and syntax. The SOM viewpoint defines several constraints that aim at guiding users to build well-formed models. This viewpoint is represented in In the same way as ECM, SOM is a particularization of the SsML metamodel, Things), specifying the roles played by both participants (Provider and Consumer) and resource interfaces (End-point).SOM is able to model communities of interacting smart objects (Resources are provided by smart objects (Things), which are in charge of implementing underlying services characterizing the resource behavior and its state. Smart objects can host more than one resource.SOM is especially designed to be supported by ROA-based approaches. This characteristic facilitates the generation and deployment of artifacts for RESTful architectures.End-points, which are defined through RESTful interfaces, characterized by an URI, a HTTP method  and message types for inputs and outputs.Resource interfaces are specified through SOM is focused on modeling participants (smart objects) working collaboratively in smart spaces to reach a common objective. The major features of SOM for modeling resources, processes and interacting smart objects are the following:4.4.etc.), where each particular instantiation of these entities can be considered as a deployment scenario. ROOD methodology proposes a semantic-based approach for describing these scenarios, achieving not only a high degree of integrity in their definition but also in the definition of the ECM and SOM models exploiting them. This integrity assurance is mainly supported by the Smart Space Ontology (SSO), which is structured as three sub-ontologies modeling different sets of Smart Spaces entities:The Domain sub-ontology describes the physical characteristics of a Smart Space, populated with Smart Objects managing devices with sensing and actuating capabilities; it is mainly based on an extension of the W3C's SSN (Semantic Sensor Network) ontology .A Service sub-ontology that defines the necessary entities and properties for modeling a service oriented architecture. For example, it defines from composite processes to simple tasks, as well as elements to orchestrate them.i.e., it defines every entity necessary to map smart objects services into RESTful style resources.Finally, the Resource sub-ontology allows encapsulating service functionalities through REST interfaces, As explained above, ECM and SOM offer a set of modeling tools for intelligently describing the relationship between different real-world entities available in the Smart Space domain  that best fits the characteristics of the problem to be solved. The second activity consists of customizing the selected common ontology (or ontologies) according to the domain and to integrate it into the host ontology.Reusing Domain Ontologies: this mechanism is focused on integrating i.e., sub-ontologies), while they are interconnected to each other. Ontology Modularization facilitates the reuse and maintenance of ontological resources.Ontology Modularization: this task consists of identifying those parts of an ontology that can be considered as independent modules . From an exhaustive analysis of the SSN ontology, some drawbacks were found: although SSN provides enriched semantics to characterize sensors, it has no semantics to define actuators and all concepts around them, being essential elements for conceptualizing high interactive smart spaces . Reengineering methods specified by NeOn were used in order to evolve the SSN ontology by adding those new concepts. That evolution consisted of adding classes and relations for defining actuators belonging to a smart space; the extension that conducts such evolution is shown in Taking into account these mechanisms, SSN ontology was selected as a ground model for building the Service and Resource sub-ontologies of the SSO from scratch and to align each other with the Domain sub-ontology. This way, we enabled the SSO to capture and specify environment requirements and to verify the ontology with respect to the requirements it has to fulfill. Those requirements are gathered through a conceptualization analysis of the smart space that is described in Section 6.2.NeOn Methodology was also used to specify the hasDeployment and hasLocation properties are used to relate SSO entity SmartSpace and SSN ontology. Apart from the extension depicted in SmartObject is built on a specific ssn:Platform (onPlatform property) and it is composed of several kinds of ssn:Devices (hasDevice property). The Service sub-ontology is aligned with the Domain one by means of Participant entity (integrates property), which relates SmartObject (and their ssn:Sensors and Actuators) to business Process managing low level Tasks. Resource is the main class in Resource sub-ontology; this class is directly linked to sensing and acting processes offered by Provider agents in the Service sub-ontology.The major entities included in each sub-ontology of the final version of SSO are presented in The abovementioned semantic models have been developed as OWL-based documents; each particular deployment scenario to be used at ECM or SOM level would need to be built as RDF triples based on these documents, conforming a specific deployment scenario Knowledge Base (KB).sso:prof1 and sso:prof2) to the same smart object (sso:smartObj1) but a cardinality restriction set in SSO states that each smart object must have just one profile . Besides detecting these inconsistencies, recent researches address explanations generation that can be used as a guide for ECM and SOM models designers [This semantic modeling of the deployment scenario for smart spaces brings several useful advantages for the MDA methodology (both at CIM and PIM level). Using a standardized language (OWL) and integrating existing and well-known models improve the compatibility of ROOD methodology with other semantic tools. It also guarantees consistency of the deployment scenario entities used in ECM and SOM, as general purpose reasoners can be invoked in order to support semantic engineers during KB filing (satisfiability checking according SSO schema), and business and software engineers during model creation (consistency checking according KB contents). In this sense, esigners . Figure Regarding this ontology design process, future works may consider also integrating other well-known models as, e.g., OWL-S  for desc5.This section presents the different stages of the ROOD methodology involving the elements of the architecture defined in Section 4. This guideline highlights the traceability between the concepts presented in ECM and SOM metamodels, as well as the mechanisms to verify models delivered in each stage.As discussed in the previous section, any development methodology based on MDA consists of three main phases: i) Computation Independent Model (CIM); ii) Platform Independent Model (PIM); iii) Platform Specific Model (PSM). Along these phases, MDA manages to separate the conceptual design  from the platform features .i.e., behavioral aspects of the system environment), PIM and PSM defines architectural and deployment aspects in order to accomplish the requirements of the system. The ROOD methodology proposes to solve this alignment issue by means of a chain of transformations between ECM and SOM models, belonging to CIM and PIM, respectively.Generally, MDA approaches specify transformation rules between PIM and CIM but just traceability relations between the requirements on CIM models and the concepts of PIM and PSM models. Very often, the own nature of CIM models prevents the creation of direct transformations to PIM models since, while CIM describes functional viewpoints . In The concepts shown in Moreover, semantic technologies play an important role within the ROOD methodology, which take all its potential from the SSO. The SSO was essentially designed in order to adjust the modeling process to specific smart spaces through Knowledge Bases, gathering concrete domain information about different scenarios. The entities specified in SSO are projected on concepts of ECM and SOM models. Those relationships are indicated in Request points in ECM will be transformed into Consumers in SOM, or Context Data Store in ECM will be transformed into Context Manager in SOM. The transformation process can be performed totally or partially, that is, whether the transformation among entities needs total or partial human interventionTraceability relations defined in The ROOD methodology provides a well-specified set of modeling tools and common terminology promoting collaborative work among individuals of heterogeneous development teams without compromising global project resources and efforts. It is important to highlight that the ROOD methodology is flexible and its stages are loosely couple. This characteristic facilitates the involvement of a variety of kinds of professionals collaborating and working jointly in the development chain, e.g., (i) business analyst; (ii) software architect, specialized in ROA; (iii) semantic engineer; (iv) software developer.agents playing two different roles: consumer or providers. Finally, services exposed by smart objects to be consumed by other entities belonging to the smart space are encapsulated into resources, which are defined according to the REST architectural style. The ROOD methodology follows the most accepted REST implementation in which, for each resource, it is assigned a Unique Resource Identifier (URI), one or more HTTP method  and specific formats for input and output messages . The analysis of the domain model described before is to be carried out by semantic engineers supported by business analysts and software architects who collaborate in the definition of the technical parameters to be subsequently collected in the smart space's Knowledge Base.Before beginning with the methodology, it is important to identify each element of the smart space by analyzing the physical places that will be populated by smart objects. Meanwhile, every smart object in such smart space is supported by one or more platforms with a set of sensor and actuator devices; these sensor and actuator devices are responsible for leading the expected behavior to the smart space. Such behavior is conditioned to the business processes and underlying tasks  that are performed by the devices associated with the smart space. In ROOD, these business processes are characterized as services managed by Once the Knowledge Base of the smart space is instantiated, the modeling phase of the ROOD methodology can start. Firstly, business analysts have to model the smart space using the elements defined in the ECM's metamodel. In this stage, only behavioral information of the smart space is represented without concerning the underlying platform, e.g., activity threads, actions, transitions between actions, and smart objects involved in that activity context.The information contained in ECM models is used to partially generate the models in the next stage, SOM, whose construction is conducted taking into account the viewpoint described in Section 4.3. This stage should be managed by software architects specialized in resource-oriented architectures, who will take advantage of the information from the ECM to model agents (providers or consumers of services), business processes and tasks. Moreover, it will be needed to set up the information system to manage context information that will have an influence in the current and future behavior of the smart objects. Finally, the involved software architects will design the necessary architectural elements that will offer the smart object resources as RESTful services. This step will provide the key piece to integrate the smart space into a WoT paradigm.The models created in previous steps will be subjected to a verification process to check the consistency and integrity of the entities, relationships and other semantic information represented in them according to the domain information stored in a scenario Knowledge Base.The final step consists of generating program code from SOM models. For this aim, the elements represented in SOM models are filtered through a model-to-text transformation mechanism. The percentage of generated code can vary depending on the platform but in any case, it will be totally generated. Therefore, a software developer is required to complete existing gaps in the code .It is important to highlight that the transformation specified in the ROOD methodology (ECM-to-SOM and SOM-to-PSM/code) is conducted by mapping rules that in some cases are almost automatically generated and only partially automated in the remainder cases.6.ROOD has been partially developed to support research in a large Spanish cooperative project named Technologies for the Hotel of the Future (THOFU Project) . Among iMotivation Scenario: the smart space used to demonstrate the feasibility of ROOD methodology is a smart hotel. This smart space may be abstracted as a composition of private and common spaces populated with a physical layer of structural, stationary and mobile smart objects, which connect to a virtual augmentation service layer handling services from different providers. People with different service needs and privacy spheres will be users of the smart hotel. With respect to its structure, the hotel has a lot of differentiated areas: rooms, restaurants, welcome zones, common areas such as corridors, stairs or elevators, parking spaces, outdoor spaces, sport facilities, operational zones , convertible meeting rooms, etc. In all of them, pervasive technology may facilitate the delivery of adaptive services and personalized attention to the visitor, and may help to monetize and optimally manage the available resources.smart indoor gym by means of the modeling tools provided by the ROOD methodology. Our smart indoor gym will be ready to support a wide range of behaviors and services: (a) visitor seamless identification; (b) personalization of the training session; (c) user's performance monitoring, for posterior personal evaluation and provision of health/nutrition tips; (d) immediate alert to medical services if an unexpected emergency situation occurs; (e) persuasive entertainment throughout the training session; (f) marketing meaningful resources through non-invasive interfaces  or (g) control of the ambient parameters of the space for optimal service and sustainability.For this case of use, we have chosen to prototype a medical alert service, which monitors the user's health status and detects and reacts to potential emergency situations.As a whole, the smart indoor gym makes a complex networked infrastructure in which a number of smart objects are involved, consuming and providing many resources related to the user and environment's contexts. In order to simplify this case study, we will focus on a single service to be provided in the smart indoor gym: the The following section describes the development process of this service in the smart gym, through the stages proposed by ROOD methodology to model the entities managing the behavior and resources of the involved smart objects.6.1.smart gym to guarantee the healthy practice of physical activity. This service stays completely hidden to the users, since it works in background without needing human intervention. This service is associated with vital signs or activity data from the user, which are analyzed through a smart object called personal trainer. The global mission of the personal trainer is to sketch a safe and adaptive work out plan for the user. On the one hand, this smart object can connect and collect data from different biometric sensors, gathering information such as heart rate, body temperature, body humidity and activity. On the other hand, the personal trainer manages a user profile with information about the user's physical condition and health history. These data can be merged with real time ones for different purposes. Additionally, the personal trainer can interact with those exercise machines in the smart gym.The alert medical service is a basic service, which has to be provided by the smart T-shirt (with a biometric belt embedded in it). The smart gym offers to the user the possibility of exercising on a smart treadmill. As previously stated, the personal trainer is capable of managing this smart training machine, being able to configure its performance according to the current health status of the user. When exercising, if the personal trainer discerns that the user suffers a sudden change in the vital parameters retrieved from the T-shirt  or that an abnormal situation, detectable through the inertial sensors in the T-shirt occurs—e.g., a fall, it generates an alert. In this circumstance, the treadmill is managed to slow down to stop and simultaneously, the notification is forwarded to the medical staff of the smart hotel through an emergency manager infrastructure component, which has its counterpart in the medical staff's smartphone.Let us now focus on the emergency detection functionality supplied by the personal trainer. In our validation scenario, when the user enters the smart gym, the personal trainer is downloaded and installed in his/her smartphone; once it is started, it asks for permission to share the user's health profile with the smart gym service. Then, the user is equipped with a personal trainer, composed by the data processing logic to determine if an emergency has occurred from bio and movement signals; it also has activity inference capabilities, to match the health status to the user's movement and detect falls [smart T-shirt, equipped with the following sensors: heart rate, body temperature and posture/movement inertial sensors; it just hosts the signal processing logic to extract the main features from the signals, which are fed into the personal trainer logic; (iii) a smart treadmill, equipped with an embedded platform that performs basic management tasks on the treadmill mechanisms and shown messages; it is managed directly through the personal trainer and communicates its state to the infrastructure; (iv) infrastructure services: a client contextualizer, which manages a data base to store user information, in particular about health profiles and health reports for this specific scenario; emergency manager, which forwards the alert information to the medical staff's smartphones; (v) a gateway, as a component of the Acquisition Platform , which manages the scenario sensing heterogeneity. The gateway provides a middleware layer for orchestrating the smart objects belonging to the smart hotel, independently of their communication protocol. Components deployed on the Acquisition Platform have to provide their functionalities as resources according to a RESTful architectural style in order to preserve the interoperability among elements of the smart space developed by means of ROOD methodology.In short, the components involved in the scenario are the following : (i) a pct falls ; (ii) a Once we have a concise description of the smart space for our case study, let us continue with the practical demonstration of the ROOD methodology in order to prove its feasibility. The following sections describe the modeling process, from ECM to SOM and program code, to develop the alert medical service according to the features specified before.6.2.Smart Space Ontology (SSO). To this aim, we need to carry out a detailed semantic analysis of the smart space in order to generate an enriched Knowledge Base (KB) of the smart scenario. A well-defined KB will allow fixing the development methodology to a specific scenario and, consequently, to improve the verification and transformation mechanisms during modeling stages. We have designed some guidelines in order to achieve an optimal KB for collecting accurate semantic information; it is not a mandatory to follow these guidelines but they can facilitate the semantic analysis of the smart space. These guidelines, adapted to concepts defined in each module of the SSO (Section 4.4), consist of the following three major procedures:Analysis of the domain aspects: This phase encompasses the analysis of those elements building the infrastructure, enabling the smart space to manage the context information necessary for it to deliver its services. In this phase, we need to define the deployment scenario and the physical components in it , and the low-level sensing and actuating processes to be performed.Analysis of the service aspects: This phase encompasses the identification of logical components, which adopt two different roles (consumers and producers), as well as the major business processes that they execute. In this phase, we need to identify concepts as the agents involved in expected behaviors of the smart space, and the processes that manage the context and its associated knowledge within the smart space.Analysis of the resource aspects: This phase encompasses the identification of resources associated to the processes executed by agents playing a “provider” role, which have to be exposed to external entities in order to be accessed according to a REST architectural style. Thus, it is necessary to formalize those resources taking into account three elements: i) Unique Resource Identifier (URI), ii) one or more HTTP methods , and iii) specific formats for input and output messages.Semantic technologies are a cornerstone in ROOD methodology. As said in Section 5, previously to start the modeling phases, it is essential to carry out a conceptualization analysis of the smart space; this initial analysis allows to achieve good semantic information of the smart space according to the Following the aforementioned guidelines, 6.3.As described in previous sections, this stage is intended to model the behavior of the smart space. In order to create models in this stage, we have to use the elements defined in the metamodel specified by the Smart Space Modeling Language (SsML) that are associated with those behavioral aspects of smart spaces see . MoreoveThe ECM proposed for this case study is shown in the i.e., storing and retrieving of health reports and notification of alert messages.Two smart objects, the smart treadmill and the personal trainer, actively interact each other and the latter interacts with the client contextualizer and the emergency manager as well. The last two entities depend on the designed behavior of the smart treadmill and the smart trainer from which they will get context information leading a specific response on both, ResourceActivity in the SsML metamodel). Those activity partitions represent execution threads that can be performed in parallel. Additionally, activity partition can contain event sensitive regions  which focus on performing actions until the occurrence of a specific event. For example, the personal trainer defines three activity partitions for managing biometric and activity sensors, and a health status analyzer. The last defines a Sensorial Activity Region in order to gather and analyze vital and activity signs of the users. The condition to leave this region is to detect an abnormal value in the health report  that generates an alert that has to be notified to the treadmill and emergency manager, if the alert is related to an emergency; otherwise, the health report is stored in a data base of users and a health status analysis will be carried out again after passing a period of time when new values of vital signs will be measured. In case of detecting a critical situation for user health, the emergency manager shows a message to the medical staff.Actions characterizing the behavior of entities in the ECM are defined within activity partition , related to the user's health . Using ECM, this communication process is modeled as follows: (1) the smart treadmill offers a resource by means of a Resource Point that links to a Request Point coming from the personal trainer; (2) A REST-based query sent from the personal trainer to the smart treadmill is defined through the element Send Query Action that define a method and a URI of the specific resource; (3) An input or output Message Type is included to define the specific format and string to be attached to the query.This ECM also models interaction aspects between different smart objects and other entities of the smart space. As said in previous sections, in ROOD methodology, interactions are modeled according to a REST architectural style. Thus, situations in which actions cause a behavior on other entities need to be modeled following the general rules that characterize resources in a REST architecture. For this purpose, SsML metamodel provided elements to model RESTful As shown in On the other hand, ECM model has to be defined according to the viewpoint provided by ECM, which is based on the SsML metamodel. This also guarantees a consistent mapping between the elements represented in this ECM model and the concepts defined in the SOM viewpoint. Consequently, the transformation process to achieve a subsequent SOM model will make better use of the information contained in the previous ECM.6.4.Following the ROOD methodology, the next stage corresponds to the modeling of SOM. As said in previous sections, models generated in this stage are enriched by means of the information defined in models of the previous stage. This is achieved through a model-to-model transformation process whose efficiency depends on the factors commented on Section 5. Thus, in a standard scenario, some artifacts would be available before starting with the modeling of SOM. This facilitates to software architects the design of the SOM models since they will not have to tackle this stage from scratch. The number of artifacts automatically generated will depend on the quality of the KB contents and the design of the previous ECM model. Moreover, whatever the number of artifacts automatically generated is, those will be aligned with ECM entities according to the traceability matrix specified in In order to simplify the explanations of the models designed in this stage, let us consider two smart objects: the personal trainer and the smart treadmill. The final SOM models are shown in RESTInterface classes) or context pieces definition to manage context information (Contex™anager classes). The rest of classes are modeled from scratch and integrated in the model according the SOM viewpoint.In previous SOM models, the classes in grey color are  automated from the previous ECM model; those classes partially generated are colored in light grey. In that case, the software architect has to complete the semantic information according to technical parameters of the smart space, e.g., identification details for defining URIs completely  are concretized in business processes and task (BusinessProccess and Task according SOM viewpoint). Each one of the ResourceActivity in the previous ECM  are mapped on BusinessProcess classes in SOM. Moreover, some Actions and SensorialActivityRegions in ECM can be mapped over Task classes, or even in BusinessProcess classes, in SOM. For example, the Action TreadmillControl in ECM model is transformed into a BusinessProccess class with the same name and semantics in the subsequent SOM.One of the major points in this stage consists of formalizing behaviors modeled in the ECM according to the SOM viewpoint. Thus, actions and activities in ECM  has been modeled for this smart object in order to manage the context information required to perform the processes of personal trainer correctly, i.e., body temperature and heart rate measured in specific instants. There are two activities that are able to provide context information ; this information is then obtained by a third activity of the smart trainer (Alert Generator), that processes such information in order to make quick diagnosis about the health status of the user.Most smart objects populating smart spaces needs to manage information related to their own context and the context of other smart objects and environment. This aspect is considered in the SOM metamodel by means of the ServerResource class, which is associated to one or more interface definitions (RESTInterface class) and a description of that interface (InterfaceDescription). A RESTInterface class defines basic parameters characterizing a RESTful access point, i.e., an URI, a HTTP method, and message types of the interchanged information. The resources modeled in SOM are managed by agents (Provider classes), which would play a server role in a typical client-server architecture. On the other hand, agents that are not enabled to provide resources but able to access resources to modify its state or receive information from it, are modeled through Consumer classes. Those agents would play a client role in client-server architectures.An important feature, to be modeled by means of SOM models, is the architectural aspect related to the REST paradigm. This is a keystone to enable a smart object for integration into the Web of Things. To this end, the SOM viewpoint provides the 6.5.The final stage of ROOD methodology corresponds to the code generation. According to the scenario requirements, this code should be ready to be compiled in some of the platforms characterizing the different devices used in the scenario. Developers of the system will have to tackle this stage by implementing templates that filters the semantic information received from SOM models to transform it into text with sense for a specific compiler. In a canonical MDA approach, those templates are defined as Platform Specific Models (PSM); there will be as many different models as kinds of platforms are deployed on the scenario.The control module of the treadmill: This control module is managed by a SunSPOT [personal trainer. SunSPOT , which iThe smart T-shirt: The platform of this device is provided by a Bioharness™ BT [ness™ BT . This isAs stated in Section 6.2 , the conThe above-mentioned platforms are clear cases of the two kinds of platforms considered in ROOD methodology, Native and Gateway, respectively. The following paragraphs focus on describing on the specific development mechanisms for each one of them.On one hand, the Sun SPOT controlling the treadmill mechanism is a programmable device with constrained resources; it is supplied by small battery (3.7 V rechargeable 770 mAh lithium-ion battery) and includes reduced memory (1 Mb of RAM and 8 Mb of Flash) and processor (400 MHz). Moreover, Sun SPOT nodes use specific communication protocols designed for embedded networks: IEEE 802.15.4 for radio and MAC layers and, in our case, 6LowPAN for network layer.native device in ROOD methodology. The development of software for Sun SPOTs has to be performed according to a reduced profile of Java Microedition (J2ME) and it uses a small Virtual Machine (VM) to execute bytecodes (Squawk). Applications (MIDlets in J2ME argot) deployed on Sun SPOTs have to follow the guidelines provided to develop software for the J2ME framework: those needs to extend the MIDlets class to allow the VM to manage the application lifecycle  during runtime via a concrete interface. Consequently, a developer, who needs to generate software artifacts for Sun SPOT, has to define a PSM that models the J2ME profile (at least the required part for the project) in order to filter the information coming from SOM model and transform it into code corresponding to MIDlets and auxiliary classes, implementing the required business logic. The specification of PSM is described in following section.Sun SPOT can be considered as a Gateway device in ROOD methodology; it is not programmable, thus it does not natively support the deployment of software artifacts. We need an intermediary entity in order to deal with Bioharness™ BT that enables intercommunication with other devices and deploy necessary business logic to manage the gathered biometric information. As said in Section 1, we use an infrastructure entity to tackle this situation: the Acquisition Platform. This platform is based on a middleware build over a RESTlet framework that is executed in a device  equipped with a variety of communication interfaces . The capabilities achieved through our Acquisition Platform are twofold: (i) to deal with a technologically heterogeneous ecosystem of non-programmable devices; (ii) to enable the deployment of RESTful services provided via software artifact generated with ROOD methodology. In our case study, the development of software for Bioharness™ BT depends on the Acquisition Platform whose logic is distributed in two parts: one deployed on the smart-phone of the user, and another on the gateway .The two different cases of code generation explained in this section have to be conducted through two development branches . Both br6.6.ROOD Visual Editor) supporting the ROOD principles. The development of this tool is being tackled through different Eclipse projects [This section gives some implementation details about the development of the MDA tool  that was designed as a UML profile. From that profile we designed two models, Environment Context Model (ECM) and Smart Object Model (SOM), which establish a well-defined Domain Specific Language (DSL) for modeling diverse aspects of smart spaces . Specifically, the Eclipse project provides the Eclipse Modelling Framework (EMF)  to suppoEach one of those frameworks is very powerful by themselves. In contrast, they are characterized by their complexity to be understood and require a high level of expertise to build quality modeler. Obeo Designer integrates all those frameworks and hides such complexity. Using Obeo Designer, it is possible to define visual modelers without having knowledge about EMF and GMF technologies. The Ecore files are generated from “viewpoints” of the system that enable the creation of modelers (odesign files) by assigning specific graphical notation and behavior to every element composing the models.etc.) in order to conduct the coding of complex transformation. ATL manages metamodels defined in Ecore files to navigate and to edit them. Thus, ATL can take advantage from Ecore files generated by Obeo Designer, that we used to create the ECM and SOM metamodels and its modelers. This process is illustrated in Once we have created the Ecore and its corresponding modeler (odesign), we have to define mechanisms to automate the transformation between ECM and SOM through Model-to-Model (M2M) transformations. For this end, we use the ATL language  that is Finally, we defined a mechanism to convert SOM models into code, that is, a Model-to-Text (M2T) transformation. For this end, we have chosen Acceleo , an EcliROOD Visual Editor implementation, we need to focus on the model verification issues. Through this mechanism we can verify consistency of the models according to the semantic information related to the smart space that is being modeled . We have taken advantage of the capability of Obeo Designer for tabulating the information represented in the models. The information collected in tables is then used to carry out corresponding verification process, as To conclude the description of the ROOD Visual Editor such functionality is integrated in the development environment as an Eclipse plug-in.Currently, this mechanism is performed off-line between each stage of the ROOD methodology, but it is expected that in subsequent versions of 7.The design of a development methodology that provides common languages and procedures to tackle with a large heterogeneous smart space is currently an open challenge in the fields of the Internet of Things and, majorly, the Web of Things. The MDE approaches, specially the OMG standard, MDA, seem good solution to deal with a methodology aimed at this objective. MDA provides specific tools to construct development methodologies stratified in three conceptual layers . The MDA specification involves some important concepts that have to be taken into account in order to design optimized methodologies, among them the creation of modeling languages or the definition of accurate alignments between concepts in different layers. The final objective is to improve the quality of Model-to-Model (M2M) transformation to achieve a fine Model-to-Text (M2T) transformation, that is, the generation of program code that is compiled and deployed on hardware.i.e., technological heterogeneity, variety of roles and reasoning, high ubiquity, and diversity of communication protocols, in order to achieve the rapid deployment of pervasive environments populated of smart objects seamlessly interconnected. We have proposed a Resource-Oriented and Ontology-Driven (ROOD) development methodology based on the principles of MDA to facilitate the development and deployment of smart spaces. Two kinds of models have been proposed in CIM and PIM levels  as well as some mapping rules to obtain the last from the former via transformations. Additionally, we have designed a verification process that use semantic technologies to verify consistency of models in relation to the semantic information of the smart space stored in a specialized Knowledge Base whose contents are shaped according to the Smart Object Ontology (SSO).This work has demonstrated that it is possible to build Model-Driven methodologies based on MDA standards to tackle the challenges of smart spaces, Currently, we are actively working on the development of the ROOD methodology with the support of open tools within the Eclipse project. This work includes, majorly, the definition of mappings rules to improve the transformation among ECM and SOM as well as the definition of templates to generate SPARQL script for semantic validation through Knowledge Bases. Further developments will try to integrate semantic validation mechanisms as an Eclipse plug-in within the ROOD Visual Editor supporting our methodology, which will implement several mechanisms for semantic debugging and model suggestion in order to support the modeling process during their creation. We are also planning to extend the SSO scope not only for describing deployment scenarios, but also to address its integration into the SsML metamodel in order to improve the verification of ECM and SOM models.


In the last twenty years, the general view of the plasma membrane has changed from a homogeneous arrangement of lipids to a mosaic of microdomains. It is currently thought that islands of highly ordered saturated lipids and cholesterol, which are laterally mobile, exist in the plane of the plasma membrane. Lipid rafts are thought to provide a means to explain the spatial segregation of certain signalling pathways emanating from the cell surface. They seem to provide the necessary microenvironment in order for certain specialised signalling events to take place, such as the innate immune recognition. The innate immune system seems to employ germ-lined encoded receptors, called pattern recognition receptors (PRRs), in order to detect pathogens. One family of such receptors are the Toll-like receptors (TLRs), which are the central “sensing” apparatus of the innate immune system. In recent years, it has become apparent that TLRs are recruited into membrane microdomains in response to ligands. These nanoscale assemblies of sphingolipid, cholesterol, and TLRs stabilize and coalesce, forming signalling platforms, which transduce signals that lead to innate immune activation. In the current paper, we will investigate all past and current literature concerning recruitment of extracellular and intracellular TLRs into lipid rafts and how this membrane organization modulates innate immune responses. The general view of the cellular plasma membrane has evolved over the last twenty years from that of a homogeneous arrangement of lipids with embedded proteins towards that of a mosaic of microdomains, each having a specific protein and lipid composition . Over thCurrently, lipid rafts are thought to allow different protein-lipid and protein-protein interactions that temporarily compartmentalise the plasma membrane. Lipid rafts are thought to provide a means to explain the spatial segregation of certain signalling pathways emanating from the cell surface. They seem to provide the necessary microenvironment in order for certain specialised signalling events to take place. Recent studies have shown the importance of lipid raft formation in the acquired immune response. Major Histocompatibility Complex- (MHC-) restricted T-cell activation seems to be facilitated by lipid raft formation . FurtherThe innate immune system constitutes the most archaic part of our immune defences and has survived through years of evolution. Its function is thought to be the recognition of invading pathogens, the activation of inflammation to control the pathogen, and the subsequent activation of the acquired immune response. As part of its mechanism of activation, the innate immune system employs germ-lined encoded receptors, called pattern recognition receptors (PRRs) in order to “sense” pathogens. These PRRs recognise a restricted collection of microbial signatures, able to sense different types of microbial pathogens ranging from bacteria and viruses to fungi and spirochetes. Lipid rafts seem to be a key feature of the innate immune response, playing a crucial role in phagocytosis, receptor-receptor as well as receptor-pathogen associations as well as signal transduction. Families of PRRs, such as the Toll-like receptor family (TLR) as well as the C-type lectin family seem to localise in lipid rafts for their function thus demonstrating the importance of this membrane partitioning for the function of the innate immune response.The TLR receptor family were the first pattern recognition receptors to be identified , 10. ThiκB) [α, IL-6, and IL-8.All identified TLRs are type I transmembrane proteins, whose intracellular domains contain regions homologous to the intracellular domains of IL-1R and are referred to as TIR domains . These iκB) , 13, whiTLR4 was found to recognise bacterial lipopolysaccharide (LPS) or endotoxin , 15; TLRThe membrane distribution of TLRs as well as their intracellular trafficking has only now begun to be investigated. Most TLRs  seem to activate cells by engaging their ligands on the cell surface, whereas TLR3, TLR7, TLR8, and TLR9 seem to trigger signalling intracellularly. These TLRs have been shown to reside in the ER and to recognise their ligands once they have been endocytosed , 37.Investigations into the innate immune recognition of bacterial endotoxin led to the discovery of the TLR family. TLR4 is the most studied TLR, mainly because of its involvement with sepsis and septic shock. Sepsis is a paradoxical and complex disorder that results from an overreaction of our innate immune system to bacterial infections. The mechanisms that are designed to protect the host against infection by bacterial pathogens, either Gram-negative or Gram-positive, can lead to oversecretion of cytokines and fatal sepsis syndrome. It is now widely accepted that the overreaction of the host occurs at the level of the innate immune system and is directly linked to the recognition of bacterial cell wall components, such as lipopolysaccharide (LPS) from Gram-negative bacteria or lipoteichoic acid (LTA) from Gram-positive bacteria. Thus the recognition of bacterial products by the innate immune system under certain conditions seems to be detrimental for the host.In the last twenty-five years, great leaps forward in our understanding of the molecular events that lead to the innate recognition of pathogens have occurred. One of the seminal discoveries has been the identification of a serum protein, lipopolysaccharide-binding protein (LBP), which binds LPS or LTA and delivers it to its cellular targets . ProbablAs far as sepsis and bacterial recognition is concerned, TLR4 seems to be the central sensor of Gram-negative bacterial products , 39, whePRRs employed by the innate immune system have been shown to have the ability to bind and recognise conserved products of pathogens that are unique to the invading microorganisms but not to the host, it is becoming increasingly apparent that the model of a single PRR recognising foreign antigen is an oversimplified one. With the discovery of the Toll-like receptors as the main signal transducing molecules of the innate immune system, an onslaught of research has shown that PRRs are part of multicomponent sensor apparatuses.κB to production and secretion of proinflammatory cytokines , such as Dectin 1, are a family of pattern recognition receptors which bind ytokines –94. Inteytokines . Thus suCell membranes are complicated in composition but precise in purpose: to selectively compartmentalize its constituents in order to coordinate cellular functions. In this way, the membrane is able to compartmentalize, segregate receptors as well as their signalling machinery and create oligomeric signalling platforms in order to transduce signals. Once the required function has subsided, these segregated islands are involved in internalization and membrane trafficking, thus bringing the whole function to a close. The innate and acquired immune systems seem to utilise this membrane partitioning for their functions. In this paper, we have extensively looked at the use of this membrane partitioning by the innate immune system and most particular by the TLRs. The molecular mechanism involved in LPS recognition and TLR signalling in general, utilises a series of protein lipid as well as protein-protein interactions. The plasma membrane seems to be heterogeneous and to coalesce to more stable membrane-ordered assemblies upon activation by ligands. This partitioning of the membrane and the assembly of more stable raft platforms in the functionalized state must be initiated by raft-resident proteins, which form protein-lipid as well as protein-protein interactions. The TLRs and other PRRs associate with the raft-resident proteins and are recruited to these “floating islands” forming higher oligomers, both extracellularly as well as inside the cell, concentrating their signalling machinery which finally leads to a functional, focused, and coordinated activation of the innate immune system.in vivo. Thus refining existing biophysical methods, such as single particle tracking (SPT), fluorescence correlation spectroscopy (FCS), and fluorescence resonance energy transfer (FRET) will help us reveal these dynamic nanoassemblies of sterol, sphingolipid, and proteins in living cell and provide us with the first dynamic picture of the innate immune response.The lifetime of these domains and the length of the response will depend on their size and factors that may stabilise or destabilise them. These factors will include not only lipid-lipid, lipid-protein and protein-protein interactions both in the plane of the membrane but also elements of the cytoskeleton, pericellular matrix adjacent to the membrane as well as transmembrane and cytoplasmic domains of the receptors involved. In the case of TLRs, the association of the TIR domains intracellularly would stabilise the ectodomains extracellularly and provide the molecular scaffold that will recruit the adaptor molecules that contribute to signalling. The challenge for the future will be to visualise the assembly and stoichiometry of these large and transient oligomeric complexes


Collecting webpage messages can serve as a sensor for investigating the energy-saving potential of buildings. Focusing on stores, a cloud sensor system is developed to collect data and determine their energy-saving potential. The owner of a store under investigation must register online, report the store address, area, and the customer ID number on the electric meter. The cloud sensor system automatically surveys the energy usage records by connecting to the power company website and calculating the energy use index (EUI) of the store. Other data includes the chain store check, company capital, location price, and the influence of weather conditions on the store; even the exposure frequency of store under investigation may impact the energy usage collected online. After collecting data from numerous stores, a multi-dimensional data array is constructed to determine energy-saving potential by identifying stores with similarity conditions. Similarity conditions refer to analyzed results that indicate that two stores have similar capital, business scale, weather conditions, and exposure frequency on web. Calculating the EUI difference or pure technical efficiency of stores, the energy-saving potential is determined. In this study, a real case study is performed. An 8-dimensional (8D) data array is constructed by surveying web data related to 67 stores. Then, this study investigated the savings potential of the 33 stores, using a site visit, and employed the cloud sensor system to determine the saving potential. The case study results show good agreement between the data obtained by the site visit and the cloud investigation, with errors within 4.17%. Among 33 the samples, eight stores have low saving potentials of less than 5%. The developed sensor on the cloud successfully identifies them as having low saving potential and avoids wasting money on the site visit. NumerBefore implementing energy-saving technologies and employing highly efficient equipment, the first priority is to investigate energy-saving potentials. A place with high-potential indicates low energy usage efficiency. Investing in improving energy efficiency at a place with high-potential obtains a rapid return on investment and speeds up the adoption of energy-saving technology . Converset al. [et al. [et al. [et al. [et al. suggests simplified factors, including scale factors and management factors. Simplified factors could efficiently investigate the energy-saving potential of government office buildings.Several methods for determining the energy-saving potentials of buildings are discussed in published research. In 1999, Carriere et al.  develope [et al.  develope [et al.  used mul [et al.  proposedSurveying energy-saving potentials only depends on information collected from webpages. This is also called a cloud sensor system.Surveying energy-saving potentials of distributed sites accurately.Identifying sites with low energy-saving potentials.Both simulation and statistical methods consider too wide a range of factors to perform a practical investigation, so any survey of energy-saving potential costs money and requires resources for collecting data. In this study, a cloud sensor system is developed for investigating energy-saving potentials. The developed system aims to fulfill the following requirements:2.In order to meet the above requirements, structured data, an analyzer and a cloud system for initial data input are integrated in this study to develop a cloud sensor system, as shown schematically in 2yr is expressed by:The panels shown in the middle of The yearly electricity consumption of To construct a multi-dimensional data array, the URL list should be specified by human experts as the pre-defined URL list. It indicates all websites that may have information related to energy consumption of the test samples.A multi-dimensional data array is the core database for the cloud sensor system developed in this study. As listed in 2. With respect to EUI, the floor area of the store, one of the influencing factors on energy consumption, is discussed.All factors are discussed in relation to EUI. The second priority of the pre-defined URL list is to find the EUI value. By connecting to the public website of the Taiwan Power Company, the only electricity supplier in Taiwan, the energy usage of a store is surveyed, as shown in Panel (b) of Another factor is equipment efficiency. Using a cloud-based sensor for investigating, it is difficult to ask the owner to provide all the details related to equipment. Subsequently, the pre-defined URL lists uses in a capital survey instead of an equipment investigation. By connecting to the public website of the Economic Bureau to survey the company information, the store capital can be investigated using the cloud sensor system, as shown in Panel (c) of The next is to check the pedestrian flow of the store. This is a complex factor influencing energy consumption. Store owners usually can't provide, and may not know the exact pedestrian flow. In this study, the pre-defined URL list uses the public website of the Ministry of the Interior for querying the price of the store and Google for surveying the number of web pages related to the store, shown in the Panels (d) and (e) of The last step is to check the influence of climate conditions. Combining the Google map and the weather condition database, a XML program is used to estimate the weather influence on the energy usage of the store. Weather influence can be divided into two factors: solar radiation shielding and wind shielding. Using the Google map, the heights of buildings neighboring the store are examined to check if they shield the store . As showAs shown in In this study, an 8-dimensional (8D) data array is constructed as a core for the proposed cloud sensor system. Data includes a check if the store belongs to a chain store series, store area, store capital, store exposure frequency on the web, price of the store and weather conditions. All factors are important for the energy usage of stores and discussed in relation to EUI. A real case study including 100 stores was performed. Details about the stores are illustrated in the following section.3.2. The primary energy consumption of these stores is lighting and air conditioning. Among the four store types, some must be investigated using the sensor on the cloud to determine their energy-saving potentials. All these samples are investigated and improved under the support of governmental projects. Because of privacy issues, this study cannot list the sample names, and instead serial numbers are used to encode them. All stores are listed in To verify the effectiveness of the proposed cloud sensor system, a case study was performed. The experiments include 100 stores with various business activities. Of the 100 stores 67 of them have been improved to optimal energy efficiency and were investigated as the references. The other 33 stores are not been upgraded and were treated as the test samples in this study. Stores can be divided according to four store types and area ranges from 18 to 250 mAs listed in 4.etc., and the price of the store, is plotted according to the EUI. After collecting 67 stores as references, the data points and envelope lines are plotted, as shown in With data from stores of case study as discussed in previous section, an 8D data array is constructed to determine energy-saving potentials. The pre-defined URL list provides all the website connections used to obtain related information for investigating the energy-saving potential by using the cloud. All gathered information, including the store ownership, store area, store capital, number of webpages related to the store surveyed on Google by using the keyword of store name The envelope line is fundamental to DEA  and consetc. With a known EUI, the data array checks for a reference with the most similar conditions to the 33 stores that are unimproved to optimal energy efficiency. The similarity condition is defined as within 5% variation related to the data point at each axis. For example, the store area variation between the reference and the test sample is less than 5% of the area of reference. Along the seven axes, the one that satisfies the 5% variation rule and has the lowest variation is the selected reference. Comparing the EUI difference between the reference and the store under investigation determines the energy-saving potential. The algorithm is shown in The main working principal of the data array is searching and finding the information correlation of the investigated topic. This study investigates the energy-saving potential of stores by constructing an 8D data array. The data collection of the 67 stores illustrated in As illustrated in the caption of Pure technical efficiency is also employed to analyze the case that lacks similarity conditions on certain axes. 5.i.e., cost reductions of 33 sample stores, and compared with the results obtained from cloud sensor system as a contrast.In order to check if the cloud sensor system developed in this study has any advantages over existing techniques, a comparison experiment was performed. Referring to the website of Oak Ridge National Laboratory , energy The EUI rating method relies on input of energy usage data online. To rate EUI, the laboratory uses the data plots collected from cumulative histograms of U.S. regions. In this study, retail stores' energy performance in the state of Florida (FL) is used as the data plot since weather conditions of this state are the most similar to Taiwan. Then, to locate the total energy use intensity of 33 sample stores on the x-axis of data plot, we move up vertically to the curve and then left to the y-axis to get EUI rating—the percent of similar buildings in the U.S. less efficient than the sample store. The procedures of the EUI rating method are shown in The lower the percentage rating, the higher savings potential for energy use and cost reductions. If a sample store ranks below 20%, there are often large energy cost savings available through improved energy management or equipment upgrades. Substantial opportunities are also often achievable for buildings rated between 20% and 50%. For ratingd above 60%, the energy-saving potential could be less than 20%. The EUI rating method uses store ratings to determine saving potentials as shown in Though there are many researches related to estimate energy-saving potentials –13,19–256.The proposed sensor on the cloud to investigate stores only depends on information collected from webpages. That fulfills the first requirement as discussed in the Introduction section. The case study includes 100 stores to test the cloud sensor system. Among them, 33 stores are unimproved to optimal energy efficiency. This research used the cloud sensor system and the 8D data array to investigate energy-saving potential and compared it with the data obtained from the EUI rating method promoted by Oak Ridge National Laboratory and those obtained during a site visit. The EUI rating method provides a contrast to the system developed in this study. The comparison results were used to evaluate if the developed system fulfills the accuracy requirement. Aside from that, whether the system can identify stores with low energy saving potentials of less than 5% is another check point.The energy-saving potential investigation according to the site visit is briefly illustrated in Determining the optimal air conditioner setting and how to adjust the lighting requires a monitoring period of 2 days or more during the summer and winter. The cost of a site visit to each store differs according to the store area. The average store investment is approximately 15,000 NTD. Considering the time and cost, the cloud sensor system provides an efficient way to investigate the energy-saving potentials of stores.Despite its high efficiency, the sensor on the cloud needs to prove its accuracy. Aside from the developed system, Oak Ridge National Laboratory has also promoted a EUI rating method to estimate energy use and cost reductions by data collection on websites. The function is almost the same as the developed system, but s different algorithm is promoted to determine energy-saving potentials of stores. Results obtained from our case study not only need to prove the accuracy of the developed system but also have to prove it's better than the EUI rating method. The energy-saving potential of the 33 stores obtained from EUI rating method is reported in percentages and plotted in As shown in The energy-saving potential of the 33 stores obtained from the cloud sensor system is reported in percentages and plotted in As shown in Comparing the results of 7.The cloud sensor system efficiently and economically surveys the energy-saving potential of sites. A site-visit investigation takes 2 days or more to complete a store report. The cloud- computing system only takes 35 s on average. A site visit costs 15,000 NTD on average for one store. A cloud investigation only requires a communication fee less than 0.1 NTD, saving substantial work time and costs.Compared with the data obtained by a site visit, the cloud sensor system reports energy-saving potentials with accuracy of less than 5%. For most physical sensors, the accuracy is within this level. Using the structured data, an 8D data array, a cloud sensor is proven to have the same accuracy as a real sensor.Web searching has become a popular human behavior. Search engines, such as Google, list all information correlated to search keywords. In this study, a multi-dimensional data array and special geometry provided more accurate information than searching does. The cloud sensor works like a real sensor. The application may not be limited to surveying energy-saving potential, and can expand to other sensing environments, detecting pedestrian flow, traffic flow, and other promising applications.The cloud-computing system developed in this study provides an efficient tool for investigating the energy-saving potential by using the cloud. The following three conclusions are made:


To the Editor: Rates of illness and death from Clostridium difficile–associated disease (CDAD) and reports of CDAD in persons without traditional risk factors  as well as a deletion in the tcdC gene, which is believed to increase virulence  that encodes for the receptor-binding component of the toxin, according to a previously reported protocol (tcdC gene deletion was also confirmed with PCR (We report this toxin-variant strain of These results indicate that this canine isolate is indistinguishable from the major strain implicated in outbreaks of highly virulent CDAD around the world. According to the infection control practitioner at the hospital the dog visited, CDAD cases were occurring at increased frequency in the facility around the time the dog’s fecal specimen was collected. However, patient diagnosis was made solely through fecal toxin testing, and strains were not characterized. The facility has reported only sporadic cases of CDAD in the past few years.C. difficile in a dog. Many C. difficile strains isolated from animals, including dogs, are indistinguishable from strains associated with disease in humans (Staphylococcus aureus. The recurrent exposure of this dog to human healthcare settings suggests that the animal acquired this strain during visits to the hospital or long-term care facility, either from the healthcare environment or contaminated hands of human contacts. We recommend that future studies evaluating the dissemination of this strain and investigations of the movement of C. difficile into the community consider the role of animals.This is the first report of this human, epidemic strain of