Chapter 5 Representation Issues for E-Commerce Similarity-Based Reasoning and CBR Stand 20.12.00

Chapter 5

Representation Issues for E-Commerce Similarity-Based

Reasoning and CBR

Stand 20.12.00

- 2 - (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern

Recommended References

• Case Representations in General:– R. Bergmann: Grundlagen Fallbasierter Systeme.

Vorlesungsfolien.

http://wwwagr.informatik.uni-kl.de/~bergmann/CBRVL2k/– Stefan Wess (1995). Fallbasiertes Problemlösen in

wissensbasierten Systemen zur Entscheidungsunterstützung und Diagnostik. DISKI 126, infix-Verlag. Kapitel 6.2 (S. 110-121).

• Case Representation for E-Commerce– W. Wilke: Knowledge Management for Intelligent Sales Support

in Electronic Commerce. DISKI 213, infix Verlag 1999.


Formal Notions in CBR and E-C (1)

• There is a wide variety of concepts used in E-C and in this chapter we will restrict ourselves to a certain subsets which are based on logic formalisms that only marginally differ from those occurring in CBR because they are both centered around the notion of similarity-based retrieval.

• The main concepts to be formalized here are– Problems, solutions in CBR– Demands, functionalities and products in E-C– Cases, case bases and structures on case bases in CBR– Product bases and structures on them in E-C

• The concepts will be based on those introduced in chapter 4.


Formal Notions in CBR and E-C (2)

• Notions connected with product representations• Notions connected with function representations • Notions connected with similarity• Notions connected with adaptation• The main algorithms and methods to be defined are

– Retrieval algorithms– Adaptation methods

• The parallel approach to the concepts in E-C and CBR is based on the following:– Demands are either intended functionalities or desired products and

both play the role of a problem to be solved– Products and realized functionalities play the role of solutions.


Products and Component Orientation

• We consider the products to be built up from atomic components by certain constructors.

• This applies not only to technical devices but also to service, travel etc, see below.

• The description of the product depends on the purpose (products are real world things !); one needs in particular the attributes and properties of interest.

• It is important to realize that the access to the products can use only the elements which are represented.


The Formal Local - Global Principle for Products

• This principle states that each object A is constructed from so-called “parts” Ai by some construction process

C(Ai |i I) = A

• C is called the construction operator and the Ai are called the components. In an attribute-value representation the attributes are the components.

• Classes of objects are described in the same way where certain parts or parameters describing them have not yet assigned values.

• In chapter 6 we introduce a corresponding local-global principle for similarities.


Functionalities• Functionalities are abilities of products to perform certain

actions:– to make pictures with a camera– to drive with a car at a certain speed– to have a certain financial benefit – etc

• Functionalities are therefore properties of products and will be part of the component oriented product description.

• Functionalities are the primary goals of the customer.• Functionalities are therefore typical elements of demands

(often the only ones) and determine the parts of the products.


Actions and Process Orientation

• Actions change given situations and are elements of processes.

• Actions are also composed of atomic parts. • Therefore for actions also the is-a-kind-of and the

part-of relation is used in the description.• There are, however, several other relations of

importance like “actions have the same or the opposite effect”.

• Actions and processes are in the context of e-c also of interest for the activities of the knowledge manager and will be discussed in chapter 15.


Elements of a CBR System

• A CBR system consists formally of– A set called case base the elements of which are

cases– A similarity function– A solution transformation system (optional)


Cases (1)

Formal definition:• A case is an ordered pair (P,S) where

• P (called the problem) is an element of a set P (the problem space)• S (called the solution) is an element from a set S (the solution space)

• P and S are usually described in some formal language.• A case base is a set of cases, denoted by CB.

Besides these simple forms of cases there are more complicated forms

which in addition may have:• explanations, • descriptions of how the solution was achieved, • remarks on the quality of the solution, • pointers to other cases, • pictures etc.


Cases (2)• Cases = (problem, solution) are usually defined in some formal

language

• Often there is a general description P(x1,...,xn) of the problems

s.th. each individual problem is an instance P(a1,...,an) of it

• Often there is also a general description of the solution S(y1,...,ym)

s.th. every solution S(b1,...,bm) is an instance of it (not all variables

have actually to occur).

• The xi are the problem variables and the the y i are the solution

variables

• The solution process consists in finding the right instances for the solution variables.


Cases (3)

• A set of cases is of rule type if there is an a priori partition of the variables into two disjoint sets of problem variables and solution variables.

• A set of cases is of constraint type if any variable may be a problem variable or a solution variable.

• Example of the constraint type:The problem is to built an artefact consisting of n parts which have to be chosen from some set s.t. certain conditions hold; any of the parts may already be determined by the user, the rest has to be found, i.e., any variable can be a solution and a problem variable.


Representation Languages

• In the context of CBR and E-C we deal mainly with three types of representation languages:

1) Logic oriented languages2) Mathematical formulas3) Plain text• The first language type refers to chapter 4• The second language type is used to represent similarity

