In information systems, the division of a domain into relevant concepts and its formal representation is known as ontology [12]. The ThinkHome ontology can be seen as basis for the proposed system. All data has to be stored and provided in an intelligent way, supplying the system with needed knowledge. For the storage of information it was decided to use the Web Ontology Language (OWL), mainly because of its formal definition and reasoning capabilities. Furthermore, OWL is one major technology of the so-called Semantic Web. This additionally supports the openness of the ThinkHome knowledge representation.
As already mentioned, an OWL datastore contains different constructs to create a formal representation of knowledge. The model, which is similar to a database scheme in database design, is constructed by concepts and properties. A concept defines a general idea of a possible item in the defined knowledge base. For the suggested ThinkHome ontology, such concepts are for example WeatherInformation including all data concerning immediate exterior circumstances or HumanActor describing the group of human system users. In most ontologies constructed from scratch, it is desired to organize the identified concepts in a subsumption hierarchy, which means in a superclass/subclass connection. Properties are the relations between these concepts and can be differentiated in two kinds: object properties which establish connections between different concepts and datatype properties which connect concepts with values of a specified datatype. The last basic elements which represent the data are individuals. These are distinct from the conceptual model and act as concrete instantiations. For example, in the field of building information this would be a particular wall separating two defined rooms or a specific window type.
In addition to defining simple relations, several logical restrictions can be put on these basic elements as to create more complex dependencies. One example would be an anonymous superclass restriction, which allows membership in a class to be defined through logically combined properties of a set of individuals.
OWL, in the majority of the cases, is restricted to some form of logic such as description logics (DL) in order to make it decidable. This means when DL is enforced, a so-called DL-reasoner (e.g., Pellet [13]) can infer new information from the ontology. As OWL is an open standard, ontology reuse as well as integration into other projects is possible.
The vision of ThinkHome is to create a comprehensive knowledge base which includes all the different concepts needed to realize energy efficient, intelligent control mechanisms. The information base brings together different branches of control information which all can be seen as universe of discourse for the intelligent multiagent system. The multiagent society can subsequently query the facts stored in the ontology, thus enabling intelligent decision making.
Figure 2 shows the main branches of the ontology. This division may not be seen as physical separation of knowledge, but merely as logical segmentation of core concepts. First and foremost the storage of building information is of great importance. As already discussed in Section 3, the storage of building characteristics can support optimized control strategies striving for energy-efficient operation of the smart home. It is not feasible for a user to enter all these values manually due to the huge effort and lack of knowledge. Thus, an automatic approach is favored. Therefore, for the ThinkHome system, the inclusion of data stored in a building information model (BIM) was considered.
A BIM is a data exchange format used by architects, construction engineers, and building physicists among other parties involved in the construction process of a building. Each of these stakeholders adds domain knowledge to a common model which keeps information of the whole building lifecycle (except the operational phase). As a consequence, the model serves as a valuable source of information. There exist several open formats of BIM, where the Industry Foundation Classes (IFC) and the Green Building XML (gbXML) can be seen as the most popular ones today [14]. gbXML was chosen for application in ThinkHome, because the format focuses on the exchange of information for energy simulation and calculation, and therefore stores facts that are helpful for the focal point of the proposed system. Through the information retrieved from the BIM, we obtain enough concepts to model the whole building including wall layers, window sizes and types, door sizes and positions, room area and volume as well as assigned room purpose and orientation of the building. Subsequently, exact calculation of the building behavior with respect to thermal mass and room arrangement becomes possible. This is especially beneficial for an energy-efficient provision of thermal comfort (cf. Section 3).
In the ThinkHome project, a transformation from gbXML to the OWL language format was carried out by Extensible Stylesheet Language Transformation (XSLT) documents. This straightforward approach allows to integrate all data already collected by former engineering parties and store it in an intelligent way as OWL document. The Web Ontology Language allows to classify the concepts retrieved from gbXML and, due to the formal definition of the language, also reasoning on the data becomes possible.
Apart from concepts relating to the building, also actor information about the users of the system has to be considered. Users in this case can be either human users, but also system agents. The reason for this is that the ontology builds the foundation of a multiagent system in which intelligent actors can take autonomous actions on behalf of the users. For humans, the knowledge base must know different characteristics (e.g., age, gender) and also keep a user profile (cf. Sections 5 and 6). In the user profile, the preferences of the users are stored. These profiles are an aggregation of atomic actions residing in the ontology as processes.
A process is a concept containing elementary operations that are used to describe the users' activities. Certainly also basic system processes are kept in this part of the ontology. Very important, with respect to the use cases depicted earlier, is to consider exterior influences. These weather and climate data can be used to infer the proper action and perform tasks most energy efficiently. In addition, this information can be exploited in order to guarantee user comfort, for example, by natural lighting through sunlight (cf. Section 3). Comfort information is a smaller part of the ontology which nevertheless can be seen as core concept: it stores various aggregations of elementary measurement units (e.g., temperature, humidity, luminosity) and therefore provides a notion of comfort to the system. Most of the measures can be retrieved from the building information unit, as the data imported from gbXML includes a vast amount of measurement units of any kind. In the energy information branch reside different available energy providers and their trading conditions. This information is especially valuable when envisioning the integration of the ThinkHome system into a smart grid, as the ontology can provide the momentarily best option for energy consumption or recovery. This part of the ontology also keeps energy schedules for different occupancy states and scenarios (e.g., day, night, weekends, holidays) and this way allows to anticipate consumption peaks. Furthermore, it is important to have an idea of the provided building automation services, as well as equipment available in the smart home. This resource information branch includes white goods, brown goods, and automation networks hosting lighting, shading as well as heating, ventilation, and air conditioning (HVAC) devices. As the automation networks can be of different types, protocols, and manufacturers, it is valuable to represent them as concepts in an ontology. This way, their definition can be generalized, which in turn supports the transparent integration and communication across the different networks. In addition, energy producers like solar collectors or a thermal heat pump are stored in this section. Hence, a complete model of the energy consuming and producing landscape available in the building is depicted in the knowledge base [15].
Especially for the last core section, approaches dealing with dynamic data and historization of information have to be kept in mind. A recording of historic sensor data can be valuable for performing trend analysis or generating updated occupancy profiles as pointed out in Section 6. As the described knowledge base can only provide an instantaneous reflection of the system's state, a proper transition into a historical permanent storage becomes necessary. Obviously, not all of the information needs to be represented as historical data as large amounts of information are known to be highly static (e.g., building information). Therefore, just a subpart of the global knowledge base has to be considered for historization. Possible comprehensive environments for managing large-scale ontologies as RDF triple store are the Virtuoso Universal Server Project [16], as well as the JENA Semantic Web Framework [17].
4.1. Benefits of Using OWL
4.1.1. Query Language
Additionally to an intelligent storage of building and process information, it is of course important to be able to question the knowledge store for these data. Just like SQL being the query language of relational database systems, SPARQL [18] is the interrogation mechanism of the Resource Description Framework (RDF). Furthermore, as RDF is the foundation of OWL, the SPARQL language can subsequently be used to query the ThinkHome knowledge base. RDF stores data as triples in a labeled-directed graph. As a consequence, SPARQL works on graphs and triples which can be combined using variables. For the ThinkHome system, it becomes possible to retrieve selected information about the building and ongoing processes with the help of this query language. For example, with the information retrieved from gbXML and stored in the ontology, it becomes possible to find out specific information of a room or the whole building. A simple SPARQL query can extract areas and volumes as well as the appropriate measurement units of the different rooms in the building (cf. Listing 1).
Listing 1: SPARQL Query: Room Areas and Volumes.
PREFIX gbOWL:<http://www.auto.tuwien.ac.at/
gbBuilding.owl#>
SELECT ?id ?name ?a ?aunit ?vol ?volunit
WHERE
{ ?gbXML gbOWL:hasAreaUnitValue ?aunit.
?gbXML gbOWL:hasVolumeUnitValue ?volunit.
?area gbOWL:hasNativeValue ?a.
?volume gbOWL:hasNativeValue ?vol.
?spc gbOWL:containsArea ?area.
?spc gbOWL:containsVolume ?volume.
?spc gbOWL:hasIdValue ?id.
?spc gbOWL:hasNameValue ?name }
This information alone can already be used to optimize the on/off heating schedule according to the space that has to be heated. Similar queries can be created to determine which rooms are adjacent to each other and to obtain the thickness as well as material of interior and exterior walls. With the data retrieved from the gbXML model, it is also possible to exactly determine the position of windows and doors and therefore take sunlight into account to reach thermal and visual comfort as previously discussed in Section 3.
An update of specific data triples in the ontology can be accomplished by SPARQL/Update queries (SPARUL). With the help of this extension of the SPARQL language, it becomes possible to delete and insert triples in RDF data models. Although this addition is not yet a standard for the World Wide Web Consortium (W3C), it is already supported by major Semantic Web technologies like the JENA Semantic Web Framework and the Virtuoso server.
4.1.2. Inference
One of the main concepts of OWL ontologies is inference. This ability can be used to perform subsumption reasoning as well as inferring new information out of the stored data. An example is considering weather conditions when choosing an appropriate cooling method. Not every cooling technique is to be allowed for all different weather situations, as it is obviously not desired to rely on natural ventilation when a thunderstorm with heavy rain and wind is currently taking place outside. Therefore, possible weather situations are classified and stored in the ThinkHome ontology as can be seen in Figure 3. The concepts shown are general classifications, as the particular weather conditions in OWL are stored as individuals. As already mentioned, it is possible to reason upon the stored data with the help of a reasoner and subsequently infer new information.
For example, if currently a badweather condition is experienced and an agent pursues a cooling task for a specific room, it is beneficial to know which cooling methods are possible with respect to the current WeatherSituation. Some concept in the ontology can model exactly this situation (cf. Figure 4). In this case, a class CoolingBadCold is provided, which members are defined to be in the class which permits a bad and cold WeatherSituation and are not heating processes (as the agent is searching for current possibilities to cool the room). Therefore, all individuals of this anonymous superclass are to be members of the defined class CoolingBadCold. As can be seen in the members section of Figure 4, the reasoning mechanism of the ontology can automatically infer two individuals, which denote processes to be possible in this situation: AirCondition and VentilationExteriorAir. Another cooling process defined in the ontology, namely, OpenWindow, is not inferred to be a member as this action should just be performed in a calm WeatherSituation.
This use case shall underline the manifold possibilities that emerge with the application of an OWL ontology. SPARQL queries, as described before, tend to become inherently easier when ontology reasoning capabilities are used and properly defined concepts are provided. Besides, the described model allows to integrate new weather situations or system processes into the model, which can subsequently be included in the result set according to the logical dependencies between the OWL classes and properties. This makes the ThinkHome system highly flexible, as, for example, different climates and weather conditions can easily be added.