1 / 19

The MatchMaker Ecology

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

tevin
Download Presentation

The MatchMaker Ecology

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The MatchMaker Ecology Antranig Basman, Core Framework Architect, GPII

  2. 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

  3. 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

  4. 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

  5. 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" ];

  6. 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: {} } } };

  7. 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

  8. 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",

  9. 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

  10. 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

  11. 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

  12. 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];

  13. 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

  14. 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)

  15. 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

  16. 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

  17. 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

  18. 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

  19. Questions? Colin Clark e: cclark@ocad.ca t: @colinbdclark Antranig Basman e: amb26@ponder.org.uk fluidproject.org gpii.net

More Related