Scenario with Conditional Items in a User Profile

From wiki.gpii
Revision as of 12:07, 25 June 2015 by CStrobbe (talk | contribs) (format described here is outdated!)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This scenario has been moved over from the ISO 24751 wiki.

This proposal represents an older and outdated format for user preferences and conditionals. Please see the Proposal for Declarative Preference Conditions page for the latest proposal and JSON format for flat conditional preferences.


Martha’s preferred language is English, so when a TV programme is not in English, she wants English subtitles. Between 6 a.m. and 6 p.m., the subtitles should be extra large, but when her eyes get tired, she wants them to be even larger. During the day, i.e. between 9 a.m. and 7 p.m., the TV’s default volume is loud, but at other times, a medium volume is OK. The TV’s brightness level also depends on the time of day: it should be at maximum brightness until 6 p.m. but at 80% of its maximum brightness in the evenings.

This is represented by the following user profile, formatted as comma-separated values (CSV).

Name, Condition, Probability, Value, , 1, en, value('') == 'en', 1, false, value('') != 'en', 1, true, value('') >= '06:00:00' && value('') <= '18:00:00', 1, x-large, value('') > '18:00:00' && value('') < '06:00:00', 1, xx-large, value('') >= '09:00:00' && value('') <= '17:00:00', 1, loud, value('') > '22:00:00' && value('') < '09:00:00', 1, medium, value('') >= '08:00:00' && value('') <= '18:00:00', 1, 100, value('') > '18:00:00' && value('') < '08:00:00', 1, 80

This format uses 4-tuples (or triples with a probability) to represent preferences. The name is a URI, the condition is an ECMAScript expression that evaluates to true or false (this syntax replaces the XPath 2.0 value comparisons using eq, ne, lt, le, gt, ge from a previous version of this scenario). The probability is a number between 0 and 1 (e.g. 0.5); the default value is 1.

Some notes on the names and values:

  • The font values come from the list of absolute font sizes in CSS 2.1 (xx-small | x-small | small | medium | large | x-large | xx-large).
  • The loudness values come from the list for voice-volume in the CSS 3 Speech module (silent | x-soft | soft | medium | loud | x-loud). These values are also listed in CSS 2 aural and SSML1.1.
  • For brightness ETSI ES 202 746 uses an integer in the range 0..100.
  • is for subtitles in general, not just for TV: if someone wants subtitles on their TV, they probably want them also when watching video on their computer.
  • is also for subtitles in general, even if x-large and xx-large will translate to a different size depending on the device (since people watch TV from a greater distance than a computer screen).
  • is the user’s local time, which is not necessarily the same as the matchmaker’s time, since the matchmaker may be located in a different time zone.

A format with 4-tuples (or triples with a probability) is preferred over a format that uses five or more tuples, like the following example, which specifies the device separately:

  condition="value('') >=  '08:00:00' && value('') <=  '18:00:00'"
  value="100" /> 

This approach makes it easier to filter properties or preferences for a specific device. The proposed format - based on 4-tuples - treats "device" and "application" as part of the condition, among other contextual conditions.

  • This enables the expression of more complex device conditions, or negated conditions, for example: (value('http://…device') != 'tv' && value('http://…/manufacturer') == 'Apple') || value('http://…/application') == 'MS Word'.
  • Making "device" a component in the tuple opens the door to other components becoming separate components, for example, "application". Similar to devices, a property might change depending on the specific application (e.g. MS Word) or application type (e.g. text processing) a user is using. This can be expressed as a condition instead of replacing the triples with bigger tuples.

