1. 1212 / Department of Computer Science Adaptive Hypermedia 2ID20 Prof. dr. Paul De Bra

2. 1212 / Department of Computer Science Reference Architecture Purpose: –formal framework for describing system behavior –modular description of AHS: separation of concerns –basis for comparison of Web-based AHS –basis for translation of applications between AHS Our basis: the Dexter reference model for hypermedia –concentrates on the hypermedia structures and server-side functionality (implementation independent) –provides an “abstract” hypermedia layer –describes interfaces with user-interface and with implementation-dependent storage and retrieval functionality

3. 1212 / Department of Computer Science AHAM: Adaptive Hypermedia Application Model

4. 1212 / Department of Computer Science AHAM: Domain Model (DM) Concept (component): –has a unique object identity (uid) –has concept information (cinfo): a set of attribute-value pairs a sequence of anchors a presentation specification –atomic and composite concepts atomic concepts represent fragments, cannot be adapted page and abstract composite concepts, consist of either only atomic concepts (page) or only composite concepts (abstract) “consists” is implemented through an attribute “children”

5. 1212 / Department of Computer Science AHAM: Domain Model (cont.) Concept relationship: –has a unique identity (uid) –is a generalization of the “hyperlink” –has a sequence of specifiers (like relationship endpoints) aid = anchor id (see later), indicates where in the concept uid the relationship is “anchored” dir = FROM, TO, BIDIRECT or NONE –has cinfo just like concepts set of attribute-value pairs, must contain “type” a presentation specification

6. 1212 / Department of Computer Science AHAM: Domain Model (cont.) Anchors: –have a unique identity (aid) –have an anchor value describes how to “locate” the anchor within the concept anchor values of atomic concepts belong to the within- component layer anchor values of composite concepts can be uid-aid pairs, indicating the uid of a sub-concept and the aid of an anchor within that sub-concept

7. 1212 / Department of Computer Science AHAM: Accessing a Concept Resolver function: –translates a “description” of a concept to the uid of a concept –can be used to find a page when accessing an abstract concept (by traversing down the concept hierarchy); this enables us to implement hyperlinks to abstract concepts, not just to pages –when traversing the hierarchy to find a page the resolver has to “choose” which page to select, hence the name page selector Accessor function: –retrieves the “content” of a concept, given its uid. –for a fragment this accessed the within-component layer –for a page or abstract concept this recursively finds descendents, down to the fragment level, and it must construct a page out of the fragments, hence the name page constructor

8. 1212 / Department of Computer Science AHAM: User Model (UM) represents all aspects of a user –uses concepts with a unique id –concept structure with attribute-value pairs –contains an overlay model to represent how user relates to domain model concepts –every concept may have different attributes –commonly used attributes: knowledge, interest, visited, recommended

9. 1212 / Department of Computer Science AHAM: Adaptation Model (AM) Adaptation rules: –event-condition-action (ECA) rules, or –condition-action (CA) rules –event = user accesses a concept (follows a link) –action = an update to the user model, or setting of a presentation specification –condition = expression to decide whether the action should be performed –“propagation”: flag to enable the action to trigger the execution of other adaptation rules –“phase”: rules are grouped into execution phases

10. 1212 / Department of Computer Science AHAM: Adaptation Model (cont.) Simple phase model: –IU: initialization of (volatile) user model attributes –UU-pre: rules that update the user model before generating the presentation –GA: rules that set presentation specifications –UU-post: rules that update the user model after generating the presentation –Some systems or application will need more phases

11. 1212 / Department of Computer Science AHAM: Adaptation Model (cont.) Example Adaptation Rule: Event: access(C) Condition: true Action: C.visited := true Propagate: true Phase: UU-pre

12. 1212 / Department of Computer Science AHAM: Adaptation Model (cont.) Example Adaptation Rule: Event: visited(C) Condition: C.recommended = true Action: C.knowledge := “well learned” Propagate: true Phase: UU-pre

13. 1212 / Department of Computer Science AHAM: Adaptation Model (cont.) Generic adaptation rules: –use variables for concepts and concept relationships (of a specified type) –apply to all the concepts and concept relationships of the right type –make authoring easy because few rules have to be specified Specific adaptation rules: –use concrete concepts –are sometimes used to create exceptions to generic adaptation rules –involve “authoring at the atomic level”, thus very laborious

