Chapter 3: Create your first knowledge graph from ontologies

Introduction

The introduction explains why integrating diverse data into a knowledge graph is difficult and how an ontology can provide shared meaning, using rare-disease data as the chapter’s example.

• Knowledge graph integration challenges: Explain why constructing a knowledge graph from multiple sources is difficult, especially when the sources express meaning differently.
  Why it matters: The difficulty is not just reading different files; it is determining when their data refers to the same or different things.
• Ontology as shared reference: Describe how an ontology and mappings help integrate data from sources that use different terms or schemas.
  Why it matters: A shared reference helps turn differently described source data into a meaningful, integrated graph.
• HPO rare disease context: State what information the Human Phenotype Ontology source provides for the chapter’s rare-disease example and what a phenotypic abnormality means here.
  Why it matters: These disease–abnormality connections establish what the chapter’s clinical example represents.

Key terms: KG construction, data integration, information syntax, information granularity, semantic integration, ontology, reference schema, vocabulary, mapping, annotations

3.1 Knowledge graph building: Warmup

3.1.1 Business and domain understanding

This section identifies clinicians’ diagnostic needs and defines the disease and phenotype concepts that the knowledge graph must represent.

• Clinician diagnostic knowledge needs: Explain why a clinician diagnosing diseases, especially rare syndromes, would benefit from a structured knowledge base and what information it should connect and trace.
  Why it matters: The clinician’s task determines which connections the KG needs to make useful and verifiable.
• Phenotype and disease meanings: Distinguish an individual’s phenotype from a disease as the section defines them.
  Why it matters: These definitions clarify what the KG is connecting when it relates observed features to diseases.
• Context-dependent diabetes classification: Explain why diabetes mellitus illustrates a gray area in distinguishing diseases from phenotypic features.
  Why it matters: The example shows why a single medical concept may not always have one fixed role in the KG’s domain.

Key terms: clinician, phenotypic anomalies, diseases, sources of the connections, phenotype, phenotypic features, disease, time course, diabetes mellitus, phenotypic characteristic

3.1.2 Data understanding

This section identifies the two HPO data sources for the example knowledge graph and shows how to inspect the ontology and interpret its disease–phenotype annotations.

• Standardized phenotype ontology: Explain what the hpo.owl file contains and why its standardized information is useful for integrating data.
  Why it matters: The ontology provides shared terms for bringing phenotype information together.
• OWL triples for inspection: Describe how the section suggests exploring the OWL file and name the parts of a triple.
  Why it matters: Thinking in triples makes the ontology easier to inspect.
• Disease phenotype annotation records: Explain what phenotype.hpoa records about diseases and phenotypic features, including the purpose of its supporting fields.
  Why it matters: The annotations connect diseases to phenotype terms while providing context for interpreting those connections.

Key terms: Human Phenotype Ontology (HPO), hpo.owl, phenotypic anomalies, interoperability, OWL, rdflib, triples, subject, predicate, object

3.2 Understanding knowledge graph technologies

This section introduces RDF and LPG, compares how they represent relationship properties, and describes tools that bridge their differences.

• RDF and LPG representations: Distinguish RDF’s subject–predicate–object statements from LPG’s nodes and relationships with key–value properties, and describe the strengths the section attributes to each.
  Why it matters: These different representations frame the choice of graph technology for a use case.
• Relationship metadata differences: Explain why metadata on an RDF predicate differs from properties on an LPG edge, and describe the RDF approaches mentioned for adding context or edge properties.
  Why it matters: The difference matters when information belongs to one particular relationship rather than every relationship of its type.
• Semantic gap bridging tools: Describe the semantic limitation attributed to LPG and how the cited vendor tools bridge RDF and LPG in different directions.
  Why it matters: These tools show that a technology choice need not completely rule out capabilities associated with the other approach.

Key terms: Resource Description Framework (RDF), Labeled Property Graph (LPG), triple, subject, predicate, object, named graphs, RDF*, edge-specific information, advanced semantics

3.2.1 RDF or LPG? A goal-driven discussion

This section uses the HPO ontology and clinical annotations to show how a knowledge graph technology choice should follow the available data and clinicians’ goals.

• Goal Driven Technology Selection: Explain why choosing a KG technology for this use case depends on both the HPO ontology and annotation data and on what clinicians need to do, rather than on a universally best choice.
  Why it matters: Starting with the clinical task keeps the technology choice focused on useful evidence rather than a preferred graph format.
• OWL Ontology Representation: Describe why the HPO ontology is serialized using RDF and what OWL adds to that representation.
  Why it matters: The ontology’s representation is one part of the data landscape the technology choice must accommodate.
• Clinical Annotation Edge Modeling: Trace how a clinical annotation becomes a KG relationship and explain why its metadata belongs on that relationship.
  Why it matters: Preserving details for each reported association lets clinicians compare the evidence behind disease–phenotype links.

Key terms: HPO ontology, annotations data, provenance, RDF, OWL, Web Ontology Language, disease, phenotypic feature, annotation, HAS_PHENOTYPIC_FEATURE

3.2.2 Representing edge properties with RDF and LPG

The section compares ways to attach annotation metadata to a disease–phenotype relationship and explains why the book chooses LPG and Cypher for its knowledge graph.

• N-ary annotation modeling: Explain how an RDF n-ary relation uses an annotation resource to connect a disease and phenotypic feature while holding the annotation’s source, author, and creation date.
  Why it matters: This gives you one RDF alternative to compare with storing metadata directly on an LPG relationship.
• Named graph provenance: Describe how a named RDF graph groups the disease–phenotype assertion so metadata can be attached to the graph, and state the management tradeoff noted in the section.
  Why it matters: Named graphs offer provenance in RDF, but their management costs matter when choosing a model.
• RDF-star edge annotation tradeoffs: Explain what RDF-star contributes to annotating edges and identify the adoption and performance limitations stated here.
  Why it matters: RDF-star narrows the modeling gap with LPG, but the section does not treat it as a cost-free substitute.
• LPG relationship metadata choice: Explain how LPG stores and retrieves the phenotypic annotation details and why the authors choose LPG and Cypher for their KG system.
  Why it matters: This modeling choice determines how the book represents and queries annotations in the KG it builds next.

Key terms: n-ary relations, blank node, PhenotypicAnnotation, provenance, named graphs, TriG, RDF-star, SPARQL, RDF engines, LPG

3.3 Building a knowledge graph

Introduces the two stages of building the knowledge graph and notes the tools and data version used in the examples.

3.3.1 Ontology ingestion and processing with neosemantics

This section prepares Neo4j for the HPO ontology, configures Neosemantics, loads and enriches the vocabulary, and inspects the resulting graph.

• HPO database preparation: Describe how the HPO database is prepared before ontology ingestion: create and initialize it, enforce uniqueness for Resource nodes, and index the IDs used for phenotype and disease nodes.
  Why it matters: This preparation makes the imported resources identifiable and their IDs easier to access.
• Neosemantics import rules: Explain the two Neosemantics configuration rules used for the HPO import and what each changes.
  Why it matters: These rules determine how ontology terms and relationships are represented when imported.
• HPO vocabulary loading and enrichment: Trace what happens after configuration: load the HPO vocabulary, then add an HpoPhenotype label and an id derived from each resource’s original URI before annotation data is loaded.
  Why it matters: This is the section’s central ingestion sequence and establishes the graph state before annotations are added.
• Imported graph snapshot: Describe the two kinds of information visible in the illustrated portion of the loaded HPO graph.
  Why it matters: The snapshot shows what the ontology import has put into the graph at this stage.

Key terms: Resource, uri, id, HpoPhenotype, HpoDisease, constraints, Neosemantics, namespaces, relationship types, LPG

3.3.2 Annotation ingestion and processing

The section explains how to integrate HPO disease–phenotype annotations into the ontology-based knowledge graph, enrich their relationships, and remove unneeded ontology content.

• Annotation and ontology integration: Describe how the TSV-format HPOA annotations add disease nodes and connect them to phenotypic feature nodes from the ontology-based graph.
  Why it matters: The annotations turn ontology-based phenotypes into a graph connected to associated diseases.
• Disease–phenotype relationship enrichment: Explain how annotation values become properties on disease–phenotype relationships, including how missing values are handled and abbreviated metadata is made readable.
  Why it matters: Relationship properties preserve the annotations’ evidence and context while making the graph easier to inspect.
• Final graph cleanup: State what is removed in the final cleanup step and why.
  Why it matters: The finished graph retains the ontology content needed for its intended use.

Key terms: HPOA, TSV, hpo.owl, phenotype.hpoa, HpoDisease, HpoPhenotype, relationship properties, FOREACH, HAS_PHENOTYPIC_FEATURE, apoc.periodic.iterate

3.4 Querying the data

Shows how a clinician can query a knowledge graph with patient phenotypic features to investigate a rare-disease diagnosis.

• Phenotype-based diagnostic querying: Trace how the clinician uses the KG first to explore features associated with Type 1 diabetes, then to find other diseases associated with newly observed features.
  Why it matters: The example shows how querying a KG can help a clinician investigate a diagnosis beyond an initially recognized disease.
• Distinct phenotype and disease codes: Explain why the example records Type 1 diabetes with two identification codes.
  Why it matters: The two codes clarify whether a KG reference treats Type 1 diabetes as a feature or as a disease.

Key terms: KG, phenotypic features, Type 1 diabetes, Ondontochondrodysplasia 2 with hearing loss and diabetes, HPO, OMIM, phenotypic feature, disease

3.5 Reasoning over the KG

This section shows how reasoning over HPO subclass relationships can reveal disease annotations that are not directly connected to an endocrine-system abnormality.

• Subclass-based biomedical inference: Explain how the HPO hierarchy supports inference about diseases characterized by endocrine-system abnormalities, including more specific traits such as thyroid abnormalities.
  Why it matters: The hierarchy helps a biomedical query find relevant disease associations that a search for direct connections alone would miss.

Key terms: inference, deductive reasoning, HPO, subclasses, annotations, Neosemantics

3.6 Summary