Edge Schema

The relationship type (or label) is the primary classifier for an edge, categorizing the nature of the connection between two vertices (e.g., WORKS_FOR, PURCHASED, LOCATED_IN). It is the fundamental unit for graph pattern matching in queries like MATCH (p:Person)-[:WORKS_FOR]->(c:Company). Defining distinct, semantically clear types is critical for query performance and data integrity.

A core function of an edge schema is to define the permissible source vertex type and target vertex type for a given relationship. This enforces a valid graph structure. For example, a SENT_TO edge schema might mandate:

• Source Vertex Label: Email
• Target Vertex Label: EmailAddress This prevents nonsensical connections, such as linking a Product vertex directly to a City vertex with a SENT_TO relationship, ensuring data quality and predictable traversal paths.

Edges can carry properties (key-value pairs) to describe the relationship's attributes. The schema defines the allowed property keys, their data types, and optional default values. For a PURCHASED edge, typical properties might include:

• amount (Float)
• currency (String)
• timestamp (DateTime)
• quantity (Integer) Property definitions transform a simple connection into a rich, queryable data entity, enabling analytics like "total sales per region" directly via graph traversals.

Cardinality constraints are business rules enforced by the schema that restrict the number of relationships of a specific type a vertex can have. Common patterns include:

• One-to-One: A Person has at most one HAS_SSN edge to a SocialSecurityNumber vertex.
• One-to-Many: A Company can have many EMPLOYS edges to Person vertices.
• Many-to-Many: Person vertices can have many KNOWS edges to other Person vertices. Enforcing these at the schema level prevents data anomalies that would break application logic.

Beyond cardinality, edge schemas can enforce data integrity through specific constraint types:

• Uniqueness Constraints: Ensure a combination of edge properties is unique (e.g., a RATED edge between a specific User and Movie can only exist once).
• Property Existence Constraints: Mandate that a specific property must have a non-null value on every edge of this type (e.g., every TRANSACTION edge must have a timestamp). These constraints guarantee that the graph data adheres to critical business rules, forming a reliable foundation for applications.

An edge schema is not static. Schema evolution involves modifying the schema—such as adding a new property or relaxing a vertex constraint—to meet changing application needs. Best practices include:

• Backward Compatibility: Adding optional properties is safe; removing them or changing constraints requires a migration plan.
• Versioning: Tracking schema changes to coordinate application and data pipeline updates.
• Validation Scripts: Using tools like SHACL (Shapes Constraint Language) for RDF or native database functions to validate existing data against a new schema before deployment.

These edges model parent-child and classification relationships, forming the backbone of organizational charts, product catalogs, and biological taxonomies.

• IS_A / SUBCLASS_OF: Defines an inheritance hierarchy (e.g., (Mammal)-[:IS_A]->(Animal)).
• PART_OF / CONTAINS: Represents composition and aggregation (e.g., (Engine)-[:PART_OF]->(Car)).
• MANAGES / REPORTS_TO: Captures organizational reporting structures.

Key Constraint: Cardinality is often one-to-many from parent to child, enforced at the schema level to prevent logical inconsistencies.

These edges capture relationships that exist within a specific timeframe or are triggered by an event, essential for audit trails, process mining, and historical analysis.

• OCCURRED_AT / HAPPENED_BEFORE: Connects entities to timestamps or orders events temporally.
• WAS_IN_STATE: Links an entity to a state vertex with valid_from and valid_to properties.
• TRIGGERED_BY / RESULTED_IN: Models causal relationships between events in a workflow.

Schema Properties: Typically include timestamp, duration, or sequence_id to enable time-window and path-based queries.

These edges model observed actions, communications, and co-occurrences between entities, forming the basis for social network analysis and recommendation systems.

• INTERACTED_WITH: Generic edge for any action (viewed, called, messaged). Often includes a weight or frequency property.
• PURCHASED / RATED: Core to e-commerce graphs, linking customers to products with rating and date properties.
• CO_AUTHORED / COLLABORATED_WITH: Connects entities that participate in a joint activity.

Schema Design: Use a single edge type with a interaction_type property for flexibility, or discrete edge types for query performance and explicit constraints.

These edges define physical and logical proximity, adjacency, and containment in space, critical for logistics, IoT, and geographic information systems.

