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
AHAMAdaptive 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)
• lt uid, aid, dir, pres gt
• 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
  rules 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 rs condition is true
• then execute rs 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 constructLet Ri ri
  and Rj rj initiallyRepeat until R1 and R2
  no longer change Ri Ri ? r ? R r ? T(r1)
  for some r1 ? Ri and r gt r2 ? P for some r2 ?
  Rj and r ? rj Rj Rj ? r ? R r ? T(r2)
  for some r2 ? Rj and r gt 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 rs condition is true
• then execute rs 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
• ris action and rjs 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.ss1.uid
  P and CR.ss2.uid F and CR.cinfo.dir1
  FROM and CR.cinfo.dir2 TO and
  CR.ss.length 2 and CR.ss2.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 ?
  knownA update C2.ready true where
  Prerequisite(C1, C2) and not exists ( select
  C3 where Prerequisite(C3, C2)
  and C3.knowledge lt 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.