- 1 Purpose
- 2 Rationale
- 3 Basics on Ontologies
- 4 Assumption/Approaches for Developing the User Profile Ontology
- 5 Input considered for Developing the User Profile Ontology
- 6 User Profile Ontology Conceptualization
- 7 ToDos
- 8 Development Tools
- 9 Download
This page aims to track and discuss the work being done to study and develop ontologies that are useful for making the different descriptors for access features/settings for devices, platforms, operating systems and applications. The activities/content described in this page are in line with the ideas elaborated in the "Needs & Preferences" Working Group (see: http://wiki.fluidproject.org/display/ISO24751/AccessForAll+Working+Group). In the scope of this initiative, among others, a REGISTRY of common terms is being developed for expressing user preferences and, consequently, user profiles (more details are available in the User Preferences page).
One of the main ontology engineering activities that is currently being conducted in Cloud4All involves the definition of a User Profile Ontology. The User Profile Ontology aims to introduce a semantic model capable of:
(a) capturing the domain knowledge that is relevant with user needs and preferences in the context of user interaction, taking into account standardization efforts in the field;
(b) offering the required expressiveness for describing user profiles based on personal needs and preferences across applications, platforms and devices, and various conditions that these needs and preferences shall be applicable for (e.g., considering the user state, the user activity, the physical environment, etc.);
(c) providing the basis for developing tools to facilitate effective user profile initialization and management, and
(d) providing thefoundation for developing semantics-based matchmaking approaches among user needs and preferences and applications/services based on semantic rules and automatic reasoning techniques (cf. Specification of Cloud Semantic Infrastructure).
Basics on Ontologies
The adoption of an ontology-based approach was due to the fact that ontologies constitute a widely accepted technology endeavour for knowledge representation and sharing. Ontologies are defined as explicit, formal specifications of shared conceptualizations for a specific context (Gruber, 1995), and are considered as the backbone of the Semantic Web and the key for its evolution.
More specifically, ontologies are machine-readable representations (formal) which explicitly define concepts, relations, attributes and constraints (explicit specification) that are accepted by a group of people/systems (shared) encapsulated in an abstract model (conceptualization) for a particular domain/scope (context). The main benefits of ontologies are the sharing of a common understanding of the entities in a given domain and enabling reuse of data and information so as to avoid reengineering efforts and introduce standards to allow interoperability (at both the syntactic and semantic level), while also enabling automatic reasoning.
Assumption/Approaches for Developing the User Profile Ontology
- Foundational for developing the User Profile Ontology is the standardization efforts of the "Needs & Preferences" Working Group (see: http://wiki.fluidproject.org/display/ISO24751/AccessForAll+Working+Group). In this regard, the User Profile Ontology has the REGISTRY as its core part. More specifically, the REGISTRY content is introduced in the User Profile Ontology (although remaining intact), in order to link various user interaction properties with actual user needs and preferences.
- Various conceptual views of the REGISTRY may be applied, in order to organize/annotate its contents. We currently elaborate towards this direction in the User Profile Ontology via the introduction of concepts like InteractionChannels (e.g. VisualInputInteractionChannel) and UserInterfaceComponents (e.g. a Window).
- The User Profile Ontology is encoded in the Web Ontology Language (OWL - http://www.w3.org/TR/owl-features/), since OWL constitutes a widely adopted standard language for ontology representation, offering rich representation contracts.
- The ontology development will be based on an iterative and incremental approach, keeping it simple and (hopefully) usable for a variety of applications.
Input considered for Developing the User Profile Ontology
- User needs and preferences gathered from surveys (i.e. literature surveys, interviews with users and experts, etc.) conducted in Cloud4all.
- The Registry of common terms to express user needs and preferences (cf. User_Preferences#The_Needs_and_Preferences_REGISTRY).
- User profile related standards, e.g. ISO/IEC 24751, ETSI ES 202 746, etc.
- Scenarios of use considered in Cloud4all.
User Profile Ontology Conceptualization
An overall diagram of the User Profile Ontology is depicted in the following Figure (object properties linking classes are depicted through the connected arrows, while example subclasses are highlighted via the "is-a" property and in different colour; for simplicity, datatype properties are not depicted in the Figure).
A rough description of the ontology is provided in the following by referring to its major concepts:
- RegistryProperty: Instances of this class correspond to common terms defined in the REGISTRY (attributes comprising the structure of the REGISTRY are highlighted in red in the Figure below, which illustrates the definition of the RegistryProperty class - cf. Discussion on Profile Structure Point1).
The Figure below presents the list of individuals defined for this class (as an example, the AbsolutePointing individual has been selected and its definition is illustrated).
- UserPreference: A class aiming to express specific UserPreferences (see Figure below for the class definition, and also see Profile Glossary). Instances of this class are linked with instances of the Condition class, via the appliesForCondition object property.
- UserProfile: A User Profile defined as a group of specific UserPreference instances (see Figure below for an example UserProfile instance, which comprises of a set of UserPreference instances, like ActivateScreenReader, ActivateScreenRecognition, etc.).
- Condition: A Condition according to which a specific UserPreference is applicable. Conditions are (currently) categorized into three subclasses (see Figure below for the class heirarchy):
- UserCondition, with further subclasses BehavioralCognitiveCondition, UserActivityCondition, UserEquipementCondition, UserFunctionalCondition;*SystemCondition, with further subclasses ApplicationRelatedCondition, AssistiveSoftwareCondition, DeviceRelatedCondition, OperatingSystemRelatedCondition and UserTaskRelatedCondition;*ExternalCondition, with further subclasses EnvironmetalCondition, SpatialCondition and TimeCondition.
- User: A User of the GPII/Cloud4All platform for whom a UserProfile shall be defined.
The semantic associations between the Core-concepts are depicted below, and correspond to the following predicates expressed in natural language:
A User has (multiple) User Profiles
A User Profile consists of (multiple) User Preferences
A User Preference applies for specific (multiple) Conditions
A User Preference corresponds to a specific property contained in the Registry.
These comprise of the following classes:
- Application: The Application that the UserProfile shall be applied to, e.g. a Text Editor, an Email Client, etc.
- AssistiveSoftware: This class is devoted to Assistive Technologies Software, e.g. screen readers, screen magnifiers, etc.
- Device: The Device that the UserProfile shall be applied to, e.g. a Smartphone, a DTV, a Desktop Computer, etc.
- ExternalFactor: Various external factors that may be considered for defining conditions for user preferences and user characteristics that may imply user preferences (i.e. Cultural, Economic, Environmental, Location, Social, Temporal, etc.)
- OperatingSystem: The Operating System that the User Profile shall be applied to e.g. Windows, Linux, etc.
- UserActivity: This class defines the "activity context" of the user which is implicitly linked with the way he/she is able to interact with ICT systems. Typical examples are "Walking", "Driving", "Working", etc.
- UserEquipment: This class corresponds to External equipment (independent of the device) that the user is using which may affect the interaction, e.g. glasses, gloves, keyguard, etc.
- UserTask: A concrete Application usage scenario that provides specific output (e.g. printout, calculation, alert, etc.).
The semantic association between the various condition-related concepts and the Condition class per se corresponds to the following predicate expressed in natural language:
A (Typeof)Condition isApplicableFor a ConditionalFactor, e.g. DeviceRelatedConditionInstance-1 isApplicableForDevice for a SmartphoneInstance-3
- InteractionChannel: Involves the various user interaction channels that are available through ICT. Two subclasses are defined, i.e. InputInteractionChannel and OutputInteractionChannel, along with consecutive subclasses (e.g. AuditoryInputInteractionChannel, HapticOutputInteractionChannel, etc.). This class aims to associate instances of the RegistryProperty class and formulate groups of relevant UserPreference instances.
- IOMedium: An Input/Output (external/peripheral) Medium that may be attached to a Device (e.g. an external keyboard attached to a smartphone).
- UserAction: This class defines high-level user actions, such as "Write", "Read", "Point", "Click", etc. User Actions take place through an InteractionChannel and require Conditions. The following subclasses are defined: AuditoryUserAction, CognitiveUserAction, HapticUserAction, VisualUserAction.
- UserInterface: A UserInterface instance that is offered through an Application, an AssistiveSoftware or an I/O Medium.
- UserInterfaceComponent: Involves the various User Interface components that are configurable, e.g. Layout, Font, Window, etc., per Application/OperatingSystem. This class aims to associate instances of the RegistryProperty class and formulate groups of relevant UserPreference instances.
- UserTask: A concrete Application usage scenario that provides specific output (e.g. printout, calculation, alert, etc.).
The Figure below illustrates the relation between the above concepts. In essence, a UserTask requires a UserInterface to be performed. The UserInterface makes use of a UserInterfaceComponent. A UserInterfaceComponent may require to be used by a UserAction that is enabled by an InteractionChannel. The UserInterface belongs to an IOMedium which may be attached or embedded to a Device.
Individuals defined for the UserInterfaceComponent class are depicted the following Figure ("Navigation" is selected; note its linkage with RegistryProperty individuals).
These are currently expressed via the following classes:
- InteractionRequirement: This class defines interaction requirements (e.g. increased size of icons) that are generated for a user from his/her Characteristics (e.g. low vision) and may in turn imply specific User Preferences (e.g. icon size preference). This is an important part for defining/building User Profiles.
- UserCharacteristics: This class corresponds to user characteristics that generate interaction requirements. At the current stage, three subclasses have been defined, namely: CulturalUserCharacteristic, e.g. mother language; FunctionalUserCharacteristic, e.g. low vision; SocioEconomicCharacteristic, e.g. use of open source software.
- PropertyInStandard: Corresponds to a set of UserPreferences that are defined/expressed in relevant Standards.
- Standards: Refers to Standards that are relevant to user profiling, e.g. ISO/IEC 27451.
The Figure below illustrates the association among the concepts RegistryProperty, PropertyInStandard and Standard (red blocks correspond to instances of classes):
- Add property restrictions where applicable, in the next iteration.
- Discuss additional conceptual groupings.
- Further test the expressiveness of the ontology via various user profile test-cases and scenarios (e.g. via user needs & preferences gathered via literature surveys and interview that are being conducted by the Cloud4All partners).
- Define simple queries to illustrate further the potential of the defined semantic model.
- The User Profile Ontology is being developed in Protégé (http://protege.stanford.edu/), v. 3.4.7.
- Visualizations are provided via the OntoViz plugin (http://protegewiki.stanford.edu/wiki/OntoViz).
- Consistency checking of the ontology is perfomed via Pellet 1.5.2 (built-in with Protégé).
Registry and Ontology Tools
As part of the technical support for the Cloud4all project and the work on NP profiles and ontologies we are working on 2 different tools:
- a REGISTRY VIEWER tool - that will make it easy to view the REGISTRY and compare it against any company's/product's user settings. Here are the currently planned features.
- an ONTOLOGY VIEWER tool - that will make it easy to view the REGISTRY entries using any ontology
Please go to this page and read about them and suggest any improvements to make them work better for you Registry Tools
In this section, consecutive versions of the User Profile Ontology will be made available.