Chapter 5

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

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

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

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.

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

6. 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 principlefor similarities.

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

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

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

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

11. 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 yi are the solution variables • The solution process consists in finding the right instances for the solution variables.

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

13. Representation Languages • In the context of CBR and E-C we deal mainly with three types of representation languages: • 1) Logic oriented languages • 2) Mathematical formulas • 3) 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.

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

15. 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 length • Hypertext: HTML-Link • The order in which the pairs are listed may be of importance Attribute Value

16. Example: Diagnosis • 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} Real [0..50] Symbol {I, II, III} String HTML-Link to repairing service

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

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

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

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

21. Relations between Objects (1) • Relations between objects are useful • General relations: • Taxonomic relations: “a-kind-of” relationexpresses 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.

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

23. Means of Transportation Airplane Automobile Railway Car Truck Sports Car Sedan 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. Inheritance Hierarchy

24. Object class Appartment Superclass: House Bedrooms: Integer Kitchen: {yes, no} Example Object class House Name: String Location: String Object class Hotel Superclass: House Single room: room Double room: room

25. 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: Car Luxury object From the taxonomy of technical objects From the taxonomy of tax regulations Special care has to be taken if an object inherits the same attribute from different superclasses. Luxury car

26. Car Fuel System Engine Electrical System Carborator Engine Case Air Channels Float Aggregations:Compositional Relations • Compositional relations are described by relational attributes. • The values of relational attributes are again objects (resp. pointers to objects). CompositionalHierarchy

27. Example Instance Object instance: Beach Hotel (Object class: Hotel) Name: “Zollamt” Location: “Kaiserslautern” Single: Single_Object Double: Double_Object Object class Hotel Name: String location: String Single: Room Double: Room Object instance: Single_Object (Object instance: Room) Number: 6 Price: 115,50 Object class Room Number: Integer Price: Real Object instance: Double_Object (Object class: Room) Number: 8 Price: 155,50

28. Structure of CASUEL Descriptive Model (Data representation) • Typ definitions • Class definitions General knowledge Similarity measures Cases Set of Object instances Functiondefinitions Rules CASUEL: A Case Representation Language(Manago, Bergmann, et al. 1994)

29. Type Nominal Cardinal Boolean Symbol Ordered Symb. Taxonomy String Integer Real Time Date Type Definitions in CASUEL Predefined Types • User Definined Types • Domain Restrictions • Enumerations (unordered, ordered, taxonomic) Syntax Example: deftype color a_kind_of symbol; range (blue red green).

30. class Inheritance Class Definitions in CASUEL • • Definition of Classes • slots • inheritance (class hierarchy) • • 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 cara_kind_of vehicle; slots color_of_car price_of_car.

31. Syntax Example for Cases in CASUEL defcase 1objects vacation iccbr95_vacation transport: iccbr_transport, .... ; multiple iccbr_transport list_of_transports: to_fra to_lis to_ses; by_train to_fra price: 60, duration: 1:30:00, kind: ice; by_plane to_lis price: 670, airline: lufthansa; by_taxi to_ses price: 40, company: lisboa_taxi.

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

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

34. OMML Class Hierarchy

35. <!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; > OMMLdtd

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

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

38. Frames • Frames are a general means to describe complex objects: frame ..... facet facet facet facet • The entries in a slot can be arbitrary • representation items: • functions, formulas, attributes ... • and even frames again. • Between frames a inheritance hierarchy • can be defined. slots

39. 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 Example: Technical System Printer John part-of is-a owns Computer System The label “owns” is just a notation while “is-a” has an inheritance service associated with it.

40. 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 nodes • E: Ordered set of node pairs (p,q), called edges.

41. Trees and Graphs (2) • Tree : Acyclic directed graph with a special node, the root • Attributed relational graph: directed graph with labelled nodes and edges: a 2 1 b a 5 ba 6 12 aa

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

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

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