## 4 Adaptation
### Use Cases
#### 4.1.4 KIDE4 Assistant: Information Systems for Assistance  
The fourth and last use case presented in this paper is an assistant for procedure execution, in the context of EKIN project [39]. Given a set of maintenance procedures, previously extracted from technical manuals, the system is able to guide the user through the processes described in them. The system has been designed for Spanish, and manuals are also in this language.  
In this use case, procedures are structured in _methods_, _tasks_ and _steps_. _Methods_ determine different ways to perform the same procedure (e.g., in normal conditions or in a clean room); each _method_ has a set of _tasks_ (e.g., extract a battery, install a battery), and each _task_ consists of a set of _steps_ (e.g., disconnect the machine, open the lid). Given a procedure, the system requests the user to select the method to follow--if the procedure has more than one--Then, the system gives the description of the current method, task or step. Users are able to navigate through the different elements of the procedure by (i) requesting for the next or previous step or task (given the current step), (ii) to repeat the information that was just given by the system, (iii) to restart a method or task (i.e., start over again from the first step of the first task of the current method or to start over again from the first step of the current task, respectively), (iv) to obtain other related information such as the list of necessary tools to perform the procedure or (v) a more extensive description or (vi) additional information, in the form of text and images. Long texts and images are shown in a screen so users can easily follow the information provided by the system, whereas shorter texts are uttered.  
Thus, the key elements to be identified by the target system are **actions** and **targets**, which correspond to the key word used to determine the action to perform (Example (6), for the _Show tool list_ action) or the reference element of the action (Example (7)).  
* **M****uestrame_action la lista de **herramientas**target-determineAction*
* **Show_action me the **tool**target-determineAction*
* **Reinicia**action la **ta****e**target-reference*
* the **task**target-reference**
In this case, as the key elements to identify were common with the guide use case ones, both definitions, rules and interpreter scripts are also common.  
The ontology design phase for this use case has two parts. On the one hand, 6 procedures--extracted from the manuals of 2 robotic arms and a controller, and formatted as JSON files--along with the relations between _procedures, methods, tasks_ and _steps_ are modelled, including sequential relations (e.g., _Step_ 2 comes after _Step_ 1 and before _Step_ 3) are automatically instantiated into TODODW. For each method, their tool list is modelled, along with the tools in each list. For each structural element of the procedure (i.e., _methods, tasks_ and _steps_), additional information and/or extended information is also automatically included. Furthermore, the elements that make reference to procedure parts--_procedures, methods, tasks, steps_ and _tools_, which correspond to the key elements labelled as _targets_--were also modelled. So as to be able to instantiate this information, the VAR ontology [40]--which is intended as a \"workplace digital twin\" [40] by representing workplaces, processes and workers--as been reused.  
On the other hand, the rest of the domain information is modelled and instantiated as in the previously described use cases, using the same methods.  
Tables 1 and 2 show that nearly all the classes for this adaptation were reused (a 99.2%), and an 88.2% of the instances were obtained through automatic methods or reused from other use cases. Although all of the dialogue information was reused, minimal modifications on the dialogue's logic were needed to cover the necessities of the use case.