cbr_4

Dr. Armin Stahl Insiders Technologies GmbH

Product Management

E-Mail: [email protected]

Lecture

Case-Based Reasoning

(Fallbasiertes Schlieen) WS 2013/14

2 Case Representation

Lecture "Fallbasiertes Schlieen WS 2013/14

Dr. Armin Stahl

Exercise

Third exercise sheet online

Submission deadline:

Fr. 2012-11-29

Submission electronically to

[email protected]

(for details see exercise sheet)

Submission is not mandatory for

admission to exam but highly

recommended!

Second exercise:

Wednesday 27.11., 10:00-10:45

Room 48-462

Tutor: Max Feltes

0 Introduction

Slide 2


Dr. Armin Stahl

Structure of the Lecture

1 Motivation and Introduction


3 Similarity Measures

4 Retrieval Algorithms

5 Adaptation Approaches

6 Learning Approaches

7 CBR in Industrial Practice

Guest lecture

Ralph Traphner

Head of Research

Empolis Knowledge Management GmbH

17.01.2014


Slide 3


Dr. Armin Stahl

Review

What type of cases can be distinguished?

How is a case structured in general?

Which general requirements have to be

considered during the definition of the case

representation?

Which three CBR approaches can be

distinguished?

What is an important difference between an

attribute-value based case representation and

a standard data base model?


Slide 4


Dr. Armin Stahl

D

LC

D

LC

CBR System

Formalization

Definitions (continuation):

: case base

Set of available cases

: situation characterization function

Characterizes a given situation in form of a query

Q, D, und L determine the vocabulary of the CBR system

It typically holds Q = D

QSsc :

CCB

D

LC

QS

Application

Environment

sc(s)


Slide 5


Dr. Armin Stahl


Case Information CBR Approaches Representation Formalisms Attribute-Value based Object-Oriented More specialized representations


Slide 6


Dr. Armin Stahl

Properties of Basic Attribute Types

Integer & Real:

Suited of numerical measurements and other numeric information

Well defined possibilities to compute similarities (based on order)

Easy adaptation (e.g. based on in/decrement or other computations)

Strings

Suited for less structured information; very flexible

Similarity definition is more difficult (typically based on syntax only)

Adaptation practically infeasible

Symbols:

Suited for small number of fixed attribute values

Simple and powerful similarity measures

Easy adaptation (just assign a new value)


Slide 7


Dr. Armin Stahl

Set Types

Example problem (blackboard example)

Attribute values may consists of a set of basic values

Use of set types

Significantly increased expression power

Significantly increased complexity of similarity measures

Interpretation

and-Semantic: all values are valid simultaneously

or-Semantic: only one value is actually valid (i.e. due to uncertainty)

The intended semantic is very important for the similarity

computation!

2 Case Representation Slide 8


Dr. Armin Stahl

Attribute-Value Based Case Representation

Simple Example: Product Recommendation

Representation of a travel case (see also excercise sheet)

Characterisation

Country: SYMBOL {Teneriffa, Lanzarote, Mallorca, Ibiza}

Accomendation: SYMBOL {Apartment, Hotel, Bungalow, Camping, }

Accomendation-Name: STRING

Price: INTEGER [100; 10000]

Sport offers: SYMBOL SET {Diving, Sailing, Golf, Tennis, }

Solution information

?


Slide 9


Dr. Armin Stahl

Attribute-Value Based Case Representations

Conclusions

Advantages:

Disadvantages:

Application areas:

Any Ideas?


Slide 10


Dr. Armin Stahl




Slide 12


Dr. Armin Stahl

Object-Oriented Representations

Idea: Aggregation of associated attributes to object

descriptions

i.e. each objected is described by a fixed set of attributes

An object is an independent entity

A case is a composition of objects

Between objects exist clearly defined relations

Implementation: Use of well-known object-oriented

representation formalisms

Compare object-oriented programming languages (e.g. Java, C++) and

corresponding modeling languages (e.g. UML)


Slide 13


Dr. Armin Stahl

Terminoloy: Objects and Classes

An object class describes the structure of objects by

