Scenario on Matchmaking

From wiki.gpii
Jump to: navigation, search

This page is out of date! Consult Cloud4all deliverable D204.1 instead.

This page illustrates examples of matchmaking.

Example 1: From generic preferences to settings for specific devices or applications

Font-size might be a generic user preference that is defined as a common property. Generic means that the property is used by different devices, platforms or applications. The values of font-size could be defined absolute through keywords xx-small, x-small, small, medium, large, x-large, xx-large as defined by CSS.

Tim wants to check e-mails on a desktop PC where Internet Explorer and Firefox are installed. Tim prefers a large font-size and the Firefox to surf the internet. The first tasks of the Matchmaker consists of the matching which solution should be configured to Tim`s preferences. If Tim has set up another application to use a large font-size and this information is available in his profile, then it is possible to make some kind of inference concerning the font-size that should be used in Firefox. The second task consists of the transformation of the common preference font-size large to the Firefox specific setting font-size. This could be done by a mapping function between the common property specification of font-size and the Firefox specific setting specification for font-size:

Matchmaker mapping1.JPG

The Matchmaker executes the following steps:

  1. Construction of the matching process based on the input data
  2. Execution of the matching process: Result is a set of preferences that best meets the user`s needs related to the current user environment. For this example, the built-in accessibility feature font-size of Firefox has to be changed.
  3. Transformation of the common user preference font-size into the application-specific preference for Firefox.
  4. Return application-specific settings that are suitable for specific application’s settings handler.

Example 2: From preferences of specific applications or devices to settings of the specific device or application

Non-Common Properties in a user profile only refer to a specific application. These have no meaning outside of an application. The work on this terminology has not been finished. For instance, a preference for the application Zoom Text is that the Toolbar should be always on top or not. The value of this property is a Boolean. Dave wants to write an Email on a Desktop PC where Windows Magnifier and ZoomText are installed. Dave prefers ZoomText and that the Toolbar is always on top. If the Matchmaker identifies ZoomText as Dave`s preferred Magnifier, the setting - Toolbar always on top - has to be passed to the Flow Manager.

  1. Construction of the matching process based on the input data.
  2. Execution of the matching process: Result is a set of preferences that best meets the user`s needs related to the current user environment. For this example, the ZoomText feature Toolbar has to be changed.
  3. Return application-specific settings that are suitable specific application’s settings handler.

Example 3: translating solution-specific settings to Generic preferences

Tim signs on the Cloud4All system by his iPad for the first time. He prefers to use Mozilla Firefox to browse in the internet. He also prefers to have a large font size in his browser since he has low vision. Thus, he sets the font size of Firefox to be 18, since he realizes that this font size is sufficient large for him in the context of the given device. This setting that Tim has made should be translated to a generic preference and stored in his user Profile. This translation from a solution specific setting to a generic preference should be done via the Semantic Framework for Content and Solutions and via the Registry. Setting to generic preference traslation.jpg

  1. Tim logs on the Cloud4All system by his iPad device and sets the Firefox’s font size setting (FF:fontSize) in 18 pt.
  2. This information is sent to the transformer which is a component of the Matchmaker as stated before.
  3. Solutions and Services Reporter reports to the Matchmaker the available on the given device solutions, namely: Firefox and Internet Explorer.
  4. The device characteristics reporter reports to the Matchmaker the device being used (Device=iPad) along with characteristics of the given device (Screen Size = 12 inch).
  5. The transformer sends the solution specific setting to the Semantic Framework of Content and Solutions, where all the solution-, platform- and device-specific settings are stored.
    1. The Semantic Framework for Content and Solutions infers that the solution-specific setting (FF:fontSize) corresponds to the generic term of the Registry (Font Size)
    2. The Registry’s generic term (Font Size) that corresponds to the solution-specific setting (FF:fontSize) is returned to the transformer
  6. The output of the transformer is the bundled information of the Solutions and Device characteristics reporter along with the generic preference (FontSize that corresponds to the setting the user has made and which is reported by the Semantic Framework for Content and Solutions). Thus a new preference (Font Size=18, ‘Device==iPad’ && Solution=‘Firefox’) is created and sent to the Preference Server for being incorporated to the user Profile.

Example 4: Translating generic preferences to solution-, platform or device-specific settings

We will extend the previous example for exploring how the transformer should translate generic preferences to solution-specific settings. Tim logs on the Cloud4All system through his iPhone. The only preference present in Tim’s profile is “Font Size=18, ‘Device= =iPad’ && ‘Solution= =FireFox’. This is the preference stored in his profile when Tim has set the Font Size preference in his iPad as illustrated in the previous scenario. Furthermore Tim will use the Opera browser to navigate on internet with his iPhone. In this scenario Tim logs on the Cloud4All system using a different device, namely his iPhone, which has a smaller screen size, and Tim will use another browser to complete his work. The matchmaker should infer that the solution Tim uses in the new device (the Opera browser) is similar to the one that is part of his Profile entry (the Firefox browser) and should also infer that the font size of the Opera solution, should be set at 9 pt, because the screen of the new device is half as little as the previous device.

