ATBox matcher is a scalable system for instance (Abox) and schema (Tbox) matching. It uses two pipelines for generating candidates for the schema and instance matching, and utilizes the schema matches to further improve the instance correspondences. Using a string blocking method, ATBox is able to align large ontologies and can run on OAEI tracks like largebio and knowledge graph. The results look promising, but further features for better nding correct instance matches can be developed.
1.1
The overall matching strategy of ATBox is shown in gure 1. The Tbox and Abox have di erent processing pipelines but the correspondences are combined in the end to get the nal alignment.
Tbox matching is applied for all classes and properties (owl:ObjectProperty, owl:DatatypeProperty, and rdf:Property). They are retrieved by the jena1 methods OntModel.listClasses() and OntModel.listAllOntProperties(). 0 Copyright c 2020 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). 1 https://jena.apache.org
TBox1 TBox 2 ABox1 ABox 2
Stopword Extraction final alignment String Matching
Synonym
Extension Cardinality Filter Similar Neighbors
Filter Cosine Similarity
Filter
String Matching Instance Filter
Type Filter
Common
Properties Filter
The Tbox matching (classes and properties) starts with the stopword extraction. In some cases the labels and/or fragments (which we de ne as the part after the last hashtag symbol # or slash /) contains tokens which appears very often like class, infobox etc. If such tokens appears in more than 20 % of all classes/properties (considered separately), then it is extracted as a corpus speci c stop word. In case there are many such stop words, they are restricted to the ve most occurring ones.
The synonyms (used during string matching) are extracted from the English
Wiktionary to cover many di erent domains. The extraction is done with
DBnary [
The string matching contains multiple di erent steps which are shown in
table 1. All processing applies to rdfs:label and in case it is missing to the URI
fragment. If the extracted text is exactly the same, the generated
correspondence has a con dence of 1.0. During the normalization process, a word written
in camel case4 is separated with whitespace (e.g. hasAge to has Age) and
afterwards lowercased. In case some UTF-8 characters are not normalized, we apply
a normalization step for them (e.g. an accented character can be encoded in
multiple di erent ways in UTF-8). All possible punctuations are furthermore
removed and multiple whitespaces are combined into one. In case the
normalized text matches, a con dence of 0.9 is assigned. In the normalizeParentheses
step, all text within parentheses is removed. If the remaining normalized text
(same as in normalize step) is equal, it assigns a con dence of 0.8. The reason
behind is that many articles in KGs de ne concepts with same names to have the
discriminating term in parentheses e.g. \Harry Potter (character)" and \Harry
Potter ( lm series)". DefaultStopwords removes a given set of stopwords while
keeping all other processing steps as before (con dence is 0.7). In the last
processing step, the corpus speci c stopwords, extracted before, are also removed
and additionally allow a levenshtein distance[
All string processing steps are executed in order starting with the highest condence. If a match is found the remaining steps are also executed to nd possible other candidates. As an example, a correspondence like <Harry Potter,harry potter, =, 0.9> is already found, then the processing continues and also add <Harry Potter,Harry Potter(Book), =, 0.8> to the resulting alignment.
The instance matching (Abox - shown in the lower part of the gure 1) starts directly with the string matching component. It reuses the processing steps described in the previous section without the corpus dependent stopword removal and synonym replacement. The applied steps are shown in table 2. The rst four steps applies to the rdfs:label and if it is missing to the fragment of the URI. The con dence is decreasing with a step size of 0.1 starting with 1.0. In the second part, the additional properties skos:prefLabel and skos:altLabel are taken into account. If they match, the con dence is set to maximally 0.6 depending in which preprocessing step the match occurs. Once again, we allow matches which a lower con dence, even when a correspondence with a higher con dence is found. This increases the recall because it might be the case that the matched entity with a high con dence is not the best available match.
The string processing step generated an alignment with a high recall. All following steps try to increase the precision by generating additional con dences for each correspondence. This helps at the end of the processing pipeline to enforce a one to one alignment and selecting the right correspondence in 4 https://en.wikipedia.org/wiki/Camel_case
Processsing Con dence Property
equality 1.0 rdfs:label (or fragment)
normalize 0.9 rdfs:label (or fragment)
normalizeParentheses 0.8 rdfs:label (or fragment)
defaultStopwords 0.7 rdfs:label (or fragment)
equality 0.6 + skos:pre abel, skos:altLabel
normalize 0.5 + skos:pre abel, skos:altLabel
normalizeParentheses 0.4 + skos:pre abel, skos:altLabel
defaultStopwords 0.3 + skos:pre abel, skos:altLabel
case there are multiple target entities for one source entity (or the other way
around). Thus the following lters only add additional con dences (with the
addAdditionalConfidence function of YAAA [
All these lters are explained in the following. The similar neighbors lter uses the instance alignment (generated by the previous string processing step) to count for each instance correspondence how many resources or literals are shared between the two instances. Figure 2 shows an example where two neighbors are detected for correspondence <one:Harry Potter, two:Harry Potter> because the literal \blue" and the resource \Gry ndor" is shared. Note that the properties are not taken into account (which is done later by the common properties lter). Thus we do not need a mapping of property \eyeColor" to \eye". We further exclude the properties rdfs:label and skos:altLabel and all properties which have the same literal as those. This will not count the literals which just repeats the name of the resource with a di erent (maybe not matched) property like \name". Two literals are the same when their lowercased lexical value is equal. The additional con dence is the absolute amount of neighbors.
The cosine similarity lter compares text which is extracted from instances. It is generated by iterating over all literals and checking if the datatype of it is xsd:string,rdf:langString or if the literal has a language tag. All lexical representations of such literals are concatenated to generate a textual representation. These representations are then compared with a cosine similarity which is added to the correspondence.
The common properties lter checks for each instance correspondence the number of shared properties. This heavily relies on already matched schema because all properties with the same URI are excluded beforehand. Thus we only check if the instances share some matched properties regardless of their objects. The number of overlap is then added to the correspondence. “blue“ one:Gryffindor one:house one:Harry_
Potter one:bloodStatus one:Half -blood two:Harry_
Potter two:father two:James_
Potter “blue“
The type lter is similar to the neighbors lter but only checks if the types (retrieved by rdf:type) actually overlap. This again requires already matched classes. The absolute overlap is added as an additional con dence.
The nal step during instance matching is to actually lter these correspondences and create a one to one alignment. This instance lter sorts the correspondences by con dence (which is initially set by the string matching) and iterating over it. If a source or target resource is already matched, then it continues with the next correspondence. In all other cases it checks if there is a correspondence in the whole instance alignment which should be used instead. The criteria for being better is xed to have greater values in two additional con dences.
As a last step, all correspondences are combined and a nal cardinality lter ensures a one to one alignment by comparing the con dence scores. 1.2
We used the following matching components of MELT [
ATBox matcher is also available as a SEALS package. Due to clashes of
dependecies of SEALS and ATBox, we decided to use the external SEALS packaging
mechanism of the MELT framework[
ATBox matcher can be downloaded from https://www.dropbox.com/s/q57rzoec9zeumi2/ATBox.zip?dl=0. 2
This section discusses the results of ATBox for each track of OAEI 2020 where the matcher is able to produce results. The following tracks are included: anatomy, conference, largebio, phenotype, and knowledge graph track.
Speci c matching strategies and interfaces for the interactive and complex track are currently not implemented and are thus not described. Due to no multi language support, the multifarm track is also excluded. 2.1
ATBox could achive a slightly higher F-measure than the baseline (0.799 vs 0.766). Even though a synonym step is included in the matcher, the recall is only at 0.671 but therefor a high precision of 0.987 could be achieved (third best value).
Some examples were the matcher could nd some non-trivial matches are: { <cranium, Skull, =, 0.5> { <lienal vein, Splenic Vein, =, 0.5> { <inner ear, Internal Ear, =, 0.5> { <celiac artery, Coeliac Artery, =, 0.6> { <grey matter, Gray Matter, =, 0.6>
The rst three have a con dence of 0.5 and thus the matches are mainly generated by synonym replacements. The last two contain di erent spellings like \grey" and \gray". They are matched because the levenshtein distance is one between the two strings.
Some examples where the synonym step yields wrong results are: { <naris, Nostril, =, 0.5> { <upper arm, Biceps, =, 0.5> This shows that not only true positives are generated and it is also the reason why the correspondence has a low con dence. 2.2
In the conference track ATBox matcher (0.56) is a bit better in terms of
FMeasure than the baselines edna (0.54) and StringEquiv (0.52) when using the
ra2-M3 evaluation. It covers the class and property alignments (M3) and uses
the ra2 reference alignment which is a transitive closure of the original
reference alignment ra1[
ATBox matcher is one of six systems which are able to run on all six test cases and return meaningful alignments. It was consequently the second fastest system after LogMapLt. The results are very good in terms of precision but the recall is to low to compete with the other participants. Only in the FMA-SNOMED small fragments test cases the presented matcher could perform better than Wiktionary and LogMapLt. 2.4
In this track the presented matcher only returns 759 correspondences for the rst task HP-MP and 1,318 correspondences for the second task DOID-ORDO. The evaluation result thus contains a low recall of 0.298 respectively 0.333. Together with a high precision, a F-measure of 0.457 and 0.498 can be achieved. This is probably due to the missing background knowledge because LogMapBio uses BioPortal, LogMap uses spelling variants of SPECIALIST lexicon, and AML uses three sources (Uberon, DOID, and MeSH). All these systems achieve a higher recall than ATBox. Nevertheless in task HP-MP we could rank higher than ALOD2Vec and Wiktionary. 2.5
In the Biodiv track ATBox could only return results in FLOPO-PTO test case. Once again the F-measure of 0.714 is much better than those of Wiktionary and ALOD2Vec but less than all LogMap variants and AML. 2.6
ATBox could score int the overall evaluation(which contains classes, properties, and instances) the second highest F-measure score of 0.85 together with AML. Only ALOD2Vec and Wiktionary scores 0.01 better. When matching only classes, the presented matcher is the second best system after AML and for properties it is the best matcher. The instance matching pipeline is helpful for nding the correct correspondences but with 0.84 it is a bit below AML (0.85), ALOD2Vec (0.87), and Wiktionary (0.87).
We would like to increase the number of feature generators. For example, all
texts connected to an instance could be compared not only with cosine
similarity but also with a BERT classi er[
Furthermore the schema matches could be improved with the help of all
instance correspondences as already shown in DOME matcher [
In this paper, we have analyzed the results of ATBox matcher in OAEI 2020. It shows that the system is very scalable and can generate class, property and instance alignments. It usually has a high precision but on some tracks like Largebio, Phenotype, and Biodiv the recall can be increased by utilizing external knowledge despite the already used synonym lexicon from Wiktionary.
Most of the used matching components are furthermore included in the
MELT framework[