Researchers and practitioners in the field of knowledge graphs rely on a variety of tools to perform knowledge graph alignment. In order to broaden the domain of a knowledge scientist, the process of aligning knowledge graphs must be accessible to a broader range of users, and in a way that can scale to meet the needs of a growing userbase. This paper presents a cloud-based, language agnostic approach that aims at providing knowledge graph alignment tooling at scale.
CEUR Workshop Proceedings 1The term knowledge graph alignment supersedes the notion of ontology alignment or matching to emphasise the need of aligning not only the terminological part (i.e., concepts and relationships), but also the data (i.e., instances of the concepts). with the MELT platform, one must first use Maven to produce Docker images, then provide the images to the MELT client. This is useful because any matching system could be swapped into the MELT client as a Docker image, provided it meets the contract, but it does not solve the problem of a zero-dependency alignment system.
This paper presents a proof of concept system that provides the matching functionality of L o g M a p over a HTTP RESTful API. This gives the consumer absolute control and agency over how to integrate with L o g M a p in a way that best fits their use case - decoupling L o g M a p from any programming language or paradigm. A Web app has also been produced that consumes the new API, meaning that a user can use a UI on the Web to perform alignments if this is preferable to a programmatic approach.
The proposed Knowledge Graph Alignment as a Service (K G A S ) system is comprised of 3 individual containerised applications (see Figure 1), deployed onto cloud infrastructure using Azure. Azure is the cloud provider chosen to host the working proof of concept on the Web, but the system is designed such that it could be deployed anywhere, be that to another cloud provider or run on a local server. It was important not to change L o g M a p ’s source code directly for the project. The purpose of the proof of concept is to show that the functionality of alignment tools can be exposed without impacting the implementation. This way L o g M a p can still be developed as a standalone tool, and K G A S will continue to work alongside it without needing to make changes. This was achieved by creating a Docker image that clones L o g M a p ’s source code from Git using the latest commit hash, and builds the application from source. This means that if a new release of L o g M a p were to be made, the app could simply rebuild with the new commit hash and users get the latest version of L o g M a p immediately. Once there is a dockerised version of L o g M a p running in a container, the REST API needs to be able to use that app. Since the API runs in a diferent container to L o g M a p , there needs to be an interface for them to communicate. The L o g M a p container exposes a port accepting SSH connections for this, which enables the CLI commands to be run by the REST server via SSH. 2.1. Cloud Implementation The containerised applications are platform-agnostic, however, in order to serve the KG alignment outputs as zip files, some external storage is required, which is where the proof of concept becomes coupled to Azure. When a user starts an alignment via the API, a unique ID is generated for the process. This is the ID a user will query against to retrieve the results of the alignment, and also represents the file name used when writing to the remote storage.
For the project to be a success, the solution must be repeatable. To ensure this, all of the cloud resources were created using Infrastructure as Code (IaC); specifically, Terraform. 3 This means that with access to the codebase anyone could spin up their own version of K G A S on their own infrastructure. This provides a wide range of benefits to maintainability of the project as well as scalability.
The K G A S Web app created for the proof of concept is a small React application4 with a UI allowing a user to upload two KGs for alignment, begin the alignment, and query for results of ongoing or previously completed alignments by their id (see Figure 2). The UI will store the alignment ID in the browser’s storage, so there is no requirement for a user to remember them. The Web app’s purpose is twofold. Firstly, to present a zero-dependency, out of the box way to perform KG alignment. Secondly, it serves as an exemplar piece on how to integrate with the REST API to access L o g M a p ’s functionality and retrieve alignment results. This will be helpful for those wishing to integrate with the API programmatically, for example when running an alignment in a Python script.
The working concept shows that KG alignment can be decoupled from its implementation and provided to consumers. This iteration is limited to L o g M a p specifically, but the same process of containerising and wrapping in a REST API layer can be applied to any alignment system. L o g M a p itself has more functionality than that which is exposed by K G A S , including the repair of a given alignment or the division of the KG alignment process into subtasks. Exposing these additional behaviours only requires a more mature API, where various parameters or configurations can be passed as arguments. The most significant room for expansion is to decouple from L o g M a p altogether. Currently K G A S relies on ssh-ing into a machine with the L o g M a p CLI, then running L o g M a p specific commands inside that machine. If the interface through which alignments were performed could be generalised, then K G A S would not need to know specific commands for any 3https://www.terraform.io/ 4https://reactjs.org/ of the systems. The MELT platform provides exactly this. MELT relies on being provided a Docker image for an alignment tool, which it will use for alignment using its common interface. A container could be created ro run MELT and include pre-made images saved to the disk that are compatible with MELT (many of these already exist). Then the API layer only needs to know the CLI commands to interact with MELT, and it can use any one of the alignment tools baked into the image. This will enable a comprehensive KG alignment API where a user can pick and choose the best tool for their use case on demand without having to learn or use any additional technologies. It will also provide a platform where the various tools can be compared with one another, since they will all be in one place and running on the same hardware. The working concept in this demo shows that such a system is within reach.
For the demonstration, we will upload to the Web app KGs from the Ontology Alignment Evaluation Initiative5 like the h u m a n . o w l and m o u s e . o w l anatomy ontologies.
The Web app will begin the alignment and display the id. It will then begin polling for results
until the alignment completes, at which point the UI will present a button to download the
alignment output as a zip file, which can be extracted to view the individual files. In the case of
L o g M a p , the alignment output is composed by the following files:
• l o g m a p 2 _ m a p p i n g s in table format (.txt and .tsv), OWL format (.owl), and RDF alignment6
format (.rdf): final output mappings selected by L o g M a p .
• l o g m a p _ a n c h o r s (same formats as above): mappings computed by L o g M a p with very high
confidence.
• l o g m a p _ d i s c a r d e d _ m a p p i n g s . t x t and l o g m a p _ h a r d _ d i s c a r d e d _ m a p p i n g s . t x t : set of
mapping that were considered by LogMap but eventually discarded.
• l o g m a p _ l o g i c a l l y _ c o n f l i c t i n g _ m a p p i n g s . t x t : mappings that were discarded during the
logic-based repair process [
The demo will be performed within a Web browser, and no additional dependencies will be required. The K G A S source code, API documentation and links to the Web app and REST API are available on GitHub: https://github.com/rupson/knowledge-graph-alignment-as-a-service.