Preference to setting crossing devices.jpg

  1. Tim logs on the Cloud4All system by his iPhone device and starts the Opera browser.
  2. This information is sent to the transformer which is, as stated before a component of the matchmaker.
  3. Solutions and Services Reporter reports to the Matchmaker that the only available on the given device solution is the Opera browser.
  4. The device characteristics reporter reports to the Matchmaker the device being used (Device=iPhone) along with characteristics of the given device (Screen Size = 6 inch).
  5. The transformer interacts with the Semantic framework for Content and Solutions and receives the configurable settings of the available solutions (i.e. the Opera browser). For simplicity’s sake we consider in this example that the only configurable setting of the Opera browser is “O:TextSize”. Furthermore the matchmaker, through the Semantic Framework for Content and Solutions receives the information that the “O:TextSize” setting corresponds to the “Font Size” generic preference stored in the Registry. This is inferred by the Semantic Framework for Content and Solution in two internal steps:
    1. A object property connects the “O:TextSize” setting to the corresponding Registry Generic Term (Font Size).
    2. The Registry’s generic term (Font Size) that corresponds to the solution-specific setting (O:TextSize) is returned to the transformer
  6. The matchmaker receives the user’s preferences from the Profile’s Ontology. The only user preference that is present to Tim profile is “Font Size = 18, ‘Device = = iPad’ && ’Solution = = Firefox”. Since Firefox is not installed in Tim’s iPhone, and the preference of Tim is to use Firefox, the matchmaker receiving semantic information from the Semantic Framework for Content and Solutions (i.e. semantic similarity between solutions) can infer that the Opera browser is semantically similar to Firefox. Further more the matchmaker should infer that in this context the O:TextSize setting should be set at 9 pt, since in the user preference the text setting for a browser in a device with twice larger screen was 18 pt.

Example 5: Translating generic preferences to solution-, platform or device-specific settings

We present a generic usage scenario of the matchmaker. In this scenario we assume that the user profile is located in the Preference Server. Furthermore we assume the user profile consists of user preference’s triples having the form of {GPi, Vi, Ci}, where GPi is a Generic Property, Vi is a value corresponding to preference PGi, and Ci is a condition corresponding to the user’s preference. For simplicity’s sake we con-sider in this scenario only one type of Conditions, namely conditions concerning whether a preference should be applied to one specific solution or not. For example the preference GP1, V1, S1 refers to Generic Preference GP1 with value V1 that should be applied only to solution S1. It is obvious that also other conditions either static (e.g. concerning specific devices, platforms etc) or dynamic (e.g. lighting conditions, noise conditions, time, location etc) could be taken in consideration within the existing scenario.

Matchmaker generic example.jpg

The User Profile in this scenario consists of 5 user preferences that are shown in the picture above. The User Profile is summarized in the table:

GP1,V1,S1
GP1,V2,S2
GP2,V3,S1
GP2,?, S2
GP3,V4,S1
GP4,V5,S2
GP5,?,?
GP6,?,?

In this user profile we see that the user has specified different values for the same Ge-neric Property (GP1) for different Solutions (S1 and S2). For instance, a user could specify the Volume for a specific solution (e.g. a screen reader) to be set at the value of “Very loud” while the same preference “Volume” for another solution (e.g. a me-dia player) to be se at the value of “Medium”.

The entries of the User Profile that are depicted in red font and are containing ques-tion marks (?) are not present in the profile. We include them for presentation pur-poses. For instance the property (GP2,?,?) states that for solution S2 the preference GP2 is given no value (i.e. is not present in the User Profile).

In this scenario we assume further that only two solutions are available in the given session of the user, namely S1 and S2. Solution S1 has three customizable settings: s11, s12, s13 and Solution S2 has five customizable settings: s21, s22, s23, s24, s25.

In the user profile is stated that the Generic Preferences GP1, GP2 and GP3 are set to the values V1, V3 and V4 respectively, as concerning Solution S1 and the Generic Preference GP4 is set to the value V5 as concerning Solution S2.

The customizable settings of each Solution are presented in the table below:

S1

S11

S12

S13

S2

S21

S22

S23

S24

S25


  1. The user logs on the Cloud4All system
  2. The Solutions Reporter reports to the Matchmaker that on the given session of the user only two available Solutions exist: S1 and S2.
  3. The transformer retrieves from the Semantic Framework for Content and Solu-tions the customizable settings of Solutions S1 and S2 along with the generic property to which each setting corresponds as shown in Figure above. The ta-ble summarizes the transformation table derived from the Semantic Frame-work for Content and Solutions.
S11->GP1
S12->GP2
S13->GP3
S21->GP1
S22->GP2
S23->GP4
S24->GP5
S25->GP6

From the table above we infer that s11 and s21 correspond to the same Generic Prop-erty (GP1) as well as s12 and s22 (GP2).


  1. The matchmaker retrieves from the Preference Server the User’s Profile.
  2. A first matching is computed. This first matching is based only on the explic-itly stated user preferences that are present on the User Profile. The settings for which nothing is explicitly stated on the profile are passed to the match-making algorithms (either statistical or rule based algorithms) that will infer the values for these settings. In our example these settings comprise s22, s24 and s25. The dashed arrows in the Figure above are showing which settings are passed to the matchmaking algorithms while the black colored arrows shown the matching computed directly by the data provided by the transformer.
  3. The matchmaking algorithms infer the values for the settings that are not pre-sent as Generic Preferences in the user profile. For instance the matchmaking algorithms could infer that the value of s22 that corresponds to the Generic Preference GP2 is v3 since in the profile is present that the preference GP2 should be set to the value v3 for solution S1.
  4. The output of the matchmaker consists of the settings of solutions S1 and S2 with the correspondent values. The output of the matchmaker is depicted in the Figure above. The red colored settings and value pairs are those settings and values that are inferred by the matchmaker in the second matching proc-ess, while the black colored pairs are inferred directly from the user profile and the transformer provided data.

See Also

For examples of the Matchmaker exploiting the Semantic Framework for Content and Solutions see also