# Novel Semantic-Based Probabilistic Context Aware Approach for Situations Enrichment and Adaptation
## 4 Proposed Approach
### Recommendation Process of Situation Rules
#### 4.2.1 Rule's Content-Based Approach  
A situation rule is a hierarchical structure of specific depth, which consists of terms, mostly called tags. In smart domains, tags are associated with different fields (security, demotics, work, shopping, tourism, etc.) for efficient rules discoverability. The methodology of calculating the degree of interest of a rule item regarding the user context is presented in this section. However, before the quantification of this degree of interest, some steps should be followed beforehand. Specifically, each user defines explicit preferences in which they will be specified as a vector \(EP=(CP_{1}\dots\ CP_{n})\), where \(CPi\) is configuration preference. Each \(CP\) contains four features:  
* **Domain:** The application's domain in the configuration preferences, as a string of the possible values (Home, Car, Office, University, Shop, Security, Hospital). * **Day:** The days in the configuration preferences, as a string of the possible values (Weekday, Weekend). * **Time:** The time in the configuration preferences, as a string of the possible values (Morning, Afternoon, Evening, Night). * **Field:** The field of user's domain in the configuration preferences, as a string of the values (Security, Demotics, Study, Health, Work, Shopping). Figure 4: Hybrid rule-based recommendation process. The preferences of the users can be specified explicitly using GUI or extracted implicitly from his rules. The explicit preferences are described using XML and stored in file called _configuration preferences_. Users can define many configurable preferences (i.e., domain, day, time and field). Besides, the user can specify the range of rules for the recommendation in terms of rules' popularity (i.e., _low_, _medium_ and _high popularity_). The vector of terms \(EP\_Term=(t_{1}\dots\ t_{m})\) is extracted from the vector \(EP\), as defined in Algorithm 1. ```
Input: Explicit preference vector \(EP=(CP_{1}\dots\ CP_{n})\); Output: Term vector \(EP\_Term=\O\); Begin
1 : For each element \(CP_{i}\) from \(EP\)
2 : For each term \(t_{j}\) from \(CP_{i}\)
3 : If \((t_{j}\
otin EP\_Term)\) Then
4 : \(EP\_Term\gets EP\_Term\cup t_{j}\) ;
5 : End If
6 : End For
7 : End For
8 : Return \(EP\_Term\) End
```  
**Algorithm 1**Extact Terms from Explicit Preferences (EP). For each pairs of user-item, we compute weights \(w_{i}\) regard an explicit term \(t_{i}\) in order to get the normalized value as follows:  
\[w_{i}=\frac{number\ of\ occurrence\ of\ term\ t_{i}\ in\ EP}{e^{|EP|}} \tag{2}\]  
Similarly, the vector of terms \(IP\_Term=(t_{1}\dots\ t_{m})\) is extracted from the Rules Repository (RR), as defined in Algorithm 2. For each user as a vector \(RR=(r_{1},\ \dots,r_{n})\), where \(r_{i}\) is a rule's metadata. The weights \(w=(w_{1},\ \dots,\ w_{m})\), where \(w_{i}\) is the weight of implicit term \(t_{i}\) are calculated as presented in Equation (3). ```
Input: Rules repository vector \(RR=(r_{1}\dots\ r_{n})\); Output: Implicit preference vector \(IP\_Term=\O\); Begin
1 : For each element \(r_{i}\) from \(RR\)
2 : For each term \(t_{j}\) from \(r_{i}\)
3 : If \((t_{j}\
otin IP\_Term)\) Then
4 : \(IP\_Term\gets IP\_Term\cup\ t_{j}\) ;
5 : End If
6 : End For
7 : End For
8 : Return \(IP\_Term\) End
```  
**Algorithm 2**Extact Terms from Rules Repository (RR). For each pairs of user-item, we compute weights \(w_{i}\) regard an explicit term \(t_{i}\) in order to get the normalized value as follows:  
\[w_{i}=\frac{number\ of\ occurrence\ of\ term\ t_{i}\ in\ EP}{e^{|EP|}} \tag{3}\]  
The aforementioned parameters, namely term and weight, are of generic nature and can be calculated for any smart domain. The terms are not equally important (i.e., _by their nature, terms in the location or field tag might be more important than subfield tag), so we assign important factors to give each term's relative importance for rule item metadata. The server stores a description of rules history, which are described using XML.