Object-Oriented Knowledge Representation Jacques Robin

Outline Object-oriented languages UML First generation OOKR languages Review: key concepts of object-orientation History of OO languages Motivation for OO software engineering and knowledge representation First generation OOKR languages Semantic networks Semantic networks x Classical First-Order Logic (CFOL) Frames Frames x Semantic Networks Frames x CFOL UML The variety of UML diagrams Class diagrams Object diagrams Meta-knowledge representation and MOF The UML meta-model Activity diagrams UML x Semantic networks UML x Frames Limitations of UML Diagrams

Review of Key Object-Orientation Concepts Class (or concept, or category): abstract representation of a set of individuals with common structural and/or behavioral properties A class defines a complex type Object (or individual, or instance): individual instance of a given class An object conforms to the complex type defined by its class An object is created by instantiating its class (constructor method) Each object has a unique identifier (oid) that distinguishes it from other instances of the same class sharing the same properties The structural properties of a class are a set of attributes (also called fields or slots), which value is constrained to be of a certain subset of types (primitive types or classes) The structural properties of an object are specific values for these attributes within the ranges defined by its class The behavioral properties of a class are a set of operations (also called methods, procedures, deamons or functions) that its instances can execute The signature of a class is the set of type constraints on its attributes and on the parameters and return value of its operations The properties of a class have various visibilities such as public, protected and private allowing their encapsulation Classes are organized in a generalization (specialization) hierarchy Properties are inherited down the hierarchy from a class to its subclasses and its objects

Inheritance Allows concise knowledge representation through reuse of specifications and implementations among classes and objects down a specialization hierarchy Types of inheritance: Structural inheritance Attribute signature inheritance (constraint inheritance) Value inheritance Behavioral inheritance Operation signature inheritance (constraint inheritance) Operation code inheritance Inheritance multiplicity Simple inheritance (each class restricted to having a single super-class, and each object restricted to belong to a single class) Multiple inheritance of different properties from different sources Multiple inheritance of same property from different sources Inheritance monotonicity Monotonic inheritance: simple without overriding Non-monotonic inheritance: with overriding, logically equivalent to default reasoning, semantics beyond Classicial First-Order Logic

A Brief History of OO Languages Software Engineering Programming Databases Knowledge Representation Distributed Systems 1965 Simula Sketchpad Smalltalk UML1 Semantic Networks Frames Description Logics C++ OQL Java Frame Logics C# SQL’99 OCL1 MOF1 OWL OCL2 UML2 MOF2 Semantic Web CHORD SWSL 2006

Motivation for OO in Software Engineering Improved productivity, quality, legibility and maintainability in developing software artifacts Software reuse instead of rewriting or cut and paste More intuitive Divide software in abstract entities and relations that directly match common cognitive abstraction of modeled domain Easy to learn Unifying notation Single representation paradigm for all software process stages Single, unified modeling language (UML)

Initial Motivation for OO in Knowledge Representation Reasoning at the level of categories Inheritance as reasoning task Representing structural knowledge with a notation that is more intuitive than formal logic Easier to acquire, understand, maintain, etc. Reasoning about classifying instances into categories and inheritance can internally reuse a logic-based theorem prover, but in a way that is transparent, hidden from the domain expert Benefits of software engineering carrying over to knowledge (base) engineering

Categories The organization of objects in categories is a vital part of knowledge representation Most human reasoning occurs at the abstract level of general categories (intentional knowledge), rather than at the level of individual objects (extensional knowledge) Partial information: coming for example from the sensors of an agent, about an object can be sufficient to classify it into a set of fixed categories about which general knowledge has been formalized The missing information: needed for example for an agent to make a decision about how to handle the object or predict its behavior about the object can then be derived from the properties of the category Complex taxomonies involving generalization and composition relationships among categories form a rich network of abstract knowlege onto which to base the reasoning of an agent

Properties of Categories Disjointness No common elements Ex.: male and female Exhaustive decomposition Covers the entire set of entities in the represented domain Ex.: an animal that is not male, must be female Partition Exhaustive decomposition into disjoint categories Counter-example: citizenships Composition A category of objects has another category of objects as one of its constituing parts Ex.: A state is part of federal nation, a chapter is part of a book

Semantic Networks Category-oriented knowledge visual modeling Each category and instance is represented by a network node Each relationship between categories and instances is represented by a network link Special subsetOf and partOf relationships among categories Special memberOf relationship between a category and its instances Early semantic networks had single isa relationship that did not distinguish between subsetOf and memberOf Efficient algorithms to derive instance properties from their category: By value inheritance By link path query

Semantic Networks: Examples Network with four categories and four instances Network with N-ary relationship reified as a category instance

