Preference Set Format

From wiki.gpii
Jump to: navigation, search

Overview

Over the course of the Cloud4All project, the GPII Needs and Preference Set (NP set) format was revised several times based on feedback and contributions from Cloud4All’s matchmaking, context-awareness, and architecture teams. In particular, a number of improvements were made, including:

  • support for user-defined contexts and conditions
  • users can now define priorities for their preferences, improving a Matchmaker’s ability to resolve conflicts in a preference set
  • containers for metadata such as provenance were added

Figure 4 provides an example of a preference set in the new format, which is now supported throughout all major components within Cloud4All.

 { 
  "contexts": {
    "gpii-default": {
      "name": "Default preferences",
      "preferences": {
        "http://registry.gpii.net/common/fontSize": 12
      }
    },

    "nighttime-at-home": {
      "name": "Nighttime at home",
      "preferences": {
        "http://registry.gpii.net/common/fontSize": 24
      },
      "conditions": [
        {
          "type": "http://registry.gpii.net/conditions/timeInRange",
          "from": "18:00",
          "to": "06:00"
          "inputPath": "http://registry\\.gpii\\.net/common/environment/temporal\\.time"
        },
        {
          "type": "http://registry.gpii.net/conditions/inRange",
          "min": 700,
          "inputPath": "http://registry\\.gpii\\.net/common/environment/visual\\.illuminance"
        }
      ],

      "metadata": [
        {
          "type": "provenance",
          "scope": ["http://registry.gpii.net/common/fontSize"],
          "source": "snapshotter"
        }, 
        {
          "type": "required":
          "scope": ["*"] // all preferences in this context are required.
        }
      ],

      "priority": 100
    }
  }
 }

Figure 4: An example of the GPII needs and preferences set JSON format, featuring support for contexts, conditions, priorities, and metadata.


User-Defined Contexts

NP Sets are now grouped at top level into a container called contexts, which allows users to define their own custom groups of contextual preferences. Each context is given a document-unique identifier as well as a friendly user-readable name. A special identifier, gpii-default, is reserved for the user’s default preferences; this context is applied in absence of an appropriately matching context.

Each context is determined by a set of conditions contained within the conditions array. The format for conditions is also declarative. In other words, it is a standard JSON data structure that can be operated on by any programming language. As a result, this format is straightforward to read and process, and substantially easier to programmatically generate than one based on a grammar-based approach. Since it is assumed that components across the GPII system (many of which are written in different programming languages) will manipulate conditions, this approach represents a significant advantage for interoperability.

Conditions and operators take the form of named terms associated with a JSON object describing their arguments. These terms are bound by the runtime system (e.g. the GPII Context Evaluator component) to a function that will evaluate the condition or operator. Operators are identified by the special keyword "operator".

 "conditions": {
  "operator": {
    "type": "http://registry.gpii.net/operators/booleanOR",
    "operands": [
      {
        "type": "http://registry.gpii.net/conditions/timeInRange",
        "from": "18:00",
        "to": "06:00"
      },
      {
        "type": "http://registry.gpii.net/conditions/location",
        "gps": {
          "lat": "79.3N",
          "long": "74.9W"
        },
        "range": {
          "value": 200,
          "unit": “metres”
        }
      }
    ]
  }
 },
 "priority": 0.5

Figure 5: Example of a declarative condition specification that uses a boolean OR operator to define context of "whenever it’s night time or I’m at home."

Conditions, Operators, and Priorities

Condition Evaluator Functions...

  • are bound to a condition term identifier (e.g. "http://registry.gpii.net/conditions/inRange")
  • take as input an arbitrary condition "value"
  • take as input some form of relevant context data (e.g. device reporter information, time of day, environmental reporter data, etc.)
  • return an appropriate value (e.g. a boolean if the condition is successfully matched)

Operator Functions...

  • are bound to an operator term identifier (e.g. "http://registry.gpii.net/operators/booleanOR").
  • take an array of operands as an argument
  • may contain sub-operators
  • defer to a set of condition evaluator functions to evaluate its conditions
  • return an appropriate value (e.g. a boolean value for a boolean operator)

Priority Values...

  • are IEEE 754 floating point numbers
  • represent the priority for a particular collections of preferences in the case that multiple contexts match equally
  • reserve values above 1024 for "system-level" prioritization
  • are optional

Another benefit of this architecture for conditional preferences is its ease of “authorability.” We know that users will employ a variety of tools to create, edit, and manage their preferences sets. In order to provide good user interfaces for editing conditions, we will need an architecture that is semantic—one that closely captures the user's natural terminology and concepts. Initial sketches for Cloud4All’s conditional format used low-level boolean operators to define conditions; further exploration and discussion revealed that this approach significantly limits the usability of the interfaces we can provide to the user. The current format emphasizes higher-level semantics that will facilitate the creation of highly usable authoring UIs. These high-level user concepts (e.g. "in the range of", "in the morning", etc.) will be registered as condition terms in the Common Terms Registry and bound to particular evaluation functions by the runtime environment. As a result, the set of conditions and operations that can be expressed is both semantic and extensible.

Metadata

Previous versions of the NP Set format were only capable of modelling user preferences. However, it is often necessary to store other information that is associated with a preference, but is not, in itself, an expression of what the user needs or wants. For example, Matchmakers may want to analyse the provenance of a particular preference (i.e the source from which it came, such as the Snapshotter or the Preferences Management Tool), and the algorithms by which it has been processed (e.g. the Statistical or Rule-based Matchmaker). A user may also want to describe the fact that some preferences are absolutely required for them to operate a computer, while others are just preferred. In both cases, this information is stored in a metadata container. Metadata can be either context-specific or can apply to all preferences within the user’s set.


Colin Clark and Antranig Basman, December 2014