Reactive Multi-Context Systems:
Heterogeneous Reasoning in Dynamic Environments
Managed multi-context systems (mMCSs) allow for the integration of heterogeneous knowledge sources in a modular and very general way. They were, however, mainly designed for static scenarios and are therefore not well-suited for dynamic environments in which continuous reasoning over such heterogeneous knowledge with constantly arriving streams of data is necessary. In this paper, we introduce reactive multi-context systems (rMCSs), a framework for reactive reasoning in the presence of heterogeneous knowledge sources and data streams. We show that rMCSs are indeed well-suited for this purpose by illustrating how several typical problems arising in the context of stream reasoning can be handled using them, by showing how inconsistencies possibly occurring in the integration of multiple knowledge sources can be handled, and by arguing that the potential non-determinism of rMCSs can be avoided if needed using an alternative, more skeptical well-founded semantics instead with beneficial computational properties. We also investigate the computational complexity of various reasoning problems related to rMCSs. Finally, we discuss related work, and show that rMCSs do not only generalize mMCSs to dynamic settings, but also capture/extend relevant approaches w.r.t. dynamics in knowledge representation and stream reasoning.
eterogeneous knowledge, Stream reasoning, Knowledge integration, Reactive systems, Dynamic systems
Fueled by initiatives such as the Semantic Web, Linked Open Data, and the Internet of Things, among others, the wide and increasing availability of machine-processable data and knowledge has prepared the ground and called for a new class of dynamic, rich, knowledge-intensive applications. Such new applications require automated reasoning based on the integration of several heterogeneous knowledge bases – possibly overlapping, independently developed, and written in distinct languages with different semantic assumptions – together with data/event streams produced by sensors and detectors, to be able to support automation and problem-solving, to enforce traceable and correct decisions, and to facilitate the internalization of relevant dynamic data and knowledge into such heterogeneous knowledge bases.
Consider a scenario where Dave, an elderly person suffering from dementia, lives alone in an apartment equipped with various sensors, e.g., smoke detectors, cameras, and body sensors measuring relevant body functions (e.g., pulse, blood pressure, etc.). An assisted living application in such a scenario could leverage the information continuously received from the sensors, together with Dave’s medical records stored in a relational database, a biomedical health ontology with information about diseases, their symptoms and treatments, represented in some description logic, some action policy rules represented as a non-monotonic logic program, to name only a few, and use it to detect relevant events, suggest appropriate action, and even raise alarms, while keeping a history of relevant events and Dave’s medical records up to date, thus allowing him to live on his own despite his condition. After detecting that Dave left the room while preparing a meal, the system could alert him in case he does not return soon, or even turn the stove off in case it detects that Dave fell asleep, not wanting to wake him up because his current treatment/health status values rest over immediate nutrition. Naturally, if Dave is not gone long enough, and no sensor shows any potential problems (smoke, gas, fire, etc.), then the system should seamlessly take no action.
Given the requirements posed by novel applications such as the one just described, the availability of a vast number of knowledge bases – written using many different formalisms – and the relevance of streams of data/events produced by sensors/detectors, modern research in knowledge representation and reasoning faces two fundamental problems: dealing with the integration of heterogeneous data and knowledge, and dealing with the dynamics of such novel knowledge-based systems.
The first problem stems from the availability of knowledge bases written in many different languages and formats developed over the last decades, from the rather basic ones, such as relational databases or the more recent triplestores, to the more expressive ones, such as ontology languages (e.g., description logics), temporal and modal logics, non-monotonic logics, or logic programs under answer set semantics, to name just a few. Each of these formalisms was developed for different purposes and with different design goals in mind. Whereas some of these formalisms could be combined to form a new, more expressive formalism, with features from its constituents – such as dl-programs Eiter et al. (2008) and Hybrid MKNF Motik and Rosati (2010) which, to different extent, combine description logics and logic programs under answer set semantics – in general this is simply not feasible, either due to the mismatch between certain assumptions underlying their semantics, or because of the high price to pay, often in terms of complexity, sometimes even in terms of decidability. It is nowadays widely accepted that there simply is no such thing as a single universal, general purpose knowledge representation language.
What seems to be needed is a principled way of integrating knowledge expressed in different formalisms. Multi-context systems (MCSs) provide a general framework for this kind of integration. The basic idea underlying MCSs is to leave the diverse formalisms and knowledge bases untouched, and to use so-called bridge rules to model the flow of information among different parts of the system. An MCS consists of reasoning units – called contexts for historical reasons Giunchiglia and Serafini (1994) – where each unit is equipped with a collection of bridge rules. In a nutshell, the bridge rules allow contexts to “listen” to other contexts, that is to take into account beliefs held in other contexts.
Bridge rules are similar to logic programming rules (including default negation), with an important difference: they provide means to access other contexts in their bodies. Bridge rules not only allow for a fully declarative specification of the information flow, but they also allow information to be modified instead of being just passed along as is. Using bridge rules we may translate a piece of information into the language/format of another context, pass on an abstraction of the original information, leaving out unnecessary details, select or hide information, add conclusions to a context based on the absence of information in another one, and even use simple encodings of preferences among parent contexts.
MCSs went through several development steps until they reached their present form. Advancing work in Giunchiglia (1993); McCarthy (1987) aiming to integrate different inference systems, monotonic heterogeneous multi-context systems were defined in Giunchiglia and Serafini (1994), with reasoning within as well as across monotonic contexts. The first, still limited attempts to include non-monotonic reasoning were done in Roelofsen and Serafini (2005); Brewka et al. (2007), where default negation in the rules is used to allow for reasoning based on the absence of information from a context.
The non-monotonic MCSs of Brewka and Eiter (2007) substantially generalize previous approaches, by accommodating heterogeneous and both monotonic and non-monotonic contexts. Hence, they are capable of integrating, among many others, “typical” monotonic logics like description logics or temporal logics, and non-monotonic formalisms like Reiter’s default logic, logic programs under answer set semantics, circumscription, defeasible logic, or theories in autoepistemic logic. The semantics of nonmonotonic MCSs is defined in terms of equilibria: a belief set for each context that is acceptable for its knowledge base augmented by the heads of its applicable bridge rules.
More recently, the so-called managed MCSs (mMCSs) Brewka et al. (2011) addressed a limitation of MCSs in the way they integrate knowledge between contexts. Instead of simply adding the head of an applicable bridge rule to the context’s knowledge base, which could cause some inconsistency, mMCSs allow for operations other than addition, such as, for instance, revision and deletion, hence dealing with the problem of consistency management within contexts.
The second problem stems from the shift from static knowledge-based systems that assume a one-shot computation, usually triggered by a user query, to open and dynamic scenarios where there is a need to react and evolve in the presence of incoming information.
Indeed, traditional knowledge-based systems – including the different variants of MCSs mentioned above – focus entirely on static situations, which is the right thing for applications such as for instance expert systems, configuration or planning problems, where the available background knowledge changes rather slowly, if at all, and where all that is needed is the solution of a new instance of a known problem. However, the new kinds of applications we consider are becoming more and more important, and these require continuous online reasoning, including observing and reacting to events.
There are some examples of systems developed with the purpose of reacting to streams of incoming information, such as Reactive ASP Gebser et al. (2011, 2012), C-SPARQL Barbieri et al. (2010), Ontology Streams Lécué and Pan (2013) and ETALIS Anicic et al. (2012), to name only a few. However, they are very limited in the kind of knowledge that can be represented, and the kind of reasoning allowed, hence unsuitable to address the requirements of the applications we envision, such as those that need to integrate heterogeneous knowledge bases. Additionally, reacting to the streams of incoming information is only part of the dynamic requirements of our applications. In many cases, the incoming information is processed only once, perhaps requiring complex reasoning using various knowledge bases to infer the right way to react, and does not have to be dealt with again – e.g., concluding that nothing needs to be done after determining that the tachycardia is caused by the decongestant recently taken by Dave. In other cases, it is important that these observations not only influence the current reaction of the system – do nothing in the previous example – but, at the same time, be able to change the knowledge bases in a more permanent way, i.e., allowing for the internalization of knowledge. For example, relevant observations regarding Dave’s health status should be added to his medical records, such as for example that he had an episode of tachycardia caused by a decongestant, and, in the future, maybe even revise such episode if it is found that Dave had forgotten to take the decongestant after all. Other more sophisticated changes in the knowledge bases include, for example, an update to the biomedical health ontology whenever new treatments are found or the revision of the policy rules whenever some exceptions are found. EVOLP Alferes et al. (2002) extends logic programming under answer set semantics with the possibility to specify its evolution, through successive updates, in reaction to external observations. It is nevertheless limited to a single knowledge representation formalism and to a single operation (update).
In this paper, we aim to address both challenges in a single, uniform approach. We develop a system that allows us to integrate heterogeneous knowledge bases with streams of incoming information and to use them for continuous online reasoning, reacting, and evolving the knowledge bases by internalizing relevant knowledge. In a nutshell, our work follows the multi-context systems tradition, but adds what is needed to also deal with dynamics.
To this end, we introduce reactive Multi-Context Systems (rMCSs). These systems build upon mMCSs and thus provide their functionality for integrating heterogeneous knowledge sources, admitting also operations for manipulating their knowledge bases. In addition, rMCSs can handle continuous streams of input data. Equilibria remain the fundamental underlying semantic notion, but the focus now lies on the dynamic evolution of the systems. Given an initial configuration of knowledge bases, that is, an initial knowledge base for each context, a specific input stream will lead to a corresponding stream of equilibria, generated by respective updates of the knowledge bases.
Contrary to existing MCSs which possess only one type of bridge rules modeling the information flow to be taken into account when computing equilibria (or the operations that need to be applied in case of mMCSs), rMCSs have an additional, different type of bridge rules, distinguished by the occurrence of the operator next in the head. Whereas the head of a managing bridge rule in mMCS specifies how a specific knowledge base should temporarily be changed for the purpose of determining the current equilibrium, the head of a new kind of bridge rule in rMCS with the operator next in the head specifies how the knowledge base should permanently be changed as the system moves to the next state. These new bridge rules allow us to decouple the computation of equilibria from specifying the evolution of knowledge base configurations.
It is often the case that the information currently available from some stream needs to be taken into account by some context when computing the semantics at that point. The way such information is taken into account is specified by a bridge rule with a management operation in its head, just as in mMCSs. For example, we may have some default value for some variable stored in a context, but, under some conditions (), prefer to use the value that is read from some sensor (observed in some stream) whenever one is available. This could be specified by the bridge rule (where is a management operation with the obvious meaning):
Whenever is observed in the stream, and holds, the would be matched, but only while is observed and holds, i.e., the management operation’s effects are not permanent. In subsequent states, if there was no observation for , or no longer holds, then would return to its original value. However, sometimes we may wish to specify some permanent change to the knowledge base of some context that persists beyond the state at which the pre-conditions were true, which is why a new form of bridge rule is needed. In the previous example, if under certain conditions () we want to internalize the current observation in a permanent way, i.e., permanently update the default value, then the following new kind of bridge rule would be specified:
The intuitive reading of this bridge rule is that whenever at some state both is true in the stream and condition holds, then the bridge rule’s context should be changed according to the operation when moving to the next state. These two different behaviors could not be achieved with a single kind of bridge rule since one of them aims at temporarily affecting the system at current state while the other one aims at permanently affecting the system from the subsequent state. Interestingly, the two kinds could be combined to specify that some current effect should be made permanent.
This new kind of bridge rule further allows the specification of the evolution of some context based on current conditions, which was not possible in mMCS. Suppose, for example, a single context that maintains a counter keeping track of how often the context was updated. With the new kind of bridge rule, we could simply write:
Assuming that the management operation has the intuitively expected meaning, using the bridge rule
would not work, as it would lead to the non-existence of equilibria. In mMCSs, one might think of a workaround that would overload the management function, but that would also require that the language of the context be extended, which might not be possible and is clearly at odds with the very idea of declarative knowledge representation. Additional examples showing the benefits of the next operator will be discussed in Sect. 3.2.
The main contributions of this paper can be summarized as follows:
We extend multi-context systems with the concepts relevant to deal with dynamics, ultimately leading to the notion of equilibria streams.
We introduce a new, second type of bridge rules using the operator next. This allows us to separate the computation of equilibria from the specification of the context evolution which provides a lot more modeling flexibility and leads to much more natural problem representations.
We study various forms of inconsistency, generalize existing inconsistency handling techniques to rMCSs and introduce several new ones.
For a subclass of rMCSs we define well-founded semantics as a skeptical, deterministic alternative to the equilibria-based semantics. The new semantics gives rise to so-called grounded equilibria streams.
We investigate the complexity of various problems related to rMCSs and provide a number of complexity results.
The paper is organized as follows. In Section 2, we introduce reactive MCSs, our framework for reactive reasoning in the presence of heterogeneous knowledge sources. In particular, we show how to integrate data streams into mMCSs and how to model the dynamics of our systems, based on two types of bridge rules. Section 3 illustrates how several typical problems arising in the context of stream reasoning can be handled using our framework. Reasoning based on multiple knowledge sources that need to be integrated faces the problem of potential inconsistencies. Section 4 discusses various methods for handling inconsistencies, with a special focus on non-existence of equilibria. In particular, we show how methods developed for mMCSs can be generalized to rMCSs. Nondeterminism in rMCSs is discussed in Section 5. One way of avoiding nondeterminism is by applying an alternative, skeptical semantics. We show how such a semantics, called well-founded semantics, can be defined for rMCSs, and what the effect of using this semantics instead of the original one is. The complexity of various problems related to rMCSs is investigated in Section 6. Section 7 discusses related work, with a special focus on two of the most relevant approaches w.r.t. stream reasoning, namely LARS (Logic-based framework for Analyzing Reasoning over Streams) Beck et al. (2015) and STARQL Özçep et al. (2013). Section 8 concludes and points out directions for future work.
This paper combines and unifies the results of Brewka et al. (2014) and Gonçalves et al. (2014b), two papers by different subsets of the authors describing independent adaptations of multi-context systems for dynamic environments. The approach developed here generalizes these earlier approaches and substantially improves on the presentation of the underlying concepts.
2 Reactive Multi-Context Systems
Reactive multi-context systems (rMCSs) make use of basic ideas from managed multi-context systems (mMCSs) Brewka et al. (2011) which extend multi-context systems (MCSs) as defined by Brewka and Eiter Brewka and Eiter (2007) by management capabilities. In particular, similar to mMCSs, we will make use of a management function and bridge rules that allow for conflict resolution between contexts as well as a fine-grained declarative specification of the information flow between contexts. To not unnecessarily burden the reader with repetitive material on these common components, we abstain from recalling the details of mMCSs first. It will be clear from the presentation when new concepts/ideas specific to rMCSs will be presented.
2.1 Specifying the Components of an rMCS
Similar as for previous notions of MCSs, we build on an abstract notion of a logic, which is a triple , where is the set of admissible knowledge bases of , is the set of possible belief sets, whose elements are called beliefs; and is a function describing the semantics of by assigning to each knowledge base a set of acceptable belief sets.111To ease readability, throughout the paper, we will often use the following convention when writing symbols: single entities are lower-case, while sets of entities and structures with different components are upper-case; in addition, sequences of those are indicated in sans serif, while notions with a temporal dimension are written in calligraphic letters (only upper-case, such as or ); finally, operators and functions are bold.
We illustrate how different formalisms we use in examples throughout the paper can be represented by the notion of a logic.
First, consider the case of description logics (DLs) as (commonly decidable) fragments of first-order logic Baader et al. (2007). Given a DL language , we consider the logic where is the set of all well-formed DL knowledge bases over , also called ontologies, is the set of deductively closed subsets of , and maps every to , where is the set of formulas in entailed by .
As an example for a non-deterministic formalism, consider logic programs under the answer set semantics Gelfond and Lifschitz (1991). Given a set of ground, i.e., variable-free, atoms , we use the logic such that is the set of all logic programs over . The set of possible belief sets is given by the set of possible answer sets and the function maps every logic program to the set of its answer sets.
Given a set of entries, a simple logic for storing elements from can be realized by the logic , such that , and maps every set to . Such can, e.g., be used to represent a simple database logic. We will call a logic of this type a storage logic.
In addition to a logic that captures language and semantics of a formalism to be integrated in an rMCS, a context also describes how a knowledge base belonging to the logic can be manipulated.
Definition 1 (Context)
A context is a triple where
is a logic,
is a set of operations,
is a management function.
For an indexed context we will write , , and to denote its components. Note that we leave the exact nature of the operations in unspecified – they can be seen as mere labels whose semantics is determined by the management function – and that we use a deterministic management function instead of a non-deterministic one, unlike mMCS Brewka et al. (2011).222Note that it is straightforward to adapt our definitions to use non-deterministic management functions. However, as they are not essential to our approach, we here refrain from doing so to keep notation simpler.
Consider the assisted living scenario from the Introduction in which we want to recognize potential threats caused, e.g., by overheating of the stove. We use the context to monitor the stove. Its logic is a storage logic taking as the set of entries, representing the stove’s power status (on if is present, and off otherwise) and a qualitative value for its temperature (cold/hot). The current temperature and power state of the stove should be kept up to date in a knowledge base over using the following operations:
The semantics of the operations is given, for , by
We assume a single constantly operating temperature sensor which triggers exactly one of the operations. Thus, the current value is simply inserted and we do not need to care about persistence of the temperature value or conflicting information. The power information, on the other hand, is based on someone toggling a switch, which requires persistence of the fluent . Note that ensures that the stove is considered on whenever it is switched on, and also when it is not being switched off and already considered on in the given knowledge base . The second alternative implements persistence. Also note that whenever both conflicting operations are in , “wins”, that is, will be in the knowledge base. This is justified by the application: a potential overheating of the stove is considerably more harmful than unnecessarily turning off the electricity.
Assume we have a knowledge base . Then, an update with the set of operations would result in the knowledge base .
Contexts exchange information using bridge rules that are rules similar in spirit to those in logic programming and that determine which operations from to apply to in a context depending on beliefs held in other contexts, and, in our approach also on input from the outside. To keep the approach as abstract as possible, we only require that inputs be elements of some formal input language . Moreover, we allow for situations where input comes from different sources with potentially different input languages and thus consider tuples of input languages.
Definition 2 (Bridge Rule)
Let be a tuple of contexts and a tuple of input languages. A bridge rule for over and , , is of the form
such that or for , , and every atom , , is one of the following:
a context atom with and for some , or
an input atom with and .
For a bridge rule of the form (1) denotes , the head of , while is the body of . A literal is either an atom or an atom preceded by , and we differentiate between context literals and input literals.
Roughly, a set of bridge rules for describes which operations to apply to its knowledge base , depending on whether currently available beliefs and external inputs match the literals in the body. Intuitively, rules with head affect the computation of the semantics at the current time instant, while rules with head affect the computation of the knowledge base(s) at the next time instant. We define their precise semantics later in Section 2.2 and proceed by defining reactive multi-context systems.
Definition 3 (Reactive Multi-Context System)
A reactive Multi-Context System
(rMCS) is a tuple , where
is a tuple of contexts;
is a tuple of input languages;
is a tuple such that each , , is a set of bridge rules for over and .
Consider rMCS with as in Example 2.333Throughout the paper we use labels (such as in ) instead of numerical indices in our examples. The input language is used to report whether the power switch of the stove has been turned. The bridge rules in are given by
and react to switching the stove on or off: depending on the current power state of the stove that is stored in the knowledge base of , whenever the switch is activated, the bridge rules derive an update of the knowledge base where the power state is reversed.
2.2 Reacting to External Inputs - Semantics of rMCSs
To define the semantics of rMCSs, we first focus on the static case of a single time instant, and only subsequently introduce the corresponding dynamic notions for reacting to inputs changing over time.
We start with the evaluation of bridge rules, for which we need to know current beliefs and current external information. The former is captured by the notion of a belief state denoted by a tuple of belief sets – one for each context – similar as in previous work on multi-context systems.
Definition 4 (Belief State)
Let be an rMCS. Then, a belief state for is a tuple such that , for each . We use to denote the set of all belief states for .
To also capture the current external information, we introduce the notion of an input.
Definition 5 (Input)
Let be an rMCS. Then an input for is a tuple such that , . The set of all inputs for is denoted by .
We are now ready to define when literals (in bridge rule bodies) are satisfied.
Definition 6 (Satisfaction of Literals)
Let be an rMCS such that and . Given an input for and a belief state for , we define the satisfaction of literals as:
if is of the form and ;
if is of the form and ;
Let be a bridge rule for over and . Then
if for every .
If , we say that is applicable under and . The operations encoded in the heads of applicable bridge rules in an rMCS determine which knowledge base updates should take place. We collect them in two disjoint sets.
Definition 7 (Applicable Bridge Rules)
Let be an rMCS such that and . Given an input for and a belief state for , we define, for each , the sets
Intuitively, the operations in are used for non-persistent updates of the knowledge base that influence the semantics of an rMCS for a single point in time. The operations in on the other hand are used for changing knowledge bases over time. They are not used for computing the current semantics but are applied in the next point in time depending on the current semantics. This continuous change of knowledge bases over time is the reason why, unlike in previous work on MCSs, we do not consider knowledge bases as part of the contexts to which they are associated but store them in a separate configuration structure defined next.
Definition 8 (Configuration of Knowledge Bases)
Let be an rMCS such that . A configuration of knowledge bases for is a tuple such that , for each . We use to denote the set of all configurations of knowledge bases for .
The semantics of an rMCS for a single time instant is given by its equilibria.
Definition 9 (Equilibrium)
Let be an rMCS, a configuration of knowledge bases for , and an input for . Then, a belief state for is an equilibrium of given and if, for each , we have that
Consider rMCS from Example 3 with the configuration of knowledge bases for , , representing that the stove is turned off, input for and the belief state for . As both bridge rules in use the \@ifmtarg operator, we have and consequently, following the definition of in Example 2, remains unchanged, i.e., . Thus, . Thus, is an equilibrium of given and .
Based on an equilibrium at the current time instant, we can compute an updated configuration of knowledge bases using the update function as introduced next.
Definition 10 (Update Function)
Let be an rMCS such that , a configuration of knowledge bases for , an input for , and a belief state for . Then, the update function for is defined as , such that, for each , .
We can finally show how an rMCS behaves in the presence of external information that changes over time. For this purpose, we assume that an rMCS receives data in a stream of inputs, i.e., an input for each time instant, and we represent individual time instants by natural numbers. These can be interpreted as logical time instants that do not necessarily represent specific physical time points, nor do we require that every pair of consecutive natural numbers represents equidistant physical time spans.
Definition 11 (Input Stream)
Let be an rMCS such that . An input stream for (until ) is a function where .
We will omit the term “until ” whenever the limit of the stream is irrelevant. Clearly, an input stream for until also fully determines an input stream for until for every . For any input stream and , we will use to denote , i.e., the input for at time . We also term stream the restriction of an input stream to a single input language , i.e., a function that is fully determined by .
Note that encapsulates (input) data for every input language of . Hence, we assume that, at every time instant, we receive input from every external source of the rMCS. This synchronicity is required since the evaluation of a bridge rule may depend on the availability of information from multiple streams. One possibility for modeling external sources that do not continuously provide information is setting to the empty set for representing a lack of input from the source with language at time .
The semantics of an rMCS over time is given by its equilibria streams for a given initial configuration of knowledge bases and an input stream for the system.
Definition 12 (Equilibria Stream)
Let be an rMCS, a configuration of knowledge bases for , and an input stream for until where . Then, an equilibria stream of given and is a function such that
is an equilibrium of given and , where is inductively defined as
We will also refer to the function as the configurations stream of given , , and .
Note that the limit of an equilibria stream is aligned with that of the given input stream. Following the definition, it is easy to see that if we have an equilibria stream of given and , then the substream of of size , with , is an equilibria stream of given and , where is the substream of of size . This implies that, conversely, each extension of the input stream can only lead to equilibria streams that extend those obtained given the original input stream.
Recall , , and from Example 4, as well as an input stream until with , , and . There is an equilibria stream of given and . Note that the input coincides with input from Example 4. As is the only equilibrium of given and , we have that .
As we have , the update function provides the following configuration of knowledge bases for time instant (with ):
Thus, switching the power state at time leads to an updated knowledge base indicating that the stove is on at time . The table in Figure 1 summarizes the equilibria stream and the configurations stream given and .
2.3 Rule Schemata
For convenience, we will represent sets of bridge rules using rule schemata. Intuitively, a rule schema is a parametrized bridge rule and each instance is a bridge rule. It will be convenient to use not only parameters, but also conditions to additionally constrain the set of instances. We will use them, e.g., for allowing arithmetic operations and comparison relations in bridge rules.
Given a tuple of contexts and a tuple of input languages, let be the alphabet of symbols occurring in all possible bridge rules for all contexts over and . We call a string over an instantiation term for and . Then, an instantiation condition for and is a predicate , where are strings over and where is a set of symbols (called parameters) such that . A rule schema for and with parameters is of the form
such that , , …, are strings over and is an instantiation condition for each .
A bridge rule for over and is an instance of a rule schema for and with parameters of the form (2) if results from by a uniform substitution of parameters with instantiation terms, and for each , , the predicate holds.
We adopt the convention from logic programming that parameters start with uppercase letters. Moreover, we will denote instantiation conditions representing comparison and arithmetic operations using standard infix notation. For example, the rule schema
expresses that temperature values received on stream should be added to the knowledge base (tagged with the stream index) if they lie between C and C.
Note that we assume that instantiation conditions only evaluate to true if their arguments are substituted by appropriate instantiation terms, for example when is substituted by numeric values in the temperature example.
2.4 Example Scenario
So far, in our examples we have only shown rMCSs with a single context, to ease the presentation. We conclude this section with an extensive example of the assisted-living scenario thereby illustrating the usage of an rMCS with several contexts (and input languages) and the flow of information within these.
The rMCS for our assisted living scenario, , as illustrated in Figure 2, with has five contexts: is the stove context, keeps track of the current position of Dave, monitors Dave’s health status, is a medical ontology that the system may consult, and is the emergency control context that is responsible for detecting potential threats and taking actions, such as raising an alarm. The five contexts are connected by their corresponding sets of bridge rules , and four input languages represent the sensors used in the assisted living scenario.
The stove context has already been described in Examples 2 and 3. We adjust to allow for temperature sensor input data in and by adding further bridge rules for context , i.e., extends (with replacing in input literals) by the instances of the following bridge rule schemata
that classify the current temperature value as cold or hot. These bridge rules do not use the \@ifmtarg operator and hence influence the computation of equilibria rather than the update of knowledge bases for the next step, i.e., temperature information does not persist in the knowledge base, but continuously computed from the input stream.
The input language is given by
and non-empty sensor (stream) input for signals when Dave changes rooms. This information is used in context to keep track of Dave’s position. This context also uses a storage logic with , and its corresponding set of bridge rules is given by the schema
The management function writes Dave’s new position into the knowledge base whenever he changes rooms and keeps the previous position, otherwise, which is why we have a bridge rule with the operator , to ensure that, as for for , the current position is stored. In addition, here we also have an identical copy of the bridge rule without with the rationale that the information is available immediately. Intuitively, this will allow us to avoid situations in which the conditions for an alarm would be met including the absence of Dave, although he is just entering the room in question.
The input language is used to provide stream data on the health sensor readings from Dave while serves to provide data on the (usage of the) drug dispenser. The information from both sensors is used in context which serves as a health monitor and also builds on a storage logic with
Here, contains a blood pressure value while contains and the bridge rules in are given by:
While the sleep status can be monitored permanently and new data arrives at every time instant, blood pressure measurements and taking medications are only taken occasionally, so this data needs to be stored until new information arrives. Here, we abstract from the details on the duration of effects of medications. The management function can then be defined quite similarly to .
The context represents a biomedical health ontology, which uses the DL logic described in Example 1. It contains information on diseases, treatments, and so on, and, it can, e.g., be used to consult for possible effects of medications by context as explained below. In our case, is simplified to
which allows one to derive that causes high blood pressure. In our simple setting, the management function leaves the knowledge base unchanged.
is the context for detecting emergencies. It is implemented as an answer set program, hence the acceptable belief sets of are the answer sets of its knowledge bases as outlined in Example 1. The bridge rules in do not refer to stream input but query other contexts:
Note that in the first bridge rule, we only import information for the case that will possibly be problematic, namely if the oven is turned on and hot, whereas, e.g., in the second, we use a schema to keep track of the position in all cases. The answer set program is given by the rules:
The management function of , , that adds information from the bridge rules temporarily as input facts to the context’s knowledge base can be defined similar to the previous contexts.
An example run of this entire rMCS is given in Figure 3. Note that we have omitted from and all information which is fixed to ease the reading, which is why, e.g., and in the figure are always empty. The presented situation begins with Dave in the kitchen, where he turns on the stove at . The effect of this is visible at , where he takes his medication (also in the kitchen). Note that blood pressure readings are not constantly done, and therefore at no reading occurs. Subsequently, Dave leaves for the bedroom to rest (thus forgetting about the stove), and this change of position is available right away and stored. The next blood pressure reading at is high, which is stored in the corresponding knowledge base from onwards, at which time point a medical assistent would be called if the medication most likely causing this was not registered. Finally, at , the oven has become hot, but since Dave has fallen asleep, the context for detecting emergencies initiates turning off the stove to prevent possible problems. If Dave was not asleep yet, an alarm would have been sounded reminding him of the stove instead.
Finally, note that in our example scenario, currently the effects of taken medications do not wear off. Such extension can be handled by e.g., incorporating explicit time, one of the modeling features of rMCSs described in the next section.
3 Modeling with rMCSs
The running example demonstrates that rMCSs can jointly integrate different formalisms and deal with a dynamic environment. In this section, we want to focus on aspects relevant to the knowledge engineer, namely how to model a certain scenario using an rMCS. To this end, we elaborate on different generic modeling techniques for rMCSs that we consider helpful in typical target applications. For concrete implementations, these techniques can still be refined and tailored towards the specific needs of the problem domain at hand. First, in Section 3.1, we discuss bridge rules as a device for translating stream data to a knowledge base language. When to use the \@ifmtarg operator in the head of bridge rules is addressed in Section 3.2. In Section 3.3, we discuss how we deal with time on the object level, including the use of timestamps as well as external and logical clocks. Then, in Section 3.4, another technique is presented that allows for managing conflicting data in input streams on the modeling level, e.g., contradictory sensor measurements. An important issue for systems that are continuously online is when to keep data and when to remove it. In Section 3.5, we discuss how to do this and provide techniques for dynamically adjusting what information is kept in the system. These techniques allow us, e.g., to modify the size of sliding windows for stream data depending on the current situation. While the computation of acceptable belief sets may be easy for some contexts, it might be expensive for others that have to perform complex reasoning. In practice, it will therefore be wise to only evaluate these contexts if necessary.
3.1 Incorporating Stream Data
Bridge rules are responsible for providing a context with information from streams and other contexts. As we deal with heterogeneous context languages and since input languages may differ from context languages, one important aspect of rMCSs (and earlier types of MCSs) is that bridge rules can be seen as a translation device between the different languages: bridge rule bodies use the languages of the source contexts or streams whereas a bridge rule head is an operation that produces a knowledge base in the target language (via the management function). But bridge rules do not necessarily pass information the way it is used in the body. Rather, we can model bridge rules such that we they focus on information relevant to the target context and, e.g., translate sensor data into a form that is convenient for reasoning. Consider the bridge rule schemas shown in Section 2.4 for :
In this case, the bridge rules only communicate whether the stove is hot or cold, abstracting away the exact temperature value coming from the sensor. This is in contrast to rule schema discussed in the previous section where parameter appears in the rule head whereby a concrete temperature value is added to the knowledge base.
3.2 Operational and Declarative Bridge Rules
were used so that an occurrence of an input atom causes the knowledge base to contain an inverted power state at the next time point. In order to highlight the difference, assume we would instead use the bridge rules
without \@ifmtarg . We refer to the version of from Example 3 with these modified bridge rules by . Consider the configuration of knowledge bases with and the input as in Example 4. Indeed, has no equilibrium given and : If we take belief state as in Example 4, we have (instead of as in Example 4). Consequently, following the definition of in Example 2, we get . But then is not contained in , thus, is not an equilibrium of given and . This is in line with the intuition that without \@ifmtarg , turning the switch should affect the current equilibrium. However, is also not an equilibrium of . Since , we get . But then does not contain , consequently also