Adding Context to Knowledge and Action BasesThis paper is an abridged version of a paper published in the proceeding of JELIA 2014 [5].

Adding Context to Knowledge and Action Basesthanks: This paper is an abridged version of a paper published in the proceeding of JELIA 2014 [5].

Diego Calvanese Free University of Bozen-Bolzano,    İsmail İlkan Ceylan Technische Universität Dresden,    Marco Montali Free University of Bozen-Bolzano,    Ario Santoso Free University of Bozen-Bolzano,

Knowledge and Action Bases (KABs) have been recently proposed as a formal framework to capture the dynamics of systems which manipulate Description Logic (DL) Knowledge Bases (KBs) through action execution. In this work, we enrich the KAB setting with contextual information, making use of different context dimensions. On the one hand, context is determined by the environment using context-changing actions that make use of the current state of the KB and the current context. On the other hand, it affects the set of TBox assertions that are relevant at each time point, and that have to be considered when processing queries posed over the KAB. Here we extend to our enriched setting the results on verification of rich temporal properties expressed in mu-calculus, which had been established for standard KABs. Specifically, we show that under a run-boundedness condition, verification stays decidable.

1 Introduction

Recent work in the areas of knowledge representation, databases, and business processes [21, 2, 9, 15] has identified the need for integrating static and dynamic aspects in the design and maintenance of complex information systems. The static aspects are characterized on the one hand by the data manipulated by the system, and on the other hand by possibly complex domain knowledge that may vary during the evolution of the system. Instead, dynamic aspects are affected by the processes that operate over the system, by executing actions that manipulate the state of the system. In such a setting, in which new data may be imported into the system from the outside environment, the system becomes infinite-state in general, and the verification of temporal properties becomes more challenging: indeed, neither finite-state model checking [12] nor most of the current techniques for infinite-state model checking apply to this case.

Knowledge and action bases (KABs) [2] have been introduced recently as a mechanism for capturing systems in which knowledge, data, and processes are combined and treated as first-class citizens. In particular, KABs provide a mechanism to represent semantically rich information in terms of a description logic (DL) knowledge base (KB) and a set of actions that manipulate such a KB over time. Additionally, actions allow one to import into the system fresh values from the outside, via service calls. In this setting, the problem of verification of rich temporal properties expressed over KABs in a first-order variant of the -calculus has been studied. Decidability has been established under the assumptions that in the properties first-order quantification across states is restricted, and that the system satisfies a so-called run-boundedness condition. Intuitively, these ensure that along each run the system cannot encounter (and hence manipulate) an unbounded number of distinct objects. In KABs, the intensional knowledge about the domain, expressed in terms of a DL TBox, is assumed to be fixed along the evolution of the system, i.e., independent of the actual state. However, this assumption is in general too restrictive, since specific knowledge might hold or be applicable only in specific, context-dependent circumstances. Ideally, one should be able to form statements that are known to be true in certain cases, but not necessarily in all.

Work on representing and formally reasoning over contexts dates back to work on generality in AI see [16]. Since then, there has been some effort in knowledge representation and in DLs to devise context-sensitive formalisms, ranging from multi-context systems [3] to many-dimensional logics [14]. An important aspect in modeling context is related to the choice of which kind of information is considered to be fixed and which context dependent. Specifically, for DLs, one can define the assertions in the TBox [1, 11], the concepts [3], or both [19, 14] as context-dependent. Each choice addresses different needs, and results in differences in the complexity of reasoning.

We follow here the approach of [1, 11], and introduce contextualized TBoxes, in which each inclusion assertion is adorned with context information that determines under which circumstances the inclusion assertion is considered to hold. The relation among contexts is described by means of a lattice in [1] and by means of a directed acyclic graph in [11]. In our case, we represent context using a finite set of context dimensions, each characterized by a finite set of domain values that are organized in a tree structure. If for a context dimension , a value is placed below in the tree (i.e., is a descendant of ), then the context associated to is considered to be more general than the one for , and hence whenever context dimension is in value , it is also in value .