14. 1212 / Department of Computer Science AHAM: Adaptation Engine (AE) The Adaptation Model does not completely define the system behavior: –many rules may be triggered by an event the execution order may determine the outcome –an action may trigger several rules their execution order may also determine the outcome –rules may trigger each other indefinitely the execution may not terminate –an execution model or abstract adaptation engine is needed to determine the actual system behavior we study several execution models and the problems of termination and confluence

15. 1212 / Department of Computer Science Detecting a Termination Problem Dynamic analysis: –one may keep track of UM instances and pending rules to decide whether a situation reoccurs (difficult) –one may limit the number of times a rule (instance) is executed –one may limit the number of times an attribute of a concept is updated –one may limit the total number of rule executions –when a loop is detected, rule execution is terminated –problem: UM is not left in a “desired” state –problem: the end-user is confronted with a problem not caused by him/her

16. 1212 / Department of Computer Science Detecting a Termination Problem Static analysis –analysis of the defined adaptation rules (together with the defined DM and AM), rather than the running adaptation engine –goal: detect whether infinite loops are impossible under any possible circumstance. –problem: how to decide which are the many possible circumstances (many possible UM instances) –approximation: consider the whole UM space, not just the UM instances that are really possible –problem: the UM space is too large to actually try every instance –solution: analyze and prove properties of the system without actually running the adaptation engine

17. 1212 / Department of Computer Science Definitions We consider instantiated rules, i.e. specific rules or generic rules with variables replaced by concrete concepts and attributes A rule execution is valid on a UM instance if the rule’s condition is true in that instance When a rule is triggered and the execution of the rule is valid on a UM instance the rule is said to be active (for that UM instance) A rule execution sequence for a given UM instance is a sequence of rule executions A rule execution sequence is valid if each rule execution in the sequence is valid and each rule is active when executed A rule execution sequence is complete if when it ends there are no more active rules

18. 1212 / Department of Computer Science Definitions (cont.) A set of rules terminates if for every initial UM instance and initial event every valid rule sequence is complete A rule execution state S is a pair (UM, R) where UM is a user model instance and R is a set of active rules A set of rules is confluent if for every initial UM instance and initial event every valid and complete rule sequence results in the same final execution state This is a strong notion of termination and confluence: it does not depend on how the adaptive engine “queues” pending triggered rules

19. 1212 / Department of Computer Science Static Analysis of ECA Rules General execution model: 1.compute the set of triggered rules 2.repeat until there are no more active rules 3.select a triggered rule r 4.if r’s condition is true 5.then execute r’s action (this may trigger more rules)

20. 1212 / Department of Computer Science Static Analysis of ECA Rules (cont.) Triggering Graph (for a rule set): –each rule instantiation is a node –there is an edge from each concept/attribute updated by an instantiated rule to the rules with that concept/attribute in its triggering event Theorem: if there are no cycles in the triggering graph then the rule set is guaranteed to terminate Note: cycles in the triggering graph do not imply that the rule set can cause an infinite loop: the theorem is very conservative because it does not consider the event

21. 1212 / Department of Computer Science Static Analysis of ECA Rules (cont.) Confluence analysis: –Execution graph (EG): “union” of all possible valid rule execution sequences from a given initial execution state –S i  S j denotes one step, S i   S j represents many steps –Lemma (Path Confluence): Suppose that for any three states S, S i and S j in an arbitrary execution graph such that S   S i and S   S j there exists a fourth state S’ such that S i   S’ and S j   S’ then that EG has only one final state –unfortunately this lemma is difficult to check because there are very many possibilities to check

22. 1212 / Department of Computer Science Static Analysis of ECA Rules (cont.) Confluence analysis: –Lemma (Edge Confluence): Suppose that for any three states S, S i and S j in an arbitrary execution graph such that S  S i and S  S j there exists a fourth state S’ such that S i   S’ and S j   S’, then for any three states S, S i and S j such that S   S i and S   S j there exists a fourth state S’ such that S i   S’ and S j   S’, hence that EG has only one final state –this lemma can be verified more efficiently –unfortunately this lemma is still difficult to check because there are still very many possibilities to check

