190 likes | 292 Views
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
E N D
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 • We need a system for smoothly transferring information back and forth between these worlds 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 { "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 [ "display.screenEnhancement.magnification", "display.screenEnhancement.showCrosshairs", "display.screenEnhancement.tracking", "display.screenEnhancement" ];
Input Image Computation [ "display.screenEnhancement.magnification", "display.screenEnhancement.showCrosshairs", "display.screenEnhancement.tracking", "display.screenEnhancement" ]; • Step 2: Convert to “skeleton model” using matchMaker.pathsToSkeleton 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 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 • 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 0 prefixLength("display.unrecognizable", sammyProfile)); // value -1 prefixLength("display.unrecognizable.thing", sammyProfile)); // value -2
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 • 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 0 -1 -2 -3 -4 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: • 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 Clark e: cclark@ocad.ca t: @colinbdclark Antranig Basman e: amb26@ponder.org.uk fluidproject.org gpii.net