Starting from this representation of contexts, we enrich KABs towards context-sensitive KABs (CKABs), by representing the intensional information about the domain using a contextualized TBox, in place of an ordinary one. Moreover, the action component of KABs, which specifies how the states of the system evolve, is extended in CKABs with context changing actions. Such actions determine values for context dimensions in the new state, based on the data and the context in the current state. In addition, also regular state-changing actions can query, besides the state, also the context, and hence be enabled or disabled according to the context. Notably, we show that verification of a very rich temporal logic, which can be used to query the system evolution, contexts, and data, is decidable for run-bounded CKABs.

2 Preliminaries

DL-Lite. For expressing knowledge bases, we use the lightweight DL DL-Lite [6]. The syntax for concept and role expressions in DL-Lite is as follows:

where denotes a concept name, a basic concept, a role name, an inverse role, and a basic role. A DL-Lite knowledge base (KB) is a tuple , where:

  • is a TBox, containing a finite set of assertion of the form:

    From left to right, assertions of the first two columns respectively denote positive inclusions between basic concepts and basic roles; assertions of the third and fourth columns denote negative inclusions between basic concepts and basic roles; assertions of the last column denote functionality on roles.

  • is an Abox, i.e., a finite set of ABox membership assertions of the form or , where , denote individuals (constants).

We use the standard semantics of DLs based on FOL interpretations such that , , and . The semantics of the DL-Lite constructs and of TBox and ABox assertions, and the notions of satisfaction and of model are as usual (see, e.g., [8]). We also say that is -consistent if is satisfiable, i.e., admits at least one model.

Queries. We are interested to query the KB, i.e., retrieving relevant constants in the ABox based on the query. We denote with the set of constants appearing in . A union of conjunctive queries (UCQ) over a KB is a FOL formula of the form with free variables and existentially quantified variables . Each in is a conjunction of atoms of the form , , where and respectively denote a concept and a role name occurring in , and , are constants in or variables in or , for some .

The (certain) answers of over are defined as the set of substitutions which substitute the free variables of with constants from such that evaluates to true in every model of . If has no free variables, then it is called boolean and its certain answers are either or .

We also consider an extension of UCQs, namely EQL-Lite(UCQ) [7] (briefly, ECQs), i.e., the FOL query language whose atoms are UCQs evaluated according to the certain answer semantics. An ECQ over a TBox is a possibly open formula of the form:

where is a UCQ over . The certain answers of an ECQ over are obtained by first computing the certain answers over of each UCQs embedded in , then evaluating them through the first-order part of , and interpreting existential variables as ranging over . As stated in [7], the reformulation algorithm for answering query over DL-Lite KB which allows us to “compile away” the TBox (i.e., , where is a UCQ computed by the algorithm in [6]) can be extended to ECQs.

Knowledge and Action Bases. In the following, we make use of a countably infinite set of constants, and a finite set of functions representing service calls, which can be used to introduce fresh values from into the system.

A knowledge and action base (KAB) is a tuple where: (i) is a DL-Lite TBox capturing the domain of interest, (ii) is the initial DL-Lite ABox, which intuitively represents the initial data of the system, (iii) is a finite set of actions that characterize the evolution of the system, (iv) is a finite set of condition-action rules forming a process that intuitively specifies when and how an action can be executed. and together form the knowledge base while and form the action base.

An action represents the progression mechanism that changes the ABox in the current state and hence generates a new ABox for the successor state. Formally, an action is represented as where (i) is the action name, (ii) are the input parameters, and (iii) is the set of effects. Each effect is of the form , where: (a) is an UCQ, and is an arbitrary ECQ whose free variables occur all among the free variables of . (b) is a set of facts (over the alphabet of ) which includes as terms: constants in , input parameters, free variables of , and Skolem terms representing service calls formed by applying a function to one of the previous kinds of terms. Intuitively, , together with acting as a filter, selects the values that instantiate the facts listed in . Collectively, the instantiated facts produced from all the effects of constitute the newly generated ABox, once the ground service calls are substituted with corresponding results. The process is formally defined as a finite set of condition-action rules of the form , where: (i) is an action, and (ii) is an ECQ over , which has the parameters of as free variables , and quantified variables or values in as additional terms.

