Next Article in Journal
Next Article in Special Issue
Previous Article in Journal
Previous Article in Special Issue

Future Internet 2012, 4(4), 865-881; doi:10.3390/fi4040865

Article
Plausible Description Logic Programs for Stream Reasoning
Adrian Groza * and Ioan Alfred Letia
Department of Computer Science Technical University of Cluj-Napoca Memorandumului 28 Cluj-Napoca 400391 Romania; Email: letia@cs-gw.utcluj.ro
*
Author to whom correspondence should be addressed; Email: adrian.groza@cs.utcluj.ro; Tel.: +40-264-401-446.
Received: 9 August 2012; in revised form: 9 September 2012 / Accepted: 25 September 2012 /
Published: 17 October 2012

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.
Keywords:
stream reasoning; description logic; plausible logic; lazy evaluation; sensors; 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 Futureinternet 04 00865 i001 is the disjunction of positive or negative atoms Futureinternet 04 00865 i002. 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 Futureinternet 04 00865 i003, where Futureinternet 04 00865 i004 is a set of contingent clauses, called axioms, characterising the aspects of the situation that are certain, Futureinternet 04 00865 i005 is a set of plausible rules, Futureinternet 04 00865 i006 is a set of defeater rules, and Futureinternet 04 00865 i007 is a priority relation on Futureinternet 04 00865 i008.

A plausible theory is computed from a plausible description by deriving the set Futureinternet 04 00865 i009 of strict rules from the definite facts Futureinternet 04 00865 i004. Thus, a plausible knowledge base consists of strict rules ( Futureinternet 04 00865 i010), plausible rules ( Futureinternet 04 00865 i011), defeater (warning) rules ( Futureinternet 04 00865 i012), and a priority relation on the rules ( Futureinternet 04 00865 i007). 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 Futureinternet 04 00865 i013 means that if all the antecedents Futureinternet 04 00865 i002 are proved and all the evidence against the consequent Futureinternet 04 00865 i014 has been defeated, then Futureinternet 04 00865 i014 can be deduced. The plausible conclusion Futureinternet 04 00865 i014 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 Futureinternet 04 00865 i007 allows the representation of preferences among non-strict rules.

Decisive plausible logic consists of a plausible theory and a proof function Futureinternet 04 00865 i015 that, given a proof algorithm Futureinternet 04 00865 i016 and a formula Futureinternet 04 00865 i017 in conjunctive normal form, returns Futureinternet 04 00865 i018 if Futureinternet 04 00865 i019 was proved, Futureinternet 04 00865 i020 if there is no proof for Futureinternet 04 00865 i019, or 0 when Futureinternet 04 00865 i019 is undecidable due to looping. Plausible Logic has five proof algorithms Futureinternet 04 00865 i021, in which one is monotonic and four are non-monotonic: Futureinternet 04 00865 i022 monotonic, strict, like classical logic; Futureinternet 04 00865 i023; Futureinternet 04 00865 i024 plausible, propagating-ambiguity; Futureinternet 04 00865 i025 plausible, blocking-ambiguity; and Futureinternet 04 00865 i026.

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

  • Futureinternet 04 00865 i028

  • Futureinternet 04 00865 i029

  • Futureinternet 04 00865 i030

  • Futureinternet 04 00865 i031

  • Futureinternet 04 00865 i032

The rule Futureinternet 04 00865 i033 is a strict one: whenever the temperature Futureinternet 04 00865 i034 measured by the sensor Futureinternet 04 00865 i035 is above 4 Futureinternet 04 00865 i036C the alarm starts automatically. The rule Futureinternet 04 00865 i037 is a plausible one: if the measured temperature is above 0 Futureinternet 04 00865 i036C, 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 Futureinternet 04 00865 i038 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 Futureinternet 04 00865 i039 is a defeater that, in case of activation, blocks the derivation of the conclusion Futureinternet 04 00865 i040. If active, Futureinternet 04 00865 i039 being stronger than Futureinternet 04 00865 i038 is able to block the corresponding decision. At this moment the consequence of the rule Futureinternet 04 00865 i037 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 Futureinternet 04 00865 i041, 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, Futureinternet 04 00865 i042 and Futureinternet 04 00865 i043 represent concept descriptions, whilst Futureinternet 04 00865 i044 and Futureinternet 04 00865 i045 role names. In this study we used the extension of Futureinternet 04 00865 i041 with transitivity ( Futureinternet 04 00865 i046) on roles and role hierarchy ( Futureinternet 04 00865 i047), known as Futureinternet 04 00865 i048 or Futureinternet 04 00865 i049. The syntax of Futureinternet 04 00865 i049 is defined by the following grammar:

