1. Object-Oriented Knowledge Representation
Jacques Robin

2. 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

3. 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

4. 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

5. 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

6. 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)

7. 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

8. 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

9. 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

10. 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

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

12. 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)

13. 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

14. 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

15. 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

16. 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.)

17. 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

18. 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

19. 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.

20. 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

21. 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)

22. 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!

23. 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!

24. 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!

25. 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

26. 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

27. 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

28. 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

29. 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)

30. 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

31. 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

32. 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

33. UML x Semantic Networks: Example
Corresponding Class Diagram

34. 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

35. <<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.

36. 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
+/-

37. 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

38. 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

39. 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

40. 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

41. 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

42. 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

43. 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

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