defining a finite set of attributes and corresponding data

types.

An object (also called object instance) of a particular

object class

allocates the pre-defined attributes of the object class with

concrete values

describes a certain entity of the application domain where each

attribute-value pair corresponds to a feature of that entity.

Object classes may be arranged in inheritance hierarchies

A sub class inherits the attribute and type definitions of its super

class


Slide 14


Dr. Armin Stahl

Objects and Object Classes

Example

HOTEL

City: SYMBOL { Puerto de la Cruz, }

Hotel name: STRING

Hotel category: REAL [1; 5]

Number of beds: INTEGER [2; 2500]

Distance to beach (km): REAL [0; 100]

Sport offers: SYMBOLSET {Diving, }

Object class

Hotel Orotava Place

City: Puerto de la Cruz

Hotel name: Orotava Place

Hotel category: 4

Number of beds: 472

Distance to beach (km): 0,2

Sport offers: {Diving, Fitness}

Object instance


Slide 15


Dr. Armin Stahl

Relations between Objects

Relations between objects are the most important aspect

Examples:

Attributive relations:

Example: Properties (red, small)

Spatial relations:

Example: over, under, in, around, in front of, near by, etc.

Temporal relations:

Example: before, after, until

Logical relations:

Example: is-precondition, if-and-only-if

etc.


Slide 16


Dr. Armin Stahl

Important Relations

Most important relations for OO-representations in CBR:

Composition / aggregation: is-part-of relation expresses the

composition of objects out of sub-objects

Example: Room is-part-of Hotel

Generalization / specialization: a-kind-of relation expresses

generalization / specialization relations between objects and

generates inheritance hierarchies

Example: Hotel a-kind-of Accomendation

Both relations are typically transitive


Slide 17


Dr. Armin Stahl

Compositional relations (is-part-

of) are modeled with so called

relational attributes

Relational attributes are attributes

which have (complex) objects (or

links to objects) as values

Compared to normal attributes

which have basic data types (e.g.

Integer or String) as values

They generate a decomposition

hierarchy

Compositional Relations

AUTO

TREIBSTOFFSYSTEM

MOTOR

ELEKTR. SYSTEM

LUFTKANLE SCHWIMMER

VERGASER MOTORGEHUSE

is-part-of


Slide 18


Dr. Armin Stahl

Compositional Relations

Example

HOTEL Hotel category: REAL [1; 5]


FLIGHT Airline: SYMBOL {Lufthansa, }

Number of stopover: INTEGER [0; 5]

Case Representation

Hotel 51 Hotel category: 4


Travel 56 Location: Teneriffa

Duration: 14

Price: 789

Accomendation: Hotel 51

Flight: Flug 73

Flight 73 Airline: Lufthansa

Number of stopover: 0

Case

TRAVEL Location: SYMBOL {Teneriffa, }

Duration: INTEGER [3; 31]


Accomendation: HOTEL

Flight: FLIGHT

relational attributes


Slide 19


Dr. Armin Stahl

Relational Set Attributes

As for attributes with basic data types, also relational

attributes may have set types

i.e. an relational attribute may have a set of objects as value

For the interpretation of these values it holds exactly the

same as for basic attributes

and-semantic

or-semantic

Relational set attributes allow to model 1:n relations

between objects


Slide 20


Dr. Armin Stahl

Relational Set Attributes

Example




Sport offers: SYMBOL SET {Tennis, }

Trip offers: TRIP SET

TRIP Name: STRING

Kind: SYMBOL {Bus, Trekking, Boat, }

Duration (h): INTEGER [1, 48]

Case Representation

Trip 1 Name: Bustour Puerto de la Cruz

Kind: Bus

Duration (h): 4


Duration: 14

Price: 789

Sport offers: {Tennis, Fitness}

Trip offfers: {Trip 1, Trip 3}

Case

Trip 3 Name: Teide Trip

Kind: Trekking

Duration (h): 10


Slide 21


Dr. Armin Stahl

Generalization / Specialization

relations (a-kind-of) have to be

modeled explicitly between

object classes

Definition of sub-/ super-classes

