CHORD: constraint handling object-oriented rules with disjunctions

Texto

(1)Universidade Federal de Pernambuco Centro de Informática. Pós Gradua¸cão em Ciências da Computa¸cão. CHORD: CONSTRAINT HANDLING OBJECT-ORIENTED RULES WITH DISJUNCTIONS Marcos Aurélio Almeida da Silva ˜ DE MESTRADO DISSERTAC ¸ AO. Recife Fevereiro/2009.

(2)

(3) Universidade Federal de Pernambuco Centro de Informática. Marcos Aurélio Almeida da Silva CHORD: CONSTRAINT HANDLING OBJECT-ORIENTED RULES WITH DISJUNCTIONS. Trabalho apresentado ao Programa de P´ os Gradua¸ c˜ ao em Ciˆ encias da Computa¸ c˜ ao do Centro de Inform´ atica da Universidade Federal de Pernambuco como requisito parcial para obten¸ c˜ ao do grau de Mestre em Ciˆ encias da Computa¸ c˜ ao.. Orientador: Prof. Jacques Pierre Louis Robin. Recife Fevereiro/2009.

(4) Silva, Marcos Aurélio Almeida da CHORD: constraint handling object-oriented rules with disjunctions / Marcos Aurélio Almeida da Silva - Recife : O Autor, 2009. xxi, 177 p. : il., fig. Dissertação (mestrado) – Universidade Federal de Pernambuco. CIn. Ciência da Computação, 2009. Inclui bibliografia, apêndice. 1. Inteligência artificial. software. I. Título. 006.3. CDD (22.ed.). 2. Engenharia de MEI2009-023.

(5) to my parents....

(6)

(7) As l´ınguas s˜ ao aspectos fundamentais, ´ unicos e irrepet´ıveis da experiˆ encia humana. E, ali´ as, a caracter´ıstica maior de nossa esp´ ecie. Cada l´ıngua que desaparece – principalmente sem deixar vest´ıgios, sem ter sido estudada e documentada – significa a extin¸ c˜ ao de uma esp´ ecie. —CARLOS DO AMARAL FREIRE (2003).

(8)

(9) RESUMO Constraint Handling Object-oriented Rules with Disjunctions (CHORD), é uma extensão orientada a objetos (OO) de CHRv, uma linguagem relacional baseada em regras que foi inicialmente desenhada para a especificação em caixa branca de resolvedores de restrições mas veio a mostrar-se uma linguagem bastante flexível. Flexibilidade esta que vêm sendo demonstrada nos últimos anos pelo grande número de serviços de raciocínio e algoritmos que foram descritos concisamente por meio desta linguagem. Para definir a sintaxe de nossa extensão, nós nos baseamos na abordagem seguida na extensão de Prolog realizada por Frame Logic que é similar à nossa, na qual, a sintaxe de frames foi introduzida para representar construtores OO em cima dos relacionais originais. Além disso, em vez de forçar o usuário (programador) a se adequar à uma semântica pré-definida para esses novos construtores, nós escolhemos uma estratégia inovadora: desacoplar a sintaxe da semântica da linguagem permitindo que o conjunto de hipóteses semânticas seja totalmente configurável. Estes avanços claramente contribuem para o domínio do Raciocínio Automático e da Representação do Conhecimento (AR/KR), dentro do qual CHRv é a linguagem de representa ção do conhecimento mais versátil. Este trabalho também permite a integração dos serviços de raciocínio já providos por CHRv ao estado da arte em linguagens orientadas a objetos reduzindo a quebra de paradigma entre elas. Há também contribuições a outros domínios: em programação declarativa, ao disponibilizar a primeira linguagem a integrar as formas mais poderosas de programação orientada a objetos, baseada em regras e baseada em restrições. No domínio da Web Semântica, nós mostramos que nossa linguagem generaliza a semântica de três dos mais importantes padrões de linguagem de representação do conhecimento, provendo uma solução para o problema recorrente de integração nesta área. No domínio da engenharia guiado por modelos (MDE), este trabalho provê o primeiro mapeamento semântico para modelos UML/OCL, MOF/OCL e transformações de modelo explícitamente configurável e com fundamentação axiomática declarativa e operacional em CFOL. Neste trabalho nós apresentamos as sintaxes abstrata e contreta de CHORD, suas semânticas operacional e declarativa em CFOL, e uma ontologia de hipóteses semânticas para herança. Para validá-lo, nós apresentamos três estudos de caso mostrando que CHORD generaliza UML/OCL, Frame Logic e OWL.. Palavras-chave: Desenvolvimento dirigido por modelos, Engenharia de Software, Problemas de Satisfaçao de Restrições, Programação Orientada a objetos, Web Semântica. ix.

(10)

(11) ABSTRACT The Constraint Handling Object-oriented Rules with Disjunctions (CHORD), is an objectoriented (OO) extension for CHR∨ , a relational rule based language that was initially designed to the white-box specification of constraint solvers but turned out being a very flexible language. This flexibility has been demonstrated in the last years by the large number of reasoning services and algorithms that were concisely described in this language. In order to define the syntax of our extension, we based our approach in the one followed in the similar extension of Prolog realized by Frame Logic, in which, frame syntax was introduced in order to represent OO constructs on top of the original relational ones. Additionally, instead of just forcing the user (programmer) to conform to a predefined semantics for these new constructs, we have chosen an innovative strategy: decoupling the syntax and the semantics of the language by allowing the set of underlying assumptions to be fully configurable. These advances clearly represent a contribution in the domain of Automated Reasoning and Knowledge Representation (AR/KR), in which CHR∨ is the most versatile KR language. This work also allows the integration of the reasoning services already provided by CHR∨ with the current state-of-the-art object-oriented languages by reducing the paradigm mismatch among them. There are also contributions in other domains: in declarative programming, by providing the first language to integrate the most powerful forms of OO, rule-based and constraint-based programming. In the domain of Semantic Web, we show that our language subsumes the semantics of three of the most important standard KR languages, providing a solution to the recurrent interoperability problems in this area. In the domain of Model Driven Engineering (MDE), this work provides the first explicitly configurable semantic mapping for UML/OCL and MOF/OCL models and model transformations with axiomatic declarative and operational CFOL reading. In this work we present the concrete and abstract syntaxes of CHORD, its operational and declarative semantics in the CFOL and an ontology of semantic assumptions for inheritance. In order to validate it, we present three case studies showing that CHORD subsumes UML/OCL, Frame Logic and OWL.. Keywords: Model Driven Approach, Software Engineering, Constraint Satisfaction Problems, Object-oriented Programming, Semantic Web. xi.

(12)

(13) CONTENTS. Chapter 1—Introduction 1.1 1.2 1.3 1.4 1.5 1.6. 1. State of the Art in Automated Reasoning and Knowledge Representation State of the Art in Constraint Programming . . . . . . . . . . . . . . . . State of the Art in Semantic Web Ontologies and Services . . . . . . . . State of the Art in Model Driven Engineering . . . . . . . . . . . . . . . Key Ideas and Scope of this Thesis . . . . . . . . . . . . . . . . . . . . . Organization of This Work . . . . . . . . . . . . . . . . . . . . . . . . . .. Chapter 2—Base Technologies 2.1 2.2 2.3 2.4 2.5. MOF . . . . . . . UML/OCL . . . OWL . . . . . . . SWSL . . . . . . CHR∨ . . . . . . 2.5.1 CHR∨ and. 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . the Rule Based. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Knowledge Representation. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. Chapter 3—Semantic Assumptions Ontology 3.1 3.2 3.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ontology Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clarifying the Semantic Differences among OO Languages . . . . . . . .. 30 31 33 37. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHORD Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHORD Full . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Concrete Syntax for CHORD in BNF . . . . . . . . . . . . . . . . . Extending the Syntax of CHORD to include Semantic Assumptions Sample CHORD Rule Base . . . . . . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . .. . . . . . .. Chapter 5—Semantics of CHORD 5.1. 12 14 17 19 24 28 29. Chapter 4—Syntax of CHORD 4.1 4.2 4.3 4.4 4.5 4.6. 2 4 6 7 8 9. 38 39 40 41 42 44 47. First Approach: Extending CHR with Default Rules . 5.1.1 Default Logic . . . . . . . . . . . . . . . . . . 5.1.2 CHRdef : Extending CHR with Default Rules . 5.1.3 Mapping CHORD into CHRdef . . . . . . . . xiii. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 49 49 50 53.

