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