Plausible Description Logic Programs for Stream Reasoning

Abstract

Sensor networks are estimated to drive the formation of the future Internet, with stream reasoning responsible for analysing sensor data. Stream reasoning is defined as real time logical reasoning on large, noisy, heterogeneous data streams, aiming to support the decision process of large numbers of concurrent querying agents. In this research we exploited non-monotonic rule-based systems for handling inconsistent or incomplete information and also ontologies to deal with heterogeneity. Data is aggregated from distributed streams in real time and plausible rules fire when new data is available. The advantages of lazy evaluation on data streams were investigated in this study, with the help of a prototype developed in Haskell.

1. Introduction

Sensor networks are gradually becoming ubiquitous in the industrial world [1], whilst they are estimated to drive the formation of the future Internet, by 2015 [2]. The value of the Sensor Web is related to the capacity to aggregate, analyse and interpret this new source of knowledge. Currently, there is a lack of systems designed to manage rapidly changing information at the semantic level [3]. The solution given by data-stream management systems (DSMS) is limited mainly by the incapacity to perform complex reasoning tasks, and semantic technologies are seen as the main technical instrumentation available to deal with the current problems [4].

Stream reasoning is defined as real time logical reasoning on huge, possible infinite, noisy data streams, aiming to support the decision process of large numbers of concurrent querying agents. In order to handle blocking operators on infinite streams (like min, mean, average, sort), the reasoning process is restricted to a certain window of concern within the stream, whilst the previous information is discarded [5]. This strategy is applicable only for situations where recent data have higher relevance (e.g., average water debit in the last 10 minutes). In some reasoning tasks, tuples in different streams that are far apart need to be joined arbitrarily.

Stream reasoning adopts the continuous processing model, where reasoning goals are continuously evaluated against a dynamic knowledge base. This leads to the concept of transient queries, opposite to the persistent queries in a database.

Typical applications of stream reasoning are: traffic monitoring, urban computing, patient monitoring, weather monitoring from satellite data, monitoring financial transactions [3] or stock market. Real time events analysis is conducted in domains like seismic incidents, flu outbreaks, or tsunami alert based on a wide range of sensor networks starting from the RFID (Radio-Frequency Identification) technology to the Twitter data flow [6]. Decisions should be taken based on plausible events. Waiting to have complete confirmation of an event might be too risky.

To summarise, the problem is given by the inability of the current stream reasoning systems (i) to perform semantic reasoning on changing information from heterogeneous sensors and (ii) to support decision in case of incomplete information.

Our solution is based on three technical components: description logic (DL), plausible logic (PL) and functional programming. Description logic is used to deal with heterogeneity and to fill the gap between low level sensor data and high level knowledge requested by decision takers. Plausible Logic, being non-monotonic, is used for handling incomplete information and its explicit priorities are used to solve inconsistencies. The Haskell data structures are used to model infinite streams based on the lazy evaluation mechanism of Haskell. Also, functional programming is used to process streams on the fly according to given aggregation policies.

Note that in the current approach, the rule-based system is not on top of the ontology level, as envisaged by the Semantic Web stack. Instead, they are at the same level with part of the ontology being translated into strict rules. Consequently, after the translation, all the reasoning on streams is performed within the plausible logic framework. The main advantage rests in the time needed, given the superior efficiency of plausible logic [7] compared to description logic [8].

This paper is an extended version of [9]. The first contribution regards the integration of plausible rules with description logic. As a second contribution, we describe the use of Haskell data structures and the lazy evaluation mechanism for continuous reasoning on infinite streams.

We exploit non-monotonic rule-based systems for handling inconsistent or incomplete information and also ontologies to deal with heterogeneity. Data is aggregated from distributed streams in real time, and plausible rules fire when new data is available. This study investigates the advantages of lazy evaluation on data streams as well.

Section 2 evidentiates distinctive features of our approach compared to related work. Section 3 introduces the technical instrumentation, which is based on plausible logic and description logic. Section 4 presents the developed stream management system. A running scenario is illustrated in Section 5. Finally, Section 6 summarizes the advantages and possible improvements of our solution.

2. Related Work