Futureinternet 04 00865 i050
where Futureinternet 04 00865 i051 represents an atomic concept and Futureinternet 04 00865 i052 the top level concept.

The semantics is defined based on an interpretation Futureinternet 04 00865 i053, where the domain Futureinternet 04 00865 i054 of Futureinternet 04 00865 i055 contains a non-empty set of individuals, whilst the interpretation function Futureinternet 04 00865 i056 maps each concept name Futureinternet 04 00865 i042 to a set of individuals Futureinternet 04 00865 i057 and each role Futureinternet 04 00865 i044 to a binary relation Futureinternet 04 00865 i058. The second column of Table 1 illustrates the extension of Futureinternet 04 00865 i056 to arbitrary concepts.

Table Table 1. Syntax and Semantics of Futureinternet 04 00865 i049 concepts.

Click here to display table

Table 1. Syntax and Semantics of Futureinternet 04 00865 i049 concepts.
SyntaxSemantics
Futureinternet 04 00865 i059 Futureinternet 04 00865 i060
Futureinternet 04 00865 i061 Futureinternet 04 00865 i062
Futureinternet 04 00865 i063 Futureinternet 04 00865 i064
Futureinternet 04 00865 i065 Futureinternet 04 00865 i066
Futureinternet 04 00865 i067 Futureinternet 04 00865 i068
Futureinternet 04 00865 i069 Futureinternet 04 00865 i070
Futureinternet 04 00865 i071 Futureinternet 04 00865 i072

Definition 2 A concept Futureinternet 04 00865 i042 is satisfiable if there exists an interpretation Futureinternet 04 00865 i055 such that Futureinternet 04 00865 i073. The concept Futureinternet 04 00865 i043 subsumes the concept Futureinternet 04 00865 i042 ( Futureinternet 04 00865 i074) if Futureinternet 04 00865 i075 for all interpretations Futureinternet 04 00865 i055.

Definition 3 An Futureinternet 04 00865 i076 is a finite set of concept assertions Futureinternet 04 00865 i077 or role assertions Futureinternet 04 00865 i078, where Futureinternet 04 00865 i042 represents a concept, Futureinternet 04 00865 i044 a role, and Futureinternet 04 00865 i079 and Futureinternet 04 00865 i080 are two instances. Usually, the unique name assumption holds within the same Futureinternet 04 00865 i076. A Futureinternet 04 00865 i081 is a finite set of terminological axioms of the form Futureinternet 04 00865 i082 or Futureinternet 04 00865 i074.

Example 2 Consider the domain Futureinternet 04 00865 i083. Let the terminology:

Futureinternet 04 00865 i084
Futureinternet 04 00865 i085
The interpretation function treats the individual Futureinternet 04 00865 i086 as a wireless sensor with the measurement accuracy of 0.1 Futureinternet 04 00865 i036C, 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 Futureinternet 04 00865 i086 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 ( Futureinternet 04 00865 i087 classes), whilst conjunction, disjunction and existential restriction appearing in the left-hand side are translated into rule bodies ( Futureinternet 04 00865 i088 classes). Figure 1 presents the mapping function Futureinternet 04 00865 i089 from DL to strict rules in a plausible knowledge base, where Futureinternet 04 00865 i051, Futureinternet 04 00865 i042 and Futureinternet 04 00865 i043 are concepts such that Futureinternet 04 00865 i090, Futureinternet 04 00865 i091, Futureinternet 04 00865 i051 is an atomic concept, Futureinternet 04 00865 i092, Futureinternet 04 00865 i093 and Futureinternet 04 00865 i094 are variables, and Futureinternet 04 00865 i095 and Futureinternet 04 00865 i096 are roles.

Futureinternet 04 00865 g001 1024
Figure 1. Mapping from DL ontologies into strict rules.

Click here to enlarge figure

Figure 1. Mapping from DL ontologies into strict rules.
Futureinternet 04 00865 g001 1024

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

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.