(14) xiv. CONTENTS. 5.2 5.3. 5.1.4 Limitations of This Approach . . . . . . . . . . Second Approach: Axiomatizing defaults in CHR . . . 5.2.1 Code Inheritance in CHORD . . . . . . . . . . Fluent Calculus Axiomatization of CHR∨ rule bases . . 5.3.1 The Fluent Calculus in a Nutshell . . . . . . . . 5.3.2 Theoretical Operational Semantics ωt of CHR . 5.3.3 Theoretical Operational Semantics ωt in the FC 5.3.3.1 Domain Sorts . . . . . . . . . . . . . . 5.3.3.2 Predicates . . . . . . . . . . . . . . . . 5.3.3.3 Functions . . . . . . . . . . . . . . . . 5.3.3.4 Fluents . . . . . . . . . . . . . . . . . 5.3.3.5 Actions . . . . . . . . . . . . . . . . . 5.3.3.6 Axioms . . . . . . . . . . . . . . . . . 5.3.4 Theoretic Operational Semantics ωt∨ in the FC . 5.3.4.1 Domain Sorts . . . . . . . . . . . . . . 5.3.4.2 Functions . . . . . . . . . . . . . . . . 5.3.4.3 Fluents . . . . . . . . . . . . . . . . . 5.3.4.4 Actions . . . . . . . . . . . . . . . . . 5.3.4.5 Axioms . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. Chapter 6—Case Studies 6.1. 6.2 6.3. 85. UML/OCL Case Study: Scheduling Ontology . . . . . . . . . . . . . . . 6.1.1 UML General Scheduling Modeling . . . . . . . . . . . . . . . . . 6.1.2 Mapping UML/OCL Models into CHORD . . . . . . . . . . . . . 6.1.3 Scheduling in CHR∨ . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.4 Implementation in CHORD . . . . . . . . . . . . . . . . . . . . . 6.1.5 Results & Discussion . . . . . . . . . . . . . . . . . . . . . . . . . SWSL Case Study: Frame Logic’s Integrated Inheritance and Deduction OWL Case Study: Representing OWL ontologies in CHORD . . . . . . . 6.3.1 OWL RDF-Compatible Model Theoretic Semantics . . . . . . . . 6.3.2 Mapping into CHORD . . . . . . . . . . . . . . . . . . . . . . . . 6.3.3 Test Results & Discussion . . . . . . . . . . . . . . . . . . . . . .. Chapter 7—Related Work 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8. Inheritance Networks . . . . . . . . . LAURE . . . . . . . . . . . . . . . . Oz . . . . . . . . . . . . . . . . . . . Integration of OWL with UML/OCL Integration of SWSL with UML . . . Integration of SWSL with OWL . . . Frame Logic in CHR . . . . . . . . . Previous work in CHORD . . . . . .. 57 59 70 73 73 75 76 76 76 77 77 77 78 80 80 80 80 80 81. 87 87 92 93 95 99 104 112 112 113 116 121. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. 122 124 125 125 126 126 127 128.

(15) CONTENTS. xv. Chapter 8—Conclusion. 129. Appendix A—Complete MOF Metamodel for CHR∨. 143. Appendix B—An Inference Engine for CHORD in SWI Prolog. 149. Appendix C—Source Code for SWSL Case Study. 157. Appendix D—Source Code for OWL Case Study. 171.

(16)

(17) LIST OF FIGURES. 1.1 1.2. Overview of AR and KR languages . . . . . . . . . . . . . . . . . . . . . State of the Art in CP . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2 4. 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12. Sample MOF Metamodel of Arithmetic Expressions Language . . . . . . Sample Instance of MOF metamodel for Arithmetic Expressions Language MOF Simplified Metamodel in itself . . . . . . . . . . . . . . . . . . . . . The 4-level Architecture of MDE . . . . . . . . . . . . . . . . . . . . . . Simplified UML metamodel . . . . . . . . . . . . . . . . . . . . . . . . . Simplified OCL metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . UML/OCL Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OWL Simplified Metamodel . . . . . . . . . . . . . . . . . . . . . . . . . OWL Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SWSL-Rules Simplified Abstract Syntax . . . . . . . . . . . . . . . . . . Mapping object-oriented predicates to relational predicates . . . . . . . . F-logic Trailing Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 12 13 13 14 15 16 17 18 19 20 22 23. 3.1 3.2 3.3 3.4 3.5 3.6. Sample Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . UML Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Semantic Assumptions: Overview . . . . . . . . . . . . . . . . . . . . . . Inheritance Assumptions: Composition, Overriding and Sharing Semantics Summarizing the World Assumptions of the Analyzed Languages . . . . Summarizing the Inheritance Assumptions of the Analyzed Languages . .. 30 31 31 32 34 35. 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9. CHORD MOF Metamodel – Overview . . . . . . . . . . . . . . . . . . . CHORD MOF Metamodel – Core CHORD . . . . . . . . . . . . . . . . . CHORD MOF Metamodel – Core CHORD – Class Hierarchy . . . . . . CHORD MOF Metamodel – Core CHORD – Feature Specification . . . . CHORD MOF Metamodel – Full CHORD . . . . . . . . . . . . . . . . . CHORD Concrete Syntax in BNF . . . . . . . . . . . . . . . . . . . . . . CHORD MOF Metamodel – Semantic Assumptions – WorldAssumption CHORD MOF Metamodel – Semantic Assumptions – OCL Constraints . CHORD MOF Metamodel – Semantic Assumptions – InheritanceAssumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.10 Concrete Syntax of Semantic Assumptions . . . . . . . . . . . . . . . . . 4.11 CHORD Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 38 38 39 40 41 42 43 44. 5.1 5.2. 47 48. Two approaches for Semantics of CHORD . . . . . . . . . . . . . . . . . CFOL Semantics of CHORD . . . . . . . . . . . . . . . . . . . . . . . . . xvii. 44 45 46.

(18) xviii. LIST OF FIGURES. 5.3 5.4 5.5 5.6 5.7 5.8 5.9. CHORD Semantics – Core Rules . . . . . . . . . . . . . CHORD Semantics – Assumptions’ Code . . . . . . . . . CHORD Semantics – Core Rules . . . . . . . . . . . . . CHORD Semantics – Core Rules – Integrity Constraints CHORD Semantics – Assumptions’ Code – Part 1 . . . . CHORD Semantics – Assumptions’ Code – Part 2 . . . . Rules for Examples 12, 13, 14, 16 and 17 . . . . . . . . .. 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12 6.13 6.14 6.15 6.16 6.17 6.18 6.19 6.20 6.21 6.22 6.23 6.24 6.25 6.26 6.27 6.28 7.1 7.2 7.3 7.4. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 55 56 62 63 65 66 67. Scheduling Model . . . . . . . . . . . . . . . . . . . Time Model . . . . . . . . . . . . . . . . . . . . . . Job Model . . . . . . . . . . . . . . . . . . . . . . . Resource Model . . . . . . . . . . . . . . . . . . . . Constraint Model . . . . . . . . . . . . . . . . . . . OCL Constraints of the Scheduling Ontology . . . . OCL Constraints of Case Study . . . . . . . . . . . UML Example . . . . . . . . . . . . . . . . . . . . . Mapping to CHORD . . . . . . . . . . . . . . . . . Low Level Constraints . . . . . . . . . . . . . . . . Resource Model in CHORD . . . . . . . . . . . . . OCL Invariants in CHORD . . . . . . . . . . . . . Room Usage Constraint in CHORD . . . . . . . . . Room Capacity Constraint in CHORD . . . . . . . Avoid Clashing Course Constraint in CHORD . . . Day Break Constraint in CHORD . . . . . . . . . . Labeling rule . . . . . . . . . . . . . . . . . . . . . Instantiating Ontology to CIn-UFPE Domain . . . Instantiating Ontology to CIn-UFPE Domain (Only Generated Schedule . . . . . . . . . . . . . . . . . . Case Study State Machine . . . . . . . . . . . . . . UML Model for Example 25 . . . . . . . . . . . . . UML Model for Example 26 . . . . . . . . . . . . . UML Model for Example 27 . . . . . . . . . . . . . UML Model for Example 28 . . . . . . . . . . . . . UML Model for Example 29 . . . . . . . . . . . . . UML Model for Example 30 . . . . . . . . . . . . . OWL Case Study Results . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Courses) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 88 88 89 90 91 91 91 92 93 94 95 96 96 97 97 98 98 100 101 102 102 104 106 107 108 109 110 118. Example of Inheritance Network . . . . . Hypothesis over an Inheritance Network Ambiguous Inheritance Network . . . . . Mapping UML into OWL . . . . . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 122 123 123 125. A.1 CHRD MOF Metamodel – Overview . . . . . . . . . . . . . . . . . . . . A.2 CHRD MOF Metamodel – Program . . . . . . . . . . . . . . . . . . . . . A.3 CHRD MOF Metamodel – Program – OCL . . . . . . . . . . . . . . . .. 143 144 145. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . . . . .. . . . .. . . . . . . .. . . . .. . . . ..