Semantic Networks x CFOL: Examples (P, person(P)  mammal(P))  (P, fenalePerson(P)  person(P))  (P, malePerson(P)  person(P))  (P, person(P)  (M hasMother(P,M)  femalePerson(M))) (P, person(P), abnormal(P,person,legNumber)  legNumber(P,2))  femalePerson(mary)  malePerson(john)  sister(mary,john)  malePerson(john)  abnormal(john,person,legNumber)  legNumber(john,1) fly(shankar,newYork,newDelhi,yesterday)

Early Semantic Networks Shortcut the formalization level of knowledge representation Directly mapped the graphical, knowledge level to the user-hidden programming code, implementation level Inference engines implemented reasoning that was unsound with semantic networks defined by most users, due to lack of: Well-defined semantics for non-monotonic inheritance and reification of N-ary relationships as categories Distinction between categories and instances

Late Semantic Networks Incorporated ever increasing types of links to get back expressive power close to that of CFOL Lost visual modeling simplicity and intuitiveness Remaining limitations: Inheritance and link navigation sole inference services No construct to represent behavioral knowledge No construct to represent behavioral knowledge, state changes, events and time Currently obsolete, superseded by Description Logics Most recent DL engines use CFOL theorem proving techniques instead of graph traversal techniques to reason correctly and efficiently

Frames A frame has a name as its identification and describes a complex category or instance using a set of attributes (called slots) A frame system is a hierarchical organized set of frames. An evolution of semantic networks They also implement monotonic and non-monotonic inheritance Nodes are replaced by frames Edges are replaced by attributes (slots) Procedures may be attached to the slots of a frame to: Represent behavioral knowledge Implement other forms of reasoning than mere inheritance Provide a knowledge acquisition user-interface Provide a reasoning explanation user-interface

Frames Categories (classes) and instances (objects) represented by Frames A frame is composed by slots A slot is composed by facets Facets may be: Value specification (known or by default) Constraint over value (type, cardinality) Procedures (triggers for when the slot is acessed, modified or necessary to derive some fact during reasoning) Frames hierarchically organized with multiple inheritance of slots Inheritance is complex (without no formal definition) due to the variety of facets and interactions Reasoning is implemented comgining inheritance and triggers Frames used for: Knowledge representation Inference engine implementation Knowledge acquisition interface implementation Reasoning explanation interface implementation Frames are always an extension of some host programming language (Lisp, C++, Prolog, etc.)

Frames: example Frame: Course in KB University Slot: enrolls Type: Student Cardinality.Min: 2 Cardinality.Max: 30 Slot: taughtby Type: (UNION GradStudent Professor) Cardinality.Min: 1 Cardinality.Max: 1 Frame: BasCourse in KB University Is-a: Course Slot: taughtby Type: Professor Frame: Professor in KB University Slot: degree Default: PhD. Frame: Student in KB University Frame: AdvCourse in KB University Is-a: Course Slot: enrolls Type: (INTERSECTION GradStudent (NOT Undergrad)) Cardinality.Max: 20 Frame: GradStudent in KB University Is-a: Student Slot: degree Default: Bachelor Frame: Undergrad in KB University Is-a: Student

Frames x CFOL: Example Frame: Course in KB University Slot: enrolls Type: Student Cardinality.Min: 2 Cardinality.Max: 30 Slot: taughtBy Type: (UNION GradStudent Professor) Cardinality.Min: 1 Cardinality.Max: 1 Frame: Professor in KB University Slot: degree Default: PhD. partOf(course,kbUniversity)  fsfv(course,enrolls,type,student)  fsfv(course,enrolls,minCard,2)  fsfv(course,enrolls,maxCard,30)  fsfv(course,taughtBy,type,courseTaughtByType)  ((courseTaughtByType = gradStudent)  (courseTaughtByType = professor))  fsfv(course,taughtBy,minCard,1)  fsfv(course,taughtBy,maxCard,1)  partOf(advCourse,kbUniversity)  isa(advCourse,course)  fsfv(advCourse,enrolls,type,advCourseEnrollsType)  includes(advCourseEnrollsType,gradStudent)  excludes(advCourseEnrollsType,undergradStudent)  partOf(professor,kbUniversity)  fsfv(professor,degree,default,phd) Missing: formulas axiomatizing in CFOL the semantics of partOf, isa and all the slots (minCard,maxCard,type, default, etc) Frame: AdvCourse in KB University Is-a: Course Slot: enrolls Type: (INTERSECTION GradStudent (NOT Undergrad)) Cardinality.Max: 20

Frames: limitations Non-declarative behavior knowledge representation as host programming language code as prevents direct acquisition from domain expert No formal semantics No distinction between categories and instances Ad-hoc implementation of deduction and abduction usually inefficient as compared to logic-based ones There are no inductive inference engines for frame learning Lacks key reuse-oriented facilities of modern OO programming languages such as visibility, interfaces, components, etc.

