ARAS: Adaptive Recommender for Academic Scheduling: Technical Review

1
ARAS Adaptive Recommender for Academic
SchedulingTechnical Review

• Mark Kilfoil, Wenpu Xing

2
Agenda

• Background of ARAS
• Problem Domain Requirements
• Motivation
• High-Level Design
• Request Analysis
• Request Processing
• User Modeling
• Knowledge Search
• Request to Response Transformation
• Detailed Design
• The Ontology Concepts, Attributes, Values and
  Relationships
• The HybridOntology short-term and long-term
  information
• Processing Block Elements (PBEs) expandable,
  dynamically reconfigurable request processing
• Page Templates Template Transformation
• User Modeling
• Navigation Recommendation Generation

• Sample Data
• Input data format
• Data Transfer
• ARAS Phase 1 data
• Conclusions Future Work
• Phase 2
• Phase 3

3
Background

• When planning a path through a university, a
  student has to contend with many different
  possibilities, different courses that they can
  take.
• The student does not have the time to go through
  all courses, even possibly within a single
  faculty.
• Thus, there is a need for a tool which can assist
  a student in browsing through course information.
• ARAS is an adaptive website tool which provides
  this assistance, primarily by providing them with
  navigational suggestions.

4
ARAS General Requirements

• This tool should
• Allow structured information for natural
  navigation
• Structured information means that it can have a
  defined shape to a data item, and that a data
  item can be connected to another data item in
  some defined way. One example is the
  whole/part connection, which allows a natural
  navigation from a page describing the whole to a
  page describing the part, and vice versa.
  Another example is the sibling connection,
  which suggests navigation between two or more
  derived elements of a common element.

5
ARAS General Requirements (2)

• Allow page templates to be created which can
  describe the informational and visual content of
  a final page
• It should be possible to associate general page
  templates with general information objects, but
  allow overrides for specific information objects.
• Page templates should promote reuse of common
  components where possible.
• The language for page templates should either a)
  be based on something already familiar to web
  developers or b) be hidden from web developers
  through the use of a tool.

6
ARAS General Requirements (3)

• Dynamically generate pages based on the context
  of the request and database information. The
  context of a request should be capable of
  including
• The actual request
• The required security context of the requested
  object
• Information about how this request relates to
  other information objects within the database
• The previous requests made during this session
• Information about the user making the request
• The previous requests made by this user
• The security context of the user

7
ARAS General Requirements (4)

• Allow for navigation recommendations to be
  generated for ARAS specifically these
  recommendations should be based on
• Relationships between courses
• Relationships between courses and course topics
• Relationships between topics
• What courses a student has already taken
• What courses a student has browsed (which
  indicates interest)

8
High Level Design

• The basic design comes from typical web server
  design
• Receive request
• Determine real request target
• Retrieve corresponding template
• Perform processing related to that target
• Fill out and transform that template with a
  database into a response.
• Deliver the response.

9
Request Receiving