Sub-classes inherit all attributes

of super-classes

Sub-classes may add additional

attributes

Advantage: Generation of

dynamic cases structures

Generalization/Specialization Relations

is-kind-of

TRANSPORTMITTEL

FLUGZEUG AUTO BAHN

PKW LKW

SPORTWAGEN KOMBI

They generate an inheritance hierarchy


Slide 22


Dr. Armin Stahl

Generalization / Specialization Relations

Example

HOTEL Hotel category: REAL [1; 5]

Board: SYMBOL {full, half, breakfast only}

ACCOMENDATION Location: SYMBOL {Playa del Carmen, }


APARTMENT Rooms: INTEGER [1; 10]

Kitchen: BOOLEAN




Accomendation: ACCOMENDATION

Flight: FLIGHT

Note: This are two different attributes since they are defined in different name spaces

Note: These are two different attributes since they are defined in different name spaces!


Slide 23


Dr. Armin Stahl

Object-Oriented Representations

Conclusions

Advantages:

Disadvantages:

Application scenarios:

Any Ideas?


Slide 24


Dr. Armin Stahl




Slide 26


Dr. Armin Stahl

Name : String = Altes Zollamt

Ort : String = Kaiserslautern

Einzelzimmer : Zimmer = Objekt2

Doppelzimmer : Zimmer = Objekt3

Object1 : Hotel

Anzahl : Integer = 6

Preis: Real = 115,50

Object2 : Zimmer

Anzahl : Integer = 8

Preis: Real = 155,50

Object3 : Zimmer

1

1

1

1

Graphs vs. Object-Oriented Representations (I)

A composition hierarchy is also an

attributed relational graph:

Each relational attribute is

an edge label

The set of all attribute-value

pairs of an object is the node

label

But such complex labels are usually not used in graphs

i.e. nodes typically do not have complex structures themselves

Specialization / Generalization relations with inheritance

cannot directly be represented

To model OO-structures with graphs makes not much sense

Hotel 51 Hotel category: 4



Price: 789

Accomendation: Hotel 51

Flight: Flight 73

Flight 73 Airline: Lufthansa

Number of stopovers: 0


Slide 27


Dr. Armin Stahl

In principle, object-oriented representations may be used to

model arbitrary graphs

Example

Disadvantages Representation is not natural

Definitions of object classes do not model domain knowledge but represent

only structure

It may appear cyclic object structures

That makes problems for the similarity definition

Graphs vs. Object-Oriented Representations (II)

1 2 a

NODE Label: STRING / SYMBOL /

Outgoing edges: EDGE SET

EDGE Label: STRING / SYMBOL /

Target node: NODE

Node 1 Label: 1

Outgoing edges: Edge 1

Edge 1 Label: a

Target node: Node 2

Node 2 Label: 2

Outgoing edges: -


Slide 28


Dr. Armin Stahl

Use of Graphs for Case Representations

Graphs can be used to represent

Problem descriptions (case characterization)

Solution descriptions

Additional information (solution way, justifications, etc.)

Application examples:

Biological or artificial neural networks

Molecular structures

Spatial structures (e.g. ground plans in architecture)

Partially ordered action sequences (plans)


Slide 29


Dr. Armin Stahl

Use of Graphs as Problem Description

Graphs may describe simple structural relations between

individual parts of the problem description

Example: Classification of the toxicity of organic molecules

Atoms become labeled nodes

The label denotes the element

Linkages become labeled edges

The label denotes the kind of linkage

Problem:

Solution (Classification): Toxicity: very toxic

Tetrachlordibenzodioxin (TCDD)


Slide 30


Dr. Armin Stahl

a b c e d f

x Problem

a b c e d f

x Solution

Use of Graphs as Solution Description

Graphs may describe simple structural relations between

individual parts of the solution description

Example: Design of the piping in architecture

Nodes: Inlet and outlet openings; connections

Edges: pipes


Slide 31


Dr. Armin Stahl

Graph Representations

Conclusions

Advantages:

Simple structures are easily representable

Algorithms from graph theory (e.g. graph isomorphism) can be

applied for similarity computation

