A schema formally specifies the structures, types, properties, and relationships permitted in a data representation. In a knowledge graph, it turns a domain into an actionable model: documents become connected nodes, relationships encode meaning, and mappings align heterogeneous source data with shared concepts. section 3.0 section 7.6.1
Use a schema as an implementation guide across the knowledge-graph pipeline:
- Start with the business goal and anticipated extensions, then choose domain concepts, node labels, properties, and relationship types. section 1.7 section 2.6
- Map each source’s local schema to a reference ontology so equivalent concepts, formal names, categories, and relationships can be integrated. section 3.0
- Represent provenance and ambiguity explicitly, such as linking Files to Pages, Pages to EntityMentions, and mentions to resolved domain entities. section 7.6.1 section 6.1.1
- Use the model to drive normalization, entity resolution, ingestion, analysis, and formal query construction; validate the resulting information before relying on it. section 6.1.1 section 6.5
Healthcare entity integration
A healthcare graph can connect a Page to a MedicalEntity, then map that entity to SnomedEntity, HpoEntity, or HpoDiseaseEntity. This separates textual mentions from normalized clinical concepts: “AIDS” and “Acquired Immunodeficiency Syndrome” can resolve to one entity, while the same string, such as “Zika,” can represent different entities. The resulting structure supports ontology-based reasoning and rare-disease analysis. section 7.6.1 section 3.0
Figure 7.9 KG schema, including relevant node labels and relationship types, to enable multiple types of analyses
Inspect the node labels and relationship types that organize documents, mentions, disambiguated medical entities, and ontology mappings for multiple analyses. section 7.6.1
