This page is still draft!
- 1 Profile Structure
- 2 Change frequency
- 3 Profile Proposal
- 4 Boolean Conditions
- 5 Example: Pitch
- 6 Conflicts
- 7 Process Flow
- 8 Alternative Proposal
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.
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.
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.
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.
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.
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.
- 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.
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).
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.
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.
The following scenarios will follow a few assumptions:
- 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
Device and Context profiles are not required in this example.
Pitch for different characters
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
|http://gpii.org/ns/up/pitch||value("http://gpii.org/ns/cp/time") > 1800||low|
|http://gpii.org/ns/up/pitch||value("http://gpii.org/ns/cp/time") > 2000 && value("http://gpii.org/ns/cp/time") <= 2300||high|
Pitch on different audio devices
Pitch with background noise
|http://gpii.org/ns/up/pitch||value("http://gpii.org/ns/cp/noise_in_db") > 10||high|
There are some scenarios in which conflicts may appear and have to be dealt with.
- 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.
- 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
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.
|Property||Static Condition||Dynamic Condition||Value|
|http://gpii.org/ns/up/pitch||value("http://gpii.org/ns/dp/id") == "SamsungChronos"||value("http://gpii.org/ns/cp/time") > 1800||low|