A reasoning step is needed to infer from available data information. As presented in the previous chapter all relevant recommendations to the user are based upon a predefined setting. This section deals with the syntax used for the realisation and presents the complete reasoning approach. The Jena framework used here includes a general purpose rule-based reasoner (henceforth referred to as generic rule reasoner) which is able to apply rules to the current Ontologystate with the output of a new state.
3.4.1 Rules
Rule :=bare-rule .
or [bare-rule]
or [ ruleName : bare-rule]
bare-rule :=term, ... term->hterm, ... hterm // forward rule orbhterm <-term, ... term // backward rule
hterm :=term
or [bare-rule]
term := (node,node,node) // triple pattern
or (node,node,functor) // extended triple pattern or builtin(node, ... node) // invoke procedural primitive
bhterm := (node,node,node) // triple pattern
functor := functorName(node, ... node) // structured literal node := uri-ref // e.g. http://foo.com/eg
or prefix:localname // e.g. rdf:type
Table 3.14: Informal description of the simplified text rule syntax of rea-soner (Source: The Apache Software Foundation [2013])
Rules are used to infer from one state and setting to new states by application of rule sets. For instance all User Modelsare classified into impairment groups using predefined rules. These rules classify each instance ofUser Modelsby data values as presented in tables3.5-3.8into different impairment groups.
Table 3.14 presents an informal description of the rule syntax of the reasoning1. Regarding the purpose of this thesis, to get new information from the initial Ontol-ogymodel including User Models, environments etc. forward chain logic rules were implemented. These rules represent different parametrical thresholds to add a new membership for single Ontology instances to each model, if the parameters match the rule set.
For instance the rule:
Rule Description
(?x rdf:type Vicon:UserModel), For each instance of the class Vicon:UserModel
(?x Vicon:UserModelArthritis ?artritis), Creation of the variable ?artritis equal(?arthritis,”Y”) Check if the value of the parameter is
“Y”
->(?x rdf:type Vicon:UsersWithArthritis). Resulting inference, here a new membership is added
infers all User Model instances, which have a “Y” as value of the “UserModelArtri-tis” parameter as members of the class “Vicon:UsersWithArtri“UserModelArtri-tis”. This scheme of rules is used for all models (for more detailed information about the RETE algorithm itself, seeForgy[1982] andShrobe[1993]).
The complete reasoning of the framework can be seen as a sequence ofOntology model inferences with the result of new classes.
3.4.2 Reasoning Engine
Figure 3.5 presents the complete reasoning process for the final Ontology. Based upon the initial Ontology, as shown in the previous section, the process contains five inferences up to the final model. The first inference classifies User Model in-stances using different rules according to WHO ICF user profiles (see Organization et al. [2012a] andOrganization et al. [2012b]). With respect to the Ontologymodel, this step adds new memberships for each User Model to different, already created profile classes. These classes are separated into no impairments (e.g. HProfile0 for no hearing impairment group), mild (e.g. VProfile1 for mild visual impairment group) and moderate (e.g. MDProfile2 for moderate manual dexterity impairment group) lev-els for visual, manual dexterity and hearing impairments. The second inference deals with component recommendations, resulting in analogue new classes with member instances for each recommendation related to an annotated component. These
rec-1Complete syntax description can be found at http://jena.apache.org/documentation/
inference/
ommendations will be presented in the CAD phase. The last three steps deal with the immediate textual recommendations presented in the sketch phase regarding the selection of the designer of aUser Model, typical environment and typical task.
Inference Action
User Model Profil-ing by User Model
Inference of Rec-ommendations to User Model Profiles
Inference of Rec-ommendations to Environments
Inference of Recom-mendations to Tasks
Inference of Recommen-dations to Components Initial Ontology
Ontology with pro-filed User Models
Ontology with Rec-ommendations for User Model profiles
Ontology with Recommen-dations for Environments
Ontology with Recom-mendations for Tasks
Ontology with Recommen-dations for Components
Resulting Virtual User Model Ontology
Figure 3.5: The reasoning approach
3.4.3 Reasoning Approach
As previously mentioned, the VICON reasoning consists of several stages in the cre-ation of the final Virtual User Model. In the first stage, based upon a user study [Vicon Consortium, 2010] User Model instances are added as members to impair-ment groups.
To simplify the reasoning the user can add or change rules directly. The syntax was reduced so that predicate values of instances are already assigned. The user can
use them without a definition. For each step single files are applied, so the vari-able generation could be automatically produced, if the name of the varivari-able is the same1 as the attribute name defined in class properties. For instance if the variable
?visualacuityis used, the definition(?x Vicon:UserModelVisualAcuity ?visualacuity)is added to the term.
Each of predicate value can be compared using the syntax presented in Table3.14.
EachUser Modelinstance is classified by parameter values. For instance the clas-sification of mild manual dexterity impaired user groups is made using the following rule:
”equal(?arthritis,”N”), equal(?grip,2), equal(?controls,2), equal(?buttons,2), equal(?discomfort,2) ->(?x rdf:type Vicon:MDProfile1).”
By using build-in commands like “equal(x,y)”, values are compared to each other.
The right arrow defines the state, if all axioms are true (forward chaining). Usually all variables (starting with a “?”) must be defined first before the first comparison. For instance, to get the value of the predicate, if theUser Modelsuffers from arthritis, the first axioms should be: “(?x rdf:type Vicon:UserModel),(?x Vicon:UserModelArthritis
?arthritis) [...]”
In the first axiom, an instance of theUser Modelclass is selected (“?x”). The value of the arthritis predicate (analogue other predicates) can be set afterwards by using the direct predicate name, always beginning with “Vicon” and the class name. All stages of reasoning are compiled analogue to this scheme resulting in new inference models until the finalVirtual User Model.
Using the knowledge base as initial model, a new model is deducted including new classes for the separation of selection states. While the knowledge base is defined as a flat hierarchy, the inference Ontology contains a tree-based taxonomy for the recommendation model.
1. Classify “User Model” instances to user profiles (mass customization, see also Pine and Davis[1999]):
This first reasoning step will be needed to define different profiles based upon the possibilities and user needs of the beneficiaries.
2. Add recommendations to eachUser Modelprofile class as members:
After this step, recommendations can be connected toUser Models.
3. Add recommendations to each environment class as members:
Thus each environment instance is an instance and cannot contain members,
1Comparison is made in lower case
as a pre-step each instance needs to have an analogue class where members can be applied.
4. Add recommendations to each task class as members:
This step is analogue to the previous environment step, involving all recommen-dations having an impact on specific task selections of the user.
5. Add recommendations to each component class as members:
This step deals with the presentation of recommendations for the second phase CAD, where based upon annotations of the components of the virtual prototype different recommendations should be presented.
3.4.4 Ontology Inference
The Forward Chain Reasoning steps of the Ontologycreate new classes. Exemplary rules were used to create newUser Modelclasses for each specified hearing impair-ment group.
1 //HI0
2 lessThan ( ? hearing500hz , 20) , lessThan ( ? hearing1khz , 25) , lessThan ( ? hearing2khz , 3 0 ) , lessThan ( ? hearing4khz , 4 0 ) ,
3 greaterThan ( ? backgroundnoise ,100) 4 −> ( ? x r d f : t y p e VICON:HProfile0 ) . 5 //HI1
6 equal ( ? hearing500hz , 20) , equal ( ? hearing1khz , 25) , equal ( ? hearing2khz , 3 0 ) , equal ( ? hearing4khz , 4 0 ) ,
7 equal ( ? backgroundnoise ,100)
8 −> ( ? x r d f : t y p e VICON:HProfile1 ) . 9 //HI2
10 equal ( ? hearing500hz , 30) , equal ( ? hearing1khz , 45) , equal ( ? hearing2khz , 6 5 ) , equal ( ? hearing4khz , 7 5 ) ,
11 equal ( ? backgroundnoise , 0 )
12 −> ( ? x r d f : t y p e VICON:HProfile2 ) .
Figure 3.6: Recommendation Rules to create User Model Recommenda-tion for impaired groups
Figure 3.6 presents e.g. rules, which were used to add a new membership1 to each User Model instance based on their predicates, which are related to hearing impairments. As mentioned in3.3.2, these predicates define targeted WHO ICF im-pairment groups. After the reasoning step, new classes are created (e.g. HProfile1for mild hearing impaired target users) describing a classification of eachUser Modelby
1For instance a membership of an instance to the User Model class is defined by (?x rdf:type Vi-con:UserModel)
Predicate Value
Name For better tactility keys should be raised above the body of the phone
Profile VI1,VI2,MD1,MD2
Summary Keys should be raised above the body of the phone (preferably by 5 mm).
ID R-5
Source NCBI,
http://www.cardiac-eu.org/guidelines/keys.htm,
http://www.cardiac-eu.org/guidelines/telecoms/mobile.htm ComponentRule button height≥5
Component turning knob, press button
Text People who rely on touch to operate keypads benefit from keys that are as distinctive as possible to the touch. Raised keys are more easily distinguished than those that are flush against their surrounding. Keys should therefore be raised above the body of the phone (preferably by 5 mm).
Level 3
Table 3.15: One instance of the recommendation class
defined parameters.
Analogue steps are performed for the classification of visual and manual dexterity impairments.
For the classification of recommendations to each selection of the user, instances contain values to connect with various classes. Table 3.15 presents one instance of the recommendation class including all defined attributes1. With respect to the purpose of defining recommendations based on different selections of the user, each instance contains information about targetUser Models,Environment Models,Task ModelsandComponent Models.
∙ User Model
The impact between one recommendation instance and their importance to dif-ferent impairments is described in the “Profile” predicate.
∙ Task
TheTaskRule predicate is used to describe the relation between tasks and
rec-187 recommendation instances available in total.
ommendation instances. On task side, each instance can optionally contain a direct connection to the profile predicate of the recommendation class by the Impairment predicate in which recommendations are presented, if the same im-pairment profile groups are included (see task parameters, table3.11).
∙ Environment
TheEnvRulepredicate represents the connection between environment and rec-ommendation instances.
∙ Component
For the component relation, available annotation component options are speci-fied in the “Component” predicate.
3.4.5 Description Logic Expressivity
Description Logic (DL) expressivity denotes the complexity of operators used through-out the Ontology (Baader [2003]). Table 3.16presents the expressivity used by the Ontology.
Naming convention Description
AL Attributive language. This is the base
language which allows:
∙ Atomic negation (negation of concept names that do not appear on the left hand side of axioms)
∙ Concept intersection
∙ Universal restrictions
∙ Limited existential quantification
C Complex concept negation.
H Role hierarchy (sub properties
-rdfs:subPropertyOf).
(D) Use of data type properties, data values or data types.
Table 3.16: Used DL Expressivity of Ontology
The initial model applies the DL expressivity with role hierarchy expressions es-pecially for a hierarchical structure of recommendations and data type properties for attribute values of instances (e.g. parameter UserModelAgewith an integer value as seen in tables3.5-3.8). The complexity of the final resulting model after the inference of rules is defined byALCH(D).
3.4.6 Multiple Selection
In the final application, the designer can select multipleUser Models, environments and tasks, resulting in a set of recommendations. In the initial set of recommenda-tions, each one refers to oneUser Modelimpairment profile, typical environment or task setting. With respect to section 1.3 and 3.4.4, each selection of the designer results in a specific set of recommendations. For instance, if the designer selects the User Model“Gandalf”, the presented recommendations are members of each impair-ment profile class, which the User Model “Gandalf” is classified to. Each presented recommendation has an impact on a specific impairment profile (e.g. class of mod-erate hearing impaired). A combined set is created containing all recommendations for each impairment group. If the user selects more than oneUser Model, the recom-mendations for all must be merged.
An intersection of the different sets would result in an empty set, due to the connec-tion of each recommendaconnec-tion to different aspects.