Matchmaker Framework Architecture

From wiki.gpii
Jump to: navigation, search

This pages constitutes work in progress towards defining the Matchmaker Framework.

TODOs:

  • How to include the Transformer?
  • How to include the Flat Matchmaker?
  • Do we need a separate component to pre-evaluate conditions?


Overview

The Matchmaker Framework comprises components interacting with each other to address various matchmaking aspects. Core components are Matchmakers aiming to match user needs and preferences with the technical capabilities of devices, platforms and software solutions including assitive technologies. Based on their provided matchmaking functionalities and strengths, Matchmakers can be both individually requested or combined (hybrid matchmaking) executed. The Matchmaker Manager is responsible to orchestra the matchmaking execution in terms of selecting a proper matchmaking strategy automatically (or pre-defined, e.g. configuration-based). Additionally, the Matchmaker Manager deals with aspects towards reducing communication and computation costs (see Cache) and user oriented aspects in terms of adaptation consistency (see History). Dynamic runtime adaption of the technical environment based on environmental factors are handled by the Environmental Reporter Filter through evaluating environmental sensor data according to adaptation rules. These adaptation rules are computed in relation to user needs and preferences by a certain component called M3RulesCreator (currently envisioned) or by Matchmakers itself (prospectively).

Components

Flow Manager

The Fow Manager is the core orchestration component of the GPII/Cloud4all personalization architecture. From the matchmaking perspective, the Flow Manager is responsible (1) to trigger a match request to the Matchmaking Framework and, in turn, (2) to apply the determined configuration at the user`s device. Additionally, we envision the Flow Manger to be responsible to cache configuration data and to store the history of applied configurations (changes). Components of the Matchmaking Framework can utilize the Matchmaking Cache and the Matchmaking History as described by components (see Matchmaker Manager and History).

Matchmaker Manager

The Matchmaker Manager has the role of managing match request from the Flow Manager, run on the local device and is responsible to orchestra the matchmaking process by means of:

  • reducing matchmaking communication and computation costs as well as providing balance against network problems by activating the last applied configuration (see Matchmaker Cache).
  • initializing and controlling hybrid matchmaking to combine different matchmaking strategies. In general, hybrid matchmaking is meant to compute better matchmaking results by combining smaller pieces or functionalities of different matchmaking approaches and technologies based on their strengths. Although not exclusive, 3 major approaches towards hybrid matchmaking strategies can be distinguished:
    • Join matchmaker strategies by evaluating which matchmaker to use. A variety of metrics can be applied in this category. Pre-evaluation in terms of the matchmaking input or post-evaluations in terms of the computed output, e.g. scoring matchmaking results.
    • Fork matchmaker strategies based on their provided functionalities and services (e.g. use Matchmaker X for A and Matchmaker Y for B) (see Matchmaker). This can be done configuration-oriented, e.g. defined by experts or users, or automatically, e.g. through a specific service synthesizer knowing the services of all matchmakers and combining the best services to use.
    • Chain matchmaker strategies. In this case, the output of one matchmaker will be the input of the next matchmaker. This approach requires each chained MM to know and fulfil requirements of the next MM.

Cache

The Cache stores computed and applied configuration data locally on the client device so that future match request can be served faster. To address requirements of public devices, stored configuration data are attributed to a user, e.g. checksums of user id and computed configuration.

History

The Matchmaker History is a database to store the history of applied preferences and preferences changes by a user at different points of time or in terms of (some sort of) contexts. This component is motivated to deal with aspects towards consistency, e.g. in terms of the time: “I just messed up my settings. Give me the settings I had yesterday!” or in term of context: “Give me the preferences I had last time on this train”. Additionally, new matchmaking strategies could base their computation on the history data of one user to infer preference for the new contexts, in contrast to use preference data of all users.

Matchmakers

Core components of the Matchmaker Framework are Matchmakers to determine the best match of user needs and preferences and device capabilities. Matchmakers provide different matchmaking functionalities or services, e.g.:

  • inferPreferences to infer preferences for the current context. (Currently supported by the RBMM, STMM, FlatMM,???.)
  • inferSolutions to infer solutions that need to be launched and configured automatically. (Currently supported by the RBMM, ???.)
  • inferFeedback to infer user feedback of applied configurations, e.g. short cuts about solutions that are potentially new to a user. (Currently supported by the RBMM, ???.)
  • inferM3Rules to infer mini rules which are applicable in the ERFilter in terms of context adaptations.

Matchmakers are independent in their technology, implementations and matchmaking functionalities. However, common concepts across all matchmakers applies to the input and output format. Specifically, we have discussed the following common concept for input and output:

  • Matchmaker input consists of:
    • Original preferences of the user preference set
    • Context (device (hardware, software), environment, …)
    • Solutions (installed applications and AT solutions)
  • Matchmaker output consists of:
    • Preferences to be configured automatically; solutions to launched automatically
    • Most relevant preferences (optionally) to be potentially presented in the PCP, e.g. [{term: “.../volume”, confidence: “0.9”}, {term: “.../fontsize”, confidence: “0.34”}]
    • Further feedback information: shortcuts, alternative solutions or preferences
    • Adjusters for bidirectional feedback, e.g. "rating", "dislike", "try different"

Environmental Reporter Filter or MiniMatchmaker

Adaptations based on context changes are handled by the Environmental Reporter Filter (ERFilter) which filters all context changes of the environment reporter. It reacts on some context changes and replies with specific configuration changes. When and how the ERFilter reacts on context changes is defined in M3Rules (Mini Matchmaker Rules). M3rule can be defined by users, e.g. as conditional preference “I want white on black for a specific brightness”, or determined by Matchmakers. In terms of consistent data exchange in the whole Matchmaking Framework, we discussed M3Rules to be expressed a conditional preferences.

Note: The ERFilter (or MiniMatchmaker) is currently being designed and developed intensively. Hence, changes in terms of the format, naming and further aspects are expected.

M3RulesCreator

We envision a component M3RulesCreator to create M3Rules based on the results of Matchmakers (inferred preferences). The initial implementation might have very simple rules. Later versions could allow a Matchmaker to define their individual rules.

Illustration

MatchmakingFrameworkDRAFT.png.

  • A. Flow Manager sends match request consisting of preferences set, context, and solutions. In turn, it orchestras the application of settings determined by matchmakers and the communication with the user interfaces (PCP, PMT).
  • B.1 Matchmaker Manager evaluates cached configurations on the device. In case of a cache hit, it returns the last configuration for the user on the device.
  • B.2 Matchmaker Manager requests Matchmaker(s) to infer (new) preferences for the current context.
  • C. Matchmaker request the History to infer preferences based on the user`s history of applied configurations.
  • D. Matchmaker Manager requests the M3RuleCreator to determine M3Rules for dynamic adaptations based on environmental context changes.
  • E. Flow Manager request the ERFilter to evaluated environmental context changes according to M3Rules.
  • F. Flow Manager (1) caches the current configuration, e.g. when the user logs out and (2) stores the history of automatically applied and manually (user triggered) configuration changes.

