Skip to content Skip to footer

Use ontologies in the model

STATUS: RELEASED

Relevant for ✓ data holder ✓ data user
Expertise required semantic expert
Keywords semantic modelontologiessemantics

Ontologies provide a flexible approach to integrating data and sharing meaning and may be better able to assist in inferring meaning in complex situations. Liyanage H, Krause P, de Lusignan S. Using ontologies to improve semantic interoperability in health data. BMJ Health & Care Informatics.

This process involves linking your semantic (meta)data model to ontologies, which are formal, shared vocabularies that provide precise, machine-readable definitions for concepts. This step is written for a broad FAIRification audience and may be used by researchers, data stewards, metadata specialists and ontology or semantic web technology experts, depending on the project context. Not all activities need to be carried out by the same person. researchers and project teams can use this step to understand the process and provide domain knowledge, while specialist support may be needed for ontology selection, concept mapping, formal representation, validation and maintenance. By assigning standard definitions to the elements in your model, you make their meanings explicit and unambiguous. This allows different computer systems to correctly understand, combine and compare data from various sources consistently, making the data more interoperable and easier to reuse across projects.

Short description

This step starts from the existing semantic (meta)data model that organises your domain’s entities, attributes and value sets with clear project-level meaning. Building on that model, this step links its elements to ontology terms to make their meanings explicit, computable and interoperable. Ontology annotation may cover metadata elements, data model elements and value sets, benefiting both metadata and data layers. Ontologies are formal, logic-based representations of domain knowledge that define types of entities, relations and constraints, enabling explicit semantics and consistent computational interpretation. By adding this semantic layer, the model becomes not only well-structured but also interoperable across systems.

Why is this step important

A (meta)data model can express semantics for its project context, but those meanings are often implicit or local. The next challenge is to make them interpretable across systems. Ontologies provide the shared semantic layer that enables this. They make model elements formally defined and logically connected beyond their original context, turning isolated data structures into interoperable and machine-understandable representations.

The following aspects highlight the main contributions of ontology use to semantic precision, data integration and FAIR alignment:

  • Shared meaning. Ontologies use formal semantics and axioms (formal rules that software can check) to make each model element’s meaning explicit across systems.
  • Data integration. By providing precise, shared semantics, ontologies reduce false matches where labels align but meanings differ, enabling reliable combination and comparison across systems. To ensure accuracy and reliability, consult experts.
  • Automated reasoning and validation. By encoding semantics formally, ontologies can support automated checks with logic reasoners such as HermiT or Pellet, both available as free tools. These checks are typically configured by data stewards, ontology experts or semantic web technology experts during implementation or quality checks. They can help infer missing connections, check for inconsistencies such as conflicting definitions or incompatible classifications and flag contradictions.
  • FAIR alignment. Using ontologies provides a formal, shared representation that makes meaning computable, directly supporting the FAIR principle I1. Adopting recognised community ontologies also advances conformance with domain standards, aligning with R1.3.
🧪 Example

As an illustrative example of these advantages, suppose System A uses the label “myocardial infarction” and System B uses “heart attack” to denote the same clinical concept. Both are mapped to the same ontology IRI (Internationalized Resource Identifier) (A = B). A third System C uses “stroke”, which is mapped to a different IRI (B ≠ C). By substitution, it follows that A ≠ C as well. In practice, this prevents false merges (heart attack ≠ stroke) while still integrating data where the label differs but the meaning is identical (myocardial infarction = heart attack). If a broader or narrower relation exists, for example “ischemic heart disease” being broader than “myocardial infarction”, queries can still aggregate correctly without conflating distinct concepts.

How to

Before starting, choose an ontology development methodology to guide your process. This applies whether you are creating a new model, extending or reusing an existing one, or annotating newly collected data or aligning previously collected data. Well-known approaches include Ontology Development 101, Methontology, SABiO – Systematic Approach for Building Ontologies and the NeOn Methodology. These provide structured workflows for requirement gathering, conceptualisation, formalisation and evaluation, helping to ensure that your ontology or mappings are coherent, reusable and aligned with best practices.

Where needed, seek support early from relevant experts, such as ontology, metadata or semantic web technology experts.

The steps below describe how to connect model elements to ontology terms and manage these mappings over time. In the steps below, a mapping means a recorded link between a model element, such as a class, attribute or value, and an ontology term.

Step 1 - Identify what needs annotation

  • List the model elements that represent concepts or enumerated values, such as classes, attributes, value sets and common data elements.
  • Record current labels, definitions and intended use to guide later term selection.

Step 2 - Select appropriate ontologies

Step 3 – Bind model elements to ontology terms

  • Choose the most specific term that fits the intended meaning and avoid overly broad terms.
  • Record both the label and IRI for each mapping (e.g. an IRI such as https://purl.obolibrary.org/obo/NCIT_C28421 for “Male”).
  • Capture mapping intent where useful, using predicates from Simple Knowledge Organization System (SKOS), such as skos:exactMatch, skos:closeMatch, owl:equivalentClass and rdfs:subClassOf. See the SKOS documentation for further guidance.
  • Keep mappings separate from the source ontology. Do not change the original ontology’s IRIs.
  • Store mappings in a structured, machine-readable form, such as Resource Description Framework (RDF), Web Ontology Language (OWL), Simple Knowledge Organization System (SKOS) or a dedicated mapping file such as Simple Standard for Sharing Ontological Mappings (SSSOM). Include provenance fields such as who mapped the term, when the mapping was created, the source version and the rationale. Always include the ontology version IRI or release date for reproducibility.
  • When no exact term exists, use the closest appropriate term and record the gap, i.e. note that no exact ontology term was found and why. Record this in both your mappings and documentation. For example, you can add an annotation in OWL using rdfs:comment or skos:note and add provenance in the mapping, for example using SSSOM. If the gap is significant, consider proposing a new term to the ontology maintainers.
🧪 Example

A local value “Neck cancer” has no exact term, so you temporarily map it to “Head and neck cancer” using https://purl.obolibrary.org/obo/DOID_5520 with a skos:closeMatch and add a comment such as “No exact term for ‘Neck cancer’; new-term request submitted at https://example.org/issue/12345”.

  • Use the fewest ontologies possible to make interoperability and maintenance easier. Using a large number of different ontologies, for instance, may make it difficult to check that terms are not contradictory.

Step 4 – Implement, validate and share

  • Represent the model, including its annotations and mappings, in a machine-readable semantic web format such as RDF or OWL. This enables the semantic (meta)data model to become interoperable and reusable through ontology mappings. Where validation rules are needed, express constraints using Shapes Constraint Language (SHACL).
  • Use dereferenceable IRIs for both your model elements and referenced ontology terms.
  • Where you control the identifiers, create persistent IRIs that dereference to both human-readable and machine-readable descriptions. For external ontology terms, reuse their IRIs as-is. If a required term’s IRI does not dereference, still use it as-is and add a reference link, for example using rdfs:seeAlso, to a stable catalogue record.
  • Include ontology citations and versions in the model metadata and changelog.
  • Validate mappings and constraints automatically as part of your quality checks. Resolve any unsatisfiable classes or constraint violations before publication and keep validation reports as part of your documentation.
  • Recommended tools for implementation and validation include:
  • Publish the annotated model and mappings in a stable, publicly accessible location with a clear licence, for example GitHub, FAIRsharing or institutional repositories.
  • Mappings and annotations themselves can be shared under permissive licences, for example CC BY 4.0 or CC0, unless source ontology licences impose restrictions.
  • Even when data cannot be openly shared, for example due to privacy or legal restrictions, publish the model and mappings so that others can understand, align with and interoperate with your work.

Step 5 – Maintain and govern mappings

Ontologies evolve over time, so mappings must be reviewed and updated to remain valid and interpretable. Regular maintenance helps ensure that your model stays aligned with current standards and avoids broken or outdated references.

  • Plan reviews appropriate to the scope of the model. For reusable models, registries or mappings maintained beyond a single study, check for new ontology releases at fixed intervals, for example every 6 or 12 months. For single-study models, at minimum record the ontology versions used and review mappings when the model is updated, before publication or when reuse is expected.
  • Watch for deprecations. When ontology terms are deprecated or merged, record the recommended alternatives and update mappings where appropriate. For resources released or reused over time, preserve the links between old and new terms in a versioned mapping or changelog so that earlier and later versions remain interoperable.
  • Update and record. Use version control, for example Git, to track all mapping changes and maintain a changelog including the ontology version used and the reason for each update.
  • Migrate if needed. When key ontology terms change, adjust your annotated data or mappings using tools such as ROBOT or simple scripts.
  • Re-validate. After each update, re-run SHACL validation or reasoning checks to confirm that the model remains coherent.

As the volume of (meta)data and repositories grows, continuous ontology maintenance can become a significant burden. Establish governance rules that clarify which mappings will be maintained, how often they are reviewed and by whom, and make these rules part of your project and repository documentation.

Expertise requirements for this step

Experts that may need to be involved, as described in Metroline Step: Build the Team, are described below.

  • Ontology experts. Select appropriate ontologies, apply alignment patterns and evaluate ontology quality and scope.
  • Metadata experts. Ensure coverage of required metadata elements and provide clear documentation for users.
  • Semantic web technology experts. Represent the model and its mappings in RDF, OWL and SKOS; maintain model coherence; design persistent IRIs, implement SHACL validation and automate mapping publication workflows.

Practical examples from the community

Training

One useful educational resource is the FAIR Cookbook recipe on ontology mapping with the Ontology Xref Service (OxO). This recipe shows how to use the EMBL-EBI Ontology Xref Service (OxO) to map ontology terms across source and target vocabularies.

Another useful resource is the OBO Semantic Engineering Training available through OBOOK. Although developed for a specific project, it provides practical examples and training materials covering ontology engineering workflows, modelling approaches and semantic technologies.

Suggestions

This page is under construction. Learn more about the contributors here and explore the development process here. If you have any suggestions, visit our How to contribute page to get in touch or fill in our Quick feedback form.