Tipo de corpus

The fixed part of every Onto++ instance consists in a set of concept and property hierarchy roots shown in the right hand side diagram of Fig. 4.1. The subconcepts and subproperties populating these hierarchies will be partially asserted by KT and partially subsumed (inferred) by the reasoner, to accurately represent specific entities from the modelled domains. Inferred knowledge represents the dynamic part of Onto++ instances and is not contained in the template. The hierarchy roots are presented below.

• Entity is the root of the ontology hierarchy modelling the problem domain. Entity subconcepts are application specific and are connected to each other via inheritance (e.g., in an Onto++ instance that models a chemical reaction, OrganicCompund and InorganicCompund directly subsume Entity, Water inherits from InorganicCompund, Carbohydrate inherits from OrganicCompound, etc.) or via bespoke properties (e.g., hasMolecule connects Carbohydrate and Water). Inheritance relationships are implicit and will be deduced by the reasoner. Bespoke properties are rooted in hasProperty and are explicitly asserted by KT. If Entity subconcepts have connections to numbers (hasNumberOfAtoms), strings (hasChemicalSymbol), boolean values (isStable), etc., those properties will be asserted under hasValue.

• State is the base concept for the ontology segment modelling possible system states. If the targeted domain is a chemical reaction, then the state of the system may be defined in terms of the resulting substance’s composition (State1 would correspond to a molecule of one Carbohydrate subconcept, State2 to two molecules of another, etc.). The connections between State and Entity subconcepts are realised by the hasEntity property. Each state has an associated

preference score, called utility, that indicates its desirability from the autonomic manager’s perspective. Utilities (block values in the architecture) are numbers, not concepts, therefore do not form a hierarchy. States are connected to utilities via the hasUtility property.

• Link is an abstract concept, in the sense that it does not model a physical entity from the target domain. Instead, it serves as an auxiliary building block to represent multifaceted properties with no natural support in RDF, a process called reification (a detailed example is provided in 4.3.2). The reificated property inherits from hasLink. hasArgOne and hasArgTwo connect the Link concept to the domain and filler of the reificated property. The extra facet of the reificated property (a number or a string from the values block) is associated to the Link concept via property hasWeight.

Design justification

The Onto++ structure is designed to meet the autonomic manager’s requirements with respect to the representation of the knowledge repository. Specifically, the problem domain should be modelled as a graph [88, 90], where nodes represent physical entities and edges model their connections. These are the roles of the Entity and hasProperty hierarchies, respectively. The State hierarchy (when it is computationally feasible to store it) supports the analysis (4.3.4) and planning (4.3.5) stages of the MAPE loop, whereas the Link hierarchy makes it possible to model more complex relationships between entities. Note that these last two hierarchies are included in the Onto++ instances only if they are needed. Another issue that requires justification is the choice of an ontology for knowledge storage. A case has been made in the introduction (1.1) for the inherent compatibility between semantic technologies (particularly ontologies and reasoners) and autonomic computing, yet a more convincing explanation is required relative to the dismissal of other knowledge management alternatives such as relational databases or object oriented models. The most compelling reason in favour of ontologies is best formulated by Soylu et al: database schemas and object-oriented models “are not meant to capture a domain per se and are not truly natural for end users” [164]. This comes down to these platforms’ incapacity to learn, that is, infer implicit knowledge from explicit facts, as a reasoner does with ontology data. Humans implicitly infer knowledge when they experience new environments, therefore semantic models are one step closer to the way organic brains build models of the world. To further strengthen this argument, a comparison between the performance of an autonomic manager storing knowledge in a relational database against that of the same autonomic manager featuring a semantic layer is presented in 5.4.1.

The reason for selecting reification as a means to represent multifaceted properties over other alternatives1 is twofold. Firstly, a significant portion of the covered literature employs reification in practical applications [169, 35, 66, 60, 134] and secondly, it is recommended as an ontology design pattern [65, 136].

The final argument relates to the absence of plans and policies from Onto++, since other approaches [147, 155, 87, 11] provide semantic representations for those two components as well. Within the KAS framework, policies and plans are not reasoned on. They are generated by the domain expert and, dynamically, by the plan algorithm (4.3.5), respectively, but are not subject to semantic inference.

Therefore, including them in the ontology would bring no computational gain. Acording to the covered literature, a consensus is yet to be reached with respect to the cost-benefits ratio of reasoning over plans and policies, thus this approach will be further investigated in future work.

Running example

The very simple smart environment considered for illustration features two cooling devices (a fridge and a freezer) and two room heating appliances (a radiator and an air conditioning unit). These are represented by concepts of the Entity hierarchy, in the Onto++ instance shown in Fig. 4.2. Cooling devices have a capacity expressed in litres, whereas heating appliances feature a temperature output in degrees Celsius - these properties are modelled by hasCapacity and hasOutput, respectively. Both types of machines use power in a specific amount expressed in Watts - this is represented by the hasWattage property. All properties mentioned thus far have numeric fillers, therefore their graphical representations in Fig. 4.2 are connected to the values box.

EnergyConsumption HighEnergy MediumEnergy LowEnergy Comfort State1 State9 hasEnergyConsumption _values hasUtility hasComfort hasRange hasFoodTemp hasRoomTemp

State hasEntity Entity hasValue