• The ARAS system acts like a regular web server,
  and connects to a port for regular HTTP requests.
  (By convention, port 8080 has been used.
• The actual processing of a request is separated
  from the receiving of a request, so it will be
  possible to add additional request sources,
  including HTTPS, WAP or from an application
  gateway.

10
Request Analysis

• When a HTTP request is received, it is analyzed
  to determine what the real ARAS target is. There
  are two possibilities
• A simple file request Simple files are
  currently delivered without any intervention
  whatsoever, allowing images, binaries,
  stylesheets, etc to be delivered. In effect,
  this is a basic webserver capability.
• A specific ARAS request ARAS requests are
  encoded with a conceptId URL parameter e.g.
  http//glass.cs.unb.ca/?conceptIdwelcome

11
Request Processing

• Once the ARAS request has been identified, the
  information describing that request is retrieved
  from the database. This information includes
• The template around which the response should be
  created.
• The series of processing steps that are required
  in order to transform the request into a response.

12
Request Processing (2)

• Once the list of processors has been identified,
  the Processing Controller executes them, one by
  one, handing each one both the request being
  processed and the context of processing.
• Processing ends when
• One of the processors indicates that it has a
  completed response
• One of the processors indicates that a fatal
  error has occurred.

13
Template Transformation

• A template is an XML-compliant HTML-encoded file
  extended with additional processing tags. This
  allows the file to be processed mechanically as a
  tree.
• The Template Transformer processes a template
  within the current context by passing each node
  through a series of transformers each
  transformer is asked if it can transform the
  node when one has transformed it, the process
  begins again, recursively, until the entire file
  has been parsed.

14
User Modeling

• based on the users own information
• Users behavior
• Users demographic information
• Explicit information from the user
• based on other users within the same group

15
Knowledge Searching
16
Detailed Design

• The Ontology the base data model.
• The Hybrid Ontology combining short- and
  long-term information.
• Data Modeling each of the major concepts used in
  ARAS is discussed.
• Processing Block Elements all processing is
  handled through an extendable system of PBEs.
• Page Transformation similar to the PBE system,
  each of the new elements is handled by a separate
  transformer using a common interface.

17
The Ontology

• An ontology is a basic knowledge storage paradigm
  in which basic units of information called
  concepts and the relationships between concepts
  are stored.
• All information in ARAS, including user modeling,
  domain modeling, session tracking and request
  processing information is stored (virtually)
  within a single ontology. This allows any sort
  of information to be related to any other sort of
  information for example, domain information in
  ARAS such as courses and course topics can be
  directly associated with a user.

18
Concepts, Attributes and Relationships

• A relationship is an association between two
  concepts (a source and a target). It
  contains
• an identifier
• an optional parent identifier
• an optional strength
• There are several base relationships which exist
  in the system. Derived relationships are
  generally instances of that particular
  relationship.
• Derived relationships are matched when searching
  for base relationships. E.g. a search for the
  base similarity relationship will match derived
  instance relationships.

• The base unit of knowledge is the concept it
  has
• an identifier (name)
• an optional parent concept
• a set of attributes, which are named and typed
  values
• a set of relationships to other concepts.
• A concept derived from another inherits
  attributes from its parent, but can also specify
  its own attribute values (overriding those that
  were inherited).

19
Ontology Interfaces

• All ontologies are derived from the Ontology
  interface class. There are three contained
  sub-interfaces
• query interface used to retrieve concepts and
  relationships from the ontology
• copy storage interface used to create a copy of
  a given object within the ontology has the
  connotation that this is to be consider a local,
  short-term object, with only a copy for reference
  within the ontology.
• original storage interface used to create a new
  object within the ontology has the connotation
  that this is to be considered a long-term object
  under control of the ontology.

20
The Hybrid Ontology

• The collection of information that makes up the
  backbone of the system is long-term and
  global information.
• During processing, a particular collection of
  information is gathered, forming the context of
  the request in which the response is to be
  formed. This information is short-term and
  local.
• In order to provide a consistent access method to
  information within the system, the hybrid
  ontology was created. It is a combination of a
  long-term ontology and a short-term ontology,
  where the short-term filters the long-term. In
  this way, short-term conclusions can overlay
  long-term data, allowing for local context to
  overlay global context.
• This is analogous to a locally-scoped variable in
  a program having precedence over a
  globally-scoped variable.
• This separates the copy and original storage
  interfaces, and the query interface first checks
  the short-term ontology for the concept or
  relationship, and then checks the long-term
  ontology if no result is found.

21
ARAS Data Modeling
22
The Sample Data for ARAS

• The sample data is recorded in XML format.
• ltprofessorgt
• ltidgtPROF_028lt/idgt
• ltfnamegtNatalielt/fnamegt
• ltlnamegtWebberlt/lnamegt
• ltpasswordgtpasswordlt/passwordgt
• ltofficegtHE118lt/officegt
• ltemailgtnwebber_at_unb.calt/emailgt
• ltdegreegtMCSlt/degreegt
• ltdegreegtBCSlt/degreegt
• ltfacultygtFAC_030lt/facultygt
• ltresearchgtSoftware Developmentlt/researchgt
• ltoccupationgtSenior Instructorlt/occupationgt
• lt/professorgt

23
The Data Transferring

• Transferring the sample data to database

24
Processing Control

• The Processing Controller manages the steps
  necessary to process a request into a response.
• It maintains a queue of processing block elements
  (PBEs) which are run in sequence to process the
  request.
• PBEs, in turn, have access to the processing
  controller, and can
• inquire whether or not a particular PBE is
  scheduled to run
• schedule another PBE to be run, either
  immediately after themselves or at some later
  point in the queue.

25
Processing Block Element

• A processing block element (PBE) is a processor
• It takes the request, the current request context
  and the hybrid ontology as input
• As output, it can update the request context
  and/or the hybrid ontology, and/or it can
  generate a response.

26
PBE Framework

• The PBE system is designed to be extendible a
  new PBE can be created by deriving from the
  abstract PBE base class, and then registered
  using static methods of that class.
• PBEs register a name, which is used to determine
  when the PBE should run.
• Each concept can have a PROC_LIST attribute which
  describes the sequence of PBEs, identified by
  name, which are to be run to process that request.

27
CoreFinder PBE

• The CoreFinder PBE is automatically scheduled by
  the system first. It analyzes the request,
  identifies the concept target of the request, and
  arranges for the other PBEs to be enqueued.
• The CoreFinder uses the PROC_LIST attribute to
  determine which PBEs should be used.

28
SessionBrander PBE

• A collection of consecutive requests from the
  same user on the same machine and browser within
  a period of time is considered a session.
• A cookie is used to perform session tracking.
  The session cookie is attached to the first
  response to a request which did not have the
  cookie.
• Sessions are recorded in the ontology as concepts
  derived from the SESSION concept. If the user is
  known, the session instance is attached to it
  with an instance of the containsSession
  relationship. Otherwise, the session is
  anonymous.
• Within each session, each request is recorded
  with a concept derived from the REQUEST concept.

29
AuthUser AuthRequired PBEs

• Users are identified by (correct) user parameters
  (username and password) matching a particular
  user concept within the ontology. It is not
  required that a user log in to ARAS for some
  basic functions (browse courses and topics), but
  in order for the system to learn about their
  interests and know their course history, the user
  must be identified.
• The AuthUser PBE simply checks for user
  authentication parameters and verifies them if
  they are found. The AuthRequired PBE is more
  strict, in that it requires either that a user
  already be attached to the current session (and
  therefore is validated), or that the user
  parameters are present and valid. If no user can
  be attached to the current session, the
  AuthRequired PBE can redirect the user to a login
  concept. Thus, concepts can be specified with
  three levels of user identification none
  required, user identification optional (AuthUser)
  or user identification required (AuthRequired).

30
Adding A User to the Request Context

• If the current session has been associated with a
  user, that user concept is attached to the
  context of the request. Alternatively, either
  the AuthUser or AuthRequired PBEs can validate
  the user parameters and attach the corresponding
  user.
• Attaching the user to the current context is
  accomplished by adding a short-term concept named
  TARGET_USER which is derived from the actual
  long-term user object. Thus, other PBEs can
  refer to a well-known short-term concept in order
  to find the user, and since it is derived from
  the actual user it inherits all of the users
  attributes.

31
Redirect PBE

• The Redirect PBE changes the target concept of
  the current request to another concept, and
  rebuilds the processing queue with PBEs
  appropriate to the new target concept.
• It is typically used to either redirect a request
  to a login concept on failed or missing
  authentication, or to redirect a successful login
  attempt to the original page which required
  authentication.
• It is not limited to these uses, however. It has
  also been used to redirect to an error page, or
  to redirect to the front page upon successfully
  logging out of the system.

32
ScrubAuth PBE

• Where the SessionBrander PBE can add cookies to a
  response in order to make it identifiable, the
  ScrubAuth PBE is responsible for destroying those
  cookies and removing the identification of that
  session.
• This is largely needed in order to allow logging
  out of the system, but could also be arranged by
  SessionBrander if a session has expired.

33
Error PBE

• The Error PBE is used to generate an error page.
  It is typically scheduled by the processing
  controller when a PBE has reported a fatal error
  in processing.
• PBEs can report errors (including non-fatal ones)
  by adding error number and error message
  information to the attributes of a SYSTEM_ERROR
  concept in the temporary ontology. The Error PBE
  simply collects these errors together into a
  formatted page and returns them.

34
UpdateUser PBE

• PBEs can affect more than just the context of a
  request or the response generated. They have
  full access to the ontology, and can be made to
  issue updates to the data as necessary.
• The UpdateUser PBE decodes user information
  parameters created by an input form and updates
  the current users information in the ontology.
  It is an example of a PBE created specifically to
  satisfy a domain-related issue, that is, to
  address user modeling.

35
UpdateUserCourses RemoveUserCourses

• Associated with each user within ARAS is a set of
  courses that they have indicated that they have
  already taken. These PBEs are specifically
  designed to respond to web forms and add and
  remove course sections from the current users
  profile.
• If there is no current user, these PBEs generate
  an error.

36
TemplateResolver PBE

• The TemplateResolver takes a template associated
  with the current request context and transforms
  it into a response.
• This is the last PBE scheduled to run for most
  target concepts, as it creates a response.
• This PBE makes use of a set of Transformer
  objects, which are responsible for a particular
  node type.

37
Template Language

• Extended version of HTML with custom tags
• IF conditional blocks. A conditional,
  boolean-valued expression is passed in the
  condition parameter. If the expression evaluates
  to TRUE, the IF tag is replaced with the contents
  of an enclosed TRUE tag otherwise, the IF tag is
  replaced with the contents of an enclosed FALSE
  tag.
• VARIABLE variable substitution, both simple,
  expression-based and database query. An
  expression is passed in the name parameter and
  evaluated if it is a multi-valued expression,
  only the first value is used.
• LIST loop-based evaluation. An expression is
  passed with the name parameter. For each value
  of the expression, the contents of the loop are
  expanded, with a variable named listitem
  replaced with the value. An alternative variable
  name can be specified with a listitem parameter.
  Additional optional variables include listcount
  and listmax, which give the current count through
  the loop and the maximum number of loops to be
  executed, respectively these variable names can
  be overridden in a similar way to the listitem
  variable.
• INCLUDE inclusion of files, templates or
  fragments (which allows reusable modules). The
  name of a template can be specified with a
  template parameter, or a filename given with a
  file parameter.
• Powerful provides access to ontology-based
  expressions.
• Extensible new tags and new internal-access
  functions can be added via modular design. Each
  tag is processed by an object derived from the
  Transformer class, and can be added to the list
  of processors with little effort.

Project Blue ARAS (Template Language)
38
Template Expressions

• Sophisticated, ontology-based expressions can be
  created within ARAS.
• Concept attributes can be referred to directly by
  name. E.g. TARGET_USER.name
• Multi-valued attributes can be accessed easily.
  E.g. CS1043.profname2
• LIST environments create variables which can be
  substituted both within and without expressions.
  For example, errors in processing can be
  displayed with the followingltULgt ltLIST
  nameSYSTEM_ERROR.ERROR_MSG listitemerrorgt
  ltLIgterrorltLIgt lt/LISTgtlt/ULgt
• Through the use of special, internal concepts
  such as System, methods can be added to cover
  things not easily expressed with normal
  expressions, such as date manipulation, ontology
  searches, etc. Parameters are passed with named
  values, and can be optional. E.g.
  System._at_getParent( conceptTARGET_CONCEPT
  )System._at_getDate()System._at_getDate(
  formatyyyy )System._at_getSortedRecommendations()
  System._at_exists( conceptTARGET_USER
  )System._at_getTargets( conceptsession,
  relcontainsRequest )

39
Template Example
Typical start of themed page
ltINCLUDE template"fragmentheader"/gt ltINCLUDE
template"fragmentbanner"/gt ... ltIF
condition"System._at_exists( 'conceptTARGET_USER'
)"gt ltTRUEgt ltLIST name"System._at_getParent(
'conceptTARGET_USER' )" listitem"user"gt ltA
CLASS"rlink" HREF"?conceptIduser"gtMy
Profilelt/Agt lt/LISTgt ltA CLASS"rlink"
HREF"?conceptIdLOGOUT"gtLogout ltVARIABLE
name"TARGET_USER.name"/gtlt/Agt lt/TRUEgt ltFALSEgt
ltA CLASS"rlink" HREF"?conceptIdLOGIN"gtLoginlt/Agt
lt/FALSEgt lt/IFgt ltULgt ltLIST name"System._at_getPa
rent( 'conceptTARGET_USER' )" listitem"user"gt
ltLIST name"System._at_getTargets( 'conceptuser',
'relhasTaken' )" listitem"section"gt ltLIST
name"System._at_getSources( 'conceptsection',
'relcContainsS' )" listitem"course"gt ltLIgt
ltA HREF"?conceptIdcourse"gtltVARIABLE
name"course"/gtlt/Agt ltA HREF"?conceptIdse
ction"gtltVARIABLE name"section"/gtlt/Agt
ltFORM ID"secremsection" ACTION"/?conceptIdrem
oveSection" METHOD"GET"gt ltINPUT
TYPE"hidden" NAME"sectionName"
VALUE"section"/gt ltINPUT TYPE"hidden"
NAME"conceptId" VALUE"removeSection"/gt
ltINPUT TYPE"submit" NAME"submitsection"
VALUE"Remove This Section" /gt lt/FORMgt
lt/LIgt lt/LISTgt lt/LISTgt lt/LISTgt lt/ULgt
From fragmentheader
All courses and sections for the current user
Project Blue ARAS (Template Example)
40
Example Realised
Project Blue ARAS (Example Realized)
41
Navigation Recommendation Generation

