The Simple Standard for Ontological Mappings (SSSOM) was first published in December 2021 (v. 0.9). After a number of revisions prompted by community feedback, we have published version 0.10.1 in August 2022. One of the key new features is the use of a controlled vocabulary for mapping-related processes, such as preprocessing steps and matching approaches. In this paper, we give an update on the development of SSSOM since v. 0.9, introduce the Semantic Mapping Vocabulary (SEMAPV) and outline some of our thoughts on the establishment of mapping commons in the future.
The problem of mapping between entities in databases and ontologies is ubiquitous - from automatically
establishing mapping using ontology matching or entity resolution techniques to applying them in the
context of data transformation, ontology merging or knowledge graph integration. We define a mapping
as the correspondence of one entity (a record in a database, a class in an ontology), i.e., the subject, to
another entity, i.e., the object. A semantic mapping is a mapping that further specifies a predicate
describing how the subject maps to the object e.g., is it an “exact match”, or merely “close”? Are the
two entities “logically equivalent” in the sense of the Web Ontology Language (OWL)? Despite their
importance, semantic mappings are rarely shared widely outside the tool-developing communities.
Standards like the EDOAL [
The Simple Standard for Ontological Mappings (SSSOM) has been proposed as a community standard
for sharing semantic mappings between information entities [
In this paper, we will describe the most significant changes to the SSSOM standard since its initial publication in December 2021, including: 1. The move from modelling mapping metadata as “type” information, e.g. this mapping corresponds to a “lexical match”, to modelling them as “mapping justifications”, e.g. this mapping is supported by “lexical matching”. 2. The establishment of a bespoke semantic mapping vocabulary that defines certain key mapping activities, such as types of matching approaches, formally. 3. A first concrete proposal to define mapping registries, collections of mapping sets, as a backbone to defining what we envision as mapping commons - community-driven spaces that curate and reconcile mappings and enrich them with metadata.
The following changes have been made since version 0.9 of the SSSOM standard. At the time this paper was written, the version is 0.10.1. 2.1.
Requiring sources to be recorded as entity references. We now require entity references instead of
strings to denote source information for the subjects and objects in the mapping (subject_source,
object_source). For example, we previously permitted the string “UBERON” to be used to declare that
the subject is part of the Uberon ontology [
Requiring entity references for documenting preprocessing techniques. Previously we allowed preprocessing techniques, for example, applying to lexical matching activities (Stemming, Lemmatisation, etc), to be recorded using natural language strings. To facilitate the standardisation of these references, we now require preprocessing techniques to be recorded using controlled vocabularies. One such vocabulary is the Semantic Mapping Vocabulary (SEMAPV), which we will introduce later in this report.
Splitting match term type into separate type fields for the subject and the object of the mapping. To facilitate mappings between different ontological types (classes and individuals, for example), we split the previous match_term_type property (which used a controlled vocabulary with terms like ConceptMatch, ClassMatch, IndividualMatch) into separate metadata elements for the subject (subject_term_type) and object (object_term_type), using the standard Semantic Web types as values, such as owl:Class, rdfs:Resource or skos:Concept. This ensures, for example, that we can map between elements that are not strictly the same type, such as “skos:Concept”, for example “Alzheimers” in a SKOS taxonomy, and “owl:Class”, for example “Alzeimhers” in an OWL Ontology. As another positive side effect, we can use this kind of information to make assumptions about the intended semantic framework for the mapping: if, for example, a mapping property is used that is formally an owl:ObjectProperty, and both the subject and the object are owl:Class, then we can export the mapping as an owl:SomeValuesFrom restriction when the user uses the SSSOM toolkit to transform their mapping into OWL.
Modelling mapping metadata as “mapping justifications”, rather than “match type” information. In SSSOM v. 0.9, the “match_type” property was used to express that the mapping between the subject entity (subject_id) and the object entity (object_id), using a particular mapping predicate (predicate_id), is of type “lexical match”. During the first phase of the design, this felt more natural, as we would often use phrases like “this is a lexical match” when talking about a specific mapping. But it turned out that there were a few problems with this metadata element. Firstly, we realised that there was a confusingly inconsistent use of the “matching” vs “mapping” terminology across the SSSOM specification. For example, the name “SSSOM” suggests that we are talking about a standard for mappings - but one of its central metadata elements (“match_type”) uses the term “match” instead. The core team has settled on the following conventions for using the terms “mapping” and “matching” across the specification: a term mapping is a statement <s,p,o> comprising a subject entity (s), an object entity (o) and a mapping predicate (p); this is synonymous to what the ontology matching literature refers to as correspondence. We refer to the process that results in a mapping between a subject and an object entity as “matching”. Obviously, these are merely conventions to ensure consistent communication when talking about SSSOM, and not in any way normative - there are many different valid uses of the terms “mapping”, “match” and “matching” across the literature. Secondly, a single mapping can be lexical, logical and expert-curated at the same time. Stating that the mapping is of “multiple types” is awkward and confusing. Instead, aligning SSSOM a bit more closely with the provenance model of PROV (another request by the community) appeared more natural: describing how the mapping came into being as “activities that generate or confirm a mapping” (“activity” is a term from the PROV data model denoting a process “that occurs over a period of time and acts upon or with entities”). We decided to refer to these processes as “mapping justifications”. 2.2.
The SSSOM toolkit offers a number of utility methods such as “merge” (to merge two mapping sets), “parse” (to convert a different format, such as EDOAL, into SSSOM) and “validate” (to check that a mapping set is legal SSSOM). While it was always part of the design philosophy of SSSOM to not require any special tooling for reading and writing SSSOM files (i.e. it should be possible to use the normal data science toolbox, such as pandas), it can be convenient to have a special toolkit that covers some of the more frequently used operations of mapping sets on the command line, and provides a convenient API for data pipelines in Python. Since SSSOM 0.9, a number of new features have been added. The “annotate” function allows adding mapping set level metadata, such as license or a version, directly using the command line. This supports, for example, use cases like automated mapping extraction or matching pipelines which automatically assign versions. The “validate” command has been significantly improved and now covers JSON schema validation. Lastly, the “filter” command allows to filter a mapping set based on any of its metadata elements: for example, mapping sets can easily be filtered by predicate id, subject id prefix or mapping provider. Some infrastructure developers have also started making pull requests. For example, a converter of SSSOM to OntoPortal mappings has been provided by the AgroPortal developers; a converter for the FHIR ConceptMap is provided by a FHIR developer (under construction).
The Ontology Access Kit (OAK) implements functionality to do basic lexical matching based on term synonyms, including a system for specifying mapping rules such as: if a label of the subject matches an exact synonym, then we declare the presence of an “skos:exactMatch”. Term matches are exported as SSSOM mapping sets, including detailed justifications such as “subject match field” and “match string”. OAK furthermore allows retrieving ontology mappings from various endpoints such as OxO or BioPortal and exporting it as SSSOM mapping sets.
The next version of the Ontology Development Kit (ODK) will implement direct support for managing SSSOM mappings alongside ontologies by providing functionality for automatically exporting mappings curated as part of the ontology into SSSOM for easier consumption, copying mappings relevant to the ontology sourced from elsewhere and curating mappings (manually or with matching tools). 2.3.
Contribution guidelines and Code of Conduct. Since April 2022, we have defined contribution
guidelines [
New SSSOM tutorial. We also developed our first comprehensive tutorial for the curation of mappings
[
SSSOM logo design. After a few rounds of proposals and feedback, we settled on a circular Sankey
diagram style solution developed by Julie McMurry that illustrates cross-mappings between resources,
similar to what the Ontology Xref Services uses [
In the first public version of SSSOM, most metadata elements were either defined as enums (hardcoded values that are part of the SSSOM standard itself, see above discussion on mapping preprocessing and justifications) or simple open-ended strings (for example the “source” element). Now, to make certain metadata more easily customisable and extensible (while still being semantically meaningful, with rich metadata), we decided to develop a new controlled vocabulary independently of SSSOM to capture the required terms. The Semantic Mapping Vocabulary (SEMAPV) is in a very early stage of development, covering at the moment primarily the terms required for the use cases of the SSSOM user community, in particular to document mapping justifications (e.g. mapping justifications, widely used preprocessing methods). We are, however, discussing the possibility to include additional mapping relationships such as cross-species mappings for connecting biological databases covering diverse species from Drosophila and zebrafish to Homo Sapiens. These are not covered well by the SKOS mapping vocabulary (which, alongside OWL is the preferred vocabulary for semantic mappings in SSSOM), unless we give up a lot of precision and model these all as skos:closeMatch or skos:relatedMatch. An early version of SEMAPV can be inspected. SEMAPV is open for community feedback and new term requests.
Traditionally, a lot of focus in and around modelling mappings has been about the individual term
mappings and mappings sets (or alignments). Very little work is done to deal with sets of mappings,
either in terms of collection, indexing and retrieval (mapping registries), or their reconciliation.
Matching tools are typically designed to generate a one-off alignment, which is difficult to reconcile
with partial alignments from other sources, such as human curated subsets. The role of human review
in general is typically seen in service to the automated approaches either by providing a training set for
machine learning based approaches, or a validation set for other more traditional approaches (“my
matcher is 70% correct compared to a human reviewed subset”). In reality mapping sets are
codeveloped by curators, automated matchers and, importantly, “crosswalks” or “mapping chains”. The
latter exploits the fact that if a subject A is an exactMatch to two objects (B and C) then we can
reasonably assume that B and C are also exact matches to each other. Manual curation may often not
be feasible due to the scale of the data, but can often be captured by user feedback (“this does not make
sense!”). It is our firm belief that all these mapping approaches should be applied in concert, which
means that a good model for dealing with collections of mapping sets must be developed. This model
answers questions like how to reconcile conflicting mappings (picking the one with higher confidence?)
or mappings whose application leads to nonsensical knowledge graphs and ontology structures
(equivalence hairballs, inconsistencies). Many of the latter issues are covered by the ontology merging
literature [
The adoption of SSSOM is still in the early stages. It is increasingly clear that precise and well documented terminological mappings are required for many use cases, such as bridging the chasm between the world of clinical terminology, which dominates the domain of clinical data, with the world of biological research (such as genomics) which is dominated by open biomedical ontologies (such as OBO Foundry ontologies), and simply relying on automated tooling won’t work for many use cases. Furthermore, it is likely that millions of taxpayer dollars are wasted on recreating the exact same mappings over and over again due to the lack of a FAIR and open mapping culture along the lines of what we already have for biomedical ontologies. What is needed is a holistic approach that integrates (partial) mappings created by different groups for specific use cases with the results from automated matchers (which enable coverage and scalability) and human curation (user feedback, biocuration). To achieve this our community (Ontology Matching) should evolve from a primarily tool-centric view (with a focus on algorithmic precision and fully automated matching) to a more data-centric view (integrated development processes, continuous updates of mapping sets, reuse and sharing, hybrid automated and manual mapping curation). Not only will the publication and curation of mappings in mapping commons improve the user experience; for the Ontology Matching community, manually curated mapping sets can ultimately evolve from silver to gold standard corpora for evaluation as well. Tools should be retrofitted to export “mapping justifications” alongside their results, documenting preprocessing steps, mapping decisions and more in a way that allows downstream users to accept or reject a mapping based on the justification alone.