measures (see chapter 6) and to describe properties of products (see chapter 10).

• Plain text needs a human interpreter.


Different Case Representations :Commercial Products

Free text: textual CBR (tecInno’s CBR answers, ServiceSoft, Serviceware, Inference’s casepoint 1st step)

Lists of questions and answers: conversational CBR (Halley enterprise, Inference’s casepoint 2nd step). No common case structure.

Database like representation: structural CBR (tecInno’s CBR Works, Acknosoft’s KATE, CaseBank, Isoft’s Recall, CSI’s Remind)


Attribute-Value Representations• An item can be represented by attribute-value-pairs.• Example: Price: 19.95 DM

• The set of attributes is either fixe or can vary.• Each attribute has associated a domain (type) for the

values, e.g.,Integer or Reals,Symbols: Arbitrary finite set as {red, yellow, green}Text: Strings of arbitrary lengthHypertext: HTML-Link

• The order in which the pairs are listed may be of importance

Attribute Value


Problem (Symptoms):

ErrorCode: i59

I/O_StateOut7: on

Relais_7: on

Currency_VDD: 23.8 V

Solution (Diagnosis):

Switch board: III

Defect: “Magnetic switch”

Repair: http://www.repair-guide.com/magsw.html

Symbol {i51,i52,i58,i58,i59,i60}

Symbol {on, off}

Symbol {switched, not_switched}

String

Symbol {I, II, III}

Real [0..50]

HTML-Link to repairing service

Example: Diagnosis


Advice

As the example shows:• Standard types contain little information („string“ is

usually good only for names)• Self defined types can be problem oriented• The choice of good types or attributes is often an

important step towards the solution


Primary and Virtual Attributes

• The attributes used in the initial problem description

may certain disadvantages although the description is in

principle complete. This is due to the fact that certain

relations between the attribute values are decisive:– For the financial situation the difference between income and

spending is relevant, not the individual values.

• Primary attributes: Directly presented by the problem.

• Virtual attributes: Defined in terms of primary attributes

• A problem is to define useful virtual attributes which are

directly relevant.


Properties of Attribute-Value Representations

Advantages:Simple representation, easy to implement Simple for efficient similarity measures Easy to store (e.g. in data bases)Efficient retrieval possible

Disadvantages:No structural and relational information

Recommended for large sets of products which are not too complicated or tasks like classification with large case bases


Object Oriented Representations

• There are various object oriented programming languages

• They all have the following properties:– classes and instances– inheritance– information hiding– polymorphism

• The intention what to model may be, however, of very different character


Relations between Objects (1)

• Relations between objects are useful• General relations:

– Taxonomic relations: “a-kind-of” relation expresses a general/special relation Example: Hotel a-kind-of House

