A Rule-Based Reasoner for Underwater Robots Using OWL and SWRL

Web Ontology Language (OWL) is designed to represent varied knowledge about things and the relationships of things. It is widely used to express complex models and address information heterogeneity of specific domains, such as underwater environments and robots. With the help of OWL, heterogeneous underwater robots are able to cooperate with each other by exchanging information with the same meaning and robot operators can organize the coordination easier. However, OWL has expressivity limitations on representing general rules, especially the statement “If … Then … Else …”. Fortunately, the Semantic Web Rule Language (SWRL) has strong rule representation capabilities. In this paper, we propose a rule-based reasoner for inferring and providing query services based on OWL and SWRL. SWRL rules are directly inserted into the ontologies by several steps of model transformations instead of using a specific editor. In the verification experiments, the SWRL rules were successfully and efficiently inserted into the OWL-based ontologies, obtaining completely correct query results. This rule-based reasoner is a promising approach to increase the inference capability of ontology-based models and it achieves significant contributions when semantic queries are done.


Ontologies for Robotic Systems
The term "Ontology" is originated from philosophy, aiming at dealing with realistic objects and conceptual entities. Recently, Artificial Intelligence (AI) and Robotics are adopting this term to represent the real world, enabling the description of objects and the relationships of objects in the knowledge domain [44]. For a robotic system, an ontology is regarded as a formal and clear specification of shared categories, properties, and relations between the concepts, data, and entities. In other words, an ontology of a robotic system captures a common understanding of the domain.
Many researchers tried to build a robotic system by using ontologies. Sadik A.R. and Urban B. [45] combined an ontology-based Multi-Agent System (MAS) and a Business Rule Management System (BRMS) and proposed a distributed control solution to solve challenges in the cooperative manufacturing. It is remarkable that they treated the ontology as a conceptual tool to represent and create a common understanding for the manufacturing work cell entities. Ali F. et al. [46] proposed a merged ontology and Support Vector Machine (SVM) based on an information extraction and recommendation system to convey information and provide recommendations. The ontology-based humanoid robot is able to give accurate feedbacks on a query of a particular topic. IEEE Robotics & Automation Society proposed a Core Ontology for Robotics and Automation (CORA) [47], used by robots that require explicit knowledge. Their ontology is meant to standardize the knowledge representation in the Robotics and Automation (RA) field.
Though plenty of ontologies for robotic systems have been proposed, the construction approaches are not the same. Meanwhile, there is no standard approach of constructing an ontology. Generally, researchers are complying with the following principles to model a robotic system by ontologies [48][49][50]:

1.
Clarity: An ontology should represent defined terms in a clear and complete manner. The definition of terms should be independent and objective. Definitions could be formularized in logic axioms. Natural languages are recommended to comment on all the definitions.

2.
Coherence: An ontology should support inferences that are consistent with the definitions. If an inference result contradicts a definition, it means that the ontology is incoherent.

3.
Extendibility: An ontology should be able to provide the extensions on the existing definitions. An updated definition could be added directly without modifying any existing definitions.

4.
Modularity: An ontology should have the capability of being divided into several modules with relevant fragments of the ontology. Because a module is usually smaller than the original ontology and is easier to be re-used. 5.
Minimal encoding bias: The description of terms does not rely on a specific encoding approach. Because the different components of a robotic system in the real world could be programmed by various languages. 6.
Minimal ontological commitment: An ontology should achieve the minimal ontological commitment, which is exactly sufficient to support knowledge sharing within the ontology. The ontology developers should define as fewer constraints as possible in order to provide freedom to specialize and instantiate the ontology as needed.

Overview of SWARMs OWL-Based Ontology
Based on the above-mentioned principles, the SWARMs project adopts the ontology language OWL to design a networked ontology. The SWARMs ontology [51] has two general characteristics, understandability and conciseness. The characteristics of understandability means that the SWARMs ontology can be easily understood by all stakeholders, including ontology developers, marine experts, human operators, etc. The characteristics of conciseness means that the SWARMs ontology consists of the least number of vocabularies to describe the underwater robotic system. The SWARMs ontology consists of one core ontology and four domain-specific ontologies, including communication, environment, mission planning, and robotic vehicle domain. The overview of SWAMRs ontology is shown in Figure 1. As is shown in Figure 1, the core ontology provides a comprehensive representation and has the capability of interconnecting the four domain-specific ontologies. The interconnection of these ontologies is shown in Figure 2. The details of four main domain-specific ontologies are explained in the following sub-sections. Besides the four main domain-specific ontologies, application ontologies could be added in order to fulfill specific requirements from different scenarios, such as pollution detection, underwater infrastructure repairing, seabed mapping, etc. The application ontologies aim at enriching the SWARMs ontology and providing the details of assigned missions. For example, an application ontology on pollution detection is given in Figure 3. As is shown in Figure 1, the core ontology provides a comprehensive representation and has the capability of interconnecting the four domain-specific ontologies. The interconnection of these ontologies is shown in Figure 2. As is shown in Figure 1, the core ontology provides a comprehensive representation and has the capability of interconnecting the four domain-specific ontologies. The interconnection of these ontologies is shown in Figure 2. The details of four main domain-specific ontologies are explained in the following sub-sections. Besides the four main domain-specific ontologies, application ontologies could be added in order to fulfill specific requirements from different scenarios, such as pollution detection, underwater infrastructure repairing, seabed mapping, etc. The application ontologies aim at enriching the SWARMs ontology and providing the details of assigned missions. For example, an application ontology on pollution detection is given in Figure 3. With the extension of application ontologies, SWARMs users could perform a pollution detection mission by using underwater robots and surface robots. Based on the environmental variables in the given region, SWARMs users are able to estimate the spread speed of pollutants and conclude the pollution level and estimated size of the polluted area [52].

Communication Domain
The communication domain contains the information model which describes the communication approaches in SWARMs platform. Due to the challenges of unstable communication channels and limited bandwidths, several communication approaches are considered, such as acoustic, cable, radio, satellite, and Wi-Fi. The communication link of acoustic uses an acoustic modem and is able to offer the possibility of wireless communication under water for Autonomous Underwater Vehicles (AUVs) [53]. The communication link of radio and satellite can be used by Remotely Operated Vehicles (ROVs) to transmit data and commands between vehicles and operators [54,55]. If the environment is terrible and the communication is easily disturbed by noise, the communication link of cable is then a reliable option [56]. Meanwhile, several types of messages are defined in the communication ontology, including "ErrorMsg", "EventMsg", "NotificationMsg", "QueryMsg", "RegistrationMsg", and "RequestMsg".
The details of communication ontology is defined by OWL in Figure 4.
Remotely Operated Vehicles (ROVs) to transmit data and commands between vehicles and operators [54,55]. If the environment is terrible and the communication is easily disturbed by noise, the communication link of cable is then a reliable option [56]. Meanwhile, several types of messages are defined in the communication ontology, including "ErrorMsg", "EventMsg", "NotificationMsg", "QueryMsg", "RegistrationMsg", and "RequestMsg". The details of communication ontology is defined by OWL in Figure 4.  In Figure 4, the classes of "Source" and "Target" represent the message sender and receiver, respectively.