• LOCATED_IN / WITHIN: Places an entity within a geographic boundary (city, region, building).
• ADJACENT_TO / CONNECTED_TO: Models physical adjacency of land parcels, network nodes, or warehouse bins.
• ROUTE_BETWEEN: Connects locations with properties for distance and travel_time.

Implementation: Often integrates with spatial indexes and requires properties with geometric data types (Point, Polygon).

These edges establish equivalence, similarity, and meaning between entities, enabling data integration, entity resolution, and rich ontological reasoning.

• SAME_AS: The foundational edge for entity resolution, indicating two vertices refer to the same real-world object. Requires high-integrity constraints.
• RELATED_TO / SIMILAR_TO: A broad association, often with a confidence_score property derived from machine learning models.
• MEANS / SYNONYM_OF: Links terms to their meanings or linguistic equivalents in a knowledge graph.

Critical Constraint: SAME_AS edges must enforce transitive closure and are often managed via specialized entity resolution pipelines.

These edges track creation, ownership, lineage, and derivation of assets, providing auditability and governance for data products, intellectual property, and supply chains.

• CREATED_BY / OWNED_BY: Assigns authorship or ownership, with properties for date_created and license.
• DERIVED_FROM / SOURCE_OF: Essential for data lineage, tracking how a dataset or model was generated from upstream sources.
• VERSION_OF: Connects successive versions of an entity, forming a chain with version_number and change_summary.

Governance Impact: These edges are primary targets for access control policies and compliance auditing within the graph.

A vertex schema defines the structure for a category of nodes within a property graph, analogous to a table definition in a relational database. It specifies:

• The allowed labels for the vertex type.
• The property keys and their expected data types (e.g., name: String, createdAt: DateTime).
• Any uniqueness constraints on properties to prevent duplicate entities.

An edge schema is inherently linked to vertex schemas, as it defines which vertex types are permitted as valid sources and targets for a given relationship.

A graph schema language is a formal syntax used to define the complete structure of a property graph. It provides the vocabulary to declare:

• Vertex types and their properties.
• Edge types, their permitted connections, and their properties.
• Constraints like uniqueness and cardinality.

Examples include the Cypher DDL extension, the open-source GraphQL Schema Definition Language (SDL) when used for graphs, and vendor-specific DSLs. These languages make an edge schema executable and machine-readable.

A cardinality constraint is a schema rule that restricts the number of relationships of a specific type a vertex can have. When defining an edge schema, cardinality dictates the logical multiplicity of the connection. Core types are:

• One-to-one (1:1): A Person vertex can have at most one HAS_DRIVERS_LICENSE edge.
• One-to-many (1:N): A Customer vertex can have many PLACED_ORDER edges.
• Many-to-many (M:N): A Product vertex can have many PURCHASED_BY edges from many Customer vertices.

Enforcing cardinality ensures data integrity and reflects real-world business rules.

SHACL is a W3C standard for validating RDF graphs against a set of conditions called shapes. While designed for RDF, its conceptual role is analogous to defining an edge schema in a property graph. SHACL shapes can:

• Define the expected class (rdf:type) of a node.
• Specify required properties and their datatypes.
• Constrain the predicates (edges) a node can have, including the allowed target classes—directly mirroring edge schema source/target rules. It is the primary mechanism for enforcing structural integrity in semantic web knowledge graphs.

Schema-on-write is a data modeling paradigm where data must conform to a predefined, rigid schema before it is persisted. In a graph context, this means:

• A vertex schema and edge schema must be defined upfront.
• Any write operation (CREATE, UPDATE) is validated against these schemas.
• Invalid data (e.g., a string value for a numeric property, or an edge connecting disallowed vertex types) is rejected at ingestion.

This approach, used by most native property graphs, guarantees immediate data consistency and quality, contrasting with the flexibility of schema-on-read.

Schema evolution is the process of modifying a graph database's schema over time without causing system downtime or data loss. For an edge schema, this involves operations like:

• Adding a new edge type or deprecating an old one.
• Adding a new property to an existing edge type.
• Changing the data type of an edge property (requiring data migration).
• Modifying cardinality or allowed vertex types for a connection.

Managing schema evolution requires careful planning, versioning, and often data transformation scripts to maintain application compatibility.