Solutions and Content ontology

From wiki.gpii
Jump to: navigation, search

Intoduction

In this page we give a more precise description of the solutions and content ontology. As stated in Specification of Cloud Semantic Infrastructure the Cloud Semantic Infrastructure should be understood as an ontology comprising information about Vendors, Platforms, Solutions and Settings. The ontology represents and maintains this information in a semantic manner. The proposed ontology is built using the OWL2 Web Ontology Languageand Protégé 4.1 ontology editor. The consistency of the ontology is checked using HermiT1.3.6 ontology reasoner.

Sources of Information for the proposed ontology

In order to provide example data to our draft ontology we employed information from 5 solutions: Microsoft Surface Media:MS_Surface_Interaction_Variables-Needs_Template_v1.xlsx , Serotek SAToGo Media:Serotek_SAToGo_v1.xlsx, Easy1 Communicator Media:Easy1_Communicator_v1.xlsx, WebAnywhere Media:WebAnywhere_v1.xlsx, Smart House Media:SmartHouse_InteractionVariables-Needs_v1.xlsx‎.

Semantic Classification of Solutions

ISO 9999 Class

Refinements of ISO 9999 Class

221821 Decoders for videotext and text television

Real time captioning system

 

Delayed captioning system

223612 Alternate input devices

Alternative input device for computer

 

Voice recognition system

 

Eyegaze system

223618 Input software

On screen keyboard

 

Mouse control software

 

Word prediction software

 

Software for adjusting input devices response

223912 Special output software

Magnifying software

 

Screen reader

 

Software for adjusting color combination and text size

 

Software to modify the pointer appearance


The semantic classification of solutions is based on ISO standard 9999 , and more specifically in class 22 “assistive products for communication and information” [1]and class 24 “assistive products for handling objects and devices” [2]of ISO 9999 . We don’t fully adopt the ISO 9999 classification, as we propose an extendible semantic repre-sentation of solutions (i.e. if a vendor or implementer proposes a new solution to be incorporated into the coud4all infrastructure, and none of the existing category classes sufficiently describes the new solution, new classes or hierarchies can be added in the ontology).

In our first draft we deploy part of ISO 9999 hierarchy considering also class refine-ments as stated in the “Survey of accessibility Solutions” report of A201.1. We present in short only the refinements of ISO 9999 classes.

Description of Solutions Ontology

In this section will describe in short the constructed ontology. In Figure 1 below, a part of the ontology is depicted, showing the top three semantic levels.

Solutions otology overview.jpg

Figure 1: Solution Ontology Overview

The ontology consists of 6 subontologies: “Platforms”, “Devices”, “Solutions”, “Set-tings”, “Vendors” and “Environment”. Each of these subontologies describes in a semantic manner different aspects of Solutions. (e.g. “Solutions” is a semantic repre-sentation of Solutions according their domain; “Settings” is a semantic representa-tion of all solution-, platform- or device- specific aspects that can be adapted etc.). In the next chapters we will describe each one of these subontologies.

The “Solutions” subontology

The “Solutions” subontology aims to describe in a semantic manner the solutions available, by categorize them according to their functionalities. Thus, the “Solutions” subotnology classifies the available solutions and applications to semantic classes. For instance, the first semantic level of “Solutions” subontology classifies the solu-tions in 2 generic classes “Assistive Products for Handling Objects and Devices” and “Assistive Products for Communication and Information”. These classes are refined as we are going deeper in the ontology, in order to classify in more detail the avail-able solutions. When a new solution needs to be incorporated into the ontology a new class can be created, if none of the existing classes meet the classification crite-ria posed by the vendor/implementer. This can be a generic class or a class that re-fines some existing class. Furthermore a whole hierarchy can be added in order to classify a new application/solution.

Solutions Subontology.jpg

Figure 2: Solutions Subontology

As we stated in the previous, the “Solutions” subontology is based on ISO 9999 allowing yet classes refinements where needed. Thus in our ontology, if a class is a original ISO 9999 class, then the name of that class is followed by the appropriate ISO’s class number (e.g. “PersonalEnvironmentalControlSoftware” is followed by “_24_13_06” denoting the 24.13.06 class in ISO 9999 standard. If a name is not followed by an ISO class number then this name is a refinement of an ISO Class (e.g. “PapperDocumentsReadingSystemOCR” is a refinement of 22.30.21 class of ISO 9999 standard, as depicted in Figure 2).

A solution is an instance of a class named after the solution’s name and belonging to the appropriate semantic category. For instance “WebAnywhere::Solution” is an in-stance of the Class “WebAnywhere” which is a subclass of “DigitalDocuments-Reader” which is a subclass of “ReadingMaterialsWithAudiableOutput_22_30_03” (see Figure 4).

Each solution’s instance participates in the following object properties:

  • hasSolutionVendor
  • runsOnDevice
  • runsOnPlatform
  • hasSolutionSpecificSetting

The “hasSolutionVendor” property relates a solution’s instance to an instance repre-senting the implementer or the vendor of the solution and belonging to “Vendor” subontology. For instance, as depicted in Figure 4, “WebAnywhere” solution is con-nected via the purple dashed arrow to “WebInSight”, which is an instance of “Ven-dors” subontology, representing the vendor of “webAnywhere”. The “runsOnDevice” property relates a solution’s instance to the appropriate devices on which it runs. The “runsOnDevice” property can relate a solution to multiple de-vices, if a solution is supported by more the one devices.

The “runsOnPlatform” property relates a solution to the appropriate platform on which it runs. For instance “WebAnywhere” is a service running on the cloud and is supported by any platform that supports a web browser with JavaScript support. Thus, in our example as depicted in Figure 4, “WebAnywhere::Solution” is related to “MozzillaFirfoxWithJava”. The relation is shown in Figure 4 by a gold colored dashed arrow.

The “hasSolutionSpecificSetting” property relates a solution to the settings that can be adapted. In our example, “WebAnywhere” has only one setting named “locale” as we can see in Table 1. Thus “WebAnywhere::solution” is related to “WebAny-where::locale” by a light brown dashed arrow, as depicted in Figure 4.

Solotuions ontology example.jpg

Figure 3: Restrictions on “WebAnywhere” class.

SolutionsOverviewNew.jpg

Figure 4:The Vendors, Platforms, Settings and Solutions subontologies: light brown dashed arrows represent the adaptingSolution properties, purple dashed arrow represent the isSolu-tionVendorOf properties, gold colored dashed arrows represent the runsOnPlatform property, blue filled arrows represent the hasIdividual property and purple filled arrows represent the has-Subclass Property.

For each solution class some restrictions are defined as seen in Figure 3. Restrictions are defined on properties “runsOnDevice”, “hasVendors” and “runsOnPlatform”. In our example as seen in Figure 3, for “WebAnywhere” class four restrictions are de-fined: “hasVendor some DeviceVendor”, “runsOnPlatform some BrowserWhithJava”, “runsOnPlatform only BrowserWhithJava” and “runsOnDevice some Devices”.

When a new solution needs to be incorporated into the ontology, “hasSolutionVen-dor”, “runsOnDevice”, “runsOnPlatform” and “hasSolutionSpecificSetting” proper-ties has to be specified according the vendor’s or the implementer’s specification.

The “Platform” subontology

The “Platform” subontology represents in a hierarchical way the platforms on witch solutions run. The term platform refers to the resource execution platform of the solution. As mentioned earlier a solution can be either an application or a cloud-based service. Thus a platform can refer either to a specific operating system on which an application runs, or to a web execution platform for web based applica-tions and web services.

The classes of the “Platform” subontology are semantic representations of specific platforms. Thus each class can contain multiple instances. For example “Browser-WithJava” refers to browsers with java script support. Thus, “MozillaFirfoxWithJava” is an instance of “BrowserWithJava” class. This class can also contain other instances as “IEWithJava” or “OperaWithJava” etc.

Figure 5 depicts a not exhaustive representation of “platforms” subontology.

PlatformsSubontology.jpg

Figure 5: The Platforms subontology

As we will analyze in more detail below, an object property named “platform-Supports” is defined as depicted in Figure 6. “platformSupports” has as domain the “Platform” class and as rage the “Solutions” class. This property is the inverse prop-erty of “runsOnPlatform” property and has not to be explicitly defined for each plat-form instance as it can be inferred by a reasoner.

Each Platform instance is related to a Platform Vendor via the “hasPlatformVendor” property as depicted in Figure 6.

As a platform can be adapted in order to fulfill a users Needs and Preferences each platform has platform specific settings (i.e. aspects of a platform generally or of a specific Operating System specially, that can be adapted). Thus each platform in-stance is related to the “Settings” class via the “hasPlatformSpecificSettings” property.

Data properties.jpg

Figure 6 : Object Properties

If a new platform needs to be incorporated into the ontology one has to specify the semantic class to which the platform belongs along with the “hasPlatformVendor” and “hasPlatformSpecificSetting” properties.

The “Devices” subontology

The “device” subontology represents in a hierarchical way the devices on witch ap-plications run, as depicted in figure 7.

DevicesSubontology.jpg

Figure 7 : "Devices" subontology


Devices are classified at the first semantic level either as “FixedDevices” or as “Mo-bileDevices”. Mobile devices are classified either as “PDADevices” or as “Mobile-PhoneDevices” and so on. The entire hierarchy is depicted in Figure 7.

A specific device belongs to a semantic class. For example, “DTV::ADTVDevice” is an example Digital TV device.

Each device has some device specific settings that can be adapted according a user’s profile. Thus, a device is related to the appropriate settings via the “hasDe-viceSpecificSettig” object property. Furthermore a device is related also to a specific device vendor via the “hasDeviceVendor” property. These properties are depicted in Figure 8 as defined in Protégé.

Furthermore, “isSupportingDeviceOf” property is the inverse property of the “runsOnDevice” property, relating a “Device” to a “Solution”. This property has not to be specified explicitly since it can be inferred by a reasoner.

ObjectPropertiesRangeDomain.jpg

Figure 8: Vendor specific object properties

When a new device has to be incorporated in the ontology, one has to specify the semantic class in which the device belongs and has to provide also the “hasDe-viceVendor” and “hasDeviceSpecificSetting” properties.

The “Settings” subontology

As stated previously the term “setting” refers to each aspect of a solution, platform or device, that can be adapted according a user’s Needs and Preferences. Thus the “Settings” subontology tries to capture in a semantic manner all possible solution specific, platform specific and device specific settings. The semantic classes in which settings are classified are depicted in Figure 9. For instance the first semantic representation level of the subontology, classifies set-tings in 4 semantic classes: “AudioSettings”, “UserPersonalInfoSettings”, “Tacticle-Settings” and “VisualSettings”. Each of these classes are further refined to subclasses in order to refine classification, as can be seen in Figure 9.

SettingsSubontology1.jpg

Figure 9: "Settings" subontology

Each setting is an individual of some class of “Settings” subontology. For example, Microsoft Surface is represented by the “MSSurface” instance as depicted in Figure 10. As mentioned earlier this instance is part of the “Solutions” subontology. Mi-cosoft Surface has 4 settings: “MsSurface::colors”, “MsSurface::textSize”, “MsSur-facemagnifier” and “MsSurface::Sound”. Each of these settings is an instance of a “Settings” class (e.g. “MsSurface::colors” is an instance of “ColorSettings” class).

Each setting is related to a solution, platform or device via “adaptingSolution”, “adaptiongPlatform” or “adaptingDevice” property respectively. For instance “MsSurface::colors”, “MsSurface::textSize”, “MsSurfacemagnifier” and “MsSur-face::Sound” are related to MSSurface::Solution via the “adaptingSolution” property. In Figure 10 these relations are depicted by a light brown dashed arrow.

Settings solutions example.jpg

Figure 10: Microsoft Surface’s settings.


Figure 11 depicts as an example the Microsoft Surface’s “MsSurface::textSize” set-ting, along with the “adaptingSolution” object property which relates “MsSur-face::textSize” to the “MSSurface::Solution”. A reverse property called “hasSolution-SpecificSetting” is also defined. “hasSolutionSpecificSetting” relates a solution to a setting. This property has not to be explicitly defined since it can be easily inferred by a reasoner. Figure 12 shows the inferred “hasSolutionSpecificSettings” property that relates the “MSSurface::Solution” to their solution specific settings.

Further more each individual setting has a solution-, platform- or device specific data property. For instance as depicted in figure 12 the “MsSurface::textSize” setting has a data property called “hasMSSurfaceTextSizeSetting” with a default value of 14. Each of these data properties have a range and a default value proposed by the ven-dor or the implementer. The range of “hasMSSurfaceTextSizeSetting” is depicted in Figure 13.

MSSUrfaceDataproperitesExample.jpg

Figure 11: "MsSurface::textSize” individual along with its data and object Properties.

MSSurfaceInferedPropertiesExample.jpg

Figure 12: The inferred “hasSolutionSpecificSettings”.

MSSUrfaceDatapropertiesExample2.jpg

Figure 13: “hasMSSurfaceTextSizeSetting”

Data Properties

In this section we will discuss the Data Properties defined in the proposed ontology. Figure 14 is a snapshot from Protégé depicting all data properties defined within the ontology.

DataPropertiesOverview.jpg

Figure 14: Data Properties defined in the ontology.


As depicted in Figure for each solution we define a general data property (e.g. for EasyOneCommunicator we define a general property named “hasEasyOneCommuni-catiorSettings which refers to all settings of EasyOneCommunicator solution). Fur-thermore each generic data property is refined by defining for each specific setting a different property (e.g. hasEasyCommunicatorAssistan’sPasswordSetting is a data property that refers to the “Assistant’sPasswordSetting” of EasyOneCommunicator solution).

Each property has a range which is defined by the vendor of the solution. The range of a property defines which values a setting can obtain (i.e. what kind of adaptations could be done).

For instance, as depicted in Figure 15, Microsoft Surface’s Color setting can only ob-tain three values “B/W”, “High Contrast” and “Normal. Thus if an adaptation is to be made on setting “color”, that will be restricted to one of these three values. Another example is shown in Figure 16. The range of Microsoft Surface’s TextSize setting is “14”, “18” or “22”.

HasMSSurfaceColorsSettingsProperty.jpg

Figure 15:“hasMSSurfaceColorSetting”

HasMSSurfaceTextSizeSetting.jpg

Figure 16: “hasMSSurfaceTextSizeSetting”

Object Properties

In this section we will discuss in short the object properties defined in the proposed ontology. We mentioned several aspects of data properties as we analyze subontologies reviously. Here we discuss these aspects in more detail.

“adapting” and “hasSetting” object properties

The “adapting” property relates a setting to a Solution, Platform or Device whether the setting is referred to a Solution, Platform or Device respectively. “adapting” property has three subproperties:

ObjectPropertiesOverView.jpg

Figure 17: Object Properties of the proposed Ontology


  • “adaptingSolution” that relates a solution specific setting to a solution.
  • “adaptingPlatform” that relates a platform specific setting to a platform
  • “adapringDevice” that relates a device specific setting to a device.

For instance, as depicted in Figure 17 the “adaptingSolution” property has as Domain the “Settings” class and as Range the “Solutions” class.

The “hasSetting” property is the inverse property of the “adapting” property. In the same manner the “hasSolutionSpecificSettings”, “hasPlatformSpecificSettings” and “hasDeviceSpecificSettings” are the inverse properties of “adaptingSolution”, “adaptingPlatform” and “adaptingDevice” properties respectively.

“hasVendor” and “isVendorOf” object properties

The “hasVendor” property relates a device belonging to the “Devices” class to a de-vice vendor or implementer belonging to the “DeviceVendors” class.

The “hasVendor” property has three subproperties:

  • “hasSolutionVendor” that relates a solution to a solution vendor or imple-menter (i.e. has Domain the “Solutions” class and Range “ the “DeviceVen-dors” class).
  • “hasPlatformVendor” that relates a platform to a platform vendor or imple-menter (i.e. has Domain the “Platforms” class and Range the “PlatformVen-dors” class).
  • “hasDeviceVendor” that relates a device to a device vendor (i.e. has Domain the “Devices” class and Range the “DeviceVendors” class).

The “isVendorOf” property is the inverse property of “hasVendor”. Furthermore “is-SolutionVendor”, “isPlatformVendor” and “isDeviceVendor” are the inverse proper-ties of “hasSolutionVendor”, “hasPlatformVendor” and “hasDeviceVendor” repsec-tively.

“runsOn” and “supports” object properties

The “runsOn” property relates a solution belonging to the “Solutions” class to a device or to a platform belonging either to the “Platforms” or “Devices” class respectively.

The “runsOnDevice” property has two subclasses:

  • “runsOnDevice” that relates a solution to a device (i.e. has as Domain the “Solutions” class and as a Range the “Devices” class.
  • “runsOnPlatform” that relates a solution to a platform (i.e. has as Domain the “Solutions” class and as Range the “Platforms” class.

The “supports” property is the inverse property of “runsOn”. Furthermore “sup-portsDevice” and “supportsPlatform” are the inverse properties of “runsOnDevice” and “runsOnPlatform” respectively.