1. CHORD Semantics January, 2007

2. F-Atoms User Defined Constraint – A::B – A[B->C], A[B=>C] – A[B(V)->C], A[B(P:T0)=>T1] Built-in Constraint – 1 : Integer, “abc” : String – Integer :: Double – 1[toString()->”1”] – False, true, e unification of F-Atoms –...

3. Monotonic OO Semantics General Rules: X::Y, Y::Z ==> X::Z. sub(X,Y), sub(Y,Z) ==> sub(X,Z) X::Y, Y[M=>T] ==> X[M=>T]. X[M=>T] ==> X[M->V]. X[M=>T], X[M->V] ==> V::T. X[M->V1], X[M->V2] ==> V1 = V2. X[M(V)->R], X[M(P:T0)=>T1) ==> V:T0, R:T1. X[M(V)->R]  op1(X, M, V, R) vop1(X,M,V,R), sop1(X,M,P,T0,T1) ==> isa(V,T0), isa(R,T1) Simple Inheritance: X::Y, X::Z ==> Y = Z.

4. Non-Monotonic OO Semantics (Overriding & Multiple Inheritance)

5. CHR Semantics x Open World Assumption Notation – ConstraintStore = Set(Constraint) – Program = Set(Rule) – i = initial constraint store – p = current program

6. CHR Semantics x Open World Assumption R : ConstraintStore x Program x ConstraintStore – Reachable predicate – R(cs, p) = some constraint store reachable from cs by iteratively applying the rules from p I : ConstraintStore x Program x Constraint  { t, f, u} – Interpretation function – Computes the “truth-value” of a constraint given some initial constraint store and set of rules t, the constraint can be proved true f, the constraint can be proved false u, the constraint can’t be proved neither true nor false

7. CHR Semantics x Open World Assumption  c  s (c  s  s  R(i,p)  I(c,i,p) = t) – Everything appearing in some reachable state is true Monotonicity assumption of rules!! – All simplification rules to be interpreted as logical equivalences If non-monotonic assumption what is the semantics of the constraints of the final store  c  s (I(c,i,p) = u  c  s  s  R(i,p)) – Every undefined constraint does not appear in any reachable state  c  s (I(c,i,p) = f  c  s  s  R(i,p)  false  R(i  c,p)) – Every false constraint causes a failed final state when added to some constraint store

8. CHR Semantics x Open World Assumption Remarks – We can’t reason directly about negative or undefined facts in CHR – The set of positive facts is partially observable – We can prove some fact to be false by finding a proof for its negation (Reductio Ad Absurdum)

9. Clark completion + integrity constraints + Abdennadher(Prolog->CHRD) = cover all usages of NAF in Prolog ??? (at least for stratified programs) Check if yang’s translation requires recursion through NAF

10. OO Inheritance in OWA

11. c1 :: c2, c2[m->b] true  c1 :: c2, c2[m->b], c1[m->b] false  c1 :: c3, c3 :: c2... undefined  Closed World Semantics

12. c1 :: c2, c2[m->b] true   X (c1[m->X]), c1 :: c2, c2[m->b] false  c2 :: c1, c2[m->c1],... unknown  c1[m->b], c1 :: c3, c3 :: c2,... Open World Semantics

13. Overriding in OWA (1st Version) X::Y, Y[M->>V] ==> X[M->>V1] Problems: – Too limited – Unnatural Solution – Use CWA locally for overriding missing facts if obtained facts do not contradict known facts – Is this abduction?

14. Locally Closed OO Semantics for CHORD Default Taxonomy Completion

15. Local Inheritance Context Definition: – a :: b, b[m->d] – b[m->d]/a

16. Local Overriding Inheritance Context Proposal: – Change the semantics from: a :: b  b[m->d] (1) – To: a :: b  b[m->d]   X,Y( a::X  X::b  X[m->Y])(2) – In this case we can inherit: a[m->d](3) If it comes directly from b – If (2) is consistent with the current constraint store and program rules we say that (1) is a Consistent Overriding Local Inheritance Context

17. Not all Local Overriding Inheritance Contexts are consistent...