Stream integration is considered an ongoing challenge for the stream management systems [2,3,10,11], with several tools available to perform stream reasoning.

DyKnow [12] introduces the knowledge processing language KPL to specify knowledge processing applications on streams. We exploit the Haskell stream operators to handle streams and the list comprehension for querying these streams. The SPARQL algebra is extended in [13] with time windows and pattern matching for stream processing. In our approach we exploit the existing list comprehension and pattern matching in Haskell, aiming at the same goal of RDF streams processing. Comparing with C-SPARQL, Haskell provides capabilities to aggregate streams before performing queries against them. Etalis tool performs reasoning tasks over streaming events with respect to background knowledge encapsulated as Prolog rules [14]. In our case, the background knowledge is obtained from ontologies, translated as strict rules in order to reason over a unified space.

The need to consider revision in stream processing is also addressed in [15]. A rule-based algorithm is developed to handle different situations in which event revision should be activated. In our case, the defeasible semantics of plausible logic is enacted to block the derivation of complex events in case of new contradictory information. Consequently, the knowledge engineer would be responsible to define what a plausible event is, and what consequences cannot be retracted even if its premises have been proved false after revision, by modelling them as strict rules. One possible line of research, which harmonises these two complementary approaches, would be to develop a logic for stream processing.

The strength of plausibility of the consequents is given by the superiority relation among rules. One idea of computing the degree of plausibility is to exploit specific plausible reasoning patterns like epagoge: “If A is true, then B is true. B is true. Therefore, A becomes more plausible”, “If A is true, then B is true. A is false. Therefore, B becomes less plausible”, or “If A is true, then B becomes more plausible. B is true. Therefore, A becomes more plausible.”

The research conducted here can be integrated into the larger context of Semantic Sensor Web, where challenges like abstraction level, data fusion, application development [16] are addressed by several research projects like Aspire [17] or Sensei [18]. By encapsulating domain knowledge as description logic programs, the level of abstraction can be adapted for the current application by importing a more refined ontology into DLP. From a different perspective, the ontology used for stream processing acts as a summator [19]: instead of storing all the input data, the incoming items are classified and only this abstract knowledge is stored as instances. One advantage is that the system facilitates business intelligence through the set of semantic queries that can be addressed against the classified knowledge. Examples of such queries are “how many dairy products have been sold since yesterday” or “what quantity of man’s wear was sold in the last month”, where the level of refinement is given by the exploited ontology.

3. Integrating Plausible Rules with Ontologies

This section starts with the formalisation of plausible logic responsible for performing reasoning on streams. Then, it introduces description logic for modelling ontologies. Finally, it formalises the translation of ontologies into strict rules in PL. We consider that sensor data are available as instances of a sensor ontology.

3.1. Plausible Logic

As a non-monotonic formalism, plausible logic (PL) deals with the problem of deriving conclusions in case of incomplete or uncertain information. Plausible logic is considered an improvement of defeasible logic [20,21].

A clause in PL is the disjunction of positive or negative atoms . If both an atom and its negation appear, the clause is a tautology. A contingent clause is a clause which is neither empty nor a tautology [20].

Definition 1 A plausible description of a situation is a tuple , where is a set of contingent clauses, called axioms, characterising the aspects of the situation that are certain, is a set of plausible rules, is a set of defeater rules, and is a priority relation on .

A plausible theory is computed from a plausible description by deriving the set of strict rules from the definite facts . Thus, a plausible knowledge base consists of strict rules ( ), plausible rules ( ), defeater (warning) rules ( ), and a priority relation on the rules ( ). Strict rules are rules in the classical sense (that is, whenever the premises are indisputable), then so is the conclusion. An atomic fact is represented by a strict rule with an empty antecedent. The plausible rule means that if all the antecedents are proved and all the evidence against the consequent has been defeated, then can be deduced. The plausible conclusion can be defeated by contrary evidence.

The only use of defeaters is to prevent some conclusions, as in “if the buyer is a regular one and he has a short delay for paying, we might not ask for penalties”. This rule does not provide sufficient evidence to support a “non-penalty” conclusion, but it is strong enough to prevent the derivation of the penalty consequent. The priority relation allows the representation of preferences among non-strict rules.

