A graph schema is a blueprint for representing a graph dataset in a real system. It specifies what nodes, edges, and properties mean, which types are permitted, and what rules the data must satisfy. Use one when a graph needs a clear implementation and testable rules—not just an informal description. section 8.2.2 section 8.2.4
Build the schema in two passes:
- Define the entities and relationships, then decide which become nodes and edges. Specify their types, properties, and any descriptors or metadata. section 8.2.2
- Write structural constraints: which nodes may connect, how relationships are restricted, whether relationship counts are limited, and which property values are allowed. section 8.2.2
- Keep a conceptual schema independent of software, then translate its relevant rules into a system schema for a chosen database or processing system. The system schema may omit conceptual elements it does not need. section 8.2.2
A recruitment graph
Suppose candidate nodes carry industry and job-type attributes, and candidate-to-candidate edges represent Knows relationships. Integrity checks can require both attributes to be non-null, confirm that candidate connections have the Knows type, and detect duplicate candidate IDs. The schema turns these decisions into checks rather than leaving them as assumptions. section 8.2.4
Figure 8.5 Schema with three node types and three edge types
A schema with three node types and three edge types shows how the blueprint can distinguish several kinds of entities and relationships. section 8.2.2
Treat the schema as revisable. Store an instance model, run integrity queries, inspect the results, adjust the model, and validate it again. Rules can be checked with Cypher or SPARQL in a graph database, or with Python in a processing system such as NetworkX. Planning for data changes and system fit helps avoid expensive later workarounds. section 8.2.4