Environment Domain
The ontology model of environment domain consists of several disjoint classes and describes the concepts within the environment, such as sensors, entities, landmarks, etc. The environment ontology is shown in Figure 5. In Figure 4, the classes of "Source" and "Target" represent the message sender and receiver, respectively.

Environment Domain
The ontology model of environment domain consists of several disjoint classes and describes the concepts within the environment, such as sensors, entities, landmarks, etc. The environment ontology is shown in Figure 5. In Figure 5, the class "Sensor" has two sub-classes, named logical sensor and physical sensor. Regarding the physical sensor, it is able to provide physical measurements of the environment, such as water currents and the water temperature. Regarding the logical sensor, it can precept logical data, such as the current condition of a robotic vehicle. The class "DataProcessor" is dealing with the sensing data in order to generate the processed data. For example, "DataProcessor" can perform feature extractions, recognitions and classifications from a captured image. The class "Landmark" refers to specific seabed features, objects, or fixed structures. The class "Entity" represents marine lives and man-made objects. The detail of "Entity" is shown in Figure 6. In Figure 5, the class "Sensor" has two sub-classes, named logical sensor and physical sensor. Regarding the physical sensor, it is able to provide physical measurements of the environment, such as water currents and the water temperature. Regarding the logical sensor, it can precept logical data, such as the current condition of a robotic vehicle. The class "DataProcessor" is dealing with the sensing data in order to generate the processed data. For example, "DataProcessor" can perform feature extractions, recognitions and classifications from a captured image. The class "Landmark" refers to specific seabed features, objects, or fixed structures. The class "Entity" represents marine lives and man-made objects. The detail of "Entity" is shown in Figure 6. as water currents and the water temperature. Regarding the logical sensor, it can precept logical data, such as the current condition of a robotic vehicle. The class "DataProcessor" is dealing with the sensing data in order to generate the processed data. For example, "DataProcessor" can perform feature extractions, recognitions and classifications from a captured image. The class "Landmark" refers to specific seabed features, objects, or fixed structures. The class "Entity" represents marine lives and man-made objects. The detail of "Entity" is shown in Figure 6.

Mission Planning Domain
The ontology model of mission planning domain represents the mission composition and planning procedure. Once a mission is established, it is decomposed into several goals according to its objectives and mission specifications. In order to achieve all the goals, certain tasks should be completed by following series of scheduled actions [57]. The details are shown in Figure 7.

Mission Planning Domain
The ontology model of mission planning domain represents the mission composition and planning procedure. Once a mission is established, it is decomposed into several goals according to its objectives and mission specifications. In order to achieve all the goals, certain tasks should be completed by following series of scheduled actions [57]. The details are shown in Figure 7.  The ontology model of mission planning domain is shown in Figure 8.  The ontology model of mission planning domain is shown in Figure 8. In Figure 8, the class "Task" has two sub-classes, named "LowLevelTask" and "HighLevelTask". A low-level task can be divided into operator-level task and vehicle-level task. The former one represents that the task requires human operators to manually perform the operations. The latter one means that the task only needs an individual robotic vehicle to carry on the mission, whereas a highlevel task has to be executed by a swarm of robotic vehicles. In Figure 8, the class "Task" has two sub-classes, named "LowLevelTask" and "HighLevelTask". A low-level task can be divided into operator-level task and vehicle-level task. The former one represents that the task requires human operators to manually perform the operations. The latter one means that the task only needs an individual robotic vehicle to carry on the mission, whereas a high-level task has to be executed by a swarm of robotic vehicles.

Robotic Vehicle Domain
The ontology model of robotic vehicle domain specifies the robots and vehicles used in the SWARMs project. Generally, a robotic vehicle is either an underwater or surface robot according to its working environment. A robotic vehicle is either an autonomous or non-autonomous according to its autonomy and intelligence [58,59]. The detail of robotic vehicle ontology is shown in Figure 9.

Robotic Vehicle Domain
The ontology model of robotic vehicle domain specifies the robots and vehicles used in the SWARMs project. Generally, a robotic vehicle is either an underwater or surface robot according to its working environment. A robotic vehicle is either an autonomous or non-autonomous according to its autonomy and intelligence [58,59]. The detail of robotic vehicle ontology is shown in Figure 9. In Figure 9, the class of "RobotCandidateForMission" represents the specific robotic vehicles which have qualified capabilities and fulfil certain requirements of the mission. For example, one certain mission requires that the remaining energy of a selected candidate vehicle should be greater than 60.0 and the vehicle should have certain sensors or actuators. In a robotic vehicle ontology, In Figure 9, the class of "RobotCandidateForMission" represents the specific robotic vehicles which have qualified capabilities and fulfil certain requirements of the mission. For example, one certain mission requires that the remaining energy of a selected candidate vehicle should be greater than 60.0 and the vehicle should have certain sensors or actuators. In a robotic vehicle ontology, there are several specific vehicles, including Remotely Operated Vehicle (ROV), Autonomous Surface Vehicle (ASV), Autonomous Underwater Vehicle (AUV), and so on. The detail of these robotic vehicles is as described in [60,61].

SWRL Rules and Rule-Based Reasoner
As is stated in the previous section, OWL is an ontology description language and has the capability of modelling complex systems and environments. One of the advantages of using OWL is that it has various operators, such as intersection, union, and negation, enabling OWL users to check whether all the definitions and relations in the ontology are consistent. Thus, OWL can represent the SWARMs ontology clearly and succinctly. However, OWL is unable to describe general rules, especially the "if-else-then" statements, leading to impossibility for users to check hidden knowledge in the ontology. Although this knowledge could be defined manually by ontology developers through OWL, this approach definitely increases the complexity of SWAMRs ontology and it actually repeats the existing knowledge. Hence, it is a promising approach to combine the Semantic Web Rule Language (SWRL) to help OWL describing general rules. SWARMs users can define their own rules and insert the rules into the SWARMs ontology for further inferences [62]. With the help of SWRL, the usability of OWL-based ontologies could be extended and the consistency of the ontologies could be improved. The SWARMs users are able to obtain more abundant and precise information by requesting queries to the ontology. A rule-based reasoner can be used to perform inferences on SWARMs ontology with SWRL rules, providing the marine experts and human operators with simple or complex query services, such as searching for a potential candidate among a swarm of robotic vehicles for a certain mission, possibility of replacing one robotic vehicle in the swarm, etc. It is worthy to mention that the proposed rules insertion mechanism allows SWARMs users to directly insert multiple SWRL rules into the SWARMs ontology at one time without editing in Protégé. By this approach, the SWARMs ontology does not need to be reloaded again after the rules insertion.