Decisive plausible logic consists of a plausible theory and a proof function that, given a proof algorithm and a formula in conjunctive normal form, returns if was proved, if there is no proof for , or 0 when is undecidable due to looping. Plausible Logic has five proof algorithms , in which one is monotonic and four are non-monotonic: monotonic, strict, like classical logic; ; plausible, propagating-ambiguity; plausible, blocking-ambiguity; and .

Example 1 Consider the following rules for triggering an alarm system in case the temperature rises above 0 in a refrigerator room.

The rule is a strict one: whenever the temperature measured by the sensor is above 4 C the alarm starts automatically. The rule is a plausible one: if the measured temperature is above 0 C, there is a reason to support the decision to trigger the alarm. The algorithm analyses if there are other reasons supporting the opposite conclusion or trying to defeat it. Rule is such a rule. If both rules can be fired, we have an ambiguity. In case of the propagating-ambiguity strategy, both consequences are derived by the system. In case of the blocking-ambiguity strategy, no conclusion would be valid. Note that the rule is a defeater that, in case of activation, blocks the derivation of the conclusion . If active, being stronger than is able to block the corresponding decision. At this moment the consequence of the rule is no longer attacked by any valid rule. This mechanism corresponds to the argumentative semantics characterising the family of the defeasible logics [22].

3.2. Description Logic

In the description logic , concepts are built using the set of constructors formed by negation, conjunction, disjunction, value restriction, and existential restriction, as Table 1 bears out [23]. Here, and represent concept descriptions, whilst and role names. In this study we used the extension of with transitivity ( ) on roles and role hierarchy ( ), known as or . The syntax of is defined by the following grammar:

(1)

where represents an atomic concept and the top level concept.

The semantics is defined based on an interpretation , where the domain of contains a non-empty set of individuals, whilst the interpretation function maps each concept name to a set of individuals and each role to a binary relation . The second column of Table 1 illustrates the extension of to arbitrary concepts.

Table 1. Syntax and Semantics of concepts.

Syntax	Semantics

Table 1. Syntax and Semantics of concepts.

Syntax	Semantics

Definition 2 A concept is satisfiable if there exists an interpretation such that . The concept subsumes the concept ( ) if for all interpretations .

Definition 3 An is a finite set of concept assertions or role assertions , where represents a concept, a role, and and are two instances. Usually, the unique name assumption holds within the same . A is a finite set of terminological axioms of the form or .

Example 2 Consider the domain . Let the terminology:

The interpretation function treats the individual as a wireless sensor with the measurement accuracy of 0.1 C, where the value is interpreted as an instance of the class MeasureUnit. Based on the second axiom in the TBox, the subsumption reasoning service of the DL derives as an instance of the Sensor concept.

3.3. Translating from DL to Plausible Logic Programs

This section exploits the work in [24] in order to translate description logic based on ontologies into plausible logic axioms. Facing the challenge to reason on huge amount of noise and heterogeneous data, the DL fragment corresponding to Horn clauses, known as Description Logic Programs [25], can be a suitable choice.

Conjunctions and universal restrictions in the right hand side of inclusion axioms are converted into rule heads ( classes), whilst conjunction, disjunction and existential restriction appearing in the left-hand side are translated into rule bodies ( classes). Figure 1 presents the mapping function from DL to strict rules in a plausible knowledge base, where , and are concepts such that , , is an atomic concept, , and are variables, and and are roles.

Figure 1. Mapping from DL ontologies into strict rules.

Figure 1. Mapping from DL ontologies into strict rules.

If is subsumed by , then each individual in is also an instance of the class . The axiom says that, with certainty, all the roles point towards individuals of type . It is translated in second line of Figure 1 as: if there is a relation between and , the element should be of type . Similar semantics is applied for the inverse role , where the domain and range are interchanged. If is interpreted as a concept, then is of type . The role assertion is interpreted as the two individuals and being in relation . The mapping of role subsumption outputs that given two elements and in relation , they are linked by the more general relation . The transitivity property of roles says that if the instance is related to by the role and if is related to by the same role, then it is necessary that is related to by the same role .

4. Data Stream Management System in Haskell