Futureinternet 04 00865 g002 1024
Figure 2. The architecture of the PSRH (Plausible Stream Reasoning in Haskell).

Click here to enlarge figure

Figure 2. The architecture of the PSRH (Plausible Stream Reasoning in Haskell).
Futureinternet 04 00865 g002 1024

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

Futureinternet 04 00865 i104

Definition 4 An RDF stream is an infinite list of tuples of the form Futureinternet 04 00865 i105 annotated with their time stamps Futureinternet 04 00865 i106.

Futureinternet 04 00865 i107

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

Futureinternet 04 00865 i108
In the first tuple the agent Futureinternet 04 00865 i109 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 Table 2. Stream operators in Haskell ( Futureinternet 04 00865 i110 stands for the Futureinternet 04 00865 i111 datatype).

Click here to display table

Table 2. Stream operators in Haskell ( Futureinternet 04 00865 i110 stands for the Futureinternet 04 00865 i111 datatype).
TypeFunctionSignature
Basicconstructor Futureinternet 04 00865 i112 ::a - Futureinternet 04 00865 i113 S a - Futureinternet 04 00865 i113 Sa
extract the first elementhead:: S a - Futureinternet 04 00865 i113 a
extracts the sequence following the stream’s headtail:: S a - Futureinternet 04 00865 i113 S a
takes a stream and returns all its finite prefixesinits :: S a - Futureinternet 04 00865 i113 S ([a])
takes a stream and returns all its suffixestails :: S a - Futureinternet 04 00865 i113 S (S a)
Transformationapplies a function over all elementsmap :: (a - Futureinternet 04 00865 i113 b) - Futureinternet 04 00865 i113 S a - Futureinternet 04 00865 i113 S b
interleaves 2 streamsinter :: Stream a - Futureinternet 04 00865 i113 Stream a - Futureinternet 04 00865 i113 S a
yields a stream of successive reduced valuesscan :: (a - Futureinternet 04 00865 i113 b - Futureinternet 04 00865 i113 a) - Futureinternet 04 00865 i113 a - Futureinternet 04 00865 i113 S b - Futureinternet 04 00865 i113 S a
computes the transposition of a stream of streamstransp :: S (S a) - Futureinternet 04 00865 i113 S (S a)
Building streamsrepeated applications of a functioniterate :: (a - Futureinternet 04 00865 i113 a) - Futureinternet 04 00865 i113 a - Futureinternet 04 00865 i113 S a
constant streamsrepeat :: a - Futureinternet 04 00865 i113 S a
returns the infinite repetition of a set of valuescycle :: [a] - Futureinternet 04 00865 i113 S a
Extracting subliststakes the first elementstake :: Int - Futureinternet 04 00865 i113 S a - Futureinternet 04 00865 i113 [a]
drops the first elementsdrop :: Int - Futureinternet 04 00865 i113 S a - Futureinternet 04 00865 i113 S a
returns the longest prefix for which p holdstakeWhile :: (a - Futureinternet 04 00865 i113 Bool) - Futureinternet 04 00865 i113 S a - Futureinternet 04 00865 i113 [a]
returns the suffix remaining after takeWhiledropWhile :: (a - Futureinternet 04 00865 i113 Bool) - Futureinternet 04 00865 i113 S a - Futureinternet 04 00865 i113 S a
removes elements that do not satisfy pfilter :: a - Futureinternet 04 00865 i113 Bool) - Futureinternet 04 00865 i113 S a - Futureinternet 04 00865 i113 S a
Indexreturns the element of the stream at index n!!:: S a - Futureinternet 04 00865 i113 Int - Futureinternet 04 00865 i113 a
returns the index of the first element equal with Futureinternet 04 00865 i079elemIndex :: Eq a = Futureinternet 04 00865 i113 a - Futureinternet 04 00865 i113 S a - Futureinternet 04 00865 i113 Int
returns the index of the first element satisfying pfindIndex :: (a - Futureinternet 04 00865 i113 Bool) - Futureinternet 04 00865 i113 S a - Futureinternet 04 00865 i113 Int
Aggregationreturns a list of corresponding pairs from 2 streamszip :: S a - Futureinternet 04 00865 i113 S b - Futureinternet 04 00865 i113 S (a,b)
combines two streams based on a given functionZipWith :: (a - Futureinternet 04 00865 i113 b - Futureinternet 04 00865 i113 c) - Futureinternet 04 00865 i113 S a - Futureinternet 04 00865 i113 S b - Futureinternet 04 00865 i113 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:

Futureinternet 04 00865 i114

It provides as output the infinite stream Futureinternet 04 00865 i115, 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 Futureinternet 04 00865 i086 and Futureinternet 04 00865 i116, expressed by two different currencies:

Futureinternet 04 00865 i117
where the conversion function is applied on each element from Futureinternet 04 00865 i116.

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:

Futureinternet 04 00865 i118

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: Futureinternet 04 00865 i119. 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 Futureinternet 04 00865 i086 is an instance of the class ActiveRDF and it measures temperature with an accuracy of 0.5 Futureinternet 04 00865 i036C. The current temperature is 6 Futureinternet 04 00865 i036C, 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 Futureinternet 04 00865 i086 and the temperature value Futureinternet 04 00865 i120, as axiom 1 defines. The corresponding RDF stream for the sensor Futureinternet 04 00865 i086 looks like:

Futureinternet 04 00865 i121
where at each 10 seconds the measured value increases with one degree Celsius, from 4 Futureinternet 04 00865 i036C to 6 Futureinternet 04 00865 i036C.

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 Futureinternet 04 00865 i122 on the transformation function Futureinternet 04 00865 i089, each axiom in the description logic is converted to strict rules as soon as it appears:

Futureinternet 04 00865 i123
outputs the infinite list:
Futureinternet 04 00865 i124

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

Futureinternet 04 00865 g003 1024
Figure 3. Partial view of the sensor ontology.

Click here to enlarge figure

Figure 3. Partial view of the sensor ontology.
Futureinternet 04 00865 g003 1024
Futureinternet 04 00865 g004 1024
Figure 4. Graphical view of the sensor ontology.

Click here to enlarge figure

Figure 4. Graphical view of the sensor ontology.
Futureinternet 04 00865 g004 1024
Futureinternet 04 00865 g005 1024
Figure 5. Translating the sensor ontology.

Click here to enlarge figure

Figure 5. Translating the sensor ontology.
Futureinternet 04 00865 g005 1024

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 Futureinternet 04 00865 i021 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 Futureinternet 04 00865 i126 of whole milk, and two types of low fat milk Futureinternet 04 00865 i127 and Futureinternet 04 00865 i128. 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 Futureinternet 04 00865 i129. The plausible rule Futureinternet 04 00865 i130 says that if the milk stock Futureinternet 04 00865 i093 is below the alert threshold Futureinternet 04 00865 i131, the NormalSupply action should be executed. NormalSupply assures a stock value of Futureinternet 04 00865 i132. Instead, the PeakSupply action is derived by the rule Futureinternet 04 00865 i129.

Futureinternet 04 00865 g006 1024
Figure 6. Domain knowledge sample for milk monitoring.

Click here to enlarge figure

Figure 6. Domain knowledge sample for milk monitoring.
Futureinternet 04 00865 g006 1024
Futureinternet 04 00865 g007 1024
Figure 7. Plausible knowledge base.

Click here to enlarge figure

Figure 7. Plausible knowledge base.
Futureinternet 04 00865 g007 1024

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

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 Futureinternet 04 00865 i136). A broken sensor defeats the stock information asserted in the knowledge base related to the measured item (the defeater Futureinternet 04 00865 i137).

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

Futureinternet 04 00865 i140
where l is a list with the available items in the simulation. Consider the following RDF stream Futureinternet 04 00865 i086 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:
Futureinternet 04 00865 i141
Futureinternet 04 00865 i142

The updateStock function continuously computes the current stocks based on the Futureinternet 04 00865 i086 stream. Based on the fact Futureinternet 04 00865 i143 and the rule Futureinternet 04 00865 i038, one can conclude that Futureinternet 04 00865 i126 is a milk item. Similarly, based on the facts Futureinternet 04 00865 i144 and Futureinternet 04 00865 i145, the rule Futureinternet 04 00865 i039 categorises the instances Futureinternet 04 00865 i127 and Futureinternet 04 00865 i128 as milk items. The filter function is used to monitor each milk item, either low fat or not:

Futureinternet 04 00865 i146