(19) LIST OF FIGURES. xix. A.4 CHRD MOF Metamodel – Formula . . . . . . . . . . . . . . . . . . . . . A.5 CHRD MOF Metamodel – Formula – OCL . . . . . . . . . . . . . . . . . A.6 CHRD MOF Metamodel – Atom . . . . . . . . . . . . . . . . . . . . . .. 146 147 147. B.1 B.2 B.3 B.4 B.5. 149 150 150 151 154. Screenshot of CHORD Inference Engine . Overview . . . . . . . . . . . . . . . . . . . Changes in Syntax . . . . . . . . . . . . . Mapping CHORD Full into CHORD Core Preferences in CHORD Engine . . . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . ..

(20)

(21) ACRONYMS ATL BICS BNF CFOL CHR CHR∨ C(L)P CT FLUX KR MDD MDE MOF OCL OWL PIM PSM STS SWSF SWSL SWSO UDCS UML UNA URI XML. Atlas Transformation Language Built-In Constraint Store Bakus Naun Form Classic First Order Logic Constraint Handling Rules Constraint Handling Rules with Disjunctions Constraint (Logic) Programming Constraint Theory FLUent Calculus eXecutor Knowledge Representation Model Driven Development Model Driven Engineering Meta Object Facility Object Constraint Language Web Object Language Platform Independent Model Platform Specifc Model State Transition System Semantic Web Services Framework Semantic Web Services Language Semantic Web Services Ontology User Defined Constraint Store Unified Modeling Language Unique Name Assumption Unified Resource Identification eXtensible Markup Language. xxi.

(22)

(23) CHAPTER 1. INTRODUCTION “Dixitque Deus fiat lux et facta est lux” —GENESIS. The Constraint Handling Object-oriented Rules with Disjunctions (CHORD), is an object-oriented (OO) extension for CHR∨ , a constraint based rule language. In this Chapter we introduce the state of the art in the related domains and define the scope of this thesis. It is organized as follows: in the first four sections, we review state of the art in the areas CHORD will bring contributions to: Automated Reasoning (AR) and Knowledge Representation (KR) (Section 1.1), Constraint Programming (CP) (Section 1.2), Semantic Web (SW) (Section 1.3) and Model Driven Engineering (MDE) (Section 1.4). Finally, in Section 1.5, we are going to show the scope and key ideas in this thesis and in Section 1.6, we overview the organization of this thesis.. 1.

(24) 2 1.1. INTRODUCTION. STATE OF THE ART IN AUTOMATED REASONING AND KNOWLEDGE REPRESENTATION. Figure 1.1 Overview of AR and KR languages. In Figure 1.1 we present the 3-dimensional space of Automated Reasoning and Knowledge Representation (AR/KR) languages. This space is organized in such a way that each KR language or AR service is represented by some region in the space. The objective of this Figure is to aid the identification of the reasoning services covered by CHORD and the extension of the contribution provided by this thesis. However, it is important to notice that this is not a complete classification of the AR/KR space. Let us now analyze each dimension in this space. The “x” axis classifies the languages/services according to the reasoning tasks they are able to perform. In the region covered by Constraint Solving, Optimization and Satisfiability we include CHR∨ [6]. Since CHR∨ is not an object-oriented language, its region does not include services such as Classification and Inheritance. Description Logic [13] and OWL [88] cover the region ranging from Satisfiability to Monotonic Inheritance, and which includes also Class Subsumption and Object Classification. Notice that object-oriented support provided by OWL and DL languages is monotonic in nature, which is improved by Frame Logic [62], by its support to NonMonotonic Inheritance and thus to Default Reasoning. CHR∨,at [43] is an extension of CHR∨ with support to component based development.

(25) 1.1 STATE OF THE ART IN AUTOMATED REASONING AND KNOWLEDGE REPRESENTATION3. techniques, such that a CHR∨,at rule base is able to provide entailment services w.r.t. a restricted set of constraints to other CHR∨,at rule bases. The next region in this axis is the one covered by the Fluent Calculus [92], which is a Sorted Second Order Logic Theory that aims to solve the problem of planning in the high level in complex domains like the one of cognitive robots. Its region in this axis includes Belief Revision, Belief Update and Planning. The Abductive Logic Programming [60] envisions to represent abductive knowledge in Logic Programming rule bases. This kind of programming occupies the next region in our “x” axis. The last represented region comprises the Machine Learning related services, which include Induction, Reinforcement Learning and Analogy. These kinds of services are not further explored in this work. The “y” axis classifies the languages/services according to their Ontological Commitment. Under this classification, CHR∨ , CHR∨,at , the Fluent Calculus and Abductive Logic Programming can only represent propositional and First Order relational knowledge. Description Logics and Frame Logic allow the representation of object oriented First-Order knowledge. Frame Logic also allows for High Order knowledge, as represented in the Figure. The “z” axis classifies the languages/services according to their Epistemological Commitment. In this case, CHR∨ , CHR∨,at , Description Logics and Abductive Logic Programming (as shown by Abdennadher in [8]) use Boolean Logic under the Open World Assumption. Frame Logic uses a Ternary Logic (true, false and undefined) under the Closed World Assumption (CWA). The Abductive Logic Programming (as shown by Christiansen in [30]) accounts for plausibilistic and probabilistic reasoning. The Fluent Calculus allows the representation of knowledge ranging from Boolean Logic CWA to plausibilistic reasoning. In fact, most of these reasoning services were shown to be concisely representable in CHR∨ : • In [48], Thom Fr¨ uhwirth shows how to represent DL knowledge in CHR∨ rule bases. • In [58], Martin Kaeser and Marc Meister, show how to reason over Frame Logic rules in CHR∨ . • In [43], Fages et al elaborate the semantics of CHR∨,at rule bases by the means of a mapping from their language into CHR∨ rule bases. • The Fluent Calculus is implemented by the means of Prolog and CHR∨ rules [93]. Additionally, the axioms of Fluent Calculus can be easily translated into CHR∨ rules. • In [8] and [30], Slim Abdennadher and Henning Christiansen show how CHR∨ can be used as a platform for abductive reasoning, which includes a mapping from Abductive Logic Programs into CHR∨ rule bases. This means that CHORD will be able to promptly cover most of this space. In terms of reasoning task, the language as presented in this work, covers from Constraint Solving.