This section details the architecture of the PSRH (Plausible Stream Reasoning in Haskell) system (Figure 2). For each problem, a domain expert is responsible to define the priorities and the plausible rules in order to handle contradictory data. The mapping module translates the available ontologies into facts and strict rules. The stream module provides a collection of functions for manipulating the input data streams. The relevant sensor-based measurements are stored as facts in the plausible theory. The decisive plausible tool is continuously queried in order to support plausible decisions in real-time. Each module described in the following paragraphs is built on top of the Haskell platform.

Figure 2. The architecture of the PSRH (Plausible Stream Reasoning in Haskell).

Figure 2. The architecture of the PSRH (Plausible Stream Reasoning in Haskell).

4.1. The Haskell Platform

The advantages that Haskell brings in this landscape—lazy evaluation and implicit parallelism—are significant features when dealing with huge data streams that are parallel in nature. The parallel performing of reasoning tasks is of significant importance in order to provide answers in due time [3]. The Haskell’s polymorphism allows to write generic code to process streams, which is particularly useful due to the different usages of the same data stream. The absence of side effects means that the order of expression evaluation is of no importance, which is extremely desirable in the context of data streams coming from different sources.

One challenge in answering many continuous queries in real-time is query optimisation. Allowing equational reasoning, the platform can be exploited for automatic program and optimising queries. A premise specified as lazy is matched only when its variables are anticipating to participate in the answer to a pending conclusion or query.

The continuous semantics of data streams assumes that: (i) streams are volatile—they are consumed on the fly and not stored forever; and (ii) continuous processing—queries are registered and produce answers continuously [5]. In our case, the rules are triggered continuously in order to produce streams of consequents. The stateless feature of pure Haskell facilitates the conceptual model of networks of stream reasoners as envisaged in [26], where data is processed on the fly, without being stored.

The lazy evaluation in Haskell provides answers perpetually, when the queries are executed against infinite streams. One does not have to specify the time steps when the query should be executed. By default, the tuples are consumed when they become available, and only in case they contribute to a query answer.

The computational efficiency is supported by the fact that a function is not forced to wait for a data to arrive—the possible computations are executed instead. Moreover, one can use the about-to-come data by borrowing it from the future, as long as no function tries to change its value. The non-strict semantics of Haskell allows the functions not to produce errors that can be avoided. Consequently, some noise data can be avoided, without disturbing the computations.

There is no constraint on the nature of data fed by a stream. The functions can be applied on RDF streams as follows: A triple object is created by the triple function

Definition 4 An RDF stream is an infinite list of tuples of the form annotated with their time stamps .

Example 3 An RDF stream of auction bids comprises the bidder agent, its action (sell or buy), and the bid value:

In the first tuple the agent wants to sell a specific item for 30$, the offer being made at the time step 14.32. The stream is implemented with the infinite list data structure in Haskell.

4.2. Streams Module

Table 2 illustrates the operators provided by Haskell to manipulate infinite streams. The basic operators allow to construct infinite streams or to extract elements from the input stream. The high order functions map, inter, scan, and transp allow to apply different transformations on the input streams.

Table 2. Stream operators in Haskell (  stands for the  datatype).

Type	Function	Signature
Basic	constructor	::a -  S a -  Sa
	extract the first element	head:: S a -  a
	extracts the sequence following the stream’s head	tail:: S a -  S a
	takes a stream and returns all its finite prefixes	inits :: S a -  S ([a])
	takes a stream and returns all its suffixes	tails :: S a -  S (S a)
Transformation	applies a function over all elements	map :: (a -  b) -  S a -  S b
	interleaves 2 streams	inter :: Stream a -  Stream a -  S a
	yields a stream of successive reduced values	scan :: (a -  b -  a) -  a -  S b -  S a
	computes the transposition of a stream of streams	transp :: S (S a) -  S (S a)
Building streams	repeated applications of a function	iterate :: (a -  a) -  a -  S a
	constant streams	repeat :: a -  S a
	returns the infinite repetition of a set of values	cycle :: [a] -  S a