Here, the predicate milk returns true if the input is of type Milk according to the rules Futureinternet 04 00865 i038 or Futureinternet 04 00865 i039. The map function is used to select only the element item from the tuples Futureinternet 04 00865 i147 from the stream Futureinternet 04 00865 i086: the composition Futureinternet 04 00865 i148 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 Futureinternet 04 00865 i086, the milkItems is:

Futureinternet 04 00865 i149

The Futureinternet 04 00865 i150 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 Futureinternet 04 00865 i131 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, Futureinternet 04 00865 i127 being low fat milk, identified as a subtype of milk, the stock is updated at the value 101. At instance 3, Futureinternet 04 00865 i126 being fat milk, identified also as a subtype of milk, the stock is updated at the value 100. At time step 6, Futureinternet 04 00865 i128, the stock value reaches Futureinternet 04 00865 i151. At this moment, the predicate Futureinternet 04 00865 i152 becomes valid.

Consequently, the rule Futureinternet 04 00865 i130 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 Futureinternet 04 00865 i130. If no one blocks it, the action normalSupply for milk of value Futureinternet 04 00865 i132 is executed. If, for instance in case of a peak period, the defeater Futureinternet 04 00865 i129 is active, since Futureinternet 04 00865 i129 is stronger than the rule Futureinternet 04 00865 i130, it successfully blocks the derivation of the action normalSupply. Instead, the consequent of the rule Futureinternet 04 00865 i134 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 Futureinternet 04 00865 i153. Also, subclases of a complex class expression which is existential quantified cannot be translated, such as Futureinternet 04 00865 i154. 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].

Acknowledgments

We are grateful to the anonymous reviewers for their useful comments. The work has been co-funded by the Sectoral Operational Programme Human Resources Development 2007–2013 of the Romanian Ministry of Labour, Family and Social Protection through the Financial Agreement POSDRU/89/1.5/S/62557.