UML as KR Language Class diagram: Activity diagram Modern, well-founded version of semantic networks Activity diagram Modern, well-founded version of flow charts Graphical syntax for procedures Class diagrams + Activity diagrams : Graphical syntax of expressive power approximately equivalent to that of Frames Strengths: Universal standard, well-thought, well-known and well-tooled (CASE) Facilitates convergence between software and knowledge engineering Limitations: Lack of full UML compilers to executable languages Lack of inference engine to automatically reasoning with knowlege represented only as UML models No mathematically defined formal semantics yet Thus: Only useful at the knowledge level Need to be used in conjunction with other language(s) that provide the formalization and/or implementation level

UML Class Diagram Categories represented as classes (nodes) Classes encapsulates: Primitive type properties, attributes Behaviors, operations Relationships between classes represented as associations (edges) Special associations for: Specialization relationship (reciprocal of isa) partOf relationship (aggregation and compositions) Reified relationships represented as association classes Role names and cardinality constraints on associations Many other logical constraints built-in class diagram syntax Arbitrary logical constraints relating any part of the class diagram using Object Constraint Language (OCL, cf. next lecture)

Classes: Attributes Common characteristics of the class members Fields (slots): Base or derived Visibility (public, protected, private) Name Type (Primitive Built-In or Used-Defined Enumerations) Initial default value Property Object attributes: different value for each object Class attributes: same value for all objects Attributes for KR: as many fields as possible!

Classes: Operations Common signature of services provided by the class members Fields: Visibility Name Input parameter Direction Type Multiplicity Default value Property Return type Object methods: called on objects Class methods: called to manipulate class attributes Operations for KR: as many fields as possible!

Associations Association: Fields: Generic relation between N classifiers Fields: One or two Names Navigation direction Two Ends, each with: One Multiplicity Range (default = 1) Zero to One role Zero to one Qualifier Qualifier: needed to distinguish different instances of a one-to-many or many-to-many association Navigation: Role if present Otherwise destination class name Associations for KR: as many fields as possible!

Association Classes Class connected to an association and not to any of its ends Allows associating properties and behaviors to an association One object of the association class for each link of the connected association A one-to-many or many-to-many association class cannot be substituted by a simple class and a pair of simple associations Example: Ca has objects A1, A2, A3, A4 Cb has objects B1, B2, B3, B4 Extent of association class Cc between Ca and Cb with * multiplicity at both ends has necessarily 16 instances Class Cc associated to Ca through association Aca and to Cb through association Acb could have only 4 instances Difference with: ? 4 Elevator control Queue Elevator

Ternary Associations Single association between 3 classes Different from two binary associations Different from one binary association class Example: Ca has objects A1, A2 Cb has objects B1, B2 Cc has objects C1, C2 No link in the ternary association Ca-Cb-Cc corresponding to pair of links A1-B1, B2-C1

Aggregation Associations Association with “part-whole” semantics Associate composite class to its building blocks Static, definitional characteristic of the “whole” class In contrast to composite structure diagrams that model dynamic, configuration characteristic of the containing class Shared aggregation: Many-to-many aggregation

Composition Associations Special case of one-to-one or one-to-many aggregation where part(s) cannot exist(s) without the unique whole Deletion of the whole must therefore always be followed by automatic deletion of the parts

Class generalizations Taxonomic relation between a class and one of its more general direct super-class Special case of generalization between any two classifiers Several generalizations form a taxonomic tree free of generalization cycles Sub-classifier inherits the features from all its direct super-classifiers Private attributes and operations not accessible from sub-classes Protected attributes and operations accessible from sub-classes but not from associated classes UML generalizations allow multiple inheritance and overriding Instances of a sub-class must satisfy all the constraints on all its super-classes (principle of substitutability)

Abstract Classes Class that cannot be instantiated Only purpose: factor gradual refinements of common and distinct structures and behaviors down a taxonomic hierarchy Abstract operation: common signatures of distinct implementations specified in subclasses Supports polymorphism: generic call signature to distinct operations, with automatic dispatch to the implementation appropriate to each specific call instance

Generalization Sets Subclass set that can be labeled as: complete or incomplete overlapping or disjoint Complete and disjoint generalization sets form a partition of the super-class Sub-subclass can specialize members of two overlapping generalization sets

UML Object Diagrams Object Diagram contains: Specific (named) or generic (named after role, unnamed) instances of classes Possibly several instances of the same class Specific instances of associations (links) among objects Possibly several instances of the same association Illustrates specific instantiation patterns of associated class diagram

UML x Semantic Networks: Example Corresponding Class Diagram