Extracting sublists	takes the first elements	take :: Int -  S a -  [a]
	drops the first elements	drop :: Int -  S a -  S a
	returns the longest prefix for which p holds	takeWhile :: (a -  Bool) -  S a -  [a]
	returns the suffix remaining after takeWhile	dropWhile :: (a -  Bool) -  S a -  S a
	removes elements that do not satisfy p	filter :: a -  Bool) -  S a -  S a
Index	returns the element of the stream at index n	!!:: S a -  Int -  a
	returns the index of the first element equal with	elemIndex :: Eq a =  a -  S a -  Int
	returns the index of the first element satisfying p	findIndex :: (a -  Bool) -  S a -  Int
Aggregation	returns a list of corresponding pairs from 2 streams	zip :: S a -  S b -  S (a,b)
	combines two streams based on a given function	ZipWith :: (a -  b -  c) -  S a -  S b -  S c

Table 2. Stream operators in Haskell (  stands for the  datatype).

Type	Function	Signature
Basic	constructor	::a -  S a -  Sa
	extract the first element	head:: S a -  a
	extracts the sequence following the stream’s head	tail:: S a -  S a
	takes a stream and returns all its finite prefixes	inits :: S a -  S ([a])
	takes a stream and returns all its suffixes	tails :: S a -  S (S a)
Transformation	applies a function over all elements	map :: (a -  b) -  S a -  S b
	interleaves 2 streams	inter :: Stream a -  Stream a -  S a
	yields a stream of successive reduced values	scan :: (a -  b -  a) -  a -  S b -  S a
	computes the transposition of a stream of streams	transp :: S (S a) -  S (S a)
Building streams	repeated applications of a function	iterate :: (a -  a) -  a -  S a
	constant streams	repeat :: a -  S a
	returns the infinite repetition of a set of values	cycle :: [a] -  S a
Extracting sublists	takes the first elements	take :: Int -  S a -  [a]
	drops the first elements	drop :: Int -  S a -  S a
	returns the longest prefix for which p holds	takeWhile :: (a -  Bool) -  S a -  [a]
	returns the suffix remaining after takeWhile	dropWhile :: (a -  Bool) -  S a -  S a
	removes elements that do not satisfy p	filter :: a -  Bool) -  S a -  S a
Index	returns the element of the stream at index n	!!:: S a -  Int -  a
	returns the index of the first element equal with	elemIndex :: Eq a =  a -  S a -  Int
	returns the index of the first element satisfying p	findIndex :: (a -  Bool) -  S a -  Int
Aggregation	returns a list of corresponding pairs from 2 streams	zip :: S a -  S b -  S (a,b)
	combines two streams based on a given function	ZipWith :: (a -  b -  c) -  S a -  S b -  S c

For instance, the map function converts each element within a stream, according to a given conversion function. The conversion takes place when the converted values are required by other function. Based on a given operation, the scan function aggregates the elements within a stream into a single value. For computing at each step the sum of a stream of transactional data, the following expression can be used:

It provides as output the infinite stream , where the current value sums all the previously ones.

The aggregation functions combine elements from two input streams in order to generate a continuous output stream. Consider one wants to add the corresponding values from two financial data streams and , expressed by two different currencies:

where the conversion function is applied on each element from .

The aggregation of two streams takes place according to an aggregation policy, depending on the time or the configuration of the new tuples. The policy is a function provided as the first input argument for the high order function zipWith, which has three input parameters and one output:

The elements of the input streams are combined according to the policy. The zipWith function continuously produces the output stream outStream with the elements from the input streams inStream1 and inStream2 aggregated based on the given policy. Similarly, generating new streams can be done based on a policy f, as in: . An incoming stream can be dynamically split into two streams, based on a predicate p.

4.3. The Mapping Module

Two sources of knowledge are exploited to reason on data collected by the sensors. On the one hand, one needs detailed information about sensors, measurements domain and units, or accuracy. On the other hand, domain specific axioms are exploited when reasoning on a specific scenario.

A partial view of the sensor ontology is formalised in DL in Figure 3. Figure 4 graphically illustrates the TBox and ABox of the ontology. The sensor is an instance of the class ActiveRDF and it measures temperature with an accuracy of 0.5 C. The current temperature is 6 C, and the measurement frequency is six observations per minute (Figure 4). Noting that Temperature is a PhysicalQuality (axiom 9 in Figure 3), there is a role measure between the sensor and the temperature value , as axiom 1 defines. The corresponding RDF stream for the sensor looks like:

where at each 10 seconds the measured value increases with one degree Celsius, from 4 C to 6 C.

The ontology is translated into strict rules based on the conceptual instrumentation introduced in Section 3.3, in order to reason only within plausible logic. The resulted strict rules and facts appear in Figure 5. Observe that the terminology is considered static, whilst assertions may vary in time in Figure 5.

Rapid developments of the sensor technology raises the problem of continuously updating the sensor ontology. The system is able to handle this situation by treating the ontology as a stream of description logic axioms. When applying the high order function on the transformation function , each axiom in the description logic is converted to strict rules as soon as it appears:

outputs the infinite list:

The main advantage consists in the possibility to dynamically include new background knowledge in the system.

Figure 3. Partial view of the sensor ontology.

Figure 3. Partial view of the sensor ontology.

Figure 4. Graphical view of the sensor ontology.

Figure 4. Graphical view of the sensor ontology.

Figure 5. Translating the sensor ontology.

Figure 5. Translating the sensor ontology.

4.4. Efficiency Remarks

The system incorporates the Decisive Plausible Logic tool [27] A Haskell glue module that exports functions requesting proofs [28] is used to make the connection with the other modules. The efficiency is mandatory when one needs to reason on huge data in real time. The efficiency of the proposed solution is based on the following vectors:

• The implementation of a family of defeasible logic is polynomial [7]. Plausible logic, being a particular case of defeasible reasoning, belongs to this efficiency class. The extensive experiments in [7] have proved that the family of defeasible reasoning tools that we integrated in our framework can deal with knowledge bases up to hundreds of thousands of rules, with a theoretical complexity of O(N log N). The cpu time for proving a conclusion was 0.4 seconds in case of 4200 contradictory rules, 3.83 seconds for 42,000 rules, and 21.15 seconds for 210,000 rules. This cpu time includes the time consumed by the garbage collector in Haskell [7].
• Under the assumption that the domain is static, the translation from description logic axioms into strict rules can be performed offline, before taking real-time decisions. The resulted Description Logic Programs are sub-fragments of Horn logics and their complexity is polynomial, as reported in [8].
• Only few general ontologies and few medical ontologies have this size. Most of the domain ontologies do no reach the comparable size of 4200 axioms. Depending on the time constraints for the given problem, a smaller ontology can be imported instead of a refined one.
• The plausible rules and preferences added by the human expert also do not go up to thousands of rules. Given the experience from the expert systems domain, few of the existing commercial expert systems do contain thousands of rules [28].
• The possibility to select the current inference algorithm among can also be exploited to adjust the reasoning task to the complexity of the current real-time decision.

5. Running Scenario

The scenario regards supporting real-time supply chain decisions based on RFID streams. Consider the stock management of an online shop. RFID sensors are used to count the items entering the warehouse from two locations. The items leave the warehouse from exit points, corresponding to three output streams. Monitoring an item like Milk implies monitoring several subcategories as WholeMilk and LowFatMilk. The retailer sells a specific item of whole milk, and two types of low fat milk and . Some peak periods are associated to each commercialised item.

This background knowledge is formalised in Figure 6. The corresponding strict rules are depicted in the upper part of the Figure 7. During peak periods for an item, the usual supply action is blocked by the defeater . The plausible rule says that if the milk stock is below the alert threshold , the NormalSupply action should be executed. NormalSupply assures a stock value of . Instead, the PeakSupply action is derived by the rule .

Figure 6. Domain knowledge sample for milk monitoring.

Figure 6. Domain knowledge sample for milk monitoring.

Figure 7. Plausible knowledge base.

Figure 7. Plausible knowledge base.

If there is an alternative itemZ for the Milk product and the stock of the alternative is larger than the threshold , this implies not to supply the higher quantity (the rule ). Whether the action is executed or not depends on the priority relation between the rules and ,