SWRL Rules
The Semantic Web Rule Language (SWRL) is firstly released in 2003. The latest version of SWRL is updated in 2004 (Version 0.7) with more extensions of Built-Ins. SWRL is on the basis of OWL DL and OWL Lite, enabling the combination of horn-like rules and OWL-based knowledge base. Due to the compatibility of SWRL, OWL can adopt the SWRL rules in order to provide a more completed ontology and enable the possibility of rule-based reasoning.

Structure and Syntax of SWRL Rules
Generally, SWRL rules consist of four components, including "Imp", "Atom", "Variables", and "Built-in". The structure of SWRL rules is shown in Figure 10.
ontology and enable the possibility of rule-based reasoning.
3.1.1. Structure and Syntax of SWRL Rules Generally, SWRL rules consist of four components, including "Imp", "Atom", "Variables", and "Built-in". The structure of SWRL rules is shown in Figure 10. In Figure 10, "Imp" is short for implication and consists of head and body. The head and body represent inference results and the initial state before inference, respectively. The basic element in the head and body is "Atom". The variables of "Atom" are stored in "Variable". Four basic forms of "Atom" are defined in "Variable" shown as follows.
• C(x). C represents an OWL description or data range.
• P(x, y). P is the property of OWL. x and y can be variables, OWL individuals or OWL data values.

•
SameAs(x, y). It represents that x is equal to y.
• DifferentFrom(x, y). It represents that x is different from y.
The "Built-In" is a modular component of SWRL and contains formulas of logic operations, such as boolean operation, mathematical calculation, string operation, etc. Seven types of built-ins are defined in SWRL in Table 1. In Figure 10, "Imp" is short for implication and consists of head and body. The head and body represent inference results and the initial state before inference, respectively. The basic element in the head and body is "Atom". The variables of "Atom" are stored in "Variable". Four basic forms of "Atom" are defined in "Variable" shown as follows.
• C(x). C represents an OWL description or data range. • P(x, y). P is the property of OWL. x and y can be variables, OWL individuals or OWL data values.

•
SameAs(x, y). It represents that x is equal to y.