KABs Execution Semantics.  The execution semantics of a KAB is defined in terms of a possibly infinite-state transition system. Formally, given a KAB , we define its semantics by the transition system , where: (i) is a DL-Lite TBox; (ii) is a (possibly infinite) set of states; (iii) is the initial state; (iv) is a function that, given a state , returns an ABox associated to ; (v) is a transition relation between pairs of states. Intuitively, the transitions system of KAB captures all possible evolutions of the system by the actions in accordance with the process rules.

During the execution, an action can issue service calls. In this paper, we assume that the semantics of service calls is deterministic, i.e., along a run of the system, whenever a service is called with the same input parameters, it will return the same value. To enforce this semantics, the transition system remembers the results of previous service calls in a so-called service call map that is part of the system state. Formally, a service call map is defined as a partial function , where is the set of (skolem terms representing) service calls. Each state of the transition system is a tuple , where is an ABox and is a service call map.

The semantics of an action execution is as follows: Given a state , let be an action of the form with , and let be a parameter substitution for with values taken from . We say that is executable in state with parameter substitution , if there exists a condition-action rule s.t.  is . The result of the application of to an ABox using a parameter substitution is captured by the following function:

Intuitively, the result of the evaluation of is obtained by combining the contribution of each effect of , which in turn is obtained by grounding the facts in the head of the effect with all the certain answers of the query over .

The result of is in general not a proper ABox, because it could contain (ground) Skolem terms, attesting that in order to produce the ABox, some service calls have to be issued. We denote by the set of such ground service calls, and by the set of substitutions that replace such calls with concrete values taken from . Specifically, is defined as

With all these notions in place, we can now recall the execution semantics of a KAB . To do so, we first introduce a transition relation that connects pairs of ABoxes and service call maps due to action execution. In particular, if the following holds: (i) is executable in state with parameter substitution ; (ii) there exists s.t. and “agree” on the common values in their domains (in order to realize the deterministic service call semantics); (iii) ; (iv) (i.e., updating the history of issued service calls).

The transition system of is then defined as where , and and are defined by simultaneous induction as the smallest sets satisfying the following properties: (i) ; (ii) if , then for all actions , for all substitutions for the parameters of and for all s.t. and is -consistent, we have , . A run of is a (possibly infinite) sequence of states of such that , for all .

3 Contextualizing Knowledge Bases

Following [17], we formalize context as a mathematical object. Basically, we follow the approach in [19] of contextualizing knowledge bases by adopting the metaphor of considering context as a box [4, 13]. Specifically, this means that the knowledge represented by the TBox (together with the ABox) in a certain context is affected by the values of parameters used to characterize the context itself.

Formally, to define the context, we fix a set of variables called context dimensions. Each context dimension comes with its own tree-shaped finite value domain , where represents the finite set of domain values, and represents the predecessor relation forming the tree. We denote the domain value in the root of the tree with . Intuitively, is the most general value in the tree-shaped value hierarchy of . We denote the fact that a context dimension is in value by , and call this a context dimension assignment.

A context over a set of context dimensions is defined as a set of context dimension assignments such that for each context dimension , there exists exactly one assignment . To predicate over contexts, we introduce a context expression language over , which corresponds to propositional logic where the propositional letters are context dimension assignments over . The syntax of is as follows:

where , and . We adopt the standard propositional logic semantics and the usual abbreviations. The notion of satisfiability and model are as usual. We call a formula expressed in a context expression.

Observe that a context , being a set of (atomic) formulas in , can be considered as a propositional theory. The semantics of value domains in can also be characterized by a theory. Specifically, we define the theory as the smallest set of context expressions satisfying the following conditions. For every context dimension , we have:

  • For all values s.t. , we have that contains the expression . Intuitively, this states that the value is more general than , and hence, whenever we have we can infer that .

  • For all values s.t.  and , we have that contains the expression . Intuitively, this expresses that sibling values and are disjoint.

Example 1