18. c1[m->a] ==> c1::c3. GOAL: c1::c2, c3::c2, c2[m->a], c3[m->b] c1::c2, c2[m->a] is a local overriding inheritance context! c1[m->a]/c2 is NOT a consistent local overriding inheritance context because  X,Y( c1::X  X::c2  X[m->Y]) is false for X = c3, Y = b

19. Proposal Local Inheritance Contexts Constraint Store 1. The final stores considers just the consistent local overriding inheritance contexts 2. Use backtracking to find the consistent local inheritance contexts

20. Important There’s no negation in CHR so: It’s not possible to directly prove anything like:  X,Y( a::X  X::b  X[m->Y]) BUT we can look for a counterexample.

21. Overriding in OWA (2nd Version) /1 X::Y, Y[M->V] ==> X[M->V1], ((V=V1, X[M->V1]/Y) ; true) X[M->V1]/Y = Lc(X,M,V1,Y) 1st option: Suppose I’m consistent and the value of V can be directly inherited 2nd option: Maybe I’m not consistent

23. iswc2006.semanticweb.org/items/Motik2006 bh.pdf

24. Overriding in OWA (2nd Version) /2 X[M->V]/Y, X::C, C::Y, C[M->Vx] ==> false. Is there any provable counterexample? Backtrack.

25. http://www.modelsconference.org/ Abstract submission deadline: May 2, 2008 CHORD Semantic assumptions for MDA modeling and Semantic Web Fazer essa idéia em Fluent Calculus ante de se preocupr com traduçãopra CHR

26. Multiple Inheritance

27. Local Source Based Multiple Inheritance Context Proposal: – Change the semantics from: a :: b  b[m->d] (1) – To: a :: b  b[m->d]   X,Y,T( b≠X  a::X   b::X   X::b  (X[m->Y]  X[m=>T]))(2) Avoid double negation! – In this case we can inherit: a[m->d](3) If no other unrelated superclass defines m (for any value) – If (2) is consistent with the current constraint store and program rules we say that (1) is a Consistent Local Source Based Multiple Inheritance Context AvoidAvoid

28. Local Value Based Multiple Inheritance Context Proposal: – Change the semantics from: a :: b  b[m->d] (1) – To: a :: b  b[m->d]   X,Y,T( b≠X  a::X   b::X   X::b  X[m->Y]  Y ≠ d)(2) – In this case we can inherit: a[m->d](3) If no other unrelated superclass defines m to be d – If (2) is consistent with the current constraint store and program rules we say that (1) is a Consistent Local Value Based Multiple Inheritance Context

29. 1.Catalogo das suposições semanticas (motik & colins student 2.Ver combinações coerentes 3.Fazer FC semantics de cada combinação 4.Escolher a combinação que corresdponda (mais perto) UML/OCL e fazer regras de traduçção pra CHR 5.Verificar com FLUX que a tradução é conforme à semantica

30. Multiple Inheritance in OWA We can’t do this change only by the means of extra rules: – We can’t prove negative constraints like  X,Y,T( b≠X  a::X   b::X   X::b  (X[m->Y]  X[m=>T]))) – We can’t find a counterexample for it We would need to prove “  X::b ” We need to change the default semantics of CHR

31. Possible Solutions Adopt a less restrictive multiple inheritance semantics Extend CHR semantics to handle negation

32. Less Restrictive Multiple Inheritance Semantics

33. Proposal We do not need extra rules to handle multiple inheritance. Ex: a::b, a::c, b[m->2], b[m->3] – This constraint store is false, because we are going to inherit a[m->2] and a[m->3] for a This is a similar approach to current programming languages supporting multiple inhertance (e. g. C++) – Multiple inheritance conflicts cause compilation or runtime errors.

34. Changing default CHR semantics

35. Source Based Multiple inheritance in OWA X[M->V]/Y, X::C,  C::Y,  Y::C, C[M->Vx] ==> Y  C | false. X[M->V]/Y, X::C,  C::Y,  Y::C, C[M=>T] ==> Y  C | false. Is there any provable counterexample? Backtrack.