•
DifferentFrom(x, y). It represents that x is different from y.
The "Built-In" is a modular component of SWRL and contains formulas of logic operations, such as boolean operation, mathematical calculation, string operation, etc. Seven types of built-ins are defined in SWRL in Table 1. URIs swrlb:anyURI If the first argument is a URI reference, followed by arguments of scheme, host, port, path, query and fragment.
Lists swrlb:empty If the first argument list is empty.
As is mentioned before, a SWRL rule consists of an antecedent (body) and a consequent (head). Both antecedent and consequent have multiple atoms. In Listing (1), it describes the abstract syntax of a SWRL rule [63]. (1) In this paper, the SWRL rules are loaded in OWL/RDF format, such as the example given in Listing (2): swrl : propertyPredicate rd f : resource = "&eg : hasBatteryLevel"/ swrl : argument1 rd f : resource = "#x1"/ swrl : argument2 rd f : ( The SWRL rules in OWL/RDF format can perfectly merge with the OWL-based SWARMs ontology. Besides, SWRL rules offer a human-readable syntax, such as in Listing (3): The above SWRL rule in Listing (3) means that if the current speed of a vehicle is zero, then it is a stand-by vehicle waiting for commands.

SWRL Rules for SWARMs Ontology
With the help of SWRL rules and its human-readable syntax, marine experts and human operators can easily express their knowledge and experience [64] as user-defined rules without knowing the technical details of programming. Usually, pre-defined rules can be embedded in the SWAMRs platform in advance and all robotic vehicles should follow these pre-defined rules to perform underwater operations. However, underwater environment is complex and dynamic. Consequently, marine experts and human operators should add extra new rules and constraints for the purpose of helping robotic vehicles adapting to the environment and carrying on operations safely during runtime. Listing (4)-(9) represent some SWRL rules used in the SWARMs ontology.
RoboticVehicle(?x)ˆvehicleBatteryLevel(?x, ?y)ˆswrlb: greaterThan(?y, 30.0) → RobotCandidateForMission(?x) (4) In Listing (4), it is a very straightforward and simple rule, representing that if the remaining battery of a robotic vehicle is greater than 30.0, then this vehicle is a candidate for enrolling in the mission. This rule can be specifically inferred by the rule-based reasoner when the SWAMRs platform tries to automatically select the mission candidates. Similar rules of selecting the mission candidates are shown as follows.
Meanwhile, event-related SWRL rules could be defined by the marine experts. For example, in the mission planning ontology, several types of event is given, including the "AlarmEvent", "ChangeEvent", "RequestEvent", "SignalEvent", and "TimeEvent". Marine experts could determine whether a robotic vehicle is at risk or not during runtime by defining a least-safety position. For example, if the remaining battery of a vehicle is lower than a certain value or the position of the vehicle is out of the mission-specified boundary, then it will trigger an alarm event. After being notified, the human operator can recall the robotic vehicle at the least-safety position in order to avoid the property loss. Relevant SWRL rules in SWARMs ontology can be defined as follows.
RoboticVehicle(?x)ˆGPSPosition(?x, ?y)ˆgpsAltitude(?y, ?z)ˆswrlb: greaterThan(?z, 100.0) → VehicleAtLeastSafetyPosition(?x) (7) RobotCandidateForMission(?x)ˆvehicleBatteryLevel(?x, ?y)ˆswrlb: lessThan(?y, 5.0) → VehicleAtLeastSafetyPosition(?x) (8) In Listing (7), the SWRL rule represents that if the robotic vehicle detects that its current altitude is greater than 100.0, then this vehicle is at the least-safety position. In Listing (8), the SWRL rule indicates that if the remaining battery of a mission candidate is lower than 5.0, then this vehicle is at the least-safe position. Once the human operator has been notified about the alarm events, immediate actions can be taken to recall these vehicles.
Meanwhile, Marine experts could define the severity level of pollutant by using SWRL rules. The severity level of pollutant depends on its denseness. For example, marine experts could determine the severity level of hydrogen sulfide, also known as H 2 S. The SWRL rule can be defined as follows.
In Listing (9), the SWRL rule suggests that if the denseness of H 2 S is greater than 20 parts per million (ppm), then we are dealing with a serious H 2 S pollution problem.
All user-defined SWRL rules are stored in a configuration file under serial orders. An example of such file is given in Figure 11.
Meanwhile, event-related SWRL rules could be defined by the marine experts. For example, in the mission planning ontology, several types of event is given, including the "AlarmEvent", "ChangeEvent", "RequestEvent", "SignalEvent", and "TimeEvent". Marine experts could determine whether a robotic vehicle is at risk or not during runtime by defining a least-safety position. For example, if the remaining battery of a vehicle is lower than a certain value or the position of the vehicle is out of the mission-specified boundary, then it will trigger an alarm event. After being notified, the human operator can recall the robotic vehicle at the least-safety position in order to avoid the property loss. Relevant SWRL rules in SWARMs ontology can be defined as follows.
RoboticVehicle(? x)^GPSPosition(? x, ? y)^gpsAltitude(? y, ? z)^swrlb: greaterThan(? z, 100.0) → VehicleAtLeastSafetyPosition(? x) (7) RobotCandidateForMission(? x)^vehicleBatteryLevel(? x, ? y)^swrlb: lessThan(? y, 5.0) → VehicleAtLeastSafetyPosition(? x) (8) In Listing (7), the SWRL rule represents that if the robotic vehicle detects that its current altitude is greater than 100.0, then this vehicle is at the least-safety position. In Listing (8), the SWRL rule indicates that if the remaining battery of a mission candidate is lower than 5.0, then this vehicle is at the least-safe position. Once the human operator has been notified about the alarm events, immediate actions can be taken to recall these vehicles.
Meanwhile, Marine experts could define the severity level of pollutant by using SWRL rules. The severity level of pollutant depends on its denseness. For example, marine experts could determine the severity level of hydrogen sulfide, also known as H2S. The SWRL rule can be defined as follows.
In Listing (9), the SWRL rule suggests that if the denseness of H2S is greater than 20 parts per million (ppm), then we are dealing with a serious H2S pollution problem.
All user-defined SWRL rules are stored in a configuration file under serial orders. An example of such file is given in Figure 11. Additionally, the rule file can contain only one rule or multiple rules.

Insertion of SWRL Rules into SWARMs Ontology
Most of ontology developers [65,66] are using SWRLTab [67] to insert SWRL rules into OWLbased ontology. SWRLTab is an extension of Protégé-OWL that permits the manipulations on SWRL rules, including creating new SWRL rules, reading and writing existing SWRL rules. A screenshot of SWRLTab is shown in Figure 12.
However, there are some constraints when using the SWRLTab. Firstly, the SWRLTab plugin only allows users to manipulate a single rule at one time. Secondly, it requires the users to have the experience in working with Protégé. Thirdly, it is necessary to have the source code of OWL-based model. Thus, this paper proposes a new approach to insert the SWRL rules into the OWL-based ontology model by several steps of model transformations. The newly proposed rules insertion mechanism allows users to write multiple SWRL rules in a configuration file and then load the rule file into the ontology model. Meanwhile, users just need to understand the SWRL syntax and do not Additionally, the rule file can contain only one rule or multiple rules.

Insertion of SWRL Rules into SWARMs Ontology
Most of ontology developers [65,66] are using SWRLTab [67] to insert SWRL rules into OWL-based ontology. SWRLTab is an extension of Protégé-OWL that permits the manipulations on SWRL rules, including creating new SWRL rules, reading and writing existing SWRL rules. A screenshot of SWRLTab is shown in Figure 12. need to use Protégé to edit the SWRL rules. The proposed rules insertion mechanism is one of the novelties in our work. The proposed rules insertion mechanism is shown in Figure 13. However, there are some constraints when using the SWRLTab. Firstly, the SWRLTab plugin only allows users to manipulate a single rule at one time. Secondly, it requires the users to have the experience in working with Protégé. Thirdly, it is necessary to have the source code of OWL-based model. Thus, this paper proposes a new approach to insert the SWRL rules into the OWL-based ontology model by several steps of model transformations. The newly proposed rules insertion mechanism allows users to write multiple SWRL rules in a configuration file and then load the rule file into the ontology model. Meanwhile, users just need to understand the SWRL syntax and do not need to use Protégé to edit the SWRL rules. The proposed rules insertion mechanism is one of the novelties in our work.
The proposed rules insertion mechanism is shown in Figure 13.
need to use Protégé to edit the SWRL rules. The proposed rules insertion mechanism is one of the novelties in our work. The proposed rules insertion mechanism is shown in Figure 13. In the SWARMs project, the Jena Ontology API [68], OWLAPI [69], and SWRLAPI [70] have been used to manipulate the SWARMs ontology and SWRL rules.
In Figure 13, the steps for model transformations with the purpose of inserting SWRL rules are shown. Normally, the ontology model is fixed and does not allow users to make any modifications, due to the fact that the whole SWARMs ontology is carefully designed and implemented by experts, thus containing highly professional knowledge. The source code of the SWARMs ontology is not fully public and all we receive from the remote server is an ontology file with the "OntModel" (An interface provided by Jena Ontology API) format. However, SWRL rules cannot be directly inserted into the "OntModel". Therefore, the original ontology model with "OntModel" format has to be converted to the "OWLOntology" (An interface provided by OWLAPI) format. The SWRL rules are parsed by the ontology model with "SWRLAPIOntology" (An interface provided by SWRLAPI) format. Afterwards, a new ontology model with "OWLOntology" format loads all the rules and is converted to "OntModel" format.
According to the specification of "OntModel", it is an extension to the "InfModel" interface and supports to wrap the abstract syntax of "OntModel" in an RDF graph [71,72]. With the help of this feature, SWRL rules can be wrapped in a RDF graph as well. The rule graph and the ontology graph are independently existed, which means that users may manipulate the SWRL rules without modifying the original SWARMs ontology. Both SWARMs ontology and SWRL rules can be understood in a human-readable manner. The key part of a rule graph is given in Figure 14.
In Figure 14, the atoms of SWRL rules are mapped to RDF triples. The above figure represents the rule Listing (4) in RDF graph. Clearly, the graph consists of two main parts, including the antecedent and consequent. In the body of antecedent, the predicates indicated by the SWRL rule is "RoboticVehicle" and "vehicleBatteryLevel". Meanwhile, the graph includes a Built-in for comparisons which is "greaterThan". Thus, the antecedent represents that comparing the battery level of a robotic vehicle, it should be greater than 30.0. In the body of consequent, the predicate is named "RobotCandidateForMission" and it suggests that if the robotic vehicle fulfills the In the SWARMs project, the Jena Ontology API [68], OWLAPI [69], and SWRLAPI [70] have been used to manipulate the SWARMs ontology and SWRL rules.
In Figure 13, the steps for model transformations with the purpose of inserting SWRL rules are shown. Normally, the ontology model is fixed and does not allow users to make any modifications, due to the fact that the whole SWARMs ontology is carefully designed and implemented by experts, thus containing highly professional knowledge. The source code of the SWARMs ontology is not fully public and all we receive from the remote server is an ontology file with the "OntModel" (An interface provided by Jena Ontology API) format. However, SWRL rules cannot be directly inserted into the "OntModel". Therefore, the original ontology model with "OntModel" format has to be converted to the "OWLOntology" (An interface provided by OWLAPI) format. The SWRL rules are parsed by the ontology model with "SWRLAPIOntology" (An interface provided by SWRLAPI) format. Afterwards, a new ontology model with "OWLOntology" format loads all the rules and is converted to "OntModel" format.
According to the specification of "OntModel", it is an extension to the "InfModel" interface and supports to wrap the abstract syntax of "OntModel" in an RDF graph [71,72]. With the help of this feature, SWRL rules can be wrapped in a RDF graph as well. The rule graph and the ontology graph are independently existed, which means that users may manipulate the SWRL rules without modifying the original SWARMs ontology. Both SWARMs ontology and SWRL rules can be understood in a human-readable manner. The key part of a rule graph is given in Figure 14.
In Figure 14, the atoms of SWRL rules are mapped to RDF triples. The above figure represents the rule Listing (4) in RDF graph. Clearly, the graph consists of two main parts, including the antecedent and consequent. In the body of antecedent, the predicates indicated by the SWRL rule is "RoboticVehicle" and "vehicleBatteryLevel". Meanwhile, the graph includes a Built-in for comparisons which is "greaterThan". Thus, the antecedent represents that comparing the battery level of a robotic vehicle, it should be greater than 30.0. In the body of consequent, the predicate is named "RobotCandidateForMission" and it suggests that if the robotic vehicle fulfills the requirement specified in the antecedent, then this vehicle is a potential candidate to execute a mission. Conclusively, the graph represents that if the battery level of a robotic vehicle is greater than 30.0, then this vehicle will be selected as a candidate for one mission.
Generally, after mapping the SWRL rules to RDF triples, the rules are ready to use by the rule-based reasoner in the inference stage. requirement specified in the antecedent, then this vehicle is a potential candidate to execute a mission. Conclusively, the graph represents that if the battery level of a robotic vehicle is greater than 30.0, then this vehicle will be selected as a candidate for one mission. Generally, after mapping the SWRL rules to RDF triples, the rules are ready to use by the rulebased reasoner in the inference stage.

Rule-Based Reasoner for Inference
After inserting SWRL rules into the ontology model, the SWARMs ontology is able to connect with a reasoner and generate inference results. This paper proposes a rule-based reasoner to provide SWARMs users with the query services. The rule-based reasoner is a particular type of reasoning approach which uses "If-Then-Else" statements and offers two reasoning strategies, including forward chaining and backward chaining strategies. Generally, the rule-based reasoner is on the basis of initial facts (provided by the SWARMs ontology) and rules (provided by the SWRL rule base). The detail of connection between the rule-based reasoner and SWARMs ontology is shown in Figure 15.
In Figure 15, it is displayed how the knowledge from domain-specific ontologies and SWRL rules are going through corresponding parsers in order to generate initial facts and the rule base respectively. Then, the inference engine loads all the facts and rules and performs rule-based reasoning. The inference results are added as new knowledge into the SWARMs ontology after format conversions.

Rule-Based Reasoner for Inference
After inserting SWRL rules into the ontology model, the SWARMs ontology is able to connect with a reasoner and generate inference results. This paper proposes a rule-based reasoner to provide SWARMs users with the query services. The rule-based reasoner is a particular type of reasoning approach which uses "If-Then-Else" statements and offers two reasoning strategies, including forward chaining and backward chaining strategies. Generally, the rule-based reasoner is on the basis of initial facts (provided by the SWARMs ontology) and rules (provided by the SWRL rule base). The detail of connection between the rule-based reasoner and SWARMs ontology is shown in Figure 15.
In Figure 15, it is displayed how the knowledge from domain-specific ontologies and SWRL rules are going through corresponding parsers in order to generate initial facts and the rule base respectively. Then, the inference engine loads all the facts and rules and performs rule-based reasoning. The inference results are added as new knowledge into the SWARMs ontology after format conversions.
The rule-based reasoner is on the basis of Jena inference framework [73]. The details of rule-based reasoner is shown in Figure 16.
In Figure 16, the rule-based reasoner is firstly registered through the reasoner registry module (provided by Jena). Meanwhile, the "ModelFactory" creates a new "OntModel" for the associated reasoner to read knowledge of the ontology. Once the rule-based reasoner is in the reasoner list, ontology graph and rules graph are then loaded in the reasoner for preparation of reasoning. An inference graph is generated and provides the inference results which are reasoned by the rule-based reasoner through forward and backward chaining strategies [74,75]. The rule-based reasoner is on the basis of Jena inference framework [73]. The details of rulebased reasoner is shown in Figure 16. In Figure 16, the rule-based reasoner is firstly registered through the reasoner registry module (provided by Jena). Meanwhile, the "ModelFactory" creates a new "OntModel" for the associated reasoner to read knowledge of the ontology. Once the rule-based reasoner is in the reasoner list, ontology graph and rules graph are then loaded in the reasoner for preparation of reasoning. An inference graph is generated and provides the inference results which are reasoned by the rule-based reasoner through forward and backward chaining strategies [74,75].

Query Service
The query service is provided for SWARMs users through Apache Jena Fuseki [76]. The Apache Jena Fuseki is basically a SPARQL server and is able to load all the triples of SWARMs ontology in a RDF graph shown in Figure 17. The rule-based reasoner is on the basis of Jena inference framework [73]. The details of rulebased reasoner is shown in Figure 16. In Figure 16, the rule-based reasoner is firstly registered through the reasoner registry module (provided by Jena). Meanwhile, the "ModelFactory" creates a new "OntModel" for the associated reasoner to read knowledge of the ontology. Once the rule-based reasoner is in the reasoner list, ontology graph and rules graph are then loaded in the reasoner for preparation of reasoning. An inference graph is generated and provides the inference results which are reasoned by the rule-based reasoner through forward and backward chaining strategies [74,75].

Query Service
The query service is provided for SWARMs users through Apache Jena Fuseki [76]. The Apache Jena Fuseki is basically a SPARQL server and is able to load all the triples of SWARMs ontology in a RDF graph shown in Figure 17.

Query Service
The query service is provided for SWARMs users through Apache Jena Fuseki [76]. The Apache Jena Fuseki is basically a SPARQL server and is able to load all the triples of SWARMs ontology in a RDF graph shown in Figure 17. The implementation of the query service is shown in Figure 18. The query service is implemented by the programming language Java. In Figure 18, the lightyellow round icons represent the interfaces and the dark-yellow rectangle icons represent components (implemented by Java classes). The SWARMs users request the queries through the component "QueryService" and write the SPARQL queries. As is mentioned in Section 3.3, the SWRL rules are created through the component "Rules&PoliciesCreator" and the rule-based reasoner is registered through the interface "ReasonerInterface". Then, the component "Reasoner" is able to infer the query based on the existing knowledge and user-defined SWRL rules. The query results are lastly returned to the component "QueryService".
There exists two types of query services, including the simple query and complex query. The simple query refers to the query which does not need any inferences. It is only a query on existing information in the knowledge base. The complex query refers to the query which triggers the rule- The implementation of the query service is shown in Figure 18. The implementation of the query service is shown in Figure 18. The query service is implemented by the programming language Java. In Figure 18, the lightyellow round icons represent the interfaces and the dark-yellow rectangle icons represent components (implemented by Java classes). The SWARMs users request the queries through the component "QueryService" and write the SPARQL queries. As is mentioned in Section 3.3, the SWRL rules are created through the component "Rules&PoliciesCreator" and the rule-based reasoner is registered through the interface "ReasonerInterface". Then, the component "Reasoner" is able to infer the query based on the existing knowledge and user-defined SWRL rules. The query results are lastly returned to the component "QueryService".
There exists two types of query services, including the simple query and complex query. The simple query refers to the query which does not need any inferences. It is only a query on existing information in the knowledge base. The complex query refers to the query which triggers the rule- The query service is implemented by the programming language Java. In Figure 18, the light-yellow round icons represent the interfaces and the dark-yellow rectangle icons represent components (implemented by Java classes). The SWARMs users request the queries through the component "QueryService" and write the SPARQL queries. As is mentioned in Section 3.3, the SWRL rules are created through the component "Rules&PoliciesCreator" and the rule-based reasoner is registered through the interface "ReasonerInterface". Then, the component "Reasoner" is able to infer the query based on the existing knowledge and user-defined SWRL rules. The query results are lastly returned to the component "QueryService".
There exists two types of query services, including the simple query and complex query. The simple query refers to the query which does not need any inferences. It is only a query on existing information in the knowledge base. The complex query refers to the query which triggers the rule-based reasoner. It involves the inferring process on the knowledge and may lead to changes on the knowledge base. The detail of these two queries are explained in the following sub-sections.

Simple Query
If the query requested by SWARMs users is just to check existing knowledge in the ontology, then it is unnecessary to trigger the rule-based reasoner for inference. For example, a SWARMs user wants to query on all robotic vehicles which are available for executing certain missions, or the SWARMs user wants to check the remaining battery of certain vehicles. Under this circumstance, this information is already presented in the SWARMs ontology. Thus, the query results can be obtained without using the rule-based reasoner.

Complex Query
Regarding the complex query, it is not a simple query on existing knowledge and it requires the rule-based reasoner for inferring new knowledge. For example, UAV 1 and 2 are involved in a mission and a SWARMs user has doubts on the mission candidates, the user wonders that if UAV 2 can be replaced by UAV 3. Under this circumstance, the rule-based reasoner has to infer the possibility of such replacement based on the status of each UAV and check that whether this substitution is feasible or not. Meanwhile, the SWARMs users may occasionally request a query with plenty of restraints. Some of the restraints may be in conflict with each other, leading to failure of query. Thus, the rule-based reasoner should check that whether the query is correct or not.

Evaluation and Results
The rule-based reasoner is evaluated by the following aspects. Firstly, the insertion of SWRL rules into the SWARMs ontology is tested. Secondly, the efficiency of rules insertion is recorded. Thirdly, the simple queries and complex queries are requested to verify the correctness of query results. The detail of evaluation is described in the following sub-sections.

Verification of Inserting SWRL Rules
At first, the configuration file (rule file) is given by the SWARMs users. We are testing two rule files, containing a single rule and multiple rules, respectively. The rule files are shown in Figure 19. based reasoner. It involves the inferring process on the knowledge and may lead to changes on the knowledge base. The detail of these two queries are explained in the following sub-sections.

Simple Query
If the query requested by SWARMs users is just to check existing knowledge in the ontology, then it is unnecessary to trigger the rule-based reasoner for inference. For example, a SWARMs user wants to query on all robotic vehicles which are available for executing certain missions, or the SWARMs user wants to check the remaining battery of certain vehicles. Under this circumstance, this information is already presented in the SWARMs ontology. Thus, the query results can be obtained without using the rule-based reasoner.

Complex Query
Regarding the complex query, it is not a simple query on existing knowledge and it requires the rule-based reasoner for inferring new knowledge. For example, UAV 1 and 2 are involved in a mission and a SWARMs user has doubts on the mission candidates, the user wonders that if UAV 2 can be replaced by UAV 3. Under this circumstance, the rule-based reasoner has to infer the possibility of such replacement based on the status of each UAV and check that whether this substitution is feasible or not. Meanwhile, the SWARMs users may occasionally request a query with plenty of restraints. Some of the restraints may be in conflict with each other, leading to failure of query. Thus, the rule-based reasoner should check that whether the query is correct or not.

Evaluation and Results
The rule-based reasoner is evaluated by the following aspects. Firstly, the insertion of SWRL rules into the SWARMs ontology is tested. Secondly, the efficiency of rules insertion is recorded. Thirdly, the simple queries and complex queries are requested to verify the correctness of query results. The detail of evaluation is described in the following sub-sections.

Verification of Inserting SWRL Rules
At first, the configuration file (rule file) is given by the SWARMs users. We are testing two rule files, containing a single rule and multiple rules, respectively. The rule files are shown in Figure 19. After uploading the SWARMs ontology to the Apache Jena Fuseki and executing the Java class "PoliciesRulesCreator" (mentioned in Figure 18), the SWRL rules are correctly and fully inserted as a rule graph. The results are shown in Figure 20.
In Figure 20, the number of triples in the rule graph for a single rule is 40 and the number of triples for multiple rules is 143. The content of rule graph is basically the same as the one shown in Figure 14. The results show that the SWRL rules are successfully inserted. After uploading the SWARMs ontology to the Apache Jena Fuseki and executing the Java class "PoliciesRulesCreator" (mentioned in Figure 18), the SWRL rules are correctly and fully inserted as a rule graph. The results are shown in Figure 20.
In Figure 20, the number of triples in the rule graph for a single rule is 40 and the number of triples for multiple rules is 143. The content of rule graph is basically the same as the one shown in Figure 14. The results show that the SWRL rules are successfully inserted. Then, the efficiency of SWRL rules insertion is recorded. In this case, we are testing the rule files which contain 50 rules for three rounds. For each round, a single rule consists of three, four, and five atoms, respectively. The example rules in the rule file for each round are shown in Listing (10)- (12).
The efficiency of rules insertion is evaluated by the processing time. The result is shown in Figure  21. In Figure 21, all the SWRL rules are successfully inserted in a very short time. Obviously, more atoms in a single rule, more time is needed. Even a rule consists of five atoms, all the 50 rules can be processed within 60 milliseconds. Compared with inserting SWRL rules by editing in Protégé, the proposed approach is able to insert multiple rules conveniently and efficiently.

Verification of Querying the Udated SWARMs Ontology
As is mentioned in the previous sections, the rule-based reasoner provides the SWARMs users with query services. In this section, the simple query and complex query are testified respectively. Firstly, in the SWARMs ontology, four instantiated models of robotic vehicles are defined (See Figure  22). Each robotic vehicle model clearly indicates its properties and capabilities (See Figure 23).  Then, the efficiency of SWRL rules insertion is recorded. In this case, we are testing the rule files which contain 50 rules for three rounds. For each round, a single rule consists of three, four, and five atoms, respectively. The example rules in the rule file for each round are shown in Listing (10)- (12).
The efficiency of rules insertion is evaluated by the processing time. The result is shown in Figure 21. Then, the efficiency of SWRL rules insertion is recorded. In this case, we are testing the rule files which contain 50 rules for three rounds. For each round, a single rule consists of three, four, and five atoms, respectively. The example rules in the rule file for each round are shown in Listing (10)- (12).
The efficiency of rules insertion is evaluated by the processing time. The result is shown in Figure  21. In Figure 21, all the SWRL rules are successfully inserted in a very short time. Obviously, more atoms in a single rule, more time is needed. Even a rule consists of five atoms, all the 50 rules can be processed within 60 milliseconds. Compared with inserting SWRL rules by editing in Protégé, the proposed approach is able to insert multiple rules conveniently and efficiently.

Verification of Querying the Udated SWARMs Ontology
As is mentioned in the previous sections, the rule-based reasoner provides the SWARMs users with query services. In this section, the simple query and complex query are testified respectively. Firstly, in the SWARMs ontology, four instantiated models of robotic vehicles are defined (See Figure  22). Each robotic vehicle model clearly indicates its properties and capabilities (See Figure 23).  In Figure 21, all the SWRL rules are successfully inserted in a very short time. Obviously, more atoms in a single rule, more time is needed. Even a rule consists of five atoms, all the 50 rules can be processed within 60 milliseconds. Compared with inserting SWRL rules by editing in Protégé, the proposed approach is able to insert multiple rules conveniently and efficiently.

Verification of Querying the Udated SWARMs Ontology
As is mentioned in the previous sections, the rule-based reasoner provides the SWARMs users with query services. In this section, the simple query and complex query are testified respectively. Firstly, in the SWARMs ontology, four instantiated models of robotic vehicles are defined (See Figure 22). Each robotic vehicle model clearly indicates its properties and capabilities (See Figure 23). Regarding the simple query, it is requested to select the qualified mission candidates. It is assumed that the robotic vehicle with remaining battery power greater than 30.0 will then be selected as a mission candidate. The SPARQL query and the result is shown in Figure 24. Obviously, in Figure 23, the battery levels of SAGA and A9 are 122.0 and 65.0, respectively. Meanwhile, the battery levels of SUSV and ATN50 are both 4.5. Thus, the robotic vehicles SAGA and A9 fulfill the requirement of being a mission candidate and the query result suggests the same (see Figure 24). Regarding the simple query, it is requested to select the qualified mission candidates. It is assumed that the robotic vehicle with remaining battery power greater than 30.0 will then be selected as a mission candidate. The SPARQL query and the result is shown in Figure 24. Obviously, in Figure 23, the battery levels of SAGA and A9 are 122.0 and 65.0, respectively. Meanwhile, the battery levels of SUSV and ATN50 are both 4.5. Thus, the robotic vehicles SAGA and A9 fulfill the requirement of being a mission candidate and the query result suggests the same (see Figure 24). Regarding the simple query, it is requested to select the qualified mission candidates. It is assumed that the robotic vehicle with remaining battery power greater than 30.0 will then be selected as a mission candidate. The SPARQL query and the result is shown in Figure 24. Regarding the simple query, it is requested to select the qualified mission candidates. It is assumed that the robotic vehicle with remaining battery power greater than 30.0 will then be selected as a mission candidate. The SPARQL query and the result is shown in Figure 24. Obviously, in Figure 23, the battery levels of SAGA and A9 are 122.0 and 65.0, respectively. Meanwhile, the battery levels of SUSV and ATN50 are both 4.5. Thus, the robotic vehicles SAGA and A9 fulfill the requirement of being a mission candidate and the query result suggests the same (see Figure 24). Obviously, in Figure 23, the battery levels of SAGA and A9 are 122.0 and 65.0, respectively. Meanwhile, the battery levels of SUSV and ATN50 are both 4.5. Thus, the robotic vehicles SAGA and A9 fulfill the requirement of being a mission candidate and the query result suggests the same (see Figure 24).
Another simple query is also requested by the SWARMs users to check the available ROVs in the SWARMs ontology. According to the specifications of robotic vehicles, SAGA and ATN50 both belong to the class "ROV". The SPARQL query and the result is shown in Figure 25. Another simple query is also requested by the SWARMs users to check the available ROVs in the SWARMs ontology. According to the specifications of robotic vehicles, SAGA and ATN50 both belong to the class "ROV". The SPARQL query and the result is shown in Figure 25.
The base station is located at 43°48′25.1″ N 28°34′57.1″ E and the current position of the robotic vehicle is located at 43°47′52.0″ N 28°35′55.0″ E (see Figure 26). These two locations are near the Mangalia coast in Romania. It is assumed that the robotic vehicle SUSV is executing a certain mission and the human operator requests the query for the safely return of SUSV. The SPARQL query and result is shown in Figure 27.   Figure 26). These two locations are near the Mangalia coast in Romania. It is assumed that the robotic vehicle SUSV is executing a certain mission and the human operator requests the query for the safely return of SUSV. The SPARQL query and result is shown in Figure 27. Another simple query is also requested by the SWARMs users to check the available ROVs in the SWARMs ontology. According to the specifications of robotic vehicles, SAGA and ATN50 both belong to the class "ROV". The SPARQL query and the result is shown in Figure 25. Regarding the complex query, it is requested to check whether a robotic vehicle can return to the base safely or not. The return depends on the current position, speed, and battery remaining of the robotic vehicle and the base position. During runtime, a human operator can request such query for the purpose of property loss. A SWRL rule for determining the safely return is shown in Listing (13).
The base station is located at 43°48′25.1″ N 28°34′57.1″ E and the current position of the robotic vehicle is located at 43°47′52.0″ N 28°35′55.0″ E (see Figure 26). These two locations are near the Mangalia coast in Romania. It is assumed that the robotic vehicle SUSV is executing a certain mission and the human operator requests the query for the safely return of SUSV. The SPARQL query and result is shown in Figure 27.   In Figure 27, it is depicted that the robotic vehicle SUSV is unable to return back to base safely and corresponding alarm alert is triggered. Obviously, the robotic vehicle SUSV lacks of energy resources according to battery level shown in Figure 23a. Thus, the query result is correct.
Conclusively, the rule-based reasoner is able to perform the reasoning based on the knowledge base and rule base. The inference results can provide the SWARMs users with query services efficiently and intelligently.