(26) 4. INTRODUCTION. through Abduction, i.e., in this work we do not support machine learning. In terms of ontological commitment, it covers from propositional through First-Order OO knowledge, i.e., in this work we do not provide support for High-Order knowledge representation as available in Frame Logic. Finally, CHORD, as CHR∨ , employs a Boolean Logic under the Open World Assumption (OWA). 1.2. STATE OF THE ART IN CONSTRAINT PROGRAMMING. Ex:. Objects Deductive Rules Constraing Solving Rules Search Formal Semantics Scalable Integrability Algorithm Customization Rule Languages. Proc. OO CSP libs firstcs, ILOG Solver -. Prolog + Proc CSP ECLiPSe, SICStus. Compiled CHR JCHR DJCHR. CHROME. OO + CSP Laure, Oz. +. Prolog + CHR∨ ECLiPSe, SWI SICStus +. Compiled CHR∨. +. +. + +. -. -. +. +. +. +. + none. + partial. +/fixed. fixed. +/fixed. + fixed. ++ + -. ++ -. + +. ++ + -. + + -. + + +. 0. 1. 2. 1. 1. 1. Figure 1.2 State of the Art in CP. The state of the art in the domain of Constraint Programming (CP) is represented by the table in Figure 1.2, in which we analyze and compare the six most common approaches taken by languages in this domain: • The OO procedural libraries are represented by the generic solvers implemented in procedural OO languages (e.g. Java and C++), such as firstcs[98] and the ILOG solver1 . On the one hand, they are usually very scalable and efficient, providing very optimized search algorithms and easy integration with commercial programming languages. On the other hand, they are the most difficult to extend to other domains, 1. http://www.ilog.com/products/cp/.

(27) 1.2 STATE OF THE ART IN CONSTRAINT PROGRAMMING. 5. since they do not offer high-level abstract languages to specify the problems, instead, this extension should be done by rewriting part of the internal code of the solver. • The Prolog combined with procedural CSP libraries is represented by Eclipse2 and SICStus3 Prolog search libraries. They represent the best compromise between the efficiency of low level search algorithms and high level problem specification in abstract languages. These systems allow part of the problem to be specified in a high level rule language such as Prolog, and this part has therefore a formal semantics. The parameters of the search and the constraint solvers are reused by the high level language as black boxes. This makes the extension of these solvers to other domains and the integration to applications harder. • The Prolog combined with CHR∨ systems is represented by the major current prolog implementations, such as Eclipse, SICStus and SWI4 Prolog. In this case the problem is completely specified using these high level languages. The problem specification has thus a formal semantics, can be easily adapted to other domains while retaining some scalability and efficiency. The problem of this approach is the number of rule languages to learn (2) and the harder integration to existing applications. • The Compiled CHR systems are represented by systems such as JCHR[84] and DJCHR[97]. These systems are usually more efficient than the implementations of CHR on top of Prolog inference engines. They are also more easily reusable by applications since the CHR code is directly compiled into the target language. These systems doesn’t offer search services, which should be implemented by the user. • The Compiled CHR∨ systems are represented by CHROME[95] which implement a generic search algorithm and are thus less scalable, but provide for easier implementation. • The Object-oriented CSP systems are represented by LAURE[27] and Oz[89]. These languages provide complete programming environments for OO constraint solving, with only one high level rule language with a fixed formal underlying semantics. The extension to new domains is therefore rather easy but the integration to existing applications is costly. These rule languages are usually very complicated do master and in some cases, like in Oz, mix very different programming paradigms which requires more specialized programmers to use it. 2. http://www.eclipse-clp.org/eclipse/ http://www.sics.se/sicstus/ 4 http://www.swi-prolog.org/ 3.

(28) 6. INTRODUCTION. In this work we are going to focus in developing a system that is object oriented, with deductive and constraint solving rules; that allows search as a built-in concept and that is based on just one rule language: CHORD. Differently from most of the other systems, this one will provide a variable formal semantics. We are not going to focus in the problems of scalability, efficiency and algorithm customization. 1.3. STATE OF THE ART IN SEMANTIC WEB ONTOLOGIES AND SERVICES. The Semantic Web[19] movement designates the vision started leveraged by the World Wide Web Consortium (W3C) and whose main idea was to enrich the pages on the web with domain-specific ontologies in the form of semantic annotations defining the concepts covered in the page and their relationships. This would allow agents to reason about the content while circumventing hard natural language processing. The Ontology Web Language (OWL)[17] is the main language used to represent these semantic annotations. It retains the expressiveness of a CFOL subset excluding n-ary predicates for n > 2, function symbols and recursive formulae. It is a triple of sublanguages: OWL-Lite, OWL-DL and OWL-Full with increasing expressive power. They integrate the Resource Description Framework (RDF) and RDF Schema (RDFS) [54] with various Description Logics[13]: SHIF(D) for OWL-Lite and SHOQ(D) for OWL-DL. OWL-Full goes beyond DL by extending OWL-DL with RDF reflection (classes can be used as objects). RDF also allows the use of XML Schema’s rich data types and web deployment metadata. Still according to W3C, Web Services are software components deployed on the web allowing semi-automated composition/orchestration of larger services (or components) from them. The automated version of these services is covered by the concept of Semantic Web Services (SWS). There are two proposed standard languages for SWSs: • OWL-S[66] is an OWL ontology of Web Services to specify their location information (reusing WSDL), constraints on operation types, pre and post conditions and valid call sequences. It allows agents to reason about WebServices orchestration but not to execute the services, since OWL is not a programming language. • SWSF[15], the Semantic Web Services Framework aims not only the definition of Web Services ontologies but also the definition of their behavior and, by the means of an inference engine, their execution. It is composed by two major building blocks: the Semantic Web Services Language (SWSL) and the Semantic Web Services Ontology (SWSO). The former reuses RuleML5 as XML syntax for rules in addition to XML Schema rich set of datatypes. It has also a very concise non-XML syntax, based on Frame Logic. It is a set of integrated but orthogonal extensions to a Definite Horn Logic core language. The only existing inference engine for SWSL is called Flora-2[103] and it implements only its Frames+NAF+Equality+Hilog+Reification variant, and also provides a model theoretic semantics to this subset. 5. http://www.ruleml.org/.

(29) 1.4 STATE OF THE ART IN MODEL DRIVEN ENGINEERING. 7. SWSO is an ontology of Web Services specified in SWSL, that is richer than OWL-S for service behavior modeling and thus orchestration by reusing the ISO Process Specification Language (PSL). The main problem with these standards is that they are so diverse that there is no practical interoperability between them. In the syntactical level, SWSL allows for horn rules, recursion, function symbols, n-ary predicates and high-order predicates, while OWL supports none of them. In the semantic level, the existing SWSL engines (the inference engines for Frame Logic) employ the Closed World Assumption (CWA) and the Unique Name Assumption (UNA) whereas the OWL uses the Open World Assumption (OWA) and no UNA. Moreover, it is important to notice that no current OWL engine covers all of its expressiveness of any of its variants. 1.4. STATE OF THE ART IN MODEL DRIVEN ENGINEERING. The Model Driven Engineering (MDE)[75], as first defined by the Object Management Group (OMG) aims to separate the orthogonal concerns of modeling the organization’s core business domain and implementing such models in specific computational platforms. The development is driven by the means of the iterative transformation of models, which are representations of the system. These models are very abstract in the first steps (when they are called PIMs – Platform Independent Models) and the purpose of the transformations is to refine them in the direction of models completely tied to a target platform (when they are called PSMs – Platform Specific Models), in such a way that the last model is usually as refined as the executable code in that platform. This allows the developers to spend the most part of the project time working in the PIM, which is intended to be very abstract, letting the details concerning the target platform to be coded in the transformations (which can be reused from one project to another). One of the advantages of MDE is that common tasks such as migration to another platform do not affect the PIM, but the transformations. Another advantage is that provided a formal semantics, it can be checked for consistency and correctness according to the business rules. This raises the abstraction and the automation levels of the software process, improving the productivity of the developers and the robustness of the system. In the current state of the art of MDE, the Meta-object Facility (MOF) language [2] plays a very important role. It is an object language for describing metamodels, which work as grammars for models: defining the entities that appear in models and the wellformedness rules they should follow. The most used model language specified in MOF is the Unified Modeling Language (UML) [3], which is a superset of MOF that is the OMG main standard for the specification of PIMs and PSMs. UML is an object-oriented abstract and extensible language which provides the necessary expressiveness and modeling power for a wide range of applications. The language contains constructors for imperative programming (like Statecharts and Activity Diagrams), object-oriented structural design (the Class, Object, Deployment and Component Diagrams), for functional and constraint programming (by the means of the Object.

(30) 8. INTRODUCTION. Constraint Language – OCL – which is used to annotate the UML diagrams, enriching its semantic expressiveness), and for distributed and component-based programming. UML also provides the necessary level of platform awareness, by the means of the Profile mechanism, which allows the specialization of the language concepts to the ones of the target platform. The most common language for specifying the transformations in a MDE framework is ATL [21]. It is an hybrid rule based/imperative extension of OCL, whose rules specify the transformation of objects in the source models onto objects conforming to a target metamodel by the means of pattern-matching and rewrite rules. An ATL transformation engine can be used as an OCL execution engine, since 80% of an ATL program is OCL. The Query View Transform (QVT)[1] is the official OMG model transformation language, but it has a very limited user based in comparison to ATL’s Eclipse project user base, which turns ATL into the de facto standard. QVT is still not sufficiently explained, exemplified, used and tooled for practical use. It turns out, that there is no unified formalized semantics for UML/OCL and therefore neither to ATL and QVT. In this context, an object-oriented extension to CHR would play a significant role if UML models could be easily translated into CHORD rule bases6 . The semantics of ATL and QVT can also be given by the means of CHORD, since each transformation rule can be translated into a CHORD rule. 1.5. KEY IDEAS AND SCOPE OF THIS THESIS. The main idea under this thesis is to combine the AR and KR versatility of CHR∨ with the very expressive high-order OO layer of Frame Logic. This will lead to a language that subsumes two mutually exclusive Semantic Web Service standards: OWL and SWSL. This also provides the most comprehensive Constraint Programming, Logic Programming and Object Oriented Programming integration to date. The syntax and the semantics of the language will be decoupled by defining a multidimensional space of semantic assumptions, clearly separating the orthogonal ones and by making this semantics fully configurable by the means of directives defining the coordinates of points in this space. This multi-dimensional space will be defined by the means of a UML/OCL ontology. This thesis also aims to develop a language with both declarative and operational semantics in the CFOL, by leveraging CHR∨ well known declarative semantics and by defining a new operational semantics for it in the Fluent Calculus. This will turn a CHR∨ inference engine (and therefore a CHORD engine) able to reasoning about itself by the translation of the Fluent Calculus axioms back into CHR∨ rules. Furthermore, we leverage in synergy CHR∨ ’s built-in pattern matching, term rewrite rules and Turing-completeness with Frame Logic’s high-order OO syntax to have CHORD become first language for model, meta-model and model transformation specification, verification and execution in MDE with both declarative and operational formal semantics in CFOL. 6. The natural translation is: the class and object diagrams are translated into facts and the OCL specifications are translated into CHORD rules..

(31) 1.6 ORGANIZATION OF THIS WORK. 9. Positive Scope. In this thesis we are going to define both the concrete and abstract syntaxes for CHORD by the means of respectively a BNF grammar and a MOF metamodel. We are also going to model the ontology of the semantic assumptions space in UML. Additionally, a prototype inference engine for CHORD will be implemented by reusing SWI Prolog’s CHR∨ implementation to both compile CHORD rule bases into semantically equivalent CHR∨ bases and to execute them. We also show the validity of our ideas by three case studies focusing three points in the assumptions space: OWL, Frame Logic and UML class diagrams. Negative Scope. This work will not address the efficiency and the scalability of our CHORD inference engine, neither we are going to implement any graphical user-friendly IDE for the language. Our case studies are not going to provide general transformations from OWL, Frame Logic and UML into CHORD bases. We are only going to illustrate their feasibility by incomplete mappings, which at this present work are not going to be formally justified. We are also not going to measure the practical benefits of CHORD on a real world MDE, Semantic Web or Constraint Programming environment. 1.6. ORGANIZATION OF THIS WORK. This work is organized as follows: in Chapter 2, we introduce our base technologies on top of which we build CHORD: MOF, UML/OCL, OWL, SWSL and CHR∨ . In Chapter 3, we develop our ontology of Semantic Assumptions that will guide the definition of the semantics of CHORD. We also show that it is general enough to cover three languages in the domain of Semantic Web Knowledge Representation: OWL, SWSL and UML and two languages in the domain of general systems programming: Java and Python. In Chapter 4, we present both the abstract and the concrete syntax for CHORD. The abstract syntax is described in the MOF language which promptly enables it to be source or target of an MDE transformation. The concrete syntax is presented as a BNF. In Chapter 5, we present two proposals for the compositional declarative and operational semantics for CHORD: 1. Mapping CHORD to CHRdef , an extension of CHR with default rules and providing the declarative and operational semantics for this extension 2. Mapping CHORD directly to CHR∨ and reusing the declarative and operational semantics of CHR∨ for CHORD Furthermore, in this section we define the formal semantics of each semantic assumption in the ontology defined in the previous chapter. In this Chapter we also define our Operational Semantics for CHR∨ in the Fluent Calculus. In Chapter 6, we present our case studies: 1. Showing the ability of CHORD to represent UML models and to reuse legacy CHR code by implementing the Scheduling Ontology defined by Fabr´ıcio Teles in [36] by the means of the reuse of the solver for Scheduling problems in CHR presented by Abdennadher & Marte in [10];.

(32) 10. INTRODUCTION. 2. Showing the ability of CHORD to represent Frame Logic rule bases by mapping the sample rule bases presented by Yang in [100] that supposedly covers the most important features of the inheritance semantics and of its interaction with deductive rules in Frame Logic. 3. Showing the ability of CHORD to represent OWL ontologies by presenting a mapping from the axioms of its formal semantics (as presented in [17]) into a CHORD rule base. Finally, in Chapter 7, we discuss our related work in both extending CHR with objectoriented reasoning and in the general problem of representing inheritance in formal languages. We finally conclude presenting the limitations of our current approach and the next steps in our research in Chapter 8. We have four appendices in this work: in Appendix A we present the complete metamodel for CHR∨ that is extended by the metamodel of CHORD in Chapter 4. In Appendix B, we present the implementation details of our inference engine for CHORD we provide on top of SWI Prolog 5.6.61 and that is available on the internet site of chord at: http://chord.sf.net/. In Appendix C and D we present the complete source code for the case studies presented respectively in Sections 6.1 and 6.3. The complete source code for the third case study, the SWSL case study, is completely presented in the Section 6.2.

(33) CHAPTER 2. BASE TECHNOLOGIES “Rien ne se perd, rien ne se cr´ ee, tout se transforme” ` NES —ANAXAGORE DE CLAZOME. The contributions of this work are located in three special domains in the Computer Science: the Model Driven Approach (MDE), the Semantic Web and the Automated Reasoning. In this chapter we are going to present the main technologies in each of these areas that we reuse in this work. In the domain of MDE, we take MOF, the meta-modeling standard from OMG and UML/OCL, the modeling standard from OMG. We use MOF to define our meta-model for CHORD and as a meta-language to help to explain the complicated and different concepts included in each of the languages we reuse in this work. We do this by presenting a simplified meta-model for each of them. We also use UML/OCL as a graphical notation for all of the examples included in this work. In the domain of Semantic Web, we selected UML, OWL and SWSL as the main standards to be reused. OWL is the main standard when it comes to represent data and the ontologies to which these data conform in a formal grounded way. SWSL is the standard from W3C whose speciality is representing Semantic Web Services. In the domain of Automated Reasoning, we present CHR∨ , which is a rule based language which was initially conceived to represent white box constraint solvers but that has been showed to be able to implement many different reasoning services in a straightforward way. In this work we extend this language with object-oriented constructs and present the semantics for this new language. This chapter is organized as follows: in Section 2.1, we present MOF; in Section 2.2, we present UML/OCL; in Section 2.3, we present OWL; in Section 2.4, we present SWSL; and finally, in Section 2.5, we present CHR∨ .. 11.

(34) 12 2.1. BASE TECHNOLOGIES. MOF. A modeling language can be defined by a pair of specifications: the abstract syntax (defining its main high-level entities) and the concrete syntax (defining their realizations by the means of characters or graphical symbols and drawings). In this context, a metamodel is a model of the abstract syntax of a language. It focuses on the concepts and on the relationships among them, rather then on low-level details such as parenthesis balancing and infix notation for operators for example. The Meta-Object Facility (MOF) [2] is an abstract meta-modeling language, which was created by the Object Management Group (OMG). In this work, MOF will be used in the definition of the meta-models for the CHR∨ language and for the definition of the meta-model for the CHORD language as an extension of the former. The benefits of using MOF are twofold: (i) during the design of the language, we are going to concentrate on its abstract elements instead of the low-level items in its syntax; (ii) the use of MOF will make our language ready to be used in the MDE pipeline. In Figure 2.1 we show a sample MOF metamodel for a language of arithmetic expressions. It describes the entities in the modeled domain in a general way, without the preoccupation of defining the concrete syntax for the language. It defines ArithmeticExpression as the most generic entity in this domain. There are two kinds of ArithmeticExpressions. The AtomicExpressions, representing the expressions that are atomic, i.e., indivisible. We detail two kinds of atomic expressions: the IntegerExpressions which represent an integer and the V ariableExpression which refer to a variable. The other kind of ArithmeticExpression is the BinaryExpression which contain two ArithmeticExpressions. we have two kinds of binary expressions: the SumExpression, which represent the sum of two expressions and the SubtractionExpression which represent a subtraction. ArithmeticExpression 2. AtomicExpression. IntegerExpression value:Integer. VariableExpression variableName:String. BinaryExpression. SumExpression. SubtractionExpression. Figure 2.1 Sample MOF Metamodel of Arithmetic Expressions Language. Notice that a MOF metamodel does not specify the concrete syntax of the strings in the modeled language. For example, (4+5)-x is an example of string in the language. In this example, the whole expression is an SubtractionExpression, 4, 5 and x are IntegerExpression, IntegerExpression and V ariableExpression respectively, while,.

(35) 13. 2.1 MOF. 4+5 is a SumExpression. In Figure 2.2 we present an alternative rendering for this sample instance of our Arithmetic Expressions language based on UML Object Diagrams. :SubtractionExpression. :SumExpression. :IntegerExpression value = 4. :VariableExpression variableName = ’x’. :IntegerExpression value = 5. Figure 2.2 Sample Instance of MOF metamodel for Arithmetic Expressions Language. In Figure 2.3 we show a simplified MOF metamodel of the MOF language. A metamodel is formed by a set of class definitions (metaclass Class) which can be abstract or concrete (meta-attribute isAbstract). A class also can have an unlimited number of superclasses (meta-association superclass). The operations and properties of a class are respectively described by the Operation and Property metaclasses. The associations (metaclass Association) define relationships between two or more classes by the means of their properties. Operation +ownedOperation *. Class isAbstract : boolean. +ownedAttribute *. *. Property. +memberEnd 2..*. Association. +superclass. Figure 2.3 MOF Simplified Metamodel in itself. To illustrate that this meta-model is an instance of itself, notice that Class, P roperty Association and Operation are instances of Class; that ownedOperation, ownedAttribute, superclass and memberEnd are instances of Association and that isAbstract is an instance of P roperty. Another important concept when dealing with MOF is the 4-Layer Architecture of the MDE leveraged by OMG. It is illustrated on Figure 2.4. In the M0 level, the Application Level, we have the objects of the running and real systems. In the M1 level, the Model Level, we have the models that describe, in an abstract way, the objects in the M0 level and their interaction. The standard language to describing the models in this level is UML, that is going to be presented in the next Section. In.

(36) 14. BASE TECHNOLOGIES. MOF Metamodel. Metamodel. Model. Metamodel. Model. i1:C1. M3 - MOF Level. Model. i2:C2. M2 - Metamodel Level. M1 - Model Level. M0 - Application Level. Figure 2.4 The 4-level Architecture of MDE. the M2 level, the Metamodel level, we have the metamodels for the modeling languages in the M1 level, e.g., the metamodel for UML and OCL. Finally, in the M3 level, the MOF level, we have the metamodel of the meta-modeling languages used to describe the meta-models in the M2, i.e. the MOF metamodel. As we said before, this level is used to describe itself. 2.2. UML/OCL. The Unified Modeling Language (UML) [3] is a graphical modeling language standardized by the OMG whose objective is to describe software systems, business processes and similar artifacts. It integrates most constructs from object-oriented, imperative, distributed and concurrent programming paradigms. In Figure 2.5, we show a simplified metamodel of UML. We are only going to focus on the constructors used to represent Class Diagrams. They represent the structure and the interfaces provided and required by the objects on the running system, without putting to much emphasis on the representation of complicated execution flows. The metamodel of UML extends the metamodel of MOF presented in Figure 2.3. It is important to state that the metamodel of UML is much more complex than the part of it presented on Figure 2.5 since we are only focusing on the subset that is used in the models in this work. In UML, we have the concept of InstanceSpecif ication that allows the modeler to include an abstract vision of how are the instances of the classes in the model going to be organized at runtime. We also added the concept of Constraint which annotates elements in the diagram and enriches its semantics. They are often used to simplify the graphical rendering of the model by utilizing a more expressive language in the constraints..

(37) 15. 2.2 UML/OCL. In Figure 2.5, we added the attribute isDerived to the meta-class P roperty, such that when it is true, it indicates that the value of the attribute can be computed from the value of other attributes (and thus doesn’t need to be stored). The def ault association in the meta-class P roperty defines the default value for an attribute, which is the value to be associated to an attribute in case no other one is defined by the model. Finally, the redef inedP roperty association between properties allows for non-monotonic inheritance, since it defines that a property (defined in a subclass) redefines other property defined in a superclass. Association. InstanceSpecification * +superclass. *. 2..* +memberEnd. *. Class. +ownedAttribute *. *. +redefinedProperty. Property isDerived:Boolean. *. Constraint. +default. ValueSpecification. Figure 2.5 Simplified UML metamodel. The Object Constraint Language (OCL) [4] is the sub-part of UML dedicated to enabling the definition of arbitrary first order constraints over model elements as means of extending the expressiviness of the graphical language. We say that a UML diagram is annotated with OCL constraints, in the sense that these constraints help to clarify the semantics of a model. In our UML metamodel in Figure 2.5, this language is the one used to specify the constraints defined as instances of the Constraint meta-class. The most important kinds of OCL constraints follow: • Invariants: these constraints are attached to UML classes in order to describe properties that should always be satisfied by the objects of these classes. • Pre-conditions: these ones are attached to UML operations and describe the conditions that should be satisfied before the execution of such operation. • Pre-conditions: these ones are attached to UML operations and describe the conditions that should be satisfied after the execution of such operation. • Body Definition: these ones define how to compute the result of an operation invokation from its inputs. • Derivation: in UML some attributes may be derived from others, in the sense that their value does not need to be really stored but instead it can be computed from the values of other fields..

(38) 16. BASE TECHNOLOGIES. In Figure 2.6, we show the simplified metamodel for OCL expressions. An OCLExpression is a T ypedElement (imported from the UML meta-model). This means that every OCL expression has a type. In our meta-model, we show three subtypes of OCL Expressions: the P ropertyCallExpressions, which have the syntax navigationSource.referedProperty, and whose semantics is a navigation in the object model; the LiteralExpression, which represents the literal in the language, like integers (e.g. 1, 2, . . .), strings (e.g. “a′′ , “b′′ , . . .) etc; and If Exp, whose syntax is If Exp1 then Exp2 else Exp3, and semantics is: If Exp1 is true, than the expression evaluates to Exp2, otherwise it evaluates to Exp3. UML::TypedElement. OCLExpression + navigationSource 0..1. UML::Property. PropertyCallExp. LiteralExp. IfExp. + referedProperty 0..1. Figure 2.6 Simplified OCL metamodel. In Figure 2.7, we display an example of UML diagram annotated with OCL constraints. In this example we define the class GroupMember with two attributes: pacifist, a boolean and color a string. It has two subclasses: ReligionMember and PartyMember which redefine the attributes defined in the superclass. The ReligionMember class redefines pacifist as being derived from the pacifist attribute of the Religion of the member. The PartyMember redefines pacifist as being derived from the pacifist attribute of the Party of the member. They both redefine color and set it to ’red’ by default. The class President is a subclass of both ReligionMember and PartyMember and redefines its attributes. It defines two OCL invariants: (i) the pacifist attribute should be equal to party.pacifist and (ii) the oppositeParty should not be the same as the party. It also defines the default value of color to blue. We define four instances in our model. nixon is a President with religion set to quaker (which is pacifist) and party set to republican (which is not pacifist).It also sets the value of the attribute impeached as true. The stronger point of UML/OCL is that it is a very versatile language that can be used to model a very wide range of domains. Its visual concrete syntax also enables a great productivity boost when it comes to modeling large systems. However, this versatility comes with a price: actually, there is no formal semantics for UML/OCL models, which causes many different tools to have conflicting interpretations of the same model. There is also no inference engine that allows reasoning about these models. In this work, we present CHORD, a constraint-based object oriented rule.

(39) 17. 2.3 OWL GroupMember pacifist:Boolean color:String. ReligionMember /pacifist : Boolean {redefines pacifist} color : String = ’red’ {redefines color}. context PartyMember derive: pacifist = party.pacifist context ReligionMember derive: pacifist = religion.pacifist. PartyMember /pacifist : Boolean {redefines pacifist} color : String = ’red’ {redefines color}. context President inv: pacifist = party.pacifist context President inv: not (oppositeParty = party) quaker:Religion pacifist=true. + oppositeParty. Religion pacifist:Boolean. President pacifist:Boolean {redefines pacifist} color : String = ’blue’ {redefines color}. Party pacifist:Boolean. nixon:President. republican:Party pacifist=false. Figure 2.7 UML/OCL Example. language which semantically subsumes UML/OCL, in such a way that we can use it to give a formal semantics to UML models. 2.3. OWL. The Ontology Web Language (OWL) [17], was defined by W3C, with the objective of formally representing ontologies defining classes (called concepts) and relationships (called roles) that model general knowledge of a given domain and specific objects of these classes (called individuals) that model the content of documents about such domain. It is in fact a family of languages, which includes OWL-Full, OWL-DL and OWL-Lite by order of decreasing expressiviness and worst-case reasoning complexity. Each of these languages integrates the constructs from a different Description Logic (DL) [13], with web-distributed, document-oriented, W3C database standards such as the Resource Description Framework (RDF) [74], and XML1 . The three OWL languages share three key properties. First, their formal semantics is based on (distinct) subsets of Classical First-Order Logic (CFOL) that exclude recursion, function symbols and predicates of arity greater than two. Second, they were conceived to support only purely deductive, monotonic reasoning services such as concept subsumption, individual classification and knowledge base consistency checking. Logically, the first two services correspond to entailment proofs while the third to a satisfiability proof. From an OO perspective, the first service corresponds to determining whether one class generalizes another based on their respective feature, while the second corresponds to determining whether an object is an instance of a class based on their respective features. The third corresponds to determining whether an OO model contains contradicting constraints. In Figure 2.8 we show a simplified abstract syntax of OWL I have developed for didatic purposes. An Ontology has a name and is composed by a set of facts and a set of axioms. The concrete syntax of an ontology is Ontology(name e1 ... en), where 1. Extensible Markup Language (XML), http://www.w3.org/XML.

(40) 18. BASE TECHNOLOGIES. Ontology name:String 0..*. 0..*. Fact. ClassFact name:String partial:Boolean. Axiom. InstanceFact name:String. DataPropertyAxiom name:String. + type 0..*. DataRange. OWLClass + superclass 0..*. + domain. + range. Figure 2.8 OWL Simplified Metamodel. e1 , . . . , en are facts or axioms. In our simplified abstract syntax we include the following facts and axioms: • the Class fact, which defines a class by its name and by listing its super classes. A class definition may be partial (partial = true) or complete (partial = f alse). The concrete syntax for this fact is Class(name m c1 ... cn). Where c1 , . . . , cn are the superclasses and m = partial or m = complete. • the Instance fact which defines an instance by providing its name and a list of its classes. The concrete syntax for this axiom is Instance(name type(c1) ... type(cn)). Where c1 , . . . , cn are the classes of the instance. • the DatatypeP roperty axiom, which define a property of a class by specifying its name, its domain (the class which contains it) and its range (the type of its values). The concrete syntax for this axiom is DatatypeProperty(name domain(d) range(r)). Where d and r are respectively the domain and the range of the property. In Figure 2.9, we show how we translate the UML/OCL class diagram presented in Figure 2.7 in OWL. The strongest points of OWL is its tool support. This comes from the fact that it has very simple syntax and semantics, in such a way that some of its sublanguages were created targeting easy implementation (OWL-Lite) and practical tractability (OWL-DL). The weakest point, mainly when compared to UML/OCL is, not surprisingly, its lack of expressiviness. This could be seen in our example ontology of Figure 2.9, in which we could not represent many of the informations contained in the original UML model..

(41) 19. 2.4 SWSL. Ontology(example Class(groupMember partial) Class(religionMember partial groupMember) Class(partyMember partial groupMember) Class(religion partial) Class(party partial) Class(president partial religionMember partyMember) Instance(nixon type(president)) DatatypeProperty(pacifist domain(groupMember) range(xsd:string)) DatatypeProperty(color domain(groupMember) range(xsd:string))) ObjectProperty(religion domain(religionMember) range(religion)) ObjectProperty(party domain(partyMember) range(party)) Figure 2.9 OWL Example. For example, in Figure 2.9 we could not represent the default values for the features pacifist and color declared by the classes ReligionMember and PartyMember using OCL and UML notations. We either couldn’t represent the invariants in the class President, since the kind of invariant used in our UML model is not supported by OWL. 2.4. SWSL. The Semantic Web Service Language (SWSL) [16] language family is an initiative from W3C with the objective of providing a language to formally specify the so-called Semantic Web Services. This language is subdivided into two sub-families, SWSL-FOL and SWSLRules. Syntactically, both consist of the common horn FOL core, with various orthogonal extensions that can be freely combined to obtain a specific language. These extensions include full FOL as well as high-order and OO extensions, these last two respectively based on HiLog [29], and F-Logic [100]. In terms of reasoning services, SWSL-FOL was conceived to support pure deduction under the open-world assumption of classical FOL which provides its formal semantics. In contrast, SWSL-Rules was conceived to support the integration of deduction with default reasoning and non-monotonic inheritance. Since, to the best of our knowledge, there is no inference engine for SWSL, in this work we focus on the subset of it, called F-logic, that is implemented in the Flora-2 system[103]. Its semantics is based on the work of Yang [100] that extends Prolog with object-oriented predicates on top of well-founded models [49] with Negation-As-Failure (NAF) to represent the default reasoning involved in inheritance. In Figure 2.10, we show a simplified abstract syntax of SWSL-Rules. A rule has a head and a body, with the following concrete syntax: “head :- body.”. A rule with a “true” body can be written as “head.” and it is called a fact. We have two kinds of F ormula: the AtomicF ormula and the ConjunctiveF ormula. If f0 , . . . , fn are instances of F ormula, f0,...,fn is the concrete syntax for their conjunction. We focus on a special kind of AtomicF ormula, the AtomicM olecule, which represent the OO formulas. The class T erm represents the FOL terms, and its subclass Oid, the terms that.

(42) 20. BASE TECHNOLOGIES. Rule. Formula. 0..*. + body. + head. AtomicFormula. AtomicMolecule. ValueMolecule inheritable:Boolean. SignatureMolecule inheritable:Boolean. Oid. + subject. ClassMembershipMolecule. + type. + feature + value. ConjunctiveFormula. Term. SubClassMolecule. + class. Oid + superclass. + feature. Figure 2.10 SWSL-Rules Simplified Abstract Syntax. identify objects, i.e., the object identifiers. Every AtomicM olecule has a subject, which is an Oid. A V alueM olecule defines the value of a feature on an object or class. It has the concrete syntax s[f->v], where s is the subject, f is the feature and v is the value. If the value is inheritable by subclasses (inheritable = true), we use the syntax s[f*->v]. The SignatureM olecule represents the type of the values of a feature in an object or class. It has the syntax s[f=>t], where s is the subject, f is the feature and t is the type. If the type should be inherited by subclasses (inheritable = true), the syntax is s[f*=>t]. The ClassM embershipM olecule states that the object subject is an instance of the class class. Its concrete syntax is subject:class. The SubClassM olecule states that the class subject is a subclass of the class superclass. Its concrete syntax is subject::superclass. In SWSL, any term can be an Oid. It is important to highlight that the difference between classes, attributes, objects and values is contextual, not syntactical. For example, in the following F-Molecules, the same Oid a plays a different role in each of them: a[m → v], c :: a, a : b, c[a → v], c[d → a] Both SWSL-FOL and SWSL-Rules use the so-called multiple inheritance with overriding and source based conflict resolution strategy. The only difference between its use in them is that in SWSL-FOL inheritable value molecules are forbidden. Because of these similarities, from now on we are going to focus only in SWSL-Rules. Example 1. Let us analyze the following set of facts:.

(43) 2.4 SWSL. 21. clyde:royalElephant. elephant[color*->gray]. royalElephant[color*->white]. royalElephant::elephant. The question is: what is the value of the color attribute of clyde? From the following set of facts we could deduce clyde[color->gray]: clyde:royalElephant. elephant[color*->gray]. royalElephant::elephant. But if we take royalElephant[color*->white] into consideration, we will notice that the answer is clyde[color->white]. In this case, we say that the definition of color in royalElephant overrides the one in elephant. The following example will illustrate the semantics for multiple inheritance in F-logic: Example 2. Let us consider the following rule base: newParty : quaker. newParty : republican. quaker[policy*->pacifist]. republican[policy*->hawk]. quaker[size*->big]. republican[age*->150]. We can deduce the following values for the attributes inherited by newParty: newParty[size->big]. newParty[age->150]. Notice that newParty inherited all attributes defined by its superclasses, except for policy. In this case we have a multiple inheritance conflict between the value for policy from quaker and from republican. In such cases, no value is inherited by the object. This is the source based conflict solving strategy, for if the same attribute or method could be inherited from different sources no inheritance takes place, regardless of the involved values. Another important feature of F-logic that, in spite of not being supported in SWSL, is going to be covered by this work is the code inheritance, whose objective is enabling a rule to define the code to derive the value of an operation that is defined in a superclass. Let us consider the following example. Example 3. Let us suppose we want to compute the bonuses for the employees in a department, which is defined according to the amount of sales of each employee, following the rule:.

(44) 22. BASE TECHNOLOGIES. F-molecule o:c c :: s o[a → v]. Relational isa(o, c) sub(c, s) f d(o, a, v) or local f d(o, a, v). Figure 2.11 Mapping object-oriented predicates to relational predicates. code dept[bonus->N] :- dept[sales->S], N = S * 10%. The difference between both kinds of inheritance (value inheritance and code inheritance) is very subtle. Suppose we have the facts mike[sales->200] and mike : dept, if there is no code inheritance, the fact mike[bonus -> 20] is inherited, if there is code inheritance the whole rule is inherited. mike[bonus -> N] :- mike[sales -> S], N = S * 10% Notice that in the second case, the inheritance takes place independently of the satisfiability of the rule body. That is why value inheritance is said to be data-dependent. The model theoretic semantics of a SWSL-Rules program is given by its optimistic object model, which is an extension of the well-founded semantics [49] for general logic programs. The optimistic object model for a rule base can be computed by rewriting it to an equivalent logic program under the well founded semantics. The equivalent program is obtained by rewriting each molecule into a relational predicate (Figure 2.11), and by appending a fixed set of trailing rules to the end of the obtained program (see Figure 2.12). An important concept is the concept of local values. We say that a value is local if it can be obtained by a deductive-only process from the rules or the facts of a program. Non-local values, differently, can be obtained only by the interference of inheritance. In the trailing rules, the predicate local_fd signals the feature values that are defined locally, i.e., appearing in the head of rules or in facts, whereas the predicate fd includes the local and the non-local values. The first part of the trailing rules defines the semantics for the isa and sub predicates. The second part defines the feature inheritance: the object O has the value V for the feature M if: (i) it is defined locally, (ii) it is inherited by value or (iii) it is inherited by code. According to the third part, a value is inherited by value if (i) it is locally defined in a super class (value candidate) and it is not overriding by any intermediate class (¬override), (ii) it is not locally defined (¬local) and (iii) it is not ambiguously defined by multiple unrelated superclasses (¬multiple). As we can see, the semantic of every SWSL-Rules rule base can be given by translating it into the relational syntax and appending a fixed set of trailing rules. This is the basis of the approach we are going to use when extending CHR∨ with frame based syntax: the semantics of the CHORD rule bases will be given by a CHR∨ rule based with some trailer rules. The only difference is that the set of appended trailer rules will vary according to the semantic assumptions taken into consideration by the input rule base..

(45) 23. 2.4 SWSL. % inheritance graph sub(S,C) ← sub(S,X), sub(X,C). isa(O,C) ← isa(O,S), sub(S,C). % feature fd(O,M,V) fd(O,M,V) fd(O,M,V). inheritance ← local fd(O,M,V). ← value fd(O,M,V). ← code fd(O,M,V).. % value inheritance value fd(O,M,V) ← value candidate(C,M,O), local fd(C,M,V), ¬ local(O,M), ¬ multiple(C,M,O). value candidate(C,M,O) ← isa(O,C), local fd(C,M,V), C 6= O, ¬ override(C,M,O). local(O,M) ← local fd(O,M,V). multiple(C,M,O) ← value candidate(X,M,O), X 6= C. override(C,M,O) ← sub(X,C), isa(O,X), local fd(X,M,V), X 6= C, X 6= O. ... Figure 2.12 F-logic Trailing Rules.

(46) 24. BASE TECHNOLOGIES. 2.5. CHR∨. CHR (Constraint Handling Rules [47]) emerges in the context of the Constraint Logic Programming (CLP) as a language for describing Constraint Solvers. In CLP, a problem is stated as a set of constraints, a set of predicates and a set of logical rules. Problems in CLP are generally solved by the interaction of a logical inference engine and constraint solving components. The logical rules (written in a host language) are interpreted by the logical inference engine and the constraint solving tasks are delegated to the constraint solvers. For example, let us assume that the logic programming language is Prolog, and we have the following logical rule: balance(ac, -100). closedAccount(C) :- balance(C,B), B < 0. In this case, let us suppose closedAccount(X) and balance(C,B) are predicates and X<Y is a constraint. Let us suppose we provide the following goal to the Prolog engine: closedAccount(ac) In this case, the Prolog engine will expand this goal to the following set of goals: balance(ac, B), B < 0 It will then expand the first goal and then instantiate B as -100. The list of goals will be: -100 < 0 Since this goal is composed by constraints the Prolog inference engine will delegate its execution to the internal constraint solver, which will rewrite it to: true These internal solvers are commonly black boxes provided along with the logical inference engines. They are often written in very low level languages and are very accoplated to the logical inference engine they are bundled into. These characteristics certainly improve their overall performance but reduce their extensibility and mutability. In this context, CHR allows the definition of constraint solvers which are very efficient while being described in a very high level language. The CHR rules are interpreted by a CHR inference engine by rewriting the initial set of constraints by the iterative application of the rules. Its extension with disjunctive bodies, CHR∨ [6] boosts its expressiveness power, turning it into a general programming language (with no need of an host language)..