slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
The MatchMaker Ecology PowerPoint Presentation
Download Presentation
The MatchMaker Ecology

Loading in 2 Seconds...

play fullscreen
1 / 19

The MatchMaker Ecology - PowerPoint PPT Presentation

  • Uploaded on

The MatchMaker Ecology. Antranig Basman, Core Framework Architect, GPII. Recap: Bridging between views. MatchMakers. Users view the world in terms of their needs Solution developers view the world in terms of what they can provide

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'The MatchMaker Ecology' - tevin

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

The MatchMaker Ecology

Antranig Basman,

Core Framework Architect, GPII

recap bridging between views
Recap:Bridging between views


  • Users view the world in terms of their needs
  • Solution developers view the world in terms of what they can provide
  • We need a system for smoothly transferring information back and forth between these worlds

The running system

structuring the matchmaker ecology
Structuring the MatchMaker Ecology
  • So far, we have constructed two baseline MatchMakers:
    • The “flat” MatchMaker – simplest viable implementation
    • The “canopy” MatchMaker – a more sophisticated implementation that optimises the entire solution set and avoids redundancy
beneficial effects
Beneficial effects
  • Having 2 MatchMakers already

- stabilises expectations and API for MatchMakers

- makes it clear how other MatchMakers can be structured and contributed into the system

- provides a “reference benchmark” against which the quality of more sophisticated MatchMakers can be compared

- starts to assemble a collection of reference utilities and algorithms which could be usefully shared amongst all/most Matchmakers

some useful matchmaker primitives
Some useful MatchMaker Primitives


"type": "gpii.integrationTesting.mockSettingsHandler",

"capabilities": ["display.screenEnhancement"],

"capabilitiesTransformations": {

"mag-factor": "display.screenEnhancement.magnification",

"show-cross-hairs": "display.screenEnhancement.showCrosshairs",

  • Compute the Input Image of a solution:
  • Step 1: convert to leaf representation

with matchMaker.computeLeavesFromSolution







input image computation
Input Image Computation







  • Step 2: Convert to “skeleton model”

using matchMaker.pathsToSkeleton

var magnifierSkeleton = {

display: {

screenEnhancement: {

magnification: {},

showCrosshairs: {},

tracking: {}




the flat matchmaker
The “Flat” MatchMaker
  • Simplest possible algorithm
  • Index into the “skeleton solution input image” with all of the leaves derived from the user’s profile
  • Pick every solution for which there is an exact match
flat matchmaker implementation
Flat MatchMaker Implementation

gpii.matchMaker.flat.disposeStrategy = function (leaves, solrecs) {

fluid.each(solrecs, function(solrec) {

var accepted = fluid.find(leaves, function (leaf) {

return fluid.get(solrec.skeleton, leaf, matchMaker.accessConfigs.get);


solrec.disposition = accepted? "accept" : "reject";


return solrecs;


  • In the form of a strategy, just 6 lines of code
  • Easy to configure alternative strategies into the GPII MatchMaker via this option:

fluid.defaults("gpii.matchMaker", {

gradeNames: ["fluid.littleComponent", "autoInit"],


strategy: "gpii.matchMaker.flat.disposeStrategy",

canopy matchmaker
Canopy MatchMaker
  • Goals – a reasonably straightforward “reference implementation” that is
    • Fast
    • Deterministic
    • Suitable to have algorithmic steps pushed into persistence layer (e.g. CouchDB)
    • Allows simple kinds of profile without requiring logic
    • Moderately sensitive to “ontological metric” – that is, willing to accept “near matches” in some cases based on hierarchy
canopy matchmaker strategy
Canopy MatchMaker Strategy
  • Based on a vectorial “fitness measure” of a solution plus a lexicographic ordering
  • Similar to the strategy used in resolving CSS rules, which have been proven a workable scheme for allowing tradeoffs between communities (designers, users) without encoding logic

some more definitions utilities
Some more definitions/utilities
  • Prefix depth of an EL path into a model is the number of path segments it falls short of matching – an integer ≤ 0

var sammyProfile = {

"display": {

"screenEnhancement": {

"fontSize": 24,



prefixLength("display.screenEnhancement.fontSize", sammyProfile)); // value 0

prefixLength("display.unrecognizable", sammyProfile)); // value -1

prefixLength("display.unrecognizable.thing", sammyProfile)); // value -2

fitness vector for a solution
Fitness vector for a solution
  • Convert user profile to leaves
  • Compute input image for solution
  • Compute vector of prefix lengths for each leaf EL in user profile
  • Sort vector in descending order of fitness (prefix length 0 at start) -> fitness vector
  • Rank solutions by fitness using lexicographic ordering (Sith Lord system)

var fitness = canopy.computeFitness(sammyLeaves, magnifierSkeleton);

var expected = [0, 0, 0, -1, -1, -1, -1, -2, -3];

the canopy algorithm
The Canopy Algorithm
  • Compute fitness vectors for each solution and sort in rank order
  • Initialise “canopy” giving value –Infinity to each profile leaf path
  • For each solution, “raise the canopy” by setting the canopy value to the maximum of its old value and solution value
    • For each solution which “raised the canopy” at any leaf, accept it
    • For each solution which did not raise the canopy, reject it
under the canopy
Under the Canopy






EL path index (imagined linearized)

Fitness: [0, 0, -1, -2, -3] – accepted (extends canopy at 4 points)

Fitness: [0, 0, -2, -2] – accepted (extends canopy at 1 point)

Fitness: [-1, -1, -3] – rejected (lies wholly under canopy)

to be addressed
To be addressed:
  • Issue of an “ontological metric”
  • We have used the hierarchical structure of the ontology to “boot this up” but it is clearly only a provisional and inaccurate measure
  • Could be improved by scaling fitness increments deeper in the tree to count less than those at the root
  • Eventually this metric information will be gathered from user data, and the tree structure will disappear/be de-emphasised
to be addressed1
To be addressed:

Currently we do not address:

- solutions which are “transformed away” through the settings mapper

  • solutions which the user has a personal preference for through familiarity – even if another might seem to meet their needs equally well or better
  • the “user loop” in general – where fine-grained preferences are queried by the system and recorded in action
  • The crucial issue of data provenance – the system needs to be clear whether a particular entry was collected from the user, computed, or arrived from some other source
where we are
Where we are
  • MatchMaker ecology is ready for new inhabitants
  • Several problems are not handled by current matchmaker
  • Statistical matchmakers will require reference point matchmaker to collect training data as well as performance benchmarks
  • Model transformation syntax represents a useful lingua franca for describing the operation and outputs of matchmakers
source code
Source Code
  • The Model Transformation System
  • (Fluid Infusion github):
  • Preferences statement:
  • Settings Handler:
  • Solutions Registry:

Colin Clark


t: @colinbdclark

Antranig Basman