The sensor related information can be integrated when reasoning. If the sensor S seems not to function according to the specifications in the ontology, it is plausible to be broken (the rule ). A broken sensor defeats the stock information asserted in the knowledge base related to the measured item (the defeater ).

The merchandise flow is simulated by generating infinite input and output streams. Assuming that the function based on the list of available items returns a random item. The infinite output stream for the payment point would be:

where l is a list with the available items in the simulation. Consider the following RDF stream of sold items (item sold price) and the associated time of measurement, where the predicate sold and the price value are removed for clarity reasons:

The updateStock function continuously computes the current stocks based on the stream. Based on the fact and the rule , one can conclude that is a milk item. Similarly, based on the facts and , the rule categorises the instances and as milk items. The filter function is used to monitor each milk item, either low fat or not:

Here, the predicate milk returns true if the input is of type Milk according to the rules or . The map function is used to select only the element item from the tuples from the stream : the composition is used to extract the first element in the first tuple.

The stream milkItems collects all the items of type milk every time an item occurs. Based on , the milkItems is:

The function is activated to compute the available stock for a specific category of products. Consider the current stock for milk is 102 and the threshold for triggering the alarm is 100. Assume the function updateStock is called with the first input parameter milk and the second parameter milkItems. At time 1, being low fat milk, identified as a subtype of milk, the stock is updated at the value 101. At instance 3, being fat milk, identified also as a subtype of milk, the stock is updated at the value 100. At time step 6, , the stock value reaches . At this moment, the predicate becomes valid.

Consequently, the rule in Figure 7 is plausibly activated. The algorithm checks whether any defeater or stronger rule can block the derivation of the conclusion of the rule . If no one blocks it, the action normalSupply for milk of value is executed. If, for instance in case of a peak period, the defeater is active, since is stronger than the rule , it successfully blocks the derivation of the action normalSupply. Instead, the consequent of the rule will be executed.

Thus, by combining ontological knowledge with plausible rules, one can reason with generic products (Milk), even if the streams report data regarding instances of specific products (WholeMilk and LowFatMilk). The benefit here consists in minimising the number of business rules that should be added within the system.

The current implementation was tested only on the above proof of concept scenario. The scenario involves a small number of axioms from the sensor ontology and from the milk-domain ontology, and also few plausible rules manually constructed to test the plausible reasoning mechanism. For the simulated ten streams of items with a time delay of 1 s for each item, the decision was taken in real time.

6. Conclusions

The proposed semantic based stream management system is characterised by: (i) continuous situation awareness and capability to handle theoretically infinite data streams due to the lazy evaluation mechanism; (ii) aggregating heterogeneous sensors based on the ontologies translated as strict rules; (iii) handling noise and contradictory information inherently in the context of many sensors, due to the plausible reasoning mechanism. The system represents a step towards building real-time stream processors for knowledge-rich applications.

With streams being approximate, omniscient rationality is not assumed when performing reasoning tasks on streams. Consequently, we argue that plausible reasoning for real time decision making is adequate. One particularity of our system consists of applying an efficient non-monotonic rule based system [7] when reasoning on gradually occurring stream data. The inference is based on several algorithms, which is in line with the proof layers defined in the Semantic Web stack. Moreover, all the Haskell language is available to extend or adapt the existing code. The efficiency of data driven computation in functional reactive programming is supported by the lazy evaluation mechanism, which allows to use values before they can be known.

In order to apply our PSRH system to a different domain, three tasks are necessary:

• to translate the domain specific ontologies into strict rules, which is automatically performed by the mapping module;
• to design plausible rules and priorities by a domain expert;
• to import the most adequate sensor ontology for the current problem (for instance SWEET or W3S SSN Ontology).

During the translation part, some knowledge from the ontology may be lost. The axioms stating a subclass of a complex class which is a disjunction cannot be translated into PL, as in . Also, subclases of a complex class expression which is existential quantified cannot be translated, such as . Our solution allows this limitation of expressivity in order to perform reasoning in real time within the efficient plausible logic framework.

The current implementation was tested only on the proof of concept scenario described in Section 5. More extensive experiments are needed to test the large scale efficiency and scalability of the proposed system. At the moment, we are able to support our solution based on the results reported in [7] and based on the reduced complexity of description logic programs [8].