Monotonicity and Persistence in Preferential Logics

Abstract

An important characteristic of many logics for Arti cial Intelligence is their nonmonotonicity. This means that adding a formula to the premises can invalidate some of the consequences. There may, however, exist formulae that can always be safely added to the premises without destroying any of the consequences: we say they respect monotonicity. Also, there may be formulae that, when they are a consequence, can not be invalidated when adding any formula to the premises: we call them conservative. We study these two classes of formulae for preferential logics, and show that they are closely linked to the formulae whose truth-value is preserved along the (preferential) ordering. We will consider some preferential logics for illustration, and prove syntactic characterization results for them. The results in this paper may improve the e ciency of theorem provers for preferential logics.De nition 2 (Persistence) Given a preferential logic (L; Mod; j=; ), a formula 2 L is called downward persistent in this logic, if 8m; n 2 Mod : (m j= and n m) ) n j= ; and it is called upward persistent if 8m; n 2 Mod : (n j= and n m) ) m j= :

Knowledge updates: Semantics and complexity issues

“…However, it is important to investigate classes of formulas that are persistent with respect to an update, as this may partially simplify the underlying inference problem [26]. Furthermore, characterizing persistence is also an important issue in nonmonotonic epistemic logic reasoning because it plays an essential role in the way of how different states of agent's knowledge can be compared [3,10,11].…”

Reasoning about confidentiality at requirements engineering time

“…We need it when we want to show that confidentiality requirements cannot be violated within the requirements model considered. The closure assumption and the "Perfect System Knowledge" axiom together make the axiomatic system non-monotonic [10,8], that is, we can have P |= Q and P ∧ R |≠ Q A confidentiality requirement might be satisfied by a requirements model but violated by some extended model where, for example, some functionality has been added (e.g., an alarm ringing on the terminal when e-purse balances are insufficient). Moreover, the confidentiality requirement might be satisfied by the requirements model but not by the final product due to information leaks introduced at implementation time [12].…”