– Compositional relations: “is-part-of” relation expresses an aggregation of objects from other objects

– Example: Room is-part-of Hotel, Motor is-part-of Car.


Relations between Objects (2)

• Domain specific relations are very important• They are often not obvious and finding them is

usually an important step towards the solution,e.g.– two products are in the relation „need each other“ if

either product requires the other one – a hotel and a beach may be in the relation „walking

distance“– etc.


Taxonomic Relations

• Taxonomic relations are explicitly expressed between object classes ( superclass, subclass).

• The subclass inherits all attributes of the superclass, i.e. subclasses can only add attributes.

Means of Transportation

Airplane Automobile Railway

Car Truck

Sports Car Sedan

InheritanceHierarchy


Object class House

Name: StringLocation: String

Object class AppartmentSuperclass: House

Bedrooms: IntegerKitchen: {yes, no}

Object class HotelSuperclass: HouseSingle room: roomDouble room: room

Example


Multiple Inheritance

Often there are different hierarchies interleaved with each other and an object may occur in both hierarchies and inherit properties from several ancestors:

Luxury car

Car Luxury object

From the taxonomyof tax regulations

From the taxonomyof technical objects

Special care has to be taken if an object inherits the same attribute from differentsuperclasses.


Aggregations: Compositional Relations

• Compositional relations are described by relational attributes.

• The values of relational attributes are again objects (resp. pointers to objects).

Car

Fuel System Engine Electrical System

Carborator Engine Case

Air Channels Float

CompositionalHierarchy


Example

Object class Hotel Name: String

location: StringSingle: RoomDouble: Room

Object instance: Beach Hotel

(Object class: Hotel)

Name: “Zollamt”

Location: “Kaiserslautern”

Single: Single_Object

Double: Double_Object

Object class Room Number: Integer

Price: Real

Object instance: Single_Object(Object instance: Room)

Number: 6Price: 115,50

Object instance: Double_Object(Object class: Room)

Number: 8Price: 155,50

Instance


CASUEL: A Case Representation Language(Manago, Bergmann, et al. 1994)

Structure of CASUEL

Descriptive Model (Data representation)

• Typ definitions

• Class definitions

Cases

Set of Object

instances

Similaritymeasures

Function

definitionsRules

Generalknowledge


Type Definitions in CASUELPredefined Types Type

Nominal Cardinal

Boolean Symbol Ordered Symb. Taxonomy String Integer Real Time Date

User Definined Types• Domain Restrictions

• Enumerations (unordered, ordered, taxonomic)

Syntax Example:

deftype color a_kind_of symbol;

range (blue red green).


Class Definitions in CASUEL

• Definition of Classes• slots

• inheritance (class hierarchy) Inheritance

class

• Kind of Slots (Attributes):• typed slots

• relational slots

• multivalued slots

Syntax Example:

defslot color_of_car type color.

defslot price_of_car type integer.

defclass car

a_kind_of vehicle;

slots color_of_car price_of_car.


Syntax Example for Cases in CASUELdefcase 1

objectsvacation iccbr95_vacation

transport: iccbr_transport,.... ;

multiple iccbr_transportlist_of_transports: to_fra to_lis

to_ses;

by_train to_fraprice: 60,duration: 1:30:00,kind: ice;

by_plane to_lisprice: 670,airline: lufthansa;

by_taxi to_sesprice: 40,company: lisboa_taxi.


What Casual Is Not

• Casual can be compared with a programming language and not with a program.

• As a language is not a program Casual does not contain a case base.

• But as languages provide services for programming and execution Casual has services for building and using CBR systems.


XML-based OO Case Representation

• XML-based case representation languages developed for the use in e-commerce

• Developed as part of the WEBSELL project• Language family (dtd’s)

– OMML: Orenge Model Markup Language: Vocabulary– OOML: Orenge Object Markup Language: Cases– OVML: Orenge Valuation Markup Language: Similarity– ORML: Orenge Rule Markup Language: Rules– OOOML: Orenge Operator Objet Markup Language:

Customization Operators


OMML Class Hierarchy


OMMLdtd

<!ELEMENT Atomic ( %ClassProperty; , (ValueEnumeration | ValueInterval)? )>

<!ATTLIST Atomic %ClassAttlist; default CDATA #IMPLIED>

<!ENTITY % ClassAttlist " id ID #REQUIRED super IDREF #REQUIRED abstract (true|false) 'false' editable (true|false) 'false' " >

<!ENTITY % ClassProperty … >

<!ELEMENT ValueEnumeration ( V*, %EnumerationProperty; ) >

<!ELEMENT V (%ValueProperty;) >

<!ATTLIST V v CDATA #REQUIRED >

<!ENTITY % ValueProperty … >

<!ENTITY % EnumerationProperty "( Taxonomy | TotalOrder )*">

<!ELEMENT Taxonomy ( TN ) >

<!ATTLIST Taxonomy id CDATA #REQUIRED >

<!ELEMENT TN ( TN* ) >

<!ATTLIST TN v CDATA #REQUIRED >

<!ELEMENT TotalOrder ( OE* ) >

<!ATTLIST TotalOrder id CDATA #REQUIRED>

<!ELEMENT OE EMPTY >

<!ATTLIST OE v CDATA #REQUIRED >

<!ELEMENT ValueInterval EMPTY >

<!ATTLIST ValueInterval min CDATA #IMPLIED max CDATA #IMPLIED>

<!ELEMENT Aggregate ( %ClassProperty; , Attribute* ) >

<!ATTLIST Aggregate %ClassAttlist; >

<!ELEMENT Attribute (%AttributeProperty;)><!ATTLIST Attribute name NMTOKEN #REQUIRED type IDREF #REQUIRED>

<!ENTITY % AttributeProperty …>

<!ELEMENT Reference ( %ClassProperty; )>

<!ATTLIST Reference %ClassAttlist; referenceType IDREF #IMPLIED >

<!ELEMENT Set ( %ClassProperty; )>

<!ATTLIST Set %ClassAttlist; minSize CDATA #IMPLIED maxSize CDATA #IMPLIED elementType IDREF #REQUIRED >

<!ELEMENT Interval ( %ClassProperty; )><!ATTLIST Interval %ClassAttlist; elementType IDREF #REQUIRED >

<!ELEMENT Compound ( %ClassProperty; , ClassReference* ) >

<!ATTLIST Compound abstract CDATA #FIXED 'true' %ClassAttlist; default IDREF #IMPLIED >

<!ELEMENT ClassReference EMPTY ><!ATTLIST ClassReference id IDREF #REQUIRED >

<!ELEMENT Void ( %ClassProperty; ) ><!ATTLIST Void %ClassAttlist; >


OMML Classes

<!ELEMENT ObjectPool (InstanceList*) >

<!ELEMENT InstanceList (%Object;)* >

<!ATTLIST InstanceList class CDATA #REQUIRED>

<!ENTITY % Object"(%Aggregate;|%Set;|%Interval;|%Atomic;| %Reference;|%Void;)">

<!ENTITY % ObjectAttlist " class CDATA #IMPLIED id CDATA #IMPLIED ">

<!ENTITY % Void"Void">

<!ENTITY % ObjectProperty… >

<!ELEMENT %Void; (%ObjectProperty;)* >

<!ATTLIST %Void; %ObjectAttlist;>

<!ENTITY % Reference"Ref">

<!ELEMENT %Reference; (%ObjectProperty;)*>

<!ATTLIST %Reference; %ObjectAttlist; v CDATA #REQUIRED>

<!ENTITY % Atomic "Ato">

<!ELEMENT %Atomic; (%ObjectProperty;)*>

<!ATTLIST %Atomic; %ObjectAttlist; v CDATA #REQUIRED>