Consider an online retail enterprise (e.g., with many warehouses. A simple order processing scenario is as follows: (i) The customer submits the order. (ii) The central processing office receives the order. (iii) The assembler collects the ordered product. For each product that is not available in the central warehouse, the assembler makes a request to one of the warehouses having that product. (iv) The wrapper wraps the ordered product. (v) The quality controller (QC) checks the prepared order. (vi) The delivery team delivers the order to the delivery service. In this scenario we consider , where PP stands for processing plan, and S stands for season. ( WEstands for worker efficiency, MEstands for material efficiency, REstands for resource efficiency, Nstands for normal processing plan, and APstands for any processing plan. ), where (i) , (ii) , (iii) , (iv) , For example, means that worker efficiency is a form of resource efficiency. ( WHstands for winter holiday, PSstands for peak season, LSstands for low season, NSstands for normal season, and ASstands for any season. ), where (i) , (ii) , (iii) , (iv) .

Context-Sensitive Knowledge Bases.  We define a context-sensitive knowledge base (CKB) over as a standard DL knowledge base in which the TBox assertions are contextualized. Formally, a contextualized TBox over is a finite set of assertions of the form , where is a TBox assertion and is a context expression over . Intuitively, expresses that the TBox assertion holds in all those contexts satisfying , taking into account the theory . Given a contextualized TBox , we denote with the set of all concept and role names appearing in , independently from the context.

Given a CKB and a context , both over , we define the KB in context as the KB , where .

Example 2

Continuing our example, in a normal situation, to guarantee a suitable service quality, wrapper and assembler must not be the QC. However, in the situation (context) where we have either peak season () or the company wants to promote worker efficiency (), the wrapper and the assembler act also as QC. This situation can be encoded as follows:

4 Context-Sensitive Knowledge and Action Bases

We now enhance KABs with context-related information, introducing in particular context-sensitive knowledge and action bases (CKABs), which consist of: (i) a context-sensitive knowledge base (CKB), which maintains the information of interest, (ii) an action base, which characterizes the system evolution, and (iii) context information that evolves over time, capturing changing circumstances. Differently from KABs, where the TBox is fixed a-priori and remains rigid during the evolution of the system, in CKABs the TBox changes depending on the current context. Alongside the evolution mechanism for data borrowed from KABs, CKABs include also a progression mechanism for the context itself, giving raise to a system in which data and context evolve simultaneously.

4.1 Formalization of CKABs

As for standard KABs, in addition to and , we fix the set of context dimensions. A CKAB is a tuple where:

  • is a DL-Lite contextualized TBox capturing the domain of interest.

  • and are as in a KAB.

  • is a finite set of condition-action rules that extend those of KABs by including, in the precondition, a context expression. Such context expression implicitly selects those contexts in which the corresponding action can be executed. Specifically, each condition-action rule has the form , where (i) is an action, (ii) is an ECQ over whose free variables correspond exactly to the parameters of , and (iii) is a context expression over .

  • is the initial context over .

  • is a finite set of context-evolution rules, each of which determines the configuration of the new context depending on the current context and data. Each context-evolution rule has the form , where: (i) is a boolean ECQ over , (ii) is a context expression, and (iii) is a finite set of context dimension assignments such that for each context dimension , there exists at most one context dimension assignment . If a context variable is not assigned by , it maintains the assignment of the previous state.

Example 3

In our running example, suppose the company has warehouses in a remote area (remote warehouses), each of which is expected to guarantee a certain time to delivery (TTD) for products. During the low season, the company is free to set the TTD for all its remote warehouses, which we model as a action. The execution of this action is controlled by the condition-action rule Assuming that the company maintains the TTD for a remote warehouse in the relation , the action can be specified as follows: Intuitively, the unique effect in updates the TTD of a remote warehouse , by issuing a service call , which also takes into account the current TTD of .

Example 4

An example of context-evolution rule is . It models the transition from peak season to normal season, independently from the data.

4.2 CKAB Execution Semantics

We are interested in verifying temporal properties over the evolution of CKABs, in particular “robust” properties that the system is required to guarantee independently from context changes. Towards this goal, we define the execution semantics of CKABs in terms of a possibly infinite-state transition system that simultaneously captures all possible evolutions of the system as well as all possible context changes.

Each state in the execution of a CKAB is a tuple , where is a state identifier, is an ABox maintaining the current data, is a service call map accounting for the service call results obtained so far, and is the current context. The context univocally selects which are the axioms of the contextual TBox that currently hold, in turn determining the current KB.

Formally, given a CKAB , we define its semantics in terms of a context-sensitive transition system , where: (i) is a contextualized TBox; (ii) is a set of states; (iii) is the initial state; (iv) is a function that, given a state , returns the ABox associated to ; (v) is a function that, given a state , returns the context associated to ; (vi) is a transition relation between pairs of states.

Starting from the initial state , accounts for all the possible (simultaneous) data and context transitions. To single out the dynamics of the system as opposed to those of the context, the transition system is built by repeatedly alternating between system and context transitions. Technically, we revise the notion of executability for KABs by taking into account context expressions, as well as the context evolution. Given an action , we say that is executable in state with parameter substitution if there exists a condition-action rule in s.t.  and .

We then introduce an action transition relation , where if the following holds:

  • Action is executable in state with parameter substitution ;

  • There exists s.t.  and “agree” on the common values in their domains;

  • ;

  • ;

  • , i.e., the context does not change.

Alongside the action transition relation, we also define a context transition relation , where if the following holds:

  • , i.e., the ABox does not change;

  • , i.e., the service call map does not change;

  • there exists a context rule in s.t.: (i) is ; (ii) ; (iii) for every context dimension s.t. , we have ; (iv) for every context dimension s.t. , and there does not exist any s.t. , we have .

Given these, we can now define how is constructed, by suitably alternating the action and context transitions. In order to single out the states obtained by applying just an action transition and for which the context transition has not taken place yet, we introduce a special marker , which is an ABox assertion with a fresh concept name and a fresh constant . When is present, it means that the state has been produced by an action execution, and that the next transition will represent a context change. Such states can be considered as intermediate, in the sense that the overall change both of the ABox facts and of the context has not taken place yet.

Formally, given a CKAB , the context-sensitive transition system is defined as follows:

  • ;

  • and are defined by simultaneous induction as the smallest sets satisfying the following properties: (i) ; (ii) if and , then for all actions , for all substitutions for the parameters of , and for all , s.t. , let

    If for some , we have that is -consistent, then and , where and is a fresh identifier. Moreover, in this case, for each such that is -consistent, we have that and .

Notice that, if at some point in the above inductive construction, for no we have that is -consistent, then neither the state nor any state in becomes part of .

5 Verifying Temporal Properties over CKAB

Given a CKAB , we are interested in verifying whether the evolution of , which is represented by , complies with some given temporal property. The challenge is that in general the transition system is infinite due to the presence of services calls, which can introduce arbitrary fresh values into the system.

5.1 Verification Formalism: Context-Sensitive FO-variant of -Calculus

In order to specify temporal properties over CKABs, we use a first-order variant of -calculus [20, 18], one of the most powerful temporal logics, which subsumes LTL, PSL, and CTL* [12]. In particular, we introduce the language of context-sensitive temporal properties, which is based on defined in [2]. Basically, we exploit ECQs to query the states, and support a first-order quantification across states, where the quantification ranges over the constants in the current active domain. Additionally, we augment ECQs with context expressions, which allows us to check also context information while querying states. Formally, is defined as follows:

where {inparablank}

is a possibly open EQL query that can make use of the distinguished constants in ,

is a context expression over , and

is a second order predicate variable (of arity 0). We adopt the usual abbreviations of FOL, and also and . Hence and .

Notice that and are used in to quantify over the successor states of the current state, obtained after a state-changing transition followed by a context-changing one. This allows one to separately control how the property quantifies over state and context changes. Furthermore, due to the fact that the diamond and box operators can be only used in pairs, the local queries that inspect the data and the context maintained by the states are never issued over intermediate states, but only over those resulting from the combination of an action and context transition.

The semantics of is defined over a transition system . Since contains formulae with both individual and predicate free variables, given a transition system , we introduce an individual variable valuation , i.e., a mapping from individual variables to , and a predicate variable valuation , i.e., a mapping from predicate variables to subsets of . The semantics of follows the standard -calculus semantics, except for the semantics of queries and of quantification. We assign meaning to formulas by associating to and an extension function , which maps formulas to subsets of . The extension function is defined inductively as follows:

where is the query obtained from by substituting its free variables according to . For a closed formula (for which does not depend on or ), we denote with the extension of in , and we say that holds in a state if .

Model checking is the problem of checking whether , denoted by . We are interested in verification of properties over CKABs, i.e., given a CKAB , and a property , check whether .

Example 5

In our running example, the property checks that every customer order placed during peak season will be eventually delivered, independently on how the context and the state evolve.

5.2 Decidability of Verification

In general, verification of temporal properties over CKABs is undecidable, even for properties as simple as reachability, which can be expressed in much weaker languages than . This follows immediately from the fact that CKABs generalize KABs [2].

In order to establish decidability of verification, we need to pose restrictions on the form of CKABs. We adopt the semantic restriction of run-boundedness identified in [2], which intuitively imposes that along every run the number of distinct values cumulatively appearing in the ABoxes of the states in the run is bounded. Formally, given a CKAB , a run of is bounded if there exists a finite bound b s.t. . We say that is run-bounded if there exists a bound b s.t. every run in is bounded by b. The following result shows that the decidability of verification for run-bounded KABs can be lifted to CKABs as well.

Theorem 5.1

Verification of properties over run-bounded CKABs is decidable, and can be reduced to finite-state model checking.

Theorem 5.2

Given a weakly acyclic CKAB , we have that is run-bounded.

From Theorems 5.1 and 5.2, we finally obtain:

Corollary 1

Verification of properties over weakly acyclic CKABs is decidable, and can be reduced to finite-state model checking.

6 Conclusion

We have introduced context-sensitive KABs, which extend KABs with contextual information. In this enriched setting, we make use of context-sensitive temporal properties based on a FOL variant of -calculus, and establish decidability of verification for such logic over CKABs in which the data values encountered along each run are bounded.

In this work, we adopt a simplistic approach to deal with inconsistency, based on simply rejecting inconsistent states. This approach is particularly critical in the presence of contextual information, which could lead to an inconsistent state simply due to a context change. In this light, it is particularly interesting to merge the approach presented here with the one in [10], where inconsistency is treated in a more sophisticated way.

Acknowledgments. This research has been partially supported by the EU IP project Optique (Scalable End-user Access to Big Data), grant agreement n. FP7-318338, and by DFG within the Research Training Group “RoSI” (GRK 1907).


  • [1] Baader, F., Knechtel, M., Peñaloza, R.: Context-dependent views to axioms and consequences of semantic web ontologies. John Wiley & Sons 12–13, 22–40 (2012)
  • [2] Bagheri Hariri, B., Calvanese, D., Montali, M., De Giacomo, G., De Masellis, R., Felli, P.: Description logic knowledge and action bases. J. of Artificial Intelligence Research 46, 651–686 (2013)
  • [3] Borgida, A., Serafini, L.: Distributed description logics: Assimilating information from peer sources. J. on Data Semantics 1, 153–184 (2003)
  • [4] Bozzato, L., Ghidini, C., Serafini, L.: Comparing contextual and flat representations of knowledge: a concrete case about football data. In: Proc. of the 7th Int. Conf. on Knowledge Capture (K-CAP). pp. 9–16. ACM Press (2013)
  • [5] Calvanese, D., Ceylan, İ.İ., Montali, M., Santoso, A.: Verification of context-sensitive knowledge and action bases. In: Proc. of the 14th European Conf. on Logics in Artificial Intelligence (JELIA). LNAI, vol. 8761, pp. 514–528. Springer (2014)
  • [6] Calvanese, D., De Giacomo, G., Lembo, D., Lenzerini, M., Poggi, A., Rodríguez-Muro, M., Rosati, R.: Ontologies and databases: The DL-Lite approach. In: Reasoning Web. Semantic Technologies for Informations Systems – 5th Int. Summer School Tutorial Lectures (RW), LNCS, vol. 5689, pp. 255–356. Springer (2009)
  • [7] Calvanese, D., De Giacomo, G., Lembo, D., Lenzerini, M., Rosati, R.: EQL-Lite: Effective first-order query processing in description logics. In: Proc. of the 20th Int. Joint Conf. on Artificial Intelligence (IJCAI). pp. 274–279 (2007)
  • [8] Calvanese, D., De Giacomo, G., Lembo, D., Lenzerini, M., Rosati, R.: Tractable reasoning and efficient query answering in description logics: The DL-Lite family. J. of Automated Reasoning 39(3), 385–429 (2007)
  • [9] Calvanese, D., De Giacomo, G., Lembo, D., Montali, M., Santoso, A.: Ontology-based governance of data-aware processes. In: Proc. of the 6th Int. Conf. on Web Reasoning and Rule Systems (RR). LNCS, vol. 7497, pp. 25–41. Springer (2012)
  • [10] Calvanese, D., Kharlamov, E., Montali, M., Santoso, A., Zheleznyakov, D.: Verification of inconsistency-aware knowledge and action bases. In: Proc. of the 23rd Int. Joint Conf. on Artificial Intelligence (IJCAI) (2013)
  • [11] Ceylan, İ.İ., Peñaloza, R.: The Bayesian description logic . In: Proc. of the 7th Int. Joint Conf. on Automated Reasoning (IJCAR). LNCS, vol. 8562, pp. 480–494. Springer (2014)
  • [12] Clarke, E.M., Grumberg, O., Peled, D.A.: Model checking. The MIT Press, Cambridge, MA, USA (1999)
  • [13] Giunchiglia, F., Bouquet, P.: Introduction to contextual reasoning. an artificial intelligence perspective. In: Perspectives on Cognitive Science, pp. 138–159. NBU Press (1997)
  • [14] Klarman, S., Gutiérrez-Basulto, V.: : A context description logic. In: Proc. of the 12th Eur. Conference on Logics in Artificial Intelligence (JELIA). LNCS, vol. 6341, pp. 208–220. Springer (2010)
  • [15] Limonad, L., De Leenheer, P., Linehan, M., Hull, R., Vaculin, R.: Ontology of dynamic entities. In: Proc. of the 31st Int. Conf. on Conceptual Modeling (ER) (2012)
  • [16] McCarthy, J.: Generality in artificial intelligence. Commun. ACM 30(12), 1030–1035 (1987)
  • [17] McCarthy, J.: Notes on formalizing context. In: Proc. of the 13th Int. Joint Conf. on Artificial Intelligence (IJCAI). pp. 555–560 (1993)
  • [18] Park, D.M.R.: Finiteness is Mu-ineffable. Theoretical Computer Science 3(2), 173–181 (1976)
  • [19] Serafini, L., Homola, M.: Contextualized knowledge repositories for the semantic web. J. of Web Semantics 12, 64–87 (2012)
  • [20] Stirling, C.: Modal and Temporal Properties of Processes. Springer (2001)
  • [21] Vianu, V.: Automatic verification of database-driven systems: a new frontier. In: Proc. of the 12th Int. Conf. on Database Theory (ICDT). pp. 1–13 (2009)
Comments 0
Request Comment
You are adding the first comment!
How to quickly get a good reply:
  • Give credit where it’s due by listing out the positive aspects of a paper before getting into which changes should be made.
  • Be specific in your critique, and provide supporting evidence with appropriate references to substantiate general statements.
  • Your comment should inspire ideas to flow and help the author improves the paper.

The better we are at sharing our knowledge with each other, the faster we move forward.
The feedback must be of minimum 40 characters and the title a minimum of 5 characters
Add comment
Loading ...
This is a comment super asjknd jkasnjk adsnkj
The feedback must be of minumum 40 characters
The feedback must be of minumum 40 characters

You are asking your first question!
How to quickly get a good answer:
  • Keep your question short and to the point
  • Check for grammar or spelling errors.
  • Phrase it like a question
Test description