Talk:Profile Conditions Proposal

From wiki.gpii
Jump to: navigation, search
old content. revise and erase when ready


WARNING: OUTDATED DRAFT. Read Proposal for Declarative Preference Conditions instead.

Original Concept

This proposal is based on thoughts and discussions back from the Access4All days as described in Profile Conditions.

Conditions Payload

A condition is used to link a preferences, either common or app-specific, to a certain concept. A typical example would be activating magnification in the evening as eyes grow tired.

TODO: replace conditions format with the already existing transformers format: Architecture - Available transformation functions

{
    "preferences": {
        "http://registry.gpii.org/common/magnifierEnabled": [
            {
                "value": true
                "conditions": [
                    {
                        "operator": "http://registry.gpii.org/operators/greater",
                        "operandA": "Time.local",
                        "operandB": "2000"
                    }
                ]
            }
        ]
    },
    "device": {
        "solutions": [
            {
                "id": "com.microsoft.windows.magnifier"
            }
        ],
        "OS": {
            "id": "win32",
            "version": "6.1.7601"
        }
        "Time": {
            "local": "2015"
        }
    }
    "context": {...}
}

Two important changes were introduced:

  1. The device payload - which is just part of context - was renamed to context and stores all kinds of dynamic (sensors) or static (knowledge) context.
  2. The preferences got a new payload, "conditions".

Conditions

Technically speaking, Conditions are operations evaluated on context that yield a bool (true/false) value. This is implemented in a declarative way using operators, which themselves are defined at the registry. In this simple example, time is expressed as an integer and the "http://registry.gpii.org/operators/greater" operator describes that. This allows to add more specific Operators later on. the conditions block boils down to Time.local > 2000.

Note that there are no combination operators as for bools, like "and" or "or". Both are implicit in the data structure.

AND

All conditions for a preference have to be true to be applied, which covers an AND operator. Say we want to activate magnification late the day, but only on windows, our home pc:

...
    "preferences": {
        "http://registry.gpii.org/common/magnifierEnabled": [
            {
                "value": true
                "conditions": [
                    {
                        "operator": "http://registry.gpii.org/operators/greater",
                        "operandA": "Time.local",
                        "operandB": "2000"
                    },
                    {
                        "operator": "http://registry.gpii.org/operators/equals",
                        "operandA": "OS.id",
                        "operandB": "win32"
                    }
                ]
            }
        ]
    }
...

OR

Each preference is checked for its condition individually, so the OR operator is covered by introducing multiple preferences. If we want to enable magnification in the evening or in the morning:

...
    "preferences": {
        "http://registry.gpii.org/common/magnifierEnabled": [
            {
                "value": true
                "conditions": [
                    {
                        "operator": "http://registry.gpii.org/operators/greater",
                        "operandA": "Time.local",
                        "operandB": "2000"
                    }
                ]
            }
        ],
        "http://registry.gpii.org/common/magnifierEnabled": [
            {
                "value": true
                "conditions": [
                    {
                        "operator": "http://registry.gpii.org/operators/less",
                        "operandA": "Time.local",
                        "operandB": "800"
                    }
                ]
            }
        ]
    }
...

Operands

While the operator field points to an operand specification on the registry, the operand fields fill in the data for the operator. Note that the number of operators is specified by the Operator, but the vast majority will need two.

Operands can have two kinds of data. Atoms or Symbols. An Atom, like "800", is a value that can directly be converted into an underlying datatype as required by the operator. A symbol, on the other hand, is a context-lookup. The symbol "Time.local" is evaluated by checking context.Time.local.

Custom Conditions

Humans usually think in very abstract operators, like "in the evening" instead of "after 8pm". Sadly, only "after 8pm" is objective, meaning that - as long as you stay into the same time zone - everybody can evaluate it the same way. "in the evening", however, is very subjective. For some evening is 8pm, but for others it might be 10pm or 7pm. To cover this usecase, but still allow user-friendly conditions, a user can specify their own conditions. This is done by introducing a new conditions field to the profile.

{
    "preferences": {
        "http://registry.gpii.org/common/magnifierEnabled": [
            {
                "value": true
                "conditions": [
                    {
                        "external": "in the evening"
                    }
                ]
            }
        ]
    },
    "conditions": {
        "in the evening": [
            {
                "operator": "http://registry.gpii.org/operators/greater",
                "operandA": "Time.local",
                "operandB": "2000"
            }
        ]
    },
    "context": {
        "solutions": [
            {
                "id": "com.microsoft.windows.magnifier"
            }
        ],
        "OS": {
            "id": "win32",
            "version": "6.1.7601"
        }
        "Time": {
            "local": "2015"
        }
    }
}

When the "external" field of a condition is set, it links to a condition defined in the conditions block of the preference set. Note that we could also have a set of predefined external conditions that everybody can use for a start.

Collisions

original content

The conditions of multiple, overlapping preferences can be active at the same time. Say we have a user Anna, and she uses 200% volume. She has been happy with that for quite some time, but now bought a new smartphone with terrible speakers, so she wants additional volume, expressing it as "I want 120% volume on that device". Obviously, we have a collision here between her generic (always-true) preference of 200% and another preference that states 120% volume for smartphoneX. We also have to take into account that Anna didn't actually mean 120% of the device's volume setting, but 120% of what she is used to.

In cases where multiple preferences have true conditions, there is a combination method that - per preference - resolves the conflict. Which combinator to be used is defined per preference at the registry. For all percentage-like values, like volume, this combination could be multiplying them. In Anna's example: 2.0 * 1.2 = 2.4 --> 240% volume.

Combinators for Common Terms

As Common Terms are hand-made, they can prebake a lot of knowledge about which combinators make sense for which preference. For Volume, for example, multiplication.

Combinators for App-Spec Terms

For Application Specific Terms, we don't know anything about their semantics. Therefore, the decision which combinator to be used has to be based on the datatype. A Matchmaker can also utilize its own knowledge for these terms, if it can, for example, tell an integer value apart from a percentage or factor. For App-Spec preferences, the combinators are not defined by the registry, but are matchmaker-defined.


See also