Conclusions and Future Work
The main focus of our work is on the SWRL rules insertions and the query service provided by the rule-based reasoner, along with the detailed implementation. The conclusion of our contribution and future work are summarized in the following sub-sections respectively.

Conclusions
Generally, this paper introduces the OWL-based SWARMs ontology as an information model to enable heterogeneous robotic vehicles to obtain a common understanding of shared knowledge. After analyzing the drawbacks of OWL-based ontology, inserting SWRL rules are proposed as an approach to enhance the expression capability of OWL-based ontology. A rules insertion mechanism is designed specifically for the insertions of multiple SWRL rules. This mechanism allows SWARMs users to efficiently insert multiple rules through a text file at once, instead of inserting the rules one by one in a specific editor. Once all the rules are successfully inserted to the rule base, a rule-based reasoner is able to provide the SWARMs users with query services to know exactly the status of robotic vehicles and desired information of underwater environment. Lastly, experimental tests are performed to verify the proposed rules insertion mechanism and the rule-based reasoner. The experimental results indicate the feasibility and usability of the proposed mechanism and reasoner. Our contribution can be summarized in detail as follows:

•
The SWARMs ontology is on the basis of the Web Ontology Language (OWL) and it is capable of representing complex models and address heterogeneous information of the underwater environment and autonomous robots. Therefore, the SWARMs project selects OWL to model the information within the platform. The SWARMs ontology consists of one core ontology and four domain-specific ontologies, including the communication, environment, mission planning, and robotic vehicles domains. As an information model, the SWARMs ontology enables the knowledge sharing and information abstractions in specific domains to help heterogeneous robotic vehicles obtaining a common understanding of shared knowledge. With the help of SWARMs ontology, various robotic vehicles could work with each other for the purpose of completing complex underwater and maritime missions cooperatively. Based on the successful In Figure 27, it is depicted that the robotic vehicle SUSV is unable to return back to base safely and corresponding alarm alert is triggered. Obviously, the robotic vehicle SUSV lacks of energy resources according to battery level shown in Figure 23a. Thus, the query result is correct.
Conclusively, the rule-based reasoner is able to perform the reasoning based on the knowledge base and rule base. The inference results can provide the SWARMs users with query services efficiently and intelligently.