<!ENTITY % Aggregate"Agg">

<!ELEMENT %Aggregate; ( (%ObjectProperty;)* , (%Attribute;)* )>

<!ATTLIST %Aggregate; %ObjectAttlist;>

<!ENTITY % Attribute "%ObjectAttribute; | %ValueAttribute; | %ReferenceAttribute;" >

<!ENTITY % AttributeAttlist " n CDATA #REQUIRED class CDATA #IMPLIED ">

<!ENTITY % ObjectAttribute"A">

<!ELEMENT %ObjectAttribute; (%Object;)?>

<!ATTLIST %ObjectAttribute; %AttributeAttlist;>

<!ENTITY % ValueAttribute"AV">

<!ELEMENT %ValueAttribute; (%ObjectProperty;)*>

<!ATTLIST %ValueAttribute; %AttributeAttlist; v CDATA #IMPLIED>

<!ENTITY % ReferenceAttribute"AR">

<!ELEMENT %ReferenceAttribute; (%ObjectProperty;)*>

<!ATTLIST %ReferenceAttribute; %AttributeAttlist; v CDATA #REQUIRED>

<!ENTITY % Set"Set">

<!ELEMENT %Set; ((%ObjectProperty;)*, (%Object;)*) >

<!ATTLIST %Set; %ObjectAttlist;>

<!ENTITY % Interval"Int">

<!ELEMENT %Interval; ((%ObjectProperty;)*, (%Object;), (%Object;)) >

<!ATTLIST %Interval; %ObjectAttlist;>


Properties of Object Oriented Representations

• Advantages:• Structured and “natural” object representation

• Structural and relational information can be represented

• More compact storage as with attribute-value representation

possible

• Structural information can be used for solution transformation

• Disadvantages:• Similarity computation and retrieval more complex

• No representation about sequences like action sequences in

planning


Frames

• Frames are a general means to describe complex objects:

facet facet facet.....

frame

facet

slotsThe entries in a slot can be arbitrary

representation items:•functions, formulas, attributes ...

and even frames again.•Between frames a inheritance

hierarchy

can be defined.


Semantic Nets• Semantic nets are intended to represent (binary) relations.

They are labeled (directed) graphs:• Node labels are objects• Edge labels are relations between objects

• Taxonomies are examples of semantic nets

Printer

Computer System

John

Technical System

is-a

owns

part-of

Example:

The label “owns” is just a notation while “is-a” has an inheritance serviceassociated with it.


Trees and Graphs (1)

• Undirected graph: A pair (N,E): – N: Finite number of nodes– E: Set of node pairs (p,q), called edges.

• Directed graph: A pair (N,E): N: Finite number of nodesE: Ordered set of node pairs (p,q), called edges.


Trees and Graphs (2)

• Tree : Acyclic directed graph with a special node, the root

• Attributed relational graph: directed graph with labelled nodes and edges:

1 2

5 6 12

a

a

ba

b

aa


Graph Representation versus Object Representation

Translations:

• Net of objects attributed graph:

– Relational attributes edge label

– Typed attribute-value pairs node labels.

• Taxonomic relations and inheritance cannot be represented


Levels of Details• There are several ways to choose language levels

which consider more or less details:• Omitting details:

– Omit attributes, predicates, constraints etc. from the description

• Generalize:– Use concepts instead of instances (replace constants by

variables)– Use different levels in the is-a-hierarchy

• More or less complex descriptions:– Choose e level in the part-of-hierarchy

• This will play a role in the chapters on product representation, customer modeling and dialogues.


Summary

• The formal representation methods were revisited for their use in E-C and CBR.

• Main topics are products, functionalities and cases.• Graph representation have been introduced and

compared with object representations. • Casuel is an example as a commercially used language

for CBR.

Documents

Chapter 5 Representation Issues for E-Commerce Similarity-Based Reasoning and CBR Stand 20.12.00