Profile Conditions

From wiki.gpii
Jump to: navigation, search

This page is still draft!

Profile Structure

A profile holds all the preferences associated with a single user. Yet, there are many influences which can affect the value of a property besides the user, for example device dependencies (like differences in display size or speaker volume). In general, these influences can be split into two categories.

Device Dependencies

Both physical hardware and applications or operation systems invoke a number of limitations which have to be dealt with. The screen size of a smart phone compared to a TV is an obvious factor to be taken into account for a property like "font size". Similar requirements apply for the audio-equipment of a device, for example the volume or the native pitch-offset of a headset.

Context Dependencies

To respect the needs of a user, properties may have to be adjusted to the environment the user is working on. For example the lighting conditions, the background noise or the time of the day. These context information is delivered by sensors on the client side.

Change frequency

An important properties of these dependencies are their likelihood to change. The screen size of a SmartPhone is very unlikely to change, while the lighting conditions can change in seconds. To differentiate between static and dynamic dependencies, it's important to see whether they can change at run-time or not.

Static Dependencies

These dependencies are unlikely to change and are often tied to the hardware, for example the audio quality, maximum volume and pitch-offset of a headset. These dependencies are very unlikely to change at runtime and if they still should, it just happens very rarely. Properties depending on these dependencies are therefore also very static at run-time and don't need to be evaluated often.

Dynamic Dependencies

These dependencies change chaotically or in short intervals, for example the background noise while traveling or the time of the day in a second or minute resolution. Properties depending on these dependencies will also have to be evaluated often with short delays between request and answer. In most cases, the input to these dependencies originates from sensors within the actual client device and can't be inferred from information available on the server side.

Profile Proposal

  • Static Dependencies - which will often, but not always, be Device Dependencies - are baked into the name of a property or into the name of the profile (both alternatives are exchangeable). To make it easier to be read by humans, there might be a special character inserted to mark generic property name.
  • Dynamic Dependencies - which will often, but not always, be Context Dependencies - are expressed as a boolean condition. There can be multiple preferences describing the same property with different conditions in the same profile.


Client-Side Evaluation

Splitting static and dynamic dependencies allows to transfer the boolean condition to the client upon querying the preferences, which allows to evaluate the dynamic dependencies on the client without having to stress the server and infrastructure. This also allows to react on chaotic dynamic dependencies as fast as possible (for example rapid changes in background noise or lighting condition).

Automated Analysis

Tools working on the server - for example the matchmaker - can easily identify a generic property and its static "sub-properties". Static dependencies don't have to be put into the boolean expressions, making them easy to be parsed and analyzed for their semantic meaning.

Boolean Conditions

The boolean expressions need to access information stored in the user, device or context profiles. To do so, there is a value(id) function, which takes an identifier - for example the property URI - and returns the value associated with it within the current context.

Example: Pitch

The following scenarios will follow a few assumptions:

  • JavaScript is used to express the boolean conditions
  • Static dependencies are marked with the "|" character
  • Pitch is expressed by values contained in the enumeration: normal, low, high, lowest, highest

Pitch for upper-case text

User Profile
Property Value normal|italic low|bold high|uppercase highest

Device and Context profiles are not required in this example.

Pitch for different characters

User Profile
Property Value normal|character1 low|character2 high|character3 lowest|character4 highest

Device and Context profiles are not required in this example. An application, for example a novel-reader, will only be able to express a limited number of characters, because there is only a limited number of pitch variations which can be identified by humans. Any such application will have to map the characters in a novel on this given set of different characters and its not reasonable to store a special setting for "Marc" in the database, as there will thousands of novels containing a "Marc".

Pitch depending on the time of the day

User Profile
Property Condition Value true normal value("") > 1800 low value("") > 2000 && value("") <= 2300 high
Context Profile
Property Value 1917

Pitch on different audio devices

User Preference Profile
(Preference) Property Value normal|iPhone low|SamsungChronos high
Device Profile (part of context profile)
(Context/device) Property Value SamsungChronos

Pitch with background noise

2 entries from a User Preference Profile
(Preference) Property Condition Value true normal value("") > 10 high
1 entry from a Context Profile (in a scenario)
(Context) Property Value 8.3

Combined example



There are some scenarios in which conflicts may appear and have to be dealt with.

Process Flow

Conditions Process Flow.png

  1. An application on the client device wants to receive it settings. This invokes a query to the infrastructure including the device profile and the context profile.
  2. The infrastructure evaluates the static requirements and returns a user profile only including the preferences which passed the static evaluation and their conditions. The dynamic requirements can now be evaluated on the client side without further need to ask the infrastructure unless something fundamental (like the current device) changes

Alternative Proposal

Alternatively, it might be a good idea to express the static dependencies with a separate boolean expression and not to bake them into the preference name. Especially when multiple static dependencies apply and there are overlaps, a boolean expression might be preferable.

User Profile
Property Static Condition Dynamic Condition Value value("") == "SamsungChronos" value("") > 1800 low