Medida de la uniformidad del riego

This component allows a producer application to publish structured data. The basic tool to publish data is by defining a PID document, which describes the structure of the environment and the created channels. The structure of the environment can be defined by means of a domain-dependent ontology description, that uses one of the many available ontologies (e.g., for smart homes, it will be structure of the house; for energy management system, it will be installed metering system). The

1

http://www.pubnub.com 2

11 – Linked Open (Dynamic) Data

created channels will carry updates. Each update is a RDF fragment having a set of properties, which are dependent on the update being carried by the channel and represent any data which changes over time.

Modeling: Publisher Ontology

LO(D)D is an ontology driven framework and it is driven by a PID document. In order to provide the formal structure of the PID document, a 3-tiered ontology has been developed. The ontology is called Publisher ontology and it is formal- ized by using the OWL Web Ontology Language [29]. The encoded ontology will provide both publisher and subscriber components a common structure and agreed upon formal semantics. Three modeling layers are defined, with decreasing usage complexity: a core layer, designed to outline the basic elements of the LO(D)D ar- chitecture, a semantics layer allowing a producer application to specifically define artifacts regarding the environment. For instance, description of the environment, type of dynamic channels, type of data events carried and the type of transport mechanism. Inheriting from the previous two layers, the operation layer allows the actual description of the environment, the number of channels, the data events being carried by the channel etc.

[Core layer:] contains the basic class definitions for expressing a producer ap-

plication (Figure 11.2); this layer is concrete and not meant to be modified by the designers of producer applications. It provides a common structural foundation for diverse producer applications that can be utilized by a consumer application to retrieve generic information regarding the producer applications.

Every producer application is formally organized into a concept hierarchy inherit- ing from the Publisher class. As mentioned before, each publisher has a structural aspect (which remains static over a long period of time) and a dynamic aspect. The former static aspect is represented by the StaticContent class (using hasContent property of Publisher class). The StaticContent class can be used to define/attach a domain-dependent ontology (using pointsToResource property). For instance, in the smart home environment the domain-dependent ontology may be DogOnt [35], whereas, in a personal environment the domain-dependent ontology may be FOAF3_.

In order to handle the dynamic aspect of the producer application, LO(D)D uses the concept of channel and therefore, each Publisher class can have a number of dy- namic channels, each represented as a Channel class (using hasChannel property). A channel streams data events of specific type, which are represented as DataEvent class (pointed as streams property. The transport mechanism used by a channel to carry data events in real time is inherited from the TransportProtocol class.

3

http://www.foaf-project.org

11.2 – Proposed Framework

Concrete Layer

11 – Linked Open (Dynamic) Data

Figure 11.3. Publisher Ontology: Energy Management domain

11.2 – Proposed Framework

[Semantics layer:] Every application domain will define different classes in-

heriting from the core layer by sub-classing the general classes defined in the core layer. A sample semantics layer for an energy management domain is shown in Fig- ure 11.3. In the energy management domain typical elaborations involve continuous data such as power or gas measures coming from meters located in the smart envi- ronment. Power and Gas events are defined that will be streamed over two channels, i.e., Electricity and Gas channels. One can define additional properties dependent upon the domain. For example, the Power event contains the meter number from where the power event is being generated. The Gas channel contains the unit of measurement for the data events being transported.

The LO(D)D architecture is generic in nature, although Figure 11.3 models a simple environment for a energy aware producer application, it’s important to notice how the framework easily supports domain-dependent definition of semantics layer. Moreover, modeling accuracy and granularity can easily be adapted to the problem under examination, thus providing designers a powerful tool for defining abstract effects on which more advanced policies can be built.

[Operation layer:] The operation layer of the Publisher ontology represents

a specific Publisher defined in a given smart environment. They are modeled as instances of the classes defined in the core or semantics layer. Figure 11.3 shows a publisher named “Energy Publisher” that has two channels. The ElectricityChannel1 and GasChannel1 uses PubNub transport mechanism and its specificities (secret, public and private keys) are defined using the instance PubNub1. Now whenever, an update occurs it is passed on a specific channel as an instance of the Power or the Gas event.

Modeling is clearly not restricted to a single knowledge domain. If, for example, we model try to model domotic effects, then the semantics layer can be created to send updates regarding the activation or deactivation of domotic effects.