Conclusions and Future Work
The main focus of our work is on the SWRL rules insertions and the query service provided by the rule-based reasoner, along with the detailed implementation. The conclusion of our contribution and future work are summarized in the following sub-sections respectively.

Conclusions
Generally, this paper introduces the OWL-based SWARMs ontology as an information model to enable heterogeneous robotic vehicles to obtain a common understanding of shared knowledge. After analyzing the drawbacks of OWL-based ontology, inserting SWRL rules are proposed as an approach to enhance the expression capability of OWL-based ontology. A rules insertion mechanism is designed specifically for the insertions of multiple SWRL rules. This mechanism allows SWARMs users to efficiently insert multiple rules through a text file at once, instead of inserting the rules one by one in a specific editor. Once all the rules are successfully inserted to the rule base, a rule-based reasoner is able to provide the SWARMs users with query services to know exactly the status of robotic vehicles and desired information of underwater environment. Lastly, experimental tests are performed to verify the proposed rules insertion mechanism and the rule-based reasoner. The experimental results indicate the feasibility and usability of the proposed mechanism and reasoner. Our contribution can be summarized in detail as follows:

•
The SWARMs ontology is on the basis of the Web Ontology Language (OWL) and it is capable of representing complex models and address heterogeneous information of the underwater environment and autonomous robots. Therefore, the SWARMs project selects OWL to model the information within the platform. The SWARMs ontology consists of one core ontology and four domain-specific ontologies, including the communication, environment, mission planning, and robotic vehicles domains. As an information model, the SWARMs ontology enables the knowledge sharing and information abstractions in specific domains to help heterogeneous robotic vehicles obtaining a common understanding of shared knowledge. With the help of SWARMs ontology, various robotic vehicles could work with each other for the purpose of completing complex underwater and maritime missions cooperatively. Based on the successful experience of modelling the SWARMs ontology, OWL is a promising approach to represent information of complex environments and robotic vehicles.