Minimal Viable System

  • Matchmaker Manager to support following minimal functions:
    • Hybrid matchmaking:
      • Join strategy - first implementation based on a simple metric about the information content of a preference set, e.g. few preferences = RBMM; many preferences = STMM.
      • Fork strategy - first implementation based configuration files, e.g. RBMM for inferSolutions; STMM for inferPreferences.
  • Matchmakers:
    • RBMM to provide functionalities: inferPreferences, inferSolutions, inferFeedback
    • STMM to provide functionalities: inferPreferences, ???
    •  ???
  • M3RuleCreator:
    • First implementation to provide M3Rules for the ERFilter
  •  ???

Use Cases

Arfst

Blind user with few common preferences, saying a screen reader, and a speech rate of 400 words per minute are required.

  1. Arfst first time at the Library to search for literature:
    • The library PC (Windows 7) is equipped with 2 screen readers (NVDA and SuperNova) and is located in a separate room.
    • It is not the first contact of Arfst with Cloud4all, so he has already a user token and a preference set.
    • The Matchmaker Manager receives a match request.
    • After verifying that no cached configuration can be automatically applied, the Matchmaker Manager selects the RBMM as the preference set consist only of few preferences.
    • The RBMM infers the best configuration for Arfst including solutions, preferences and feedback:
      • The RBMM infers that NVDA should be launched for Arfst.
      • The RBMM additionally infers volume as a new preference for Arfst to be applied on the system as the device reported tells that volume is muted on the library system.
      • The RBMM additionally determine shortcuts for NVDA helping Arfst to interact with NVDA as no information are available if Arfst has used NVDA before.
    • … launch NVDA, apply speech rate and volume, present short cuts in the PCP and inform Arfst about the alternative screen reader SuperNova …
    • Arfst searches for some books and logs out to go for lunch …
    • The Flow Manager caches the last configuration in the cache.
  2. Arfst back to the library computer after lunch.
    • Arfst logs in again to the same library computer.
    • The Matchmaker Manager receives a match request.
    • The Matchmaker Manager returns the last configuration as a cache hit was found.


Wubke

Visual impaired person with just application-specific preferences for Windows Magnifier. She requires magnification of 250 and invert colors.

  1. Wubke in the computer lab (Windows computer) at the university.
    • Windows Magnifier is installed on the computer (Windows 7).
    • Theoretically, there is no need to request a Matchmaker to infer preferences and solutions, as application-specific preferences for Windows Magnifier can be applied directly. The functionality equates with Flat Matchmaking.
    • Note: Perfect matches are not covered yet in the Matchmaking Framework. It might worth considering a further pre-evaluation of perfect matches in the Matchmaker Manager to further reduce communication cots.
  2. Wubke in the computer lab (Linux computer) at the university.
    • Gnome Magnifier is installed on the computer (Fedora 18).
    • A Matchmaker is selected, e.g. the STMM, to infer from application-specific preferences (Windows Magnifier)to application-specific (Gnome Magnifier).
    • Note: Pre-evaluation of preferences types is not covered yet in the Matchmaking Framework. It might be worth to consider it as further pre-evaluation functionality in the Matchmaker Manager.

Eike

In general, Eike prefers increased font size of 18. Between 5:30 pm and 7.30 am, he prefers to increase font size to 24. Preference set of Eike contain common preferences.

  1. Eike is writing on his study thesis at 3:00 pm (Laptop with Linux)
    • Matchmaker Manager selects a Matchmaker to infer preferences and solutions, e.g. text-scaling-factor of GNOME Interface Settings.
    • Matchmaker Manager request the M3RuleCreator to infer M3Rules to dynamically change the font-size when it`s between 5:30 pm and 7.30 am.
    • Note: It might worth to consider a condition evaluator as already mentioned in the Matchmaker Ecology. What would be the functionality of that component and how can it simplify the matchmaking flow?
  2. Eike still writing on his study thesis at 5.30 pm (Laptop with Linux)
    • ERFilter evaluates the time of the day and detects that the text-scaling-factor of GNOME Interface Settings need to be changed now (based on sensor data and available M3Rules).

To be continued (input from everyone is welcome)

Related Pages