Disadvantages:

Limited structural expressiveness compared with OO representations

Algorithms from graph theory are very costly

(e.g. sub-graph isomorphism check is NP-complete)

Application areas:

Analytical and synthetic tasks with graph structures

In combination with OO representations also for highly structured

and complex information (objects as node descriptions)


Slide 32


Dr. Armin Stahl

Definitions (elementary symbols):

Logical symbols:

Variables: x, y, z, ... x1, y1, z1,...

Function symbols: f, g, ... f1, g1,...

Predicate symbols: P, Q, ... P1, Q1,...

Definition (terms)

(i) All variables and 0-ary function symbols are terms

(ii) If t1,...,tn are terms and f is an n-ary function symbol (n>0) then

f(t1,...,tn) is also a term.

(iii) All terms arise from (i) through iteration of (ii)

(iv) Terms without any variables are called ground terms

Basics of First-Order Logic (I)


Slide 33


Dr. Armin Stahl

Definition (formulas):

(i) If p is an n-ary predicate symbol and t1,...,tn are terms, then

p(t1,...,tn) is a formula; such formulas are also called atomic

formulas or atoms

(ii) If F and Y are formulas, then

FYFYFYFare also formulas

If x is a variable, then xFxFare also formulas

(iii) All formulas arise from (i) through iteration of (ii).

(iv) Ground formulas are formulas without any variables

Basics of First-Order Logic (II)


Slide 34


Dr. Armin Stahl

Case Representations based on First-Order Logic

Problems and solutions are described by a set of ground

atoms

Example (Diagnosis):

Problem = {errorcode(i59), i/o_state(out7,on),

relay(rel7, switched), voltage(vdd, gnd, 23.8)}

Solution = {defect(magnetic switch(rack3,mgs43))}

Attribute-value based representations may be mapped on

predicates (one predicate per attribute or case)

Graph representions may be mapped on predicates (one

predicate per node and edge)

Object-oriented representations may be mapped on

predicates (terms represent compositional relations)

term

predicate


Slide 35


Dr. Armin Stahl


Example: Action Planning

a

b

c a

b

c a

b

c

Initial state

c

b

a

Goal state

move(c,table) move(b,c) move(a,b)

Problem

Solution

{ on_table(i,a),

on(i,b,a),

on(i,c,b),

on_table(g,c),

on(g,b,c),

on(g,a,b) }

plan(cons(move(c,table),

cons(move(b,c),

move(a,b))))

Problem Solution

Case based on

first-order logic


Slide 36


Dr. Armin Stahl


Conclusions

Advantages:

Disadvantages:

Application areas:

Any Ideas?


Slide 37


Dr. Armin Stahl

Representation of Cases in Planning

Combination of

First-order logic

Graphs

Case = ( , , , ....)

Initial state and goal state are sets of ground atoms

Plan graph:

Totally ordered sequences of actions

Nodes are actions; labels are names of actions

Edges describe total order

Partially ordered sequences of actions

Nodes are actions; labels are names of actions

Edges describe partial order (action 1 before action 2)


Slide 39


Dr. Armin Stahl

Representation of Cases in Planning

Example

initial state plan graph

a

b

c

d

{on_table(a),

on(b,a),

on(c,b),

on(d,c) }

goal state

a

c

b

d

{ on_table(a),

on_table(b),

on(c,a),

on(d,b) }

move(d,table)

move(c,table)

move(b,table)

move(d,b) move(c,a)


Slide 40


Dr. Armin Stahl

Structure of the Lecture

1 Motivation and Introduction



4 Retrieval Algorithms

5 Adaptation Approaches

6 Learning Approaches

7 CBR in Industrial Practice

1 Motivation & Introduction

Slide 41


Dr. Armin Stahl


Cases

Background

Knowledge Tested/

Repaired

Case

Solved

Case

Learned

Case

New

Case

New

Case

Similar

Case

Similarity Measures


Slide 42

cbr_4

Documents

case representation

armin stahl exercise

armin stahl review

armin stahl structure

introduction slide

adaptation approaches

set of basic values

similarity computation