•
The Semantic Web Rule Language (SWRL) is combined with the SWAMRs ontology for the purpose of overcoming the drawbacks of OWL-based ontologies. OWL-based ontologies cannot represent the general rules, however, with the help of SWRL rules, marine experts and human operators are able to turn their knowledge and experience as user-defined rules and insert them into the SWARMs ontology during runtime. All the SWRL rules are manipulated in a text file before insertion. A rules insertion mechanism is designed and implemented in this paper. The proposed mechanism specifies several steps of model transformations to convert the SWARMs ontology between different formats for the possibility of rule insertions. It is worth noting that the rules insertion mechanism allow SWARMs users to insert multiple rules in one time, which greatly increases the efficiency of rules insertion. Conclusively, SWRL rules could enable the OWL-based ontologies to represent general rules and enhance the completeness of ontologies. Compared with inserting the SWRL rules in a specific editor, the proposed approach does not require the SWARMs users to have knowledge about the editors. Meanwhile, the proposed rules insertion mechanism is more efficient and convenient. • A rule-based reasoner is implemented to provide the SWARMs users with query services. In the reasoning module, the initial facts of SWARMs ontology and user-defined SWRL rules are loaded to the inference engine from the knowledge base and rule base respectively. Then, the rule-based reasoner is able to perform the inference and generate query results. In this paper, the query service is provided by Apache Jena Fuseki. After all the triples of SWARMs ontology and SWRL rules are loaded in the server, the SWARMs users can write SPARQL queries and request inference results. The query services not only can check the status of robotic vehicles and environment information, but are also able to give feedback to the users regarding the emergency events and decision corrections. It is concluded that the rule-based reasoner is a promising approach to increase the inference capability of SWARMs ontology and provide the SWARMs users with precise query services. • Lastly, experimental tests are performed in order to verify the proposed rules insertion mechanism and the rule-based reasoner. In this paper, the success of rules insertion and the insertion efficiency are tested. No matter inserting a single rule or multiple rules at once, the successful insertions are ensured with high efficiency. Afterwards, the rule-based reasoner is testified by requesting simple and complex queries. The query results are totally correct. Consequently, the rules insertion mechanism and rule-based reasoner are feasible and useful for the SWARMs project.