CoolingDevice Fridge Freezer HeatingDevice Radiator AirConditioner hasCapacity hasWattage hasOutput hasWattage HighComfort MediumComfort LowComfort

Fig. 4.2:The Onto++ instance modelling the smart environment - concept hierarchies are presented as indented lists

To get a better picture of how the above concepts and properties are connected, the complete definitions of ontology concepts Fridge and AirConditioner are given in Fig. 4.3 (Freezer and Radiator can be described in a similar fashion).

The two ontology classes, along with their sub-concepts, towards the bottom of the Entity hierarchy, namely EnergyConsumption and Comfort, support the definition of all possible states that the smart environment can be found in. In this case, there are nine possible states, one for every combination of energy consumption and comfort levels. For instance, State7 (Fig. 4.4) is reached when the overall energy consumption is low and the level of comfort (room temperature and food preservation) is high. Since maintaining a comfortable ambient temperature and ensuring that kitchen appliances are

Class: Fridge EquivalentTo: CoolingDevice

and (hasCapacity value "150"^^integer) and (hasWattage value "200"^^integer)

Class: AirConditioner EquivalentTo: HeatingDevice

and (hasOutput value "20"^^integer) and (hasWattage value "2000"^^integer)

Fig. 4.3: FridgeandAirConditionerconcept definitions

cool enough to keep food fresh, at a low energy cost, is an ideal situation, concept State7 represents the goal state and is thus awarded the maximum utility.

Class: State EquivalentTo:

hasEnergyConsumption some EnergyConsumption and (hasComfort some Comfort)

and (hasUtility some xsd:integer)

Class: State7 EquivalentTo: State

and (hasEnergyConsumption some LowEnergyConsumption) and (hasComfort some HighComfort)

and (hasUtility value "9"^^integer)

Fig. 4.4: StateandState7concept definitions

The values used to define the EnergyConsumption and Comfort subclasses (in other words, the range a temperature value would have to be in to be considered high) are either prescribed manually or discretised automatically (e.g., when given the upper and lower limits of the energy consumption value range – for instance, 1000W and, respectively, 4000W – and the number of desired classes – say, 3 – the manager will automatically determine that a high energy consumption is over 4000W, a medium one is between 1000W and 4000W and low one is under 1000W). To illustrate, the definitions of HighEnergy and MediumComfort are given in Fig. 4.5.

Concepts EnergyConsumption and Comfort (specifically, its two facets, room and food temperature) correspond to the environment signals that the autonomic manager is capable of monitoring. Provided that a new sensor is installed to measure, for instance, humidity, a new ontology class will be asserted with the appropriate sub-hierarchy (for a discretisation factor of 2, sub-concepts LowHumidity and HighHumidity would be considered).

4.2.2 Policy

Class: HighEnergy EquivalentTo: EnergyConsumption

and (hasRange some xsd:integer[>4000])

Class: MediumComfort EquivalentTo: Comfort

and (hasFoodTemp some xsd:integer[>3 , <=5]) and (hasRoomTemp some xsd:integer[>15 , <=20])

Fig. 4.5: HighEnergyandMediumComfortconcept definitions

• utilities. These are numerical values associated to system states. In the most common scenario, the system state is given by the values of the monitored inputs. For example, one of the states that a system monitoring temperature and humidity may be in is described by:

temperature <= 10 AND humidity <= 100 5

In this example, a utility of 5 is associated to the state where the environment temperature is lower than 10 units and the humidity is under 100 units. All relevant system states must be provided with a utility in this section of the policy document. Input discretisation (a task performed during ontology learning - see 4.3.2) is directly relevant to utility definition as it significantly reduces the size of the state space. Unless otherwise specified, the autonomic system goal is defined as achieving the state with the highest utility.

• actions. This section of the policy document is related to the managed resource parameters modified by the autonomic system’s effectors. Relative to the previous example, let us assume that the controlled parameter is the environment’s pressure, leading to three possible actions: increasing, maintaining or decreasing it. At each step of the MAPE loop’s planning stage, an action is selected from the available set and inserted in the plan under development.

• heuristics. These represent high level knowledge prescribed by the domain expert to deal with safety-critical situations (like in the example to follow) or help expedite the analysis and planning stages of the MAPE loop (see 5.2.3). An example of a heuristic policy expressed in the ECA formalism is given below:

When the temperature is above 150 event AND

the pressure valve is faulty condition THEN

switch off power. action

All policy sections are optional apart from the goal definition (given by the maximum utility state as in the example above or by a goal policy as in 6.2).

Running example

In the case of the smart environment application, the policy document would contain:

• utility values for all nine states (a low level of comfort obtained at a high energy cost is intuitively the minimum utility state, just as a high level of comfort at a low energy cost – Fig. 4.4 – is the system goal and, consequently, the highest utility state; however, it takes a human system administrator to assign utilities for less clear-cut states, as, in some scenarios, high comfort at a medium energy cost may be preferable to medium comfort at a low energy cost, whereas, in others, the situation may be reversed)

• actions that the autonomic manager can operate on the environment (for example, switching appliances on or off and commuting to a low power state or back to regular operation parameters)

• heuristics such as the one below.

When the energy consumption is medium event AND

the comfort level is high condition

THEN

switch all electrical appliances over 200L to low power mode. action