Adaptive Hypermedia 2ID20

Department of Computer Science

Adaptive Hypermedia2ID20

Prof. dr. Paul De Bra


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


AHAM:Adaptive Hypermedia Application Model

Run-time Layer

Presentation Specifications

Adaptation model

Anchoring

Within-Component Layer

DomainModel

UserModel

Storage Layer


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”


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


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


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


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


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


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


AHAM: Adaptation Model (cont.)• Example Adaptation Rule:

Event: access(C)Condition: trueAction: C.visited := truePropagate: truePhase: UU-pre


AHAM: Adaptation Model (cont.)• Example Adaptation Rule:

Event: visited(C)Condition: C.recommended = trueAction: C.knowledge := “well learned”Propagate: truePhase: UU-pre


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


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


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


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


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


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


Static Analysis of ECA Rules• General execution model:

1. compute the set of triggered rules2. repeat until there are no more active rules

3. select a triggered rule r4. if r’s condition is true5. then execute r’s action

(this may trigger more rules)


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


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


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


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 andr > r2 P for some r2 Rj and r rj } Rj := Rj {r R | r T(r2) for some r2 Rj andr > 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


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


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 collection3.select a rule r4.if r’s condition is true5.then execute r’s action

and add newly activated rules to the collection• Note: an activated rule may become inactive

before it is executed


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


Static Analysis of CA Rules (cont.)• Lemma: two distinct rules ri and rj

commute if:1. ri cannot activate rj

2. ri cannot deactivate rj

3. conditions 1 and 2 with i and j reversed4. ri’s action and rj’s action commute

• Theorem: a rule set R is confluent if all pairs of rules in R commute


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


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)


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


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 C3where Prerequisite(C3, C2) andC3.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


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.

Documents

Adaptive Hypermedia 2ID20