Future Work
Though the SWRL rules are able to enhance the expression capability of OWL-based ontologies and the rule-based reasoner is a promising approach for providing the SWARMs users with a convenient query services, further developments are still pending to be implemented for the purpose of improving the SWARMs ontology, SWRL rules, and rule-based reasoner. The future work is summarized as follows: • Firstly, regarding OWL, it is necessary to extend and enrich the SWARMs ontology with more elements, such as various robotic vehicles, communication approaches, user cases, and environment landmarks. Meanwhile, though the SWARMs ontology is designed to provide a common information model for underwater environment and robotic vehicles, the reusability of such ontology should be taken into consideration for other underwater robotics projects. • Secondly, it is worth exploring the extensibility of SWRL rules. Apart from the expressions of general rules, statistics-based uncertainty also existed in the SWARMs project. It is promising to implement a probabilistic extension of SWRL to deal with the incomplete or partial knowledge. With the help of probabilistic extension, certain reasoning algorithms (such as Multi-Entity Bayesian Network algorithm) could be executed in order to infer uncertainties, providing an improved query services to the SWARMs users. • Thirdly, a conflict-free mechanism for rules insertion should be developed in order to avoid the redundancy and complexity of the rule base. Repeated rules and conflict rules may result in difficulties for the rule-based reasoner to understand and perform inferences. The conflict-free mechanism aims at filtering the SWRL rules and eliminating unnecessary ones, keeping the simplicity of the rule base in this way.