LogMap family participation in the OAEI 2018

We present the participation of LogMap and its variants in the OAEI 2018 campaign. The LogMap project started in January 2011 with the objective of developing a scalable and logic-based ontology matching system. This is our eight participation in the OAEI and the experience has so far been very positive. LogMap is one of the few systems that participates in (almost) all OAEI tracks. 1 Presentation of the system LogMap [11, 13] is a highly scalable ontology matching system that implements the consistency and locality principles [12]. LogMap also supports (real-time) user interaction during the matching process, which is essential for use cases requiring very accurate mappings. LogMap is one of the few ontology matching system that (i) can efficiently match semantically rich ontologies containing tens (and even hundreds) of thousands of classes, (ii) incorporates sophisticated reasoning and repair techniques to minimise the number of logical inconsistencies, and (iii) provides support for user intervention during the matching process. LogMap relies on the following elements, which are keys to its favourable scalability behaviour (see [11, 13] for details). Lexical indexation. An inverted index is used to store the lexical information contained in the input ontologies. This index is the key to efficiently computing an initial set of mappings of manageable size. Similar indexes have been successfully used in information retrieval and search engine technologies [2]. Logic-based module extraction. The practical feasibility of unsatisfiability detection and repair critically depends on the size of the input ontologies. To reduce the size of the problem, we exploit ontology modularisation techniques. Ontology modules with well-understood semantic properties can be efficiently computed and are typically much smaller than the input ontology (e.g. [5]). Propositional Horn reasoning. The relevant modules in the input ontologies together with (a subset of) the candidate mappings are encoded in LogMap using a Horn propositional representation. Furthermore, LogMap implements the classic Dowling-Gallier algorithm for propositional Horn satisfiability [6]. Such encoding, although incomplete, allows LogMap to detect unsatisfiable classes soundly and efficiently. Axiom tracking. LogMap extends Dowling-Gallier’s algorithm to track all mappings that may be involved in the unsatisfiability of a class. This extension is key to implementing a highly scalable repair algorithm. Local repair. LogMap performs a greedy local repair; that is, it repairs unsatisfiabilities on-the-fly and only looks for the first available repair plan. Semantic indexation. The Horn propositional representation of the ontology modules and the mappings is efficiently indexed using an interval labelling schema [1] — an optimised data structure for storing directed acyclic graphs (DAGs) that significantly reduces the cost of answering taxonomic queries [4, 19]. In particular, this semantic index allows us to answer many entailment queries as an index lookup operation over the input ontologies and the mappings computed thus far, and hence without the need for reasoning. The semantic index complements the use of the propositional encoding to detect and repair unsatisfiable classes. 1.1 LogMap variants in the 2018 campaign As in previous campaigns, in the OAEI 2018 we have participated with two additional variants: LogMapLt is a “lightweight” variant of LogMap, which essentially only applies (efficient) string matching techniques. LogMapBio includes an extension to use BioPortal [8, 9] as a (dynamic) provider of mediating ontologies instead of relying on a few preselected ontologies [3]. In previous years we also participated with LogMapC5. 1.2 Adaptations made for the 2018 evaluation LogMap’s algorithm described in [11, 13, 16, 15, 14] has been adapted with the following new functionalities: i HOBBIT adaptation. We have implemented the required interface classes to run LogMap under the HOBBIT platform.6 LogMap can currently be evaluated in five different tracks available in the HOBBIT platform.7 ii Ontology division module. This module extends LogMap’s ontology overlapping estimation module to compute a number of divisions of the input ontologies and to create a set of smaller matching subtasks [10]. iii Obsolete classes. We have extended the lexical and structural indexation modules to ignore classes in the ontology annotated as obsolete. 1.3 Link to the system and parameters file LogMap is open-source and released under GNU Lesser General Public License 3.0. 8 LogMap components and source code are available from the LogMap’s GitHub page: https://github.com/ernestojimenezruiz/logmap-matcher/. 5 LogMapC is a variant of LogMap which, in addition to the consistency and locality principles, also implements the conservativity principle (see details in [20–22, 18]). 6 https://gitlab.com/ernesto.jimenez. ruiz/logmap-hobbit 7 https://git.project-hobbit.eu/ernestoj/logmapsystem 8 http://www.gnu. org/licenses/ LogMap distributions can be easily customized through a configuration file containing the matching parameters. LogMap, including support for interactive ontology matching, can also be used directly through an AJAX-based Web interface: http://krrwebtools.cs. ox. ac.uk/. This interface has been very well received by the community since it was deployed in 2012. More than 3,000 requests coming from a broad range of users have been processed so far. 1.4 LogMap as a mapping repair system Only a very few systems participating in the OAEI competition implement repair techniques. As a result, existing matching systems (even those that typically achieve very high precision scores) compute mappings that lead in many cases to a large number of unsatisfiable classes. We believe that these systems could significantly improve their output if they were to implement repair techniques similar to those available in LogMap. Therefore, with the goal of providing a useful service to the community, we have made LogMap’s ontology repair module (LogMap-Repair) available as a self-contained software component that can be seamlessly integrated in most existing ontology matching systems [17, 7]. 1.5 LogMap as a matching task division system LogMap also includes a novel module to divide the ontology alignment task into (independent) manageable subtasks [10]. This component relies on LogMap’s lexical index, a neural embedding model [23] and locality-based modules [5]. This module can be integrated in existing ontology alignment systems as a external module. The preliminaty results in [10] are encouraging as the division enabled systems to complete some large-scale matching tasks. 2 General comments and conclusions Please refer to http://oaei.ontologymatching. org/2018/results/ for the results of the LogMap family in the OAEI 2018 campaign. 2.1 Comments on the results As in previous campaigns, LogMap has been one of the top systems and one of the few systems that participates in (almost) all tracks. Furthermore, it has also been one of the few systems implementing repair techniques and providing (almost) coherent mappings in all tracks. LogMap’s main weakness is that the computation of candidate mappings is based on the similarities between the vocabularies of the input ontologies; hence, in the cases where the ontologies are lexically disparate or do not provide enough lexical information LogMap is at a disadvantage.