23. 1212 / Department of Computer Science Static Analysis of ECA Rules (cont.) Confluence Requirement: –Let R be a set of rules, r i, r j  R, let T(r i ) be the set of rules triggered by r i, let P be the “priority relation”. We construct: Let R i := {r i } and R j := {r j } initially; Repeat until R 1 and R 2 no longer change R i := R i  {r  R | r  T(r 1 ) for some r 1  R i and r > r 2  P for some r 2  R j and r  r j } R j := R j  {r  R | r  T(r 2 ) for some r 2  R j and r > r 1  P for some r 1  R i and r  r i } The confluence requirement says that for every pair of rules r i, r j  R and for any r 1  R i and r 2  R j r 1 and r 2 must commute –Theorem: If R satisfies the confluence requirement and there are no infinite execution graphs for R then R is confluent

24. 1212 / Department of Computer Science Condition-Action Rules In many adaptation rules the event is “tied to” the condition –pseudo CA rules, do not actually need the event In Condition-Action rules a change to the condition “is” the triggering event –a CA rule becomes active when its condition becomes true. (rule is activated) –a CA rule becomes inactive when its condition becomes false. (rule is deactivated) –when a CA rule (action) is executed all the conditions are checked. Rules whose condition becomes true (and was false) are queued for execution –when a CA rule is executed the rule only activates itself if its condition remain true and some attribute value in that condition has changed

25. 1212 / Department of Computer Science Condition-Action Rules (cont.) General execution model: 1.compute the initial set of active rules and place them in a collection (set, queue, stack…) 2.repeat until there are no more rules in the collection 3.select a rule r 4.if r’s condition is true 5.then execute r’s action and add newly activated rules to the collection Note: an activated rule may become inactive before it is executed

26. 1212 / Department of Computer Science Static Analysis of CA Rules The activation graph contains a node for each CA rule (instance) r. It contains an edge r i  r j iff the action of r i updates a concept/attribute used in the condition of r j –The activation graph only represents changes to the condition. It may not be an activation and it may even be a deactivation Theorem: If there are no cycles in the activation graph then the rule execution is guaranteed to terminate –This is a conservative way to guarantee termination –Improvement: look at what the action does, and at the condition –More improvement: look at rule sequences from initial state

27. 1212 / Department of Computer Science Static Analysis of CA Rules (cont.) Lemma: two distinct rules r i and r j commute if: 1.r i cannot activate r j 2.r i cannot deactivate r j 3.conditions 1 and 2 with i and j reversed 4.r i ’s action and r j ’s action commute Theorem: a rule set R is confluent if all pairs of rules in R commute

28. 1212 / Department of Computer Science AHAM Rule Language We use AHAM to describe adaptive hypermedia systems: –AHAM ECA or CA rule language (we write the rules using a condition and action but the condition contains an event and the action can be quite complex with a condition of its own) –SQL-like syntax –used for generic or specific rules –it is a description language, not an implementation language –independent of the actual execution model We introduce the language through examples

29. 1212 / Department of Computer Science AHAM Rule Language (cont.) Example 1: decide when to show a fragment C: select P.access A: update F.pres := “show” where Fragment(P, F) and F.relevant = true the “where” clause is shorthand for: CR.cinfo.type = “Fragment” and CR.ss[1].uid = P and CR.ss[2].uid = F and CR.cinfo.dir[1] = “FROM” and CR.cinfo.dir[2] = “TO” and CR.ss.length = 2 and CR.ss[2].relevant = true through P.access we monitor whether page P is accessed (it becomes true on access)

30. 1212 / Department of Computer Science AHAM Rule Language (cont.) Example 2: knowledge update C: select P.access where P.ready = true A: update P.knowledge := “well known” –We see here that there is a condition, separate from the event: we only set the knowledge value to “well known” if the page is considered “ready”.

31. 1212 / Department of Computer Science AHAM Rule Language (cont.) Example 3: handling prerequisites C: select C1.knowledge where C1.knowledge  “known” A: update C2.ready := true where Prerequisite(C1, C2) and not exists ( select C3 where Prerequisite(C3, C2) and C3.knowledge < “known” ) –This rule expresses that a concept becomes “ready” when all its prerequisites are satisfied. This rule has an instance for each prerequisite of a concept

32. 1212 / Department of Computer Science Execution of AHAM CA rules The rule language does not specify the system behavior: –an execution semantics is still needed –most systems use a queue for pending rule executions –in most systems not all actions trigger or activate rules –we must introduce execution phases in order to describe some systems’ behavior In another part of this course will see how to describe actual system behavior using AHAM CA rules.