Specification of Cloud Semantic Infrastructure

From wiki.gpii
Jump to: navigation, search


The objective of activity A201.2, as stated in the Description of Work, is to provide a high-level modelling of context-related information of solutions, in order to support and provide input to the matchmaking tools of WP205. In this task we develop and deploy the technical infrastructure that will enable to store semantics – aware de-scriptions of the offered solutions. Moreover this activity deals with semantic classi-fication of available solutions.

Thus, in this activity we construct, using the OWL2 ontology language, a solution’s ontology, which semantically describes and classifies different aspects of content and solutions. In the constructed ontology, solutions are classified according their domain. Moreover, platform (i.e. operating system) and device characteristics are described and categorized in a semantic and hierarchical manner. Solution-, plat-form- and device specific settings (i.e. aspects that could be adapted) are also se-mantically and hierarchically categorized. Implementer and vendor specific informa-tion are included also in our draft ontology, in order to provide a more complete de-scription of solutions, and in order to provide a framework for other activities such as A201.3 “Metadata framework support for proper business rules for management of IPR and data or service ownership”. More over the semantic cloud infrastructure of solutions and content will provide a framework for WP202 “Generation & Main-tenance of Metadata for content and solutions.

The Cloud semantic infrastructure should be understood as an ontology containing, in a hierarchical manner, information about solutions. This information comprise domain description and classification of solutions, platforms and devices, customiza-ble settings of solutions/platforms/devices and information about context of use of a solution/platform/device.

The semantic framework aims to classify the solutions according to their domain. Furthermore classification of platforms and devices on which solutions run is also preformed according their domain. Solution-, platform- and device- specific settings are also classified in a hierarchical manner.

Semantics Framework for content and solutions

Abstract description of the ontology of solutions

The abstract representation of the solutions ontology is depicted in Figure 1.

Abstract schema of solutions framework.jpg

Figure 1: Abstract representation of the solutions ontology

The ontology consists of 5 subontologies:

  • “Solutions” subontology, which classifies solutions in a semantic manner ac-cording to their domain
  • “Platforms” subotnology, which classifies Platforms (i.e. resource execution platforms) in a hierarchical manner. A platform refers either to an operating system or to a web execution platform.
  • “Devices“ subontology, which classifies devices in a hierarchical manner.
  • “Settings“ subontology, which maintains and classifies in a hierarchical man-ner, solution – specific, platform – specific and device – specific settings. The term “settings” refers to all customizable settings of a solution, platform or device.
  • “Vendors” subontology, which maintains and classifies information about so-lutions’, platforms’ or devices’ vendors or implementers.

The different subontologies are connected via object properties representing rela-tions between subontologies. The properties are depicted in Figure 1 by black ar-rows. The main properties are:

  • “runsOnPlatform” property, which relates a solution to the corresponding platform on which it runs.
  • “runsOnDevice” property, which relates a solution to the corresponding de-vice on which it runs.
  • “isSolutionVendor” property, which relates a Vendor to a solution.
  • “isPlatformVendor” property, which relates a Vendor to a platform.
  • “isDeviceVendor” property, which relates a Vendor to a device.
  • “hasSolutionSpecificSetting”, which relates a Setting to the a solution
  • “hasPlatformSpecificSetting”, which relates a Setting to a platform.
  • “hasDeviceSpecificSetting”, which relates a Setting to a device.


Description of interaction of Semantics representation of content and solutions with the components of Cloud4All system


The Could semantic infrastructure consists of the Semantic Representations of Content and Solutions built in SP2 (A201.2) and the tools for generating and maintain metadata that will be implemented in WP202. The Cloud semantic infrastructure is communicating with other components of the Cloud4All system namely: the Profiles Ontology built in SP1 (A101.2), the Registry that stores generic (i.e. solution-, platform-, device- independent settings) built in SP1 and the matchmaker built in SP2 (WP204).

The semantic representation of content and solutions, as stated before, aims to provide semantic information about solutions and content. The Profiles Ontology aims to provide a semantic description of users Needs and Preferences (i.e. a semantic representation of user profiles). The Registry aims to register in a flat manner (i.e. without using any hierarchical structure) generic preferences. Finally the matchmaker aims to find matches between users Needs and Preferences and solution-, platform, device-specific settings in order to customize solutions/platforms/devices to the Needs and Preferences of the user.

The communication and interaction of the Cloud semantic infrastructure with the other components of Cloud4All system is depicted in Figure 2.

Cloud semantinc infrastructure and interaction with cloud4aa.jpg

Figure 2 The overall Cloud semantic infrastructure and the interaction with the Cloud4All system.

We will describe in short each component of the Coud4All system and the interaction with the cloud semantics framework.

The semantic representation of content and solutions (i.e. the solution’s and content’s ontology described in an abstract manner in the previous section) is located on the cloud.

The profile ontology as proposed by WP101[[File:file:///C:/Documents and Settings/tpapastergiou/My Documents/thomas/cloud4all/sp201/trasformer].doc#_ftn1|[1]]]  aims to provide a semantic framework for representing user profiles trying to capture user Needs and Preferences. A user profile is constructed from user preferences and in turn a preference contains the fowling aspects:

·        Preference – Value pairs corresponding to the Needs and Preferences of the user (e.g. “fontSize” = “12” is a preference denoting that the user prefers to use font size 12)

·        Conditions, which corresponds to a condition for the use of a preference (e.g. a condition could be that the use of “fontSize=12” would be applied from 9:00 p.m. to 17:00 p.m[[File:file:///C:/Documents and Settings/tpapastergiou/My Documents/thomas/cloud4all/sp201/trasformer].doc#_ftn2|[2]]]).

·        Probability, which denotes the confidence of a Preference. The confidence of a property is 1 if the property is set explicitly be the user and less that 1 if the preference is inferred by some other means (e.g. statistical tools).

As stated before, the solutions ontology maintains and represents solution-, platform- and device specific settings. A preference on the other hand, as described, is a generic setting. The term “generic setting” is referring to a setting that is solution-, platform and device independent. These generic settings are stored and maintained in the Registry[[File:file:///C:/Documents and Settings/tpapastergiou/My Documents/thomas/cloud4all/sp201/trasformer].doc#_ftn3|[3]]]., as depicted in Figure 2.

The Registry [[File:file:///C:/Documents and Settings/tpapastergiou/My Documents/thomas/cloud4all/sp201/trasformer].doc#_ftn4|[4]]]is a flat structure that contains solution-, platform- and device- independent settings. As in Figure 2 each user’s preference, contained in the profile, is related via an object property named “userPreferenceCorrespondsToRegistryItem”, to a Registry item. Furthermore, each registry item is related via the object property “registryItemCorrespondsToSetting” to a Setting of the solutions ontology. Thus each generic setting of the registry is related to a solution-, platform- or device-specific setting.

Furthermore the semantic representation of content and solutions represents in a hierarchical manner solution-, platform-, device- specific settings, along with other information on solutions. For each setting a data property is defined where a value, a default value and the range of the setting is defined.

The transformer aims to map generic settings stored in the registry of the Preference Server to solution-, platform and device- specific settings stored in the semantics framework for content and solutions and visa versa. If the transformer wants to map a generic setting to a specific setting it access the registry. As stated before there is a property connecting each registry item to the appropriate specific setting, named “registryItemCorrespondsToSetting”. Thus the mapping is performed. If the transformer wants to transform a specific setting to a generic setting the semantic framework for content and solutions are accessed, and the setting is mapped to the generic setting stored in the registry via the inverse property of “registryItemCorrespondsToSetting” as depicted in Figure 3 below. The red coloured arrows depict the interaction of the transformer, the “Preference Server” and the “Cloud Semantic Infrastructure”. The dashed arrows depict the mapping between the Registry Items and solution-specific settings stored in the semantic representation of content and solutions.


Figure 3 The transformer.

The matchmaker that will be developed in SP2 is a component of the could4all architecture that aims to match a user’s profile to the settings of the solutions available in a given device. As depicted in Figure 2 the matchmaker receives input form:

  •         The user profile ontology (Nr.1 in Figure 2). This information comprises as stated efore the user Needs and Preferences.
  •         The Local Solutions Reporter (Nr.2 in Figure 2) who reports which solutions are available on a local device.
  •         The solutions ontology (Nr.3 in Figure 2), containing solution-, platform- and device-specific settings. The information received form the solutions ontology corresponds to the available solutions reported by the Local Solutions Reporter.

Having all this information the matchmaker can infer a set of settings that should be customized according to the user’s preferences (i.e. to the user’s profile).

[[File:file:///C:/Documents and Settings/tpapastergiou/My Documents/thomas/cloud4all/sp201/trasformer].doc#_ftnref1|[1]]] See http://wiki.gpii.net/index.php/Ontologies

[[File:file:///C:/Documents and Settings/tpapastergiou/My Documents/thomas/cloud4all/sp201/trasformer].doc#_ftnref2|[2]]] See http://wiki.gpii.net/index.php/Scenario_with_Conditional_Items_in_a_User_Profile

[[File:file:///C:/Documents and Settings/tpapastergiou/My Documents/thomas/cloud4all/sp201/trasformer].doc#_ftnref3|[3]]] See http://wiki.gpii.net/index.php/Profile_Glossary

[[File:file:///C:/Documents and Settings/tpapastergiou/My Documents/thomas/cloud4all/sp201/trasformer].doc#_ftnref4|[4]]] See http://wiki.gpii.net/index.php/Profile_Glossary and http://wiki.gpii.net/index.php/Discussion_on_Profile_Structure

Usage Scenarios

In this section we describe 4 usage cases of the semantic framework of content and solutions. The first usage case will be from the point of view of a vendor who wants to incorporate a new solution in to the infrastructure and the following 3 will be from the view point of a cloud4all user, displaying the use of the matchmaker in exploiting the semantic infrastructure of content and solutions.

Usage Scenario 1 – Updating the ontology

Vendor usage scenario.jpg

Figure 3. Usage scenario 1: A vendor interacts with the Semantics Framework for Content and Solutions to incorporate a new solution into the ontology.

A vendor wants to incorporate a new solution into the proposed infrastructure. The vendor should be able

  • to browse through the ontology,
  • to see the classes and the instances of the classes,
  • to see the properties of a class and to provide input to the proper properties,
  • to incorporate the new solution into the infrastructure,
  • to propose a new class to be incorporated into the infrastructure, if none of the existing classes meets his criteria,
  • to propose a new hierarchy of classes to be incorporated into the infrastruc-ture, if none of the existing hierarchies meets his criteria.

Usage Scenario 2 – Semantic Matching

The semantic structure of the solutions ontology can be exploited in order to per-form a “semantic” matching. Since the “Settings” subontology is structured in a hier-archical manner, if no exact match can be found for a given preference in a user’s profile, the matchmaker could propose other settings to be adapted according the semantic structure of the “Setings” subontology. An example of the hierarchical de-ployment of “settings” subontology is depicted in Figure 5. All the communication in the cloud4all system is done through the Flow Manager as stated in the so far sys-tem architecture proposal that can be found on Annex A. The overall scenario is de-picted is Figure 4.

Usage scenario 2 semantinc matchmaking.jpg

Figure 4. Usage Scenario 2: Semantinc Matchmaking

The user signs in (Step 1), on the cloud4all system through a public computer. The only available (i.e. incorporated in the cloud4all project) solution on this device is App1. The Local Solutions Reporter (Step 2) reports to the matchmaker that the only available application on this user’s session is App1. The matchmaker receives infor-mation from the solutions and content infrastructure (Step 3). The information re-ceived is that the customizable settings of App1 are the “Mangifier”, “Volume” and “Text Color” settings.

As we stated before, the “Settings” subontology classifies in a hierarchical manner the all the solution-, platform- and device- specific settings. Thus a part of this subontology is depicted in Figure 5.


Figure 5. Hierarchical structure of "Settings" subontology

The “Magnifier” setting is an instance of “MagnifierSettinfs” class, “TextColor” is as instance of “TextSettings” class and “Volume” is an instance of “AudioSettings” class as depicted in Figure 5.

Afterwards, the matchmaker receives information from the profile ontology (Step 4). Since a link from the user’s preference to the generic preferences stored in the Reg-istry and a link from the Registry to the Settings’ subontology, containing solution-specific settings exists, the semantic class to which a preference corresponds is ex-plicitly defined. Thus this information is sent also to the matchmaker (Step 4.2) along with the preferences of the user. In this scenario the information that the match-maker receives in steps 4 and 4.2 is:

  • The user’s preference (TextSize=20)
  • TextSize corresponds to the “TextSizeSettings” class of the “settings” subon-tology.

The matchmaker combines all this information (User Preferences, available solu-tions, solution-specific settings) and doesn’t find an exact match for the “TextSize” preference of the user, since there is no such setting in the customizable settings of App1. However, the matchmaker can find not exact matchings exploiting the seman-tic infrastructure of the “Settings” subontology. The matchmaker should infer that “TextColor” is a not exact match since “Text Color” belongs to the parent class of “textSizeSettings” meaning that “Text Color” is semantically a more generic setting than “TextSize” setting. Furthermore the matchmaker should infer that “Magnifier” is also a not exact match since it is an instance of “MagnifierSettings” class which is sibling to the “TextSettings” class, implying that “Magnifier” is also related to the “TextSize” setting. In the same way the matchmaker should infer that there is not a match between “textSize” and “Volume” since their semantic distance is rather big.

Usage Scenario 3 – Semantic selection of solutions

Another example of exploiting the semantic infrastructure proposed here is the semantic selection of solutions. Since the solutions are semantically categorized, if two available solutions belong to the same or to related semantic classes, the matchmaker can propose the solution that fulfils more User Preferences.

Usage scenario 3 semantinc selection of solutions.jpg

Figure 6. Usage Scenario 3: Semantic selection of solutions

For instance, let assume a user, who signs in on the cloud4all system on a public desktop computer (Step 1). There are three available solutions on this computer: App1, App2 and App3 that are reported to the matchmaker by the Local Solutions Reporter (Step 2). Let us assume that App1 and App2 belong to the same semantic class according to their domain (e.g. App1 and App2 are two screen magnifier solutions). If, according to the user’s preferences (Step 3 and Step 4), on App1 there are found 3 matches and on App2 there are found 5 matches, then the matchmaker can infer that App2 fulfils better the user’s preferences and can propose App2 against App1 to the user.

Usage Scenario 4 – Installing no available solutions

Another example of exploiting the semantic infrastructure for content and solutions proposed in this document, is installing no available solutions on a given device, ac-cording to the user’s preferences.

As the matchmaker is communicating with the “Profiles” and “Solutions” ontologies as depicted in Figure 7, he can infer which solutions, not available in a given device, are relevant to user’s preferences and propose these solutions to be installed by the user.

Since all settings from all cloud4all solutions are available on the “Solutions” ontol-ogy the matchmaker can match the user’s preferences to all the solutions of the on-tology and determine which solutions best fit to the preferences of the user. Com-bining then the information provided by the local solutions reporter and the “over-all” matchmaking process, the matchmaker can propose to the user new, none yet installed solutions. We can state that a solution best fits to the preferences of a user if an amount of matchings has been found. Thus a solution is more suitable for a user as much matchings between User’s Preferences and Solutions’ Settings are found.

Usage scenario 4 installing none available solutions.jpg

Figure 7. Usage Scenario 4: Installing no available solutions.

For instance, a User signs in, on the Cloud4All system (Step1) by a public computer. On this computer three solutions: App1, App2, App3 are installed. The Local Solu-tions Reporter (Step 2) reports to the matchmaker the available on the given device cloud4all solutions (i.e. App1, App2, App3). The matchmaker receives all solutions and settings from all available cloud4all solutions (Step 3) and the user Profile from profiles ontology (Step 4). Thus, combining this aggregate information the Match-maker should infer the no yet installed, on the given device, solutions. The Match-maker returns to the user a list (Step 5) of solutions that the user could install in the given device.

See also