In this approach, different devices are part of the context (expressed in a device profile). It may be one property (http://.../device) or multiple properties (e.g. http://.../device-category<nowiki>, <nowiki>http://.../device-model, http://.../device-serial-number, etc.).

Only the user profiles need conditions. The contextual profiles (device, application, environment, etcetera) describe occurrences of real contexts of use. These contextual profiles don't need conditions. In a device profile, 'tv', 'mobile', and 'kiosk' can occur as possible values for a property (e.g. http://.../device). In an application profile, we can have any number of ATs listed as multiple occurrences of a property (e.g. http://.../assistive-tech). If a property name occurs multiple times, all listed values are assumed. So one property may have multiple values. In Dublin Core, this is the same. One document may have multiple authors by listing all of them as separate <dc:creator> statements.

An alternative approach - avoiding conditionals but keeping all the same info using refined terms

Error creating thumbnail: Unable to save thumbnail to destination

This image shows Martha has a profile with redundant metadata:


  • property language has-value en-us
  • property notEnglish-TV-format has-value subtitles
  • property subtitle-fontsize-1800-0600 has-value xxlarge
  • property volume-0900-1700 has-value loud
  • property volume-2200-0900 has-value medium
  • property brightness-level-0800-1800 100
  • propertybrightness-level-1800-0800 80
  • ...

Without putting in a long explanation, ....

This version includes three possibilities:

  1. The properties are all in the registry so the profile references them within the registry
  2. Some properties are in the registry and some are ones that we use at 'our place' so they are just in a namespace we maintain. We refer to it as shown below.
  3. No properties used are in the registry but they are all defined within two namespaces that are not in the registry but in the profile these places are identified and two prefixes are added to property-names to show where to find definitions, eg dc:language would lead to a lookup in the dc namespace, etc.

The conditional is not in the declaration of needs but a system, as ever, will be designed to test the condition and depending on if it is satisfied, the declaration will be recognised and implemented or ignored.

Device Profile

Below is a device profile for a TV set. Some properties are static, some may change during a session (e.g. the current channel). This type of profile consists of simple name-value pairs without conditions or probabilities.

Name, Value, 'Sony', 'Bravia XY', 1400, 768, '80cm', '45cm', 'CNN', 'fr'

Context Profile

Below is a context profile:

Name, Value, '19:25:00'

Using the Profiles

With the above profiles, we can already do some basic adaptations:

  • the current time is 19:25:00 (see context profile), so
    • the condition value('') > '18:00:00' && value('') < '06:00:00' for xx-large subtitles is triggered,
    • the condition value('') > '22:00:00' && value('') < '09:00:00' for medium sound volume is triggered,
    • the condition value('') > '18:00:00' && value('') < '08:00:00' for 80% TV brightness is triggered.
  • the device tells us that the current program is in French (, 'fr'), which triggers the condition value('') != 'en' for subtitles.

So Martha will be watching the French TV program with English subtitles (if they are available), displayed in xx-large font size; the TV will use a medium sound value (unless Martha changes the volume) and 80% brightness.

XML and JSON Representations

The CSV represenation can be converted into XML and JSON. For example, the user profile in the first section of this page could be represented as follows (representations generated with some simple JavaScript code):


{ "name" : "",
"condition" : "",
"probability" : "1",
"value" : "en"
{ "name" : "",
"condition" : "value('') == 'en'",
"probability" : "1",
"value" : "false"
{ "name" : "",
"condition" : "value('') != 'en'",
"probability" : "1",
"value" : "true"
{ "name" : "",
"condition" : "value('') >= '06:00:00' && value('') <= '18:00:00'",
"probability" : "1",
"value" : "x-large"
{ "name" : "",
"condition" : "value('') > '18:00:00' && value('') < '06:00:00'",
"probability" : "1",
"value" : "xx-large"
{ "name" : "",
"condition" : "value('') >= '09:00:00' && value('') <= '17:00:00'",
"probability" : "1",
"value" : "loud"
{ "name" : "",
"condition" : "value('') > '22:00:00' && value('') < '09:00:00'",
"probability" : "1",
"value" : "medium"
{ "name" : "",
"condition" : "value('') >= '08:00:00' && value('') <= '18:00:00'",
"probability" : "1",
"value" : "100"
{ "name" : "",
"condition" : "value('') > '18:00:00' && value('') < '08:00:00'",
"probability" : "1",
"value" : "80"

XML (without escaping <, >, & etcetera for readability):

<preference name="" condition="" probability="1" >en<preference/>
<preference name="" condition="value('') == 'en'" probability="1" >false<preference/>
<preference name="" condition="value('') != 'en'" probability="1" >true<preference/>
<preference name="" condition="value('') >= '06:00:00' && value('') <= '18:00:00'" probability="1" >x-large<preference/>
<preference name="" condition="value('') > '18:00:00' && value('') < '06:00:00'" probability="1" >xx-large<preference/>
<preference name="" condition="value('') >= '09:00:00' && value('') <= '17:00:00'" probability="1" >loud<preference/>
<preference name="" condition="value('') > '22:00:00' && value('') < '09:00:00'" probability="1" >medium<preference/>
<preference name="" condition="value('') >= '08:00:00' && value('') <= '18:00:00'" probability="1" >100<preference/> 

See Also