Asynchronous Multi-Context Systems††thanks: This work has been partially supported by the German Research Foundation (DFG) under grants BR-1817/7-1 and FOR 1513.
In this work, we present asynchronous multi-context systems (aMCSs), which provide a framework for loosely coupling different knowledge representation formalisms that allows for online reasoning in a dynamic environment. Systems of this kind may interact with the outside world via input and output streams and may therefore react to a continuous flow of external information. In contrast to recent proposals, contexts in an aMCS communicate with each other in an asynchronous way which fits the needs of many application domains and is beneficial for scalability. The federal semantics of aMCSs renders our framework an integration approach rather than a knowledge representation formalism itself. We illustrate the introduced concepts by means of an example scenario dealing with rescue services. In addition, we compare aMCSs to reactive multi-context systems and describe how to simulate the latter with our novel approach.
Research in the field of knowledge representation (KR) has originated a plethora of different languages and formats. Based on these formal concepts a wealth of tools has emerged (e.g., ontologies, triple-stores, modal logics, temporal logics, nonmonotonic logics, logic programs under nonmonotonic answer set semantics, …). In a “connected world” it is desirable not to spread out information over different applications but to have it available for every application if need be. Expressing all the knowledge usually represented in specifically tailored languages in a universal language would be too hard to achieve from the point of view of complexity as well as the troubles arising from the translation of the representations. Instead, a framework seems desirable that integrates multiple existing formalisms in order to represent every piece of knowledge in the language that is most appropriate for it.
Another aspect that has received little attention in the development of many KR formalisms is that in a variety of applications, knowledge is provided in a constant flow of information and it is desired to reason over this knowledge in a continuous manner. Many formalisms are conceptually one-shot formalisms: given a knowledge base, the user triggers the computation of a result (e.g., the answer to a query). In this paper we aim at using KR formalisms in an online fashion as it has been done in recent works, e.g., on stream data processing and querying [11, 10], stream reasoning with answer set programming , and forgetting [9, 5].
To address the demand for an integration of heterogeneous knowledge representation formalisms together with the awareness of a continuous flow of knowledge over time, reactive multi-context systems (rMCSs)  and evolving multi-context systems (eMCSs)  where proposed. Both frameworks are based on the ideas of managed multi-context systems (mMCSs)  which combine multiple contexts which can be seen as representations of different formalisms. The semantics of rMCSs and eMCSs are based on the notion of an equilibrium which realises a tight semantical integration of the different context formalisms which is in many applications not necessary. Due to reasoning over all contexts, the whole computation is necessarily synchronous as the different contexts have to agree on common beliefs for establishing equilibria.
Many real world applications which utilise communication between different services use asynchronous communication protocols (e.g., web services) and compute as soon as they have appropriate information about the problem they have to address. Therefore, we introduce asynchronous multi-context systems (aMCSs), a framework for loosely coupled knowledge representation formalisms and services. It still provides the capabilities to express different knowledge representation languages and the translation of information from one formalism to another. In addition, aMCSs are also aware of continuous streams of information and provide ways to model the asynchronous exchange of information. To communicate with the environment, they utilise input and output streams.
We will illustrate aMCSs using the example of a task planner for medical rescue units. Here, we assume a scenario where persons are calling an emergency response team to report incidents and the employee needs to collect all relevant information about the case. Afterwards, the case needs to be classified and available resources (e.g., free ambulances, …) have to be assigned to the emergencies. In addition, current traffic data as well as the estimated time of arrival should be considered by another employee, the dispatcher. Our proposed aMCS that we understand as a recommender-system for the emergency response employee as well as to the dispatcher, incorporates different contexts like a medical ontology, a database with the current state of the ambulances, or a navigation system which is connected to a traffic density reporter. We want to stress that this might be one application where it would be a great gain for the overall system by allowing asynchronous computation and communication such that it is not necessary to wait for all other contexts (e.g., it would be unnecessary to wait for the recommendation of a plan of action for the dispatcher during the treatment of an emergency call).
The remainder of this paper is structured as follows. At first we will give a short background on concepts we need. In Section 3, we extend the basic ideas of MCS to propose our new notion of aMCS for modelling asynchronous interaction between coupled knowledge representation formalisms and formally characterise its behaviour over time. The subsequent section presents an example scenario, where asynchronous computation and a reactive response to different events is needed. Section 5 compares aMCSs to rMCSs and shows how the latter can be simulated by the former. Section 6 concludes this paper with a discussion including an outlook on future work.
We base our approach on the underlying ideas of mMCSs  which extend heterogeneous multi-context systems (MCSs)  by a management layer. It allows for complex updates and revisions of knowledge bases and is realised by a management function that provides the updates for each equilibrium. Despite we build on mMCSs, they differ substantially in some aspects from the formalism we introduce in this work for reasons intrinsic to the asynchronous approach (cf. Section 5). Consequently, we only reuse basic notions from the original work and refer the interested reader to the paper of Brewka et al.  for full details on mMCS.
Like mMCS, aMCSs build on an abstract notion of a logic suite which can be seen as an abstraction of different formalisms for knowledge representation. A logic suite is a triple , where is the set of admissible knowledge bases (KBs) of . Each knowledge base is a set of formulas that we do not further specify. is the set of possible belief sets of , whose elements are beliefs. A semantics for is a function assigning to each KB a set of acceptable belief sets. Using a semantics with potentially more than one acceptable belief set allows for modelling non-determinism, where each belief set corresponds to an alternative solution. Finally, is a set of semantics for . We denote ,, respectively, by ,, respectively, .
The motivation behind having multiple semantics for one formalism is that in our framework, the semantics of a formalism can be changed over time. While it is probably rarely the case that one wants to switch between different families of semantics during a run, e.g., from the stable-model semantics to the well-founded semantics of logic programs other switches of semantics are quite natural to many applications: we use different semantics to express different reasoning modes or to express different queries, i.e., returns belief sets answering a query , whereas answers query ; , in turn, could represent the computation of all solutions to a problem, whereas at some point in time one could be interested in using that only computes a single solution. For instance one that is optimal with respect to some criterion.
3 Asynchronous Multi-Context Systems
An aMCS is built up by multiple contexts which are defined next and which are used for representing reasoning units. We assume a set of names that will serve as labels for sensors, contexts, and output streams.
A context is a pair where is the name of the context and is a logic suite.
For a given context we denote and by and , respectively.
An aMCS (of length with output streams) is a pair , where is an -tuple of contexts and with for each is a tuple containing the names of the output streams of .
By we denote the set of names of contexts and output streams of .
A context in an aMCS communicates with other contexts and the outside world by means of streams of data. In particular, we assume that every context has an input stream on which information can be written from both external sources (we call them sensors) and internal sources (i.e., other contexts). For the data in the communication streams we assume a communication language where every is an abstract piece of information. In our framework, the data in the input stream of a context and the data in output streams are modelled by information buffers that are defined in the following.
A data package is a pair , where is either a context name or a sensor name, stating the source of , and is a set of pieces of information. An information buffer is a sequence of data packages.
As we assume that data is asynchronously passed to a context on its input stream, it is natural that not all information required for a computation is available at all times. Consequently, we need means to decide whether a computation should take place, depending on the current KB and the data currently available on the stream, or whether the context has to wait for more data. In our framework, this decision is made by a computation controller as defined next.
Let be a context. A computation controller for is a relation between a KB and a finite information buffer.
Thus, if then a computation should take place, whereas means that further information is required before the next computation is triggered in the respective context.
In contrast to the original definition of multi-context systems  and extensions thereof, we do not make use of so-called bridge rules as a means to communicate: a bridge rule defines which information a context should obtain based on the results of all the contexts of a multi-context system. In the asynchronous approach, we do not have (synchronised) results of all contexts available in general. As a consequence we use another type of rules, called output rules, that define which information should be sent to another context or an output stream, based on a result of a single context.
Let be a context. An output rule for is an expression of the form
such that is the name of a context or an output stream, is a piece of information, and every () is a belief for , i.e., for some .
We call the stakeholder of , the head of denoted by and the body of . Moreover, we say that is active under , denoted by , if and .
Intuitively, the stakeholder is a reference to the addressee of information .
Let be a context, a set of output rules for , a belief set, and a name. Then, the data package
is the output of with respect to under relevant for .
Compared to previous notions of multi-context systems, contexts in our setting only specify which formalisms they use but they do not contain knowledge bases, the concrete semantics to use, and communication specifications. The reason is that for aMCSs these may change over time. Instead, we wrap concepts that are subject to change during runtime in the following notion of a configuration.
Let be a context. A configuration of is a tuple , where , , is a finite information buffer, and is a context management for which is a triple , where
is a computation controller for ,
is a set of output rules for , and
is a context update function for which is a function that maps an information buffer and an admissible knowledge base of to a configuration of with for some .
We write , , and to refer to the components of a given context management . The context management is the counterpart of a management function of an rMCS, that computes an update of the knowledge base of a context given the results of bridge rules of the context.
In Section 2 we already discussed why we want to change semantics over time. Allowing also for changes of output rules can be motivated with applications where it should be dynamically decided where to direct the output of a context. For example, if a particular subproblem can be solved by two contexts and and it is known that some class of instances can be better solved by and others by . Then a third context that provides an instance can choose whether or should carry out the computation by adapting its output rules. Dynamically changing output rules and semantics could require adjustments of the other components of the context management. Thus, it makes sense that also compution controllers and context update functions are subject to change for the sake of flexibility.
Let be an aMCS. A configuration of is a pair
for all is a configuration for and for every output rule we have for , and
is an information buffer with a final element that corresponds to the data on the output stream named for each such that for each with we have for some .
Figure 1 depicts an aMCS with three contexts and a configuration for .
We next characterise the dynamic behaviour of an aMCS. For easier notation we stick to a discrete notion of time represented by integers.
Let be an aMCS. A run structure for is a sequence
where is a point in time, and every in () is a configuration of .
We will sometimes use to denote the configuration of a context that appears at time in a given run structure in the context of a given aMCS. Similarly, refers to the information buffer representing the data in the output stream named . Moreover, we write , , , and to refer to the components of . We say that context is waiting at time if .
From run structure to run
In aMCSs we take into account that the computation of the semantics of a knowledge base needs time. Moreover, in a computation of our framework, different belief sets may become available at different times and verifying the non-existence of further belief sets can also take time after the final belief set has been computated. In order to model whether a context is busy with computing, we introduce a boolean variable for each configuration in a run structure. Hence, context is busy at time iff is true. While a context is busy, it does not read new information from its input stream until every belief set has been computed and it has concluded that no further belief set exists.
After the computation of a belief set, the output rules are applied in order to determine which data is passed on to stakeholder contexts or output streams. These are represented by stakeholder buffers: An information buffer is the stakeholder buffer of (for ) at time if
for some such that is stakeholder of some output rule in or
for some such that is stakeholder of some output rule in .
In order to indicate that a computation has finished we assume a dedicated symbol that notifies a context’s stakeholder buffers about the end of a computation.
Next, we formally characterise the behaviour of aMCSs followed by a summary of its intuition.
Let be an aMCS of length with output streams and a run structure for . is a run for if the following conditions hold for every and every :
if and are defined, is neither busy nor waiting at time , then
is busy at time ,
We say that started a computation for at time .
if started a computation for at time then
we say that this computation ended at time , if is the earliest time point with such that is added to every stakeholder buffer of at ; the addition of to is called an end of computation notification.
for all such that is defined, is busy at unless the computation ended at some time with .
if the computation ended at time and is defined then is not busy at .
if started a computation for at time that ended at time then for every belief set there is some time with such that
is added to every stakeholder buffer of for at .
We say that computed at time . The addition of to is called a belief set notification.
if and are defined and then for some . Moreover, every data package with that was added at time results from an end of computation notification or a belief set notification.
if and are defined, is busy or waiting at time , and then we have for some . Moreover, every data package with that was added at time either results from an end of computation notification or a belief set notification or (i.e., is a sensor name) for .
Condition (i) describes the transition from an idle phase to an ongoing computation. The end of such a compation is marked by an end of computation notification as introduced in Item (ii). Condition (iii) states that between the start and the end of a computation all belief sets are computed and stakeholders are notified. Items (iv) and (v) express how data is added to an output stream or to an input stream, respectively. Note that here, sensors and the flow of information from sensors to the input buffers of contexts are implicit. That is, data packages from a sensor may appear at the end of input buffers at all times and the only reference to a particular sensor is its name appearing in a data package.
Summarising the behaviour characterised by a run, whenever a context is not busy, its context controller checks whether a new computation should take place, based on the knowledge base and the current input buffer of . If yes, the current configuration of the context is replaced by a new one, computed by the context update function of . Here, the new input buffer has to be a suffix of the old one and a new computation for the updated knowledge base starts. After an undefined period of time, belief sets are computed and based on the application of output rules of , data packages are sent to stakeholder buffers. At some point in time, when all belief sets have been computed, an end of computation notification is sent to stakeholders, and the context is not busy anymore.
4 Scenario: Computer-Aided Emergency Team Management
Now we want to consider a scenario, where aMCSs may be used to describe the asynchronous information-exchange between different specialised reasoning systems. Our example deals with a recommender-system for the coordination and handling of ambulance assignments. The suggested aMCS supports decisions in various stages of an emergency case. It gives assistance during the rescue call, helps in assigning priorities and rescue units to a case, and assists in the necessary communication among all involved parties. The suggestions given by the system are based on different specialised systems which react to sensor readings. Moreover, the system can tolerate and incorporate overriding solutions proposed by the user that it considers non-optimal.
Figure 2 depicts the example aMCS which models such a Computer-Aided Emergency Team Management System (CAET Management System). Note that interaction with a human (e.g., EM employee) is modelled as a pair containing an input stream and an output stream. The system consists of the following contexts:
- Case Analyser (ca)
This context implements a computer-aided call handling system which assists an emergency response employee (ER employee) during answering an emergency call. The system utilises reasoning methods to choose which questions need to be asked based on previous answers. In addition, it may check whether answers are inconsistent (e.g., amniotic sac bursts when the gender is male). For these purposes the case analyser context may also consult a medical ontology represented by another context. The communication with the ER employee is represented, on the one hand, as a sensor that reads the input of the employee and, on the other hand, by an output stream which prints the questions and results on a computer screen.
During the collection of all the important facts for this emergency case, the analyser computes the priority of the case and passes it to the task planner.
- Med Ontology (mo)
This medical ontology can be realised, e.g., by a description logic reasoner which handles requests from the case analyser and returns more specific knowledge about ongoing cases. This information may be used for the prioritisation of the importance of a case.
- Task Planner (tp)
This context keeps track of emergency cases. Based on the priority and age of a case and the availability and position of ambulances it suggests an efficient plan of action for the ambulances to the (human) case dispatcher (cd). The dispatcher may approve some of the suggestions or all of them. If the dispatcher has no faith in the given plan of action, she can also alter it at will. These decisions are reported back to the planning system such that it can react to the alterations and provide further suggestions. Based on the final plan, the task planner informs the ambulance about their new mission.
The knowledge base of the context is an answer-set program for reasoning about a suggested plan. It gets the availability and position of the ambulances by the ambulance manager. In addition, the cases with their priority are provided by the case analyser. With this information, the task planner gives the locations of the ambulances together with the target locations of the cases to a navigation system which provides the distances (i.e., the estimated time of arrival (ETA)) of all the ambulances to all the locations.
- Amb Manager (am)
The ambulance manager is a database, which keeps track of the status and location of ambulance units. Each ambulance team reports its status (e.g., to be on duty, waiting for new mission, …) to the database (modelled by the sensor “Ambulance” (amb)). Additionally, the car periodically sends GPS-coordinates to the database. These updates will be pushed to the task planner.
- Navigation (na)
This part of the aMCS gets traffic information (e.g., congestions, roadblocks, construction zones, …) to predict the travel time for each route as accurate as possible. The task planner may push a query to the navigation system, which consists of a list of locations of ambulance units and a list of locations of target areas. Based on all the given information this context will return a ranking for each target area, representing the ETAs for each ambulance.
Now we want to have a closer look on the instantiation details of some aspects of our example. At first we investigate the relation of the case analyser. It allows for the computation of new belief sets whenever the ER employee pushes new information to the analyser. In addition, it will also approve of a new computation if the medical ontology supplies some requested information. Recall that the case analyser also assigns a priority to each case and that we want to allow the employee to set the priority manually. Let us suppose that such a manual override occurs and that the case analyser has an ongoing query to the medical ontology. Due to the manual priority assignment, the requested information from the ontology is no longer needed. Therefore, it would be desirable that does not allow for a recomputation if all conclusions of the ontology are only related to the manually prioritised case. With the same argumentation in mind, the context update function will also ignore this information on the input stream. This kind of behaviour may need knowledge about past queries which can be provided by an additional output rule for the case analyser which feeds the relevant information back to the context.
Next, we will have a look at the task planner that is based on answer-set programming. We will only present parts of the program, to show how the mechanics are intended to work. To represent the incoming information on the input stream, the following predicates can be used:
represents an active case (with its location and priority) which needs to be assigned to an ambulance.
states the location of an available ambulance.
provides the estimated time of arrival for a unit at the location of the target area of the case.
represents the assignment of an ambulance to a case by the dispatcher.
These predicates will be added by the context update function to the knowledge base if corresponding information is put on the input stream of the context. Based on this knowledge, the other components of the answer-set program will compute the belief sets (e.g., via the stable model semantics). Note that an already assigned ambulance or case will not be handled as an available ambulance or an active case, respectively. In addition, can (and should) also manage forgetting of no longer needed knowledge. For our scenario it may be suitable to remove all eta, avail and case predicates when the cases or the unit is assigned. The assign predicate can be removed when the ambulance manager reports that the assigned ambulance is available again.
The set of output rules of the task planner could contain the following rules:111Keep in mind that in an actual implementation one may want to provide further information via communication.
The first rule informs the case dispatcher (cd) about a suggested assignment that has been computed by the answer-set program. Rules two and three prepare lists of ambulances and cases for querying the navigation context. Recall that the latter needs a list of ambulance locations (generated by rule two) and a list of target area locations (generated by rule three). Also keep in mind that for each belief set a data package with all information for one context or output stream is constructed. So the whole list of current target areas and free ambulance units will be passed to the navigation context at once. The last rule notifies the ambulance team that it has been assigned to a specific case.
Related to this example we want to mention privacy aspects as a real world policy which is especially important to applications in public services and health care. As the multi-context system is a heterogeneous system with different contexts, a completely free exchange of data may be against privacy policies. This issue can be addressed by the adequate design of output rules, which can also be altered with respect to additional information in the input stream (e.g., some context gains the permission to receive real names instead of anonymous data). So each context may decide by its own which parts of the belief sets are shared and exchanged with other contexts.
Another interesting aspect about aMCSs is the possibility to easily join two aMCSs together, outsource a subset of contexts in a new aMCS, or to view an aMCS as an abstract context for another aMCS in a modular way. This can be achieved due to the abstract communication by means of streams. With respect to our scenario there could be some aMCS which does the management of resources for hospitals (e.g., free beds with their capabilities). The task planner might communicate with this system to take the needed services for a case into account (e.g., intensive care unit) and informs the hospital via these streams about incoming patients. It would be easy to join both aMCSs together to one big system or to outsource some contexts as input sensors paired with an output stream. In addition, one may also combine different contexts or a whole aMCS to one abstract context to provide a dynamic granularity of information about the system and to group different reasoning tasks together.
5 Relation to Reactive Multi-Context Systems
In this section we want to address differences and communalities between aMCSs and rMCSs  as both are types of multi-context systems that work in an online fashion and can react to external information. Runs of rMCSs are based on equilibria which are collections of belief sets—one for each context—on which, intuitively, all of the contexts have to agree. Thus, equilibria can be seen as a tight integration approach in which the semantics of the individual contexts are interdependent. However, the high level of integration also comes at the price that the different contexts must wait for each other for the computation of each equilibrium, i.e., they are synchronised. In aMCSs, on the other hand, the coupling of the semantics is much looser—communication between contexts only works via data packages that are sent to another context after a computation and not via a higher-level common semantics for multiple contexts. But as a benefit, each context can run at its own pace which is useful in settings where there is a context that requires much more time for evaluating its semantics than others.
A further difference is the role of non-determinism in the semantics of aMCSs and rMCSs. An equilibrium in an aMCS consists of a single belief set for each context. Hence, as aMCSs also use a multiple belief set semantics, there may also be multiple equilibria as a source of non-determinism at each step in a run. For aMCSs, all belief sets of a context are computed in a consecutive way (we assume that if only a single belief set is desired than the semantics of the respective context should be adapted accordingly by the knowledge engineer). Nevertheless, there is also a source of non-determinism in the case of aMCSs caused by the undefined duration of computations.
Regarding the computational complexity of the two frameworks, the computation of an equilibrium requires to guess an equilibrium candidate first before the semantics of the context is computed which is expensive regarding runtime when put to practice. In theory, this guess does not add extra complexity if the context semantics is already -hard (as shown in ) because it can be combined with the guesses required in the contexts. However, this trick cannot be used in implementations that uses black boxes for computing context semantics. On the other hand, aMCSs do not add substantial computational requirements to the effort needed for computing context semantics. In particular, aMCSs are scalable as adding a further context has no direct influence on how the semantics of the other contexts are computed but can only influence the input they get.
Both, aMCSs and rMCSs are very general frameworks that allow for simulating Turing machines and thus for performing multi-purpose computations even if only very simple context formalisms are used (if the length of a run is not restricted). In this sense the approaches are equally expressive. Moreover, when allowing for arbitrary contexts one could trivially simulate the other by including it as a context. Despite the existence of these straightforward translations, we next sketch how we simulate an rMCS with an aMCS using a more direct translation, as this gives further insight into the differences of the two frameworks. Moreover, it demonstrates a way to implement rMCSs by means of aMCSs. For every context of a given rMCS , we introduce three contexts in the aMCS that simulates :
a context that stores the current knowledge base of the context,
a context in which a candidate for an updated knowledge base can be written and its semantics can be computed, and
a management context that implements the bridge rules, and the management function of the context.
There are three further contexts:
receives sensor data and distributes it to every context where depends on the respective sensor. The context is also responsible for synchronisation: for each sensor, new sensor data is only passed on after an equilibrium has been computed.
guesses equilibrium candidates for and passes them to the management contexts . Based on that and the information from , computes an update of the knowledge base in and stores in . The latter context then computes the semantics of and passes it to the final context
that compares every belief set it receives with the equilibrium candidate (that it also receives from ). If a matching belief set has been found for each context of , the candidate is an actual equilibrium. In this case sends the equilibrium to an output stream and notifies the other contexts about the success.
In case of a success, every context replaces the knowledge base in by and a next iteration begins. In case no equilibrium was found but one of the contexts has finished its computation, orders to guess another equilibrium candidate.
6 Related Work and Discussion
A concept similar to output-rules has been presented in the form of reactive bridge rules . There the flow of information is represented by rules which add knowledge to the input streams of other contexts. Which information is communicated to other contexts is also determined by the local belief set of each context.
Note that evolving multi-context systems  follow a quite similar approach as rMCSs and hence the relation of aMCSs to rMCSs sketched in the previous section also applies in essence to this approach.
The system clingo  is a reactive answer-set programming solver. It utilises TCP/IP ports for incoming input streams and does also report the resulting answer sets via such a port. It provides means to compute different semantics and can keep learned structures and knowledge from previous solving steps. Although there are no output rules or input stream pre-processing as in aMCSs, the system features embedded imperative programming languages which may be helpful to model some of the presented concepts of this paper.
In general, the tasks performed by a context management can be realised by different formalisms (e.g., imperative scripting languages or declarative programming). Here, it seems likely that different languages can be the most appropriate management language, depending on the type of context formalism and the concrete problem domain. A feature that is not modelled in our proposal but that is potentially useful and we intend to consider in the future is to allow for aborting computations. Moreover, we want to study modelling patterns and best practices for aMCSs design for typical application settings and compare different inter-context topologies and communication strategies.
The next natural step towards an implementation is an analysis of how existing tools such as clingo could be used for a realisation. It is clear that such formalisms can be used as a context formalism. Moreover, we are interested in how reactive features of clingo (e.g., iterative computation, on-demand grounding, online-queries, …) relate to aMCS concepts (e.g., , , …) and whether the system can be described in terms of an aMCS.
-  Gerhard Brewka and Thomas Eiter, ‘Equilibria in heterogeneous nonmonotonic multi-context systems’, in AAAI’07, pp. 385–390, (2007).
-  Gerhard Brewka, Thomas Eiter, and Michael Fink, ‘Nonmonotonic multi-context systems: A flexible approach for integrating heterogeneous knowledge sources’, in Logic Programming, Knowledge Representation, and Nonmonotonic Reasoning, 233–258, Springer, (2011).
-  Gerhard Brewka, Thomas Eiter, Michael Fink, and Antonius Weinzierl, ‘Managed multi-context systems’, in IJCAI’11, pp. 786–791, (2011).
-  Gerhard Brewka, Stefan Ellmauthaler, and Jörg Pührer, ‘Multi-context systems for reactive reasoning in dynamic environments’, in Proc. ECAI’14, (2014). To appear.
-  Fu-Leung Cheng, Thomas Eiter, Nathan Robinson, Abdul Sattar, and Kewen Wang, ‘Lpforget: A system of forgetting in answer set programming’, in Proc. AUSAI’06, eds., Abdul Sattar and Byeong Ho Kang, volume 4304 of LNCS, pp. 1101–1105. Springer, (2006).
-  Stefan Ellmauthaler, ‘Generalizing multi-context systems for reactive stream reasoning applications’, in Proc. ICCSW’13, pp. 17–24, (2013).
-  Martin Gebser, Torsten Grote, Roland Kaminski, Philipp Obermeier, Orkunt Sabuncu, and Torsten Schaub, ‘Stream reasoning with answer set programming: Preliminary report’, in Proc. KR’12, (2012).
-  Ricardo Gonçalves, Matthias Knorr, and João Leite, ‘Evolving multi-context systems’, in Proc. ECAI’14, (2014). To appear.
-  Jérôme Lang and Pierre Marquis, ‘Reasoning under inconsistency: A forgetting-based approach’, Artif. Intell., 174(12-13), 799–823, (2010).
-  Danh Le-Phuoc, Josiane Xavier Parreira, and Manfred Hauswirth, ‘Linked stream data processing’, in Proc. RW’12, eds., Thomas Eiter and Thomas Krennwallner, volume 7487 of LNCS, pp. 245–289. Springer, (2012).
-  Carlo Zaniolo, ‘Logical foundations of continuous query languages for data streams’, in Proc. Datalog 2.0, pp. 177–189, (2012).