Adaptive Hypermedia 2ID20

1. Adaptive Hypermedia2ID20 Prof. dr. Paul De Bra

2. 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. AHAM:Adaptive Hypermedia Application Model

4. 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. 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) • < uid, aid, dir, pres > • 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. 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. 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. 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. 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. 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. AHAM: Adaptation Model (cont.) • Example Adaptation Rule: Event: access(C) Condition: true Action: C.visited := true Propagate: true Phase: UU-pre

12. 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. 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. 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. 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. 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. 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. 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. Static Analysis of ECA Rules • General execution model: • compute the set of triggered rules • repeat until there are no more active rules • select a triggered rule r • if r’s condition is true • then execute r’s action (this may trigger more rules)

20. 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. 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 • Si Sj denotes one step, Si  Sj represents many steps • Lemma (Path Confluence): Suppose that for any three states S, Si and Sj in an arbitrary execution graph such that S   Si and S   Sj there exists a fourth state S’ such that Si  S’ and Sj  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. Static Analysis of ECA Rules (cont.) • Confluence analysis: • Lemma (Edge Confluence): Suppose that for any three states S, Si and Sj in an arbitrary execution graph such that S  Si and S  Sj there exists a fourth state S’ such that Si  S’ and Sj  S’, then for any three states S, Si and Sj such that S   Si and S   Sj there exists a fourth state S’ such that Si  S’ and Sj  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. Static Analysis of ECA Rules (cont.) • Confluence Requirement: • Let R be a set of rules, ri, rj R, let T(ri) be the set of rules triggered by ri, let P be the “priority relation”. We construct:Let Ri := {ri} and Rj := {rj} initially;Repeat until R1 and R2 no longer change Ri := Ri {r  R | r  T(r1) for some r1  Ri and r > r2 P for some r2  Rj and r  rj } Rj := Rj {r  R | r  T(r2) for some r2  Rj and r > r1 P for some r1  Ri and r  ri }The confluence requirement says that for every pair of rules ri, rj R and for any r1 Ri and r2 Rj r1 and r2 must commute • Theorem: If R satisfies the confluence requirement and there are no infinite execution graphs for R then R is confluent

24. 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. Condition-Action Rules (cont.) • General execution model: • compute the initial set of active rules and place them in a collection (set, queue, stack…) • repeat until there are no more rules in the collection • select a rule r • if r’s condition is true • 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. Static Analysis of CA Rules • The activation graph contains a node for each CA rule (instance) r. It contains an edge ri rj iff the action of ri updates a concept/attribute used in the condition of rj • 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. Static Analysis of CA Rules (cont.) • Lemma: two distinct rules ri and rj commute if: • ri cannot activate rj • ri cannot deactivate rj • conditions 1 and 2 with i and j reversed • ri’s action and rj’s action commute • Theorem: a rule set R is confluent if all pairs of rules in R commute

28. 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. AHAM Rule Language (cont.) • Example 1: decide when to show a fragment C: select P.accessA: 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. AHAM Rule Language (cont.) • Example 2: knowledge update C: select P.access where P.ready = trueA: 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. 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. 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.