Post on 21-Jan-2016
description
The MatchMaker Ecology
Antranig Basman,Core Framework Architect,
GPII
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
MatchMakers
The running system
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 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
Compute the Input Image of a solution:
Step 1: convert to leaf representation
with matchMaker.computeLeavesFromSolution
{ "type": "gpii.integrationTesting.mockSettingsHandler", "capabilities": ["display.screenEnhancement"], "capabilitiesTransformations": { "mag-factor": "display.screenEnhancement.magnification", "show-cross-hairs": "display.screenEnhancement.showCrosshairs", …
[ "display.screenEnhancement.magnification", "display.screenEnhancement.showCrosshairs", "display.screenEnhancement.tracking", "display.screenEnhancement" ];
Input Image Computation
Step 2: Convert to “skeleton model”
using matchMaker.pathsToSkeleton
[ "display.screenEnhancement.magnification", "display.screenEnhancement.showCrosshairs", "display.screenEnhancement.tracking", "display.screenEnhancement" ];
var magnifierSkeleton = { display: { screenEnhancement: { magnification: {}, showCrosshairs: {}, tracking: {} } } };
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
In the form of a strategy, just 6 lines of code Easy to configure alternative strategies into
the GPII MatchMaker via this option:
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;};
fluid.defaults("gpii.matchMaker", { gradeNames: ["fluid.littleComponent", "autoInit"], …… strategy: "gpii.matchMaker.flat.disposeStrategy",
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
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
http://www.stuffandnonsense.co.uk/archives/images/specificitywars-05v2.jpg
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 0prefixLength("display.unrecognizable", sammyProfile)); // value -1prefixLength("display.unrecognizable.thing", sammyProfile)); // value -2
Fitness vector for a solution
i) Convert user profile to leaves
ii) Compute input image for solution
iii) Compute vector of prefix lengths for each leaf EL in user profile
iv) Sort vector in descending order of fitness (prefix length 0 at start) -> fitness vector
v) 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
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 Canopy0
-1
-2
-3
-4EL 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: 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 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 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 https://github.com/GPII/universal
The Model Transformation System
(Fluid Infusion github):
http://bit.ly/LaXMbJ
• Preferences statement: http://bit.ly/LN4iEB
• Settings Handler: http://bit.ly/M6mDfD
• Solutions Registry: http://bit.ly/KrLo6Z
Questions?Colin Clarke: cclark@ocad.cat: @colinbdclark
Antranig Basmane: amb26@ponder.org.uk
fluidproject.orggpii.net