References

  1. Christin, D.; Mogre, P.S.; Hollick, M. Survey on wireless sensor network technologies for industrial automation: The security and quality of service perspectives. Future Internet 2010, 2, 96–125. [Google Scholar] [CrossRef]
  2. Le-Phuoc, D.; Parreira, J.X.; Hausenblas, M.; Hauswirth, M. Unifying Stream Data and Linked Open Data; Technical Report for Digital Enterprise Research Institute (DERI): Galway, Ireland, 2010. [Google Scholar]
  3. Valle, E.D.; Ceri, S.; van Harmelen, F.; Fensel, D. It’s a streaming world! Reasoning upon rapidly changing information. IEEE Intell. Syst. 2009, 24, 83–89. [Google Scholar] [CrossRef]
  4. Granitzer, M.; Sabol, V.; Onn, K.W.; Lukose, D.; Tochtermann, K. Ontology alignment—A survey with focus on visually supported semi-automatic techniques. Future Internet 2010, 2, 238–258. [Google Scholar] [CrossRef]
  5. Barbieri, D.; Braga, D.; Ceri, S.; Valle, E.D.; Grossniklaus, M. Incremental reasoning on streams and rich background knowledge. Lect. Notes Comput. Sci. 2010, 6088, 1–15. [Google Scholar]
  6. Savage, N. Twitter as medium and message. Commun. ACM 2011, 54, 18–20. [Google Scholar] [CrossRef]
  7. Maher, M.J.; Rock, A.; Antoniou, G.; Billington, D.; Miller, T. Efficient defeasible reasoning systems. Int. J. Artif. Intell. Tools 2001, 10, 483–501. [Google Scholar] [CrossRef]
  8. Krötzsch, M.; Rudolph, S.; Hitzler, P. Complexity boundaries for horn descriptionl logics. In Proceedings of the 22nd national conference on Artificial intelligence, Toronto, Canada, 22–26 July 2012; AAAI Press: Palo Alto, CA, USA, 2007; pp. 452–457. [Google Scholar]
  9. Letia, I.A.; Groza, A. Description Plausible Logic Programs for Stream Reasoning; Filipe, J., Fred, A.L.N., Eds.; SciTePress: Setubal, Portugal, 2012; pp. 560–566. [Google Scholar]
  10. Calbimonte, J.P.; Corcho, Ó.; Gray, A.J.G. Enabling ontology-based access to streaming data sources. Lect. Notes Comput. Sci. 2010, 6496, 96–111. [Google Scholar]
  11. Palopoli, L.; Terracina, G.; Ursino, D. A plausibility description logic for handling information sources with heterogeneous data representation formats. Ann. Math. Artif. Intell. 2003, 39, 385–430. [Google Scholar]
  12. Heintz, F.; Kvarnström, J.; Doherty, P. Stream reasoning in DyKnow: A knowledge processing middleware system. In Presented at 1st International Workshop on Stream Reasoning,, Heraklion, Crete, Greece, 31 May 2009.
  13. Bolles, A.; Grawunder, M.; Jacobi, J. Streaming SPARQL extending SPARQL to process data streams. Lect. Notes Comput. Sci. 2008, 5021, 448–462. [Google Scholar]
  14. Anicic, D.; Fodor, P.; Rudolph, S.; Stühmer, R.; Stojanovic, N.; Studer, R. A rule-based language for complex event processing and reasoning. Lect. Notes Comput. Sci. 2010, 6333, 42–57. [Google Scholar]
  15. Anicic, D.; Rudolph, S.; Fodor, P.; Stojanovic, N. Retractable complex event processing and stream reasoning. Lect. Notes Comput. Sci. 2011, 6826, 122–137. [Google Scholar]
  16. Corcho, Ó.; Garcia-Castro, R. Five challenges for the Semantic Sensor Web. Semant. Web 2010, 1, 121–125. [Google Scholar]
  17. ASPIRE Project (Advanced Sensors and lightweight Programmable middleware for Innovative Rfid Enterprise applications). Available online: http://www.fp7-aspire.eu/ (accessed on 15 October 2012).
  18. Sensei Project. Available online: http://www.ict-sensei.org/Sensei090422/ (accessed on 15 October 2012).
  19. Ruta, M.; Colucci, S.; Scioscia, F.; Sciascio, E.D.; Donini, F.M. Finding commonalities in RFID semantic streams. Procedia Comput. Sci. 2011, 5, 857–864. [Google Scholar] [CrossRef]
  20. Rock, A. Implementation of Decisive Plausible Logic; Technical Report for School of Information and Communication Technology, Griffith University: South Brisbane, Australia, 2010. [Google Scholar]
  21. Billington, D.; Rock, A. Propositional plausible logic: Introduction and implementation. Stud. Log. 2001, 67, 243–269. [Google Scholar] [CrossRef]
  22. Governatori, G.; Maher, M.J.; Antoniou, G.; Billington, D. Argumentation semantics for defeasible logic. J. Log. Comput. 2004, 14, 675–702. [Google Scholar] [CrossRef]
  23. Baader, F.; Calvanese, D.; McGuinness, D.; Nardi, D.; Patel-Schneider, P. The Description Logic Handbook: Theory, Implementation and Applications; Cambridge University Press: New York, NY, USA, 2003. [Google Scholar]
  24. Gomez, S.A.; Chesnevar, C.I.; Simari, G.R. A defeasible logic programming approach to the integration of rules and ontologies. J. Comput. Sci. Technol. 2010, 10, 74–80. [Google Scholar]
  25. Grosof, B.N.; Horrocks, I.; Volz, R.; Decker, S. Description logic programs: Combining logic programs with description logic. In Proceedings of the 12th international conference on World Wide Web, Budapest, Hungary, 20–24 May 2003; pp. 48–57.
  26. Stuckenschmidt, H.; Ceri, S.; Valle, E.D.; van Harmelen, F. Towards expressive stream reasoning. In Semantic Challenges in Sensor Networks; Aberer, K., Gal, A., Hauswirth, M., Sattler, K.U., Sheth, A.P., Eds.; Schloss Dagstuhl—Leibniz-Zentrum fuer Informatik: Dagstuhl, Germany, 2010. [Google Scholar]
  27. Decisive Plausible Logic Tool. Available online: http://www.ict.griffith.edu.au/arock/DPL/ (accessed on 15 October 2012).
  28. De Hoog, R. Expert Systems—Past, Present, and Future; Technical Report for Metis, University of Amsterdam: Amsterdam, the Netherlands, 2003. [Google Scholar]
Future Internet EISSN 1999-5903 Published by MDPI AG, Basel, Switzerland RSS E-Mail Table of Contents Alert