36. Value Based Multiple inheritance in OWA X[M->V]/Y, X::C,  C::Y,  Y::C, C[M->V] ==> Y  C | false. Is there any provable counterexample? Backtrack.

37. CHRD ¬

38. Negation as Absense Extending CHR with negation as Absence [Schrijvers et al 2006]Schrijvers et al 2006 p \\ q ==> r – If p is present and q is absent, then add r Conclusion – Lost declarativity – Lost theoretical properties – Non-logical negation We need logical negation!

39. Negation in Integrity Constraints + Abduction An Experimental CLP Platform for Integrity Constraints and Abduction [Abdennadher, 2000]Abdennadher, 2000 For each predicate p, generate an abducible predicate  p characterized by the integrity constraint: – p,  p ==> false

40. Negation in Integrity Constraints + Abduction Conclusion – Doesn’t properly handle negation in rule head  p may be true even if there’s no “  p” in the constraint store a ==> false p ==> a b,  p ==> c d, c ==> t Initial store: b, d “t” is true, however Abdennadher can’t prove it

41. My Proposal For each user defined constraint p – allow the constraint  p having the same arity – add the following integrity constraint p(X),  p(Y) ==> X = Y | false Change rule head matching semantics

42. New rule semantics p 0,..., p n ==> g | b – If “p 0,...,p k ” match some constraint set in the current constraint store – At least one constraint in the rule head must be on the constraint store (avoids trivial non termination) Adding “(  p k+1 ;... ;  p n )” to current constraint store doesn’t lead to a failed state Guard holds – Then Add body to the current constraint store

43. Remarks This approach adds logical negation to CHR Generalizes the semantics of CHR rule matching – CHRD: rule fires if there’s a set of matching constraints on the constraint store – CHRD  : rule fires if there is a proof for the existence of matching constraints for the rule head » Looking for matching constraints is still proving them Adding “(r  s)” to current constraint store means: T  (r  s ) |=  T |= (r  s )   T |=  (r  s ) T |=  r   s

44. Example R1 @ p ==> false R2 @ b,  p ==> c R3 @ d, c ==> t Initial store: b, d

45. Example – Extended Program R1 @ p ==> false R2 @ b,  p ==> c R3 @ d, c ==> t E1 @ b,  b ==> false E2 @ c,  c ==> false E3 @ d,  d ==> false E4 @ p,  p ==> false

46. Example – Execution R1 @ p ==> false R2 @ b,  p ==> c R3 @ d, c ==> t E1 @ b,  b ==> false E2 @ c,  c ==> false E3 @ d,  d ==> false E4 @ p,  p ==> false + Store: b, d + Rule try: R3, (trying:  c) ++ Store: b, d,  c ++ Rule try: R2 (trying: p) +++ Store: b, d,  c, p +++ Rule: R1 – failed state, backtrack ++ Store: b, d,  c, c ++ Rule: E2 – failed state, backtrack + Store: b, d, t

47. Example with Variables R1 @ p(2) ==> false. R2 @ q(X),  p(X) ==> s(X). Initial store: q(2)

48. Example with Variables – Extended Program R1 @ p(2) ==> false. R2 @ q(X),  p(X) ==> s(X). E1 @ p(X),  p(Y) ==> X = Y | false. E2 @ q(X),  q(Y) ==> X = Y | false. E3 @ s(X),  s(Y) ==> X = Y | false.

49. Example with Variables – Execution R1 @ p(2) ==> false. R2 @ q(X),  p(X) ==> s(X). E1 @ p(X),  p(Y) ==> X = Y | false E2 @ q(X),  q(Y) ==> X = Y | false E3 @ s(X),  s(Y) ==> X = Y | false + Store: q(2) + Rule try: R2 (trying p(2)) ++ Store: q(2), p(2) ++ Rule: R1, failed state, backtrack + Store: q(2), s(2)

50. Future Work on CHRD ¬ Investigate termination of CHRD ¬ programs – Rules may be appliable even with no matching constraint at current constraint store Investigate variables in rule head – How to deal with not found constraints containing uninstantiated variables?