• There are a number of PBEs responsible for
  generating navigation recommendations within the
  ARAS system. Each of them is responsible for a
  particular stage of the recommendation finding,
  with each stage dependant on the output of the
  previous (but not the way that output was
  generated. At each stage, the output is placed
  in the (temporary ontology).
• Generally, the recommendation system follows four
  steps
• Assemble the browsing history and the list of
  courses already taken by this student.
• From the set of starting courses, determine the
  set of topics which are representative.
• From the set of topics, find other courses and
  other topics related strongly to them.
• Select the top few recommendations and translate
  those into concept links.

42
Recommendation Generation PBEs

• CleanUserInterestHistoryPBE
• Cleans up the users interests from the user
  profile before re-mining interests for the user.
• LearnCurrentSessionPBE
• Finds the courses viewed in the current session
  and passes the courses to LeanFromCoursesPBE for
  mining the users interests.
• LearnSessionHistoryPBE
• Finds the courses viewed in the users session
  history and passes the courses to
  LeanFromCoursesPBE for mining the users
  interests.
• LearnUserCourseHistoryPBE
• Finds the courses taken by the user and passes
  the courses to LeanFromCoursesPBE for mining the
  users interests.

43
Processing Block Elements (PBEs)

• LearnFromCoursesPBE
• Mines the users interests from the given course
  list.
• Find the weights for the related topics
• Normalize the weights by
• making the total to 1

44
Future Work

• Phase 2 housecleaning locks
• Cleanly separate PBE integration, so that new
  PBEs can be added easily, preferably without
  recompilation.
• Add new data management tools, both
  domain-independent and domain-specific.
• Separate the front-end further from processing,
  making it configurable add HTTPS and
  inter-server front ends.
• Explore additional recommendation generation
  mechanisms.
• Design an extension to the user model which would
  describe user privileges/capabilities/roles.
• Design an extension to the request context to
  include generic online data update.
• Explore ways to make the hybrid ontology less
  integrated, including a remote API, proxies over
  data stores, etc.

45
Future Work (2)

• Phase 3 Divide and conquer
• Component-ize and compartmentalize the user model
  as an externally-controlled yet integrated
  ontology.
• Externalize the definition of the domain
  information into a configurable, manipulable
  component.
• Consider image and stylesheet transformations.
  (I.e. those things which are currently delivered
  as non-concept things would become concept
  things.)

46
Questions?