UML x Semantic Networks: Example <<enumeration>> Genders female male transsexual Mammals sisterOf Person gender: genders 0..2 Legs hasMother femalePerson gender = female malePerson gender = male sisterOf mary:femalePerson john:malePerson Missing: OCL constraint defining semantics of sisterOf association has derived from hasMother (an hasFather) associations :Legs hasMother hasMother :femalePerson

<<enumeration>> Frame: Course in KB University Slot: enrolls Type: Student Cardinality.Min: 2 Cardinality.Max: 30 Slot: taughtBy Type: (UNION GradStudent Professor) Cardinality.Min: 1 Cardinality.Max: 1 UML x Frames: Example KBUniversity 1..* 1..* 0..20 Frame: AdvCourse in KB University Is-a: Course Slot: enrolls Type: (INTERSECTION GradStudent (NOT Undergrad)) Cardinality.Max: 20 enrolls Student Course Professor degree = phd 1..* taughtBy AdvCourse BasCourse Frame: BasCourse in KB University Is-a: Course Slot: taughtBy Type: Professor Lecturer Undergrad GradStudent degree = bachelor Frame: Student in KB University <<enumeration>> Degrees bachelor master phd Frame: GradStudent in KB University Is-a: Student Slot: degree Default: Bachelor Frame type constraint in red best modeled as OCL constraints Frame: Undergrad in KB University Is-a: Student Frame: Professor in KB University Slot: degree Default: PhD.

Comparison Table Intuitive Graphical Syntax Well-Founded Constructs Expressivity KR Layer Formal Semantics Available Inference Engines Standard Widely Used Semantic Networks Y N Structural Knowledge Implementation Frames Behavioral as Code Knowledge +/- Implementation UML2 (w/ OCL) Behavioral as Model Temporal CFOL ( unintuitively ) Behavioral through Logic Programming Temporal through Axiomatization Knowledge +/- Formalization +/-

Meta-Object Facility (MOF) Structural meta-knowledge representation language Reuses UML class diagrams to specify, in an object-oriented way, the abstract syntax of computational languages Advantages over BNF grammars: Visual clarity Abstract Terminals with internal structure and behaviors Richer variety of relation semantics among non-terminals: specialization, aggregation, composition and simple associations instead of merely linearization order Reuse through inheritance, package import and package merge A MOF specification of the abstract syntax of a language L is called a meta-model of L

Relationship between MOF and UML UML2 Infrastructure ... UML2 Superstructure Activities Actions States Transitions Behavioral Components Ports Structural ... Classes Attributes Types Packages ... Basic Constructs Associations ... merge Application models merge ... MOF Reflection metamodels metamodels metamodels

Simplified MOF Meta-Model of itself NamedElement Element Relationship Classifier 1..* * Generalization RedefinableElement Type TypedElement Constraint Association redefined ValueSpecification * Feature Classifier AssociationClass Class BehaviorallFeature Operation Parameter * Property * StrcuturalFeature InstanceSpecification

Simplified MOF Meta-Model of itself NamedElement BehaviorallFeature StructuralFeature Operation Parameter * Property * Classifier Feature TypedElement Type ValueSpecification 1..* Relationship RedefinableElement * NamedElement Element * InstanceSpecification Constraint * Generalization * Association Class AssociationClass DataType PrimitiveType Enumeration Interface

MOF Meta-Model of Early Semantic Networks  OOP/OOSE Classes & Objects  OOP/OOSE subclass & instance relationships  OOSE aggregation & composition associations OOP/OOSE attributes & other associations Node Link * * <<enum>> Certainty Level Known Default IS-A PART-OF Attribute Specification Single Value Specification Multiple Value Specification

MOF Meta-Model of Frames  OOP/OOSE subclass & instance relationships  OOP/OOSE Classes & Objects OOP/OOSE Attributes & Associations No corresponding concepts in OOP/OOSE  OOSE Constraints  OOP/OOSE Methods & Activities IS-A * Frame * Slot * Facet Host Language Procedure <<enum>> Certainty Level Known Default Value Specification Constraint Procedural Attachment Missing Read Write <<enum>> Trigger Cardinality Constraint Single Value Specification Min: Int Max: Int Multiple Value Specification Type Constraint Return Value Input Parameter

Simplified MOF Meta-Model of UML Classifiers Type Classifier generalizes Feature DataType Interface Class Association StructuralFeature BehavioralFeature Parameter PrimitiveType Enumeration AssociationClass Property Operation Constraint Boolean Integer Real String AssociationEnd Attribute

Simplified MOF Meta-Model of UML Relations Association Generalization Dependency AssociationClass QualifiedAssociation Aggregation GeneralizationSet Realization Composition PowerType