This page is a draft outline of the requirements and architectural approach for the Matchmaker Framework, authored by Kasper and Colin
We envision a matchmaking framework where multiple, small, self-contained matchmaker strategies are available to be mixed and matched in new ways. This will, among other things, enable the goal of producing “hybrid matchmakers,” which combine a variety of strategies for matching the user’s needs to the device and context. We already do this to some extent with the Rule-Based Matchmaker, which uses the Flat strategy as part of its implementation.
Our goal is to take a flexible approach to matchmaking and to make sure that we don’t have code-level overlap between matchmaker implementations. This means, as developers, we need to move from thinking about The Matchmaker to a matchmaker ecology consisting of a set of components, each with a clear, specific (and limited) functionality that is part of the overall matchmaking process. Having this kind of matchmaker ecology will allow us to reuse and share these underlying “building block components” between different matchmaker strategies.
Ideas for components in the matchmaker ecology (many of these already exist in at least prototypal form):
- Context/condition evaluation - simple and small component that can evaluate (all or part of) the conditions in an NP set.
- Input: contexts, NP set
- Output: Evaluated NP set
- Ontology service - can apply an ontology to the preference set (and remove it), done via model transformation.
- Input: Transformation schema, NP set
- Output: ontologized NP set
- Inferring solutions - the general purpose of this is to modify the set of solutions that will be launched on the machine. We will probably have several of these. This component can both add and remove solutions from the list (i.e. pull in relevant web-based solutions if necessary)
- Input: NP Set, solutions available (perhaps only locally, perhaps web as well), perhaps some context info
- Output: list of solutions to start (perhaps integrated in NP set)
- Some sort of orchestrator for flow - with e.g. that ability to pass on results between components and that will allow MMs to fail and the result being passed on to a different MM. It needs to be quite intelligent when directing the flow of things. Should probably be able to support dynamic flows - i.e. flow will depend on results from each components. Perhaps part of the solution is for each component to tell what type of (or specific) component should be next, something that might vary for a component from run to run (i.e. RB MM might in one case solve conflicts and decide that we should send the NP set to user. In another case, it might decide that it’s completely lost and send everything to a ST MM)
- Inferring preferences - take a preferences set and modify it in terms of the settings in it (e.g. adding preferences, removing them, etc.). The flat matchmaker is an example of this.
- Input: all available data
- Output: an NP set
- Result Scoring - not sure this is realistic or even useful, but it could be worth considering having a component that evaluates whether a proposed solution (i.e. inferred prefs set and set of solutions to launch) covers the needs of the users in a way that enables them to use the device.
We are likely to have several versions of some of these components (that's the whole idea), but in each case the role and responsibility of these components should be clear, simple, and separate from all other responsibilities. It should be possible to add new components and inject them in the flow using the real-time framework’s inversion of control infrastructure. Some components will take the role of several of these (e.g. ST MM strategy will probably both infer preferences and infer solutions).
General Notes and Ideas
- all components are fast, small, and able to run locally (i.e. not only as a remote web service)
- model transformation (flat matchmaker)
- CSS style-best match solutions selection based on hierarchical/ontologized NP set (canopy matchmaker) - i.e. solution selection
- Interesting Rule-based Matchmaker functionality to focus on:
- Exploding and merging terms - i.e.: "make it easier readable" can mean both font-size, magnification, etc.
- Intelligent, expert-based interpretations of terms - i.e.: font-size can cover the same needs as magnifier, but wont affect images on the screen, and might screw up layout. Screen resolution is a closer match with magnification, but will mess up screen layout, etc.
- We want to take as much offline as possible, but not everything can be done on the local machine—important to consider what parts of the MMs could be separated out to run lightweight and offline (and cross platform - i.e. android/IOS/etc)
- Multi-pass workflow: experiment through some scenarios to make them think about the advantage of ecology and hybridization, e.g: attempting to do things with flat+canopy, not satisfactory result, so passed to RB MM to figure out alternatives, adding settings, etc., and then potentially passing it back to flat/canopy. If RB MM is at a loss as to what to do, pass to ST MM. Take a scenario like that, walk through the order of components, when is context evaluated?, How do we know if a result is satisfactory? How can we orchestrate flow in an intelligent way? etc.
- worth to consider more general/abstract common terms - e.g. "make text readable", "don't use graphical UI", "I find computers confusing"
- We should ensure that the basics are working (as in supporting a minimal viable system)
- We shouldn’t neglect advanced MM functionality and future scenarios; we should keep this in mind, include it in our discussions, and ensure what we’re building will support it - but supporting advanced MM functionality us useless if we can't handle the basics
- Consider how the mini MM fits into this
- CS: Find alternative names for "flat matchmaker" and "canopy matchmaker" that don't use the term "matchmaker".
- CS: One type of "result scoring" could be a confidence score. When a matchmaker gives a low confidence score ("low" with regard to a threshold we have not yet defined), it may delegate the relevant part of its matchmaking process to another matchmaker.
- CS: The components listed in the previous section ("Context/condition evaluation", "Inferring solutions", "Inferring preferences", ...) should not be read to imply a sequence. However, we should look at the sequence implemented in the current matchmakers to see whether they expect a specific sequence.