## 4 Materials and Methods
### Driver Preference Management System Integration  
In this phase, the driver profile ontology was integrated with the KG to manage, validate and update driver preferences based on user inputs. The system retrieves detailed information about the preferences, determines which settings can be adjusted, and updates the KG accordingly.  
* We developed a Python script that loads the driver profile ontology and KG, queries driver preferences and updates comfort settings for a specific driver. The following SPARQL query (Listing 2) retrieves detailed information about the preferences of a specific driver, [PERSON]. This query gathers various attributes associated with her driving profile, such as driving type, behaviour and comfort settings (see results in Figure 6)  
```
1 Creating realistic user profiles
```  
Listing 2: SPARQL query to retrieve [PERSON]'s driver preferences.  
```
0 ccms:[PERSON] ocms:hasType?drType. 0 ccms:[PERSON] ocms:hasDrivingBehavior?drBehavior. 0 ccms:[PERSON] ocms:hasComfortSettings?comSettings. }
```  
Listing 3: Validation of [PERSON]'s preferences showing modifiable and fixed attributes.  
\begin{table}
\begin{tabular}{p{142.3 pt} p{142.3 pt} p{142.3 pt}} \hline \hline
**No** & **Phase** & **Description** \\ \hline
1 & **Creating realistic user profiles** & Realistic user profiles are created by specifying attributes and preferences for each profile, including comfort settings and multimedia preferences, represented in JSON for compatibility and clarity. \\ \hline
2 & **Mapping information into RDF** & User profiles are mapped to data extracted during the ontology definition phase. This process ensures that user characteristics are accurately aligned with ontology properties, enabling seamless integration and data analysis. \\ \hline \hline \end{tabular}
\end{table}
Table 5: Summary of phases in developing a KG using driver profile ontology.  
Figure 6: Results of Listing 2: [PERSON]’s driver preferences, including her driver type, behaviour, comfort settings and multimedia choices.  
```
**Listing 3** SPARQL query to forward [PERSON]'s preferences to Onto-CMS.
``` PREFIXocms:<[[http://cui.unige.ch/ocms#](http://cui.unige.ch/ocms#)]([http://cui.unige.ch/ocms#](http://cui.unige.ch/ocms#))> SELECT?preference?modifiability WHERE{ {  ocms:Anneocms:hasSafetySettings?safety.?safetyocms:modifiable?modifiability. BIND(\"Emergency Pedal Icon\" AS?preference) } UNION {  ocms:Anneocms:hasDrivingMode?mode.?modeocms:modifiable?modifiability. BIND(\"Driving Mode\" AS?preference) } UNION { ocms:Anneocms:hasComfortSettings?comfort.?comfortocms:modifiable?modifiability. BIND(\"Comfort Settings\" AS?preference) } UNION { ocms:Anneocms:hasMultimediaPreferences?multimedia.?multimediaocms:modifiable?modifiability. BIND(\"Multimedia Preferences\" AS?preference) } } ```
* If a preference can be changed, the system replaces the old value with the new one to ensure the KG reflects the latest choices. The following SPARQL query (Listing 4) demonstrates how [PERSON]'s driving mode is updated (see the corresponding results in Figure 8).  
From Listing 4, it emerges that only three of [PERSON]'s preferences were successfully updated. However, her request to remove the pedal settings was denied. This preference does not appear among the modifiable options because pedal settings are classified as non-modifiable. The icon cannot be removed, but other features can still be adjusted (see use cases in Sections 4.5.1 and 4.5.2). Consequently, [PERSON] was then notified that this adjustment was unsuccessful.  
Table 6 sums up the phases to develop the driver preference management system integration.  
Figure 8: Results of Listing 4: Updating [PERSON]’s preferences.