deletions | additions       diff --git a/chapter_The_USAR_Ontology_The__.tex b/chapter_The_USAR_Ontology_The__.tex  index fbd2553..a843de4 100644  --- a/chapter_The_USAR_Ontology_The__.tex  +++ b/chapter_The_USAR_Ontology_The__.tex 
...
The USAR Ontology is aimed to capture the high-level information of the TRADR project, fulfilling several requirements. First, to represent the information that is being discovered during a mission, such that this can be shown on a visual interface, as well as used by the agents for reasoning.   The environment is represented as a map with areas, points of interest, hazards such as fire or explosion. The actors of the operation (robots and humans) are all geographically positioned on the map, and hence stored in the ontology as well. An agent stands for an actor, and each actor present has an agent, to map the reality to a multi-agent system.   Agents operate on this ontology in order to determine the "display logic" (as described in Chapter 5), the mapping of roles and capabilities to visual elements on the interface. Thus, the ontology serves as the base core to create situational awareness on the team level. That means that every member of the rescue team has the perfect overview of the situation he/she needs, given his/her role, task, capabilities, current status and activity. The ontology hence should capture information about a member, as well as a team, a mission, a sortie, etc\... etc..  \begin{itemize}  \item Reuse other ontologies 
...
From the robot perspective the ontology has to capture all information that the robot can detect (which depends on the available hard- and software that these robots are equipped with). The environment might take a status information such as traversable/non-traversable, which clearly serves the ground robot, but not the aerial one. A big importance is given to providing explicit failure information, such as: a flipper is blocked, or software is restarting, or calculating planned path, that serves every other team member with the most crucial status information. This information would come from lower level software that is concerned with the operability of the robot.  \item Team perspective  From the team perspective every actor (human or robot) in the mission is a team member with a specific role, activity status, a set of capabilities, and a list of assigned tasks. Some properties will be clearly human-specific: level of cognitive overload, physical tiredness, etc..., and some robot-specific: battery level,.... level,...  But from the team perspective they are viewed as equal, with different and varying properties. \end{itemize} 
...