Label

A label is the fundamental type identifier for a graph element. It acts as a tag attached to a vertex or edge, categorizing it into a distinct class or set. This enables efficient type-based operations.

• For vertices: Labels categorize nodes (e.g., Person, Product, Organization).
• For edges: Labels define the nature of the relationship (e.g., PURCHASED, WORKS_FOR, CONTAINS).
• Multiple labels: A single vertex can have multiple labels (e.g., Person:Customer), supporting flexible polymorphism and inheritance-like structures within the graph model.

Labels enable the definition of a graph schema by serving as the anchor for structural rules. Database constraints are applied per label to enforce data integrity.

• Uniqueness constraints: Ensure a property value is unique across all vertices with a specific label (e.g., email on Person).
• Property existence constraints: Mandate that all vertices/edges of a given label must have a specific property key.
• Cardinality constraints: Can be implemented at the application layer to restrict the number of relationships of a specific label a vertex can have.
• Data type enforcement: Schemas can define the expected data type (String, Integer, etc.) for properties on a per-label basis.

Labels are critical for graph query optimization. They allow the query engine to quickly filter and locate relevant portions of the graph, bypassing full scans.

• Indexing: Labels are often used in composite indexes (e.g., an index on :Person(name)). Starting a traversal from a labeled vertex using an indexed property is a constant-time operation.
• Query planning: In languages like Cypher, specifying a label (MATCH (p:Person)) immediately restricts the search space, allowing the planner to choose efficient execution paths.
• Parallel execution: In distributed graphs, labels can inform graph partitioning strategies, co-locating connected entities of the same type to minimize cross-machine traversals.

In the property graph model, a label is a core, native structural element. This differs from the RDF model, where typing is done via a specific predicate.

• Property Graph: A label is an intrinsic, schema-enforcing tag attached directly to the vertex/edge.
• RDF Triplestore: An entity's type is defined by an explicit triple using the rdf:type predicate (e.g., <Alice> rdf:type <Person>).
• Implication: In RDF, rdf:type is just another triple, offering flexibility but requiring explicit reasoning. In property graphs, the label is a first-class citizen used directly by the database engine for storage optimization and constraint validation.

A single vertex can be assigned multiple labels, enabling rich, overlapping categorizations. This supports design patterns akin to multiple inheritance or interface implementation.

• Use Case: A vertex can be both a Person and an Employee, allowing queries to target either the broader category (Person) or the specific role (Employee).
• Polymorphic queries: A query for :Person will return all vertices with that label, including those also labeled Employee. This is useful for hierarchical or role-based data models.
• Schema Design: Multi-labels allow for modeling complex domain relationships without requiring numerous intermediate junction nodes.

Graph query languages have specific syntax for leveraging labels in pattern matching and data manipulation.

• Cypher (Neo4j): Labels are prefixed with a colon, e.g., (:Person)-[:WORKS_FOR]->(:Company). The WHERE clause can filter labels dynamically using WHERE n:Label.
• GQL (ISO Standard): Follows a similar colon-prefix syntax, standardizing label usage across implementations.
• Gremlin (Apache TinkerPop): Uses the .hasLabel('Person') step filter within a traversal. Labels are treated as a special property key.
• Core Operation: Label-based matching is the starting point for most efficient graph traversals, enabling the engine to leverage native storage structures like index-free adjacency within a labeled subset.

These are foundational entity labels for representing actors in a social or business graph.

• Person: Used for vertices representing individuals. Common properties include name, email, dateOfBirth.
• Organization: Used for vertices representing companies, departments, or groups. Properties often include name, industry, foundedDate.
• Edge Labels: Relationships like WORKS_FOR (from Person to Organization), OWNS (from Person to Organization), or SUBSIDIARY_OF (from Organization to Organization) connect these entities.

Labels for structuring e-commerce or inventory data into a navigable hierarchy.

• Product: A vertex representing a sellable item. Properties: sku, name, price, inStock.
• Category: A vertex for product classification (e.g., 'Electronics', 'Clothing'). Properties: name, description.
• Edge Labels: BELONGS_TO connects a Product to a Category. SUBCATEGORY_OF creates a taxonomy tree between Category vertices, enabling hierarchical queries.

Labels for modeling temporal occurrences and their geospatial context.

• Event: A vertex for something that happens at a point in time. Properties: title, startTime, endTime.
• Location: A vertex for a physical or logical place. Properties: address, city, coordinates (as a geo-point).
• Edge Labels: OCCURRED_AT (Event → Location), HOSTED (Location → Event). Additional labels like Person connect via ATTENDED or ORGANIZED edges.

Labels for building content graphs for search and recommendation systems.

• Document: A vertex for a text artifact (article, report, webpage). Properties: title, url, contentHash, publishDate.
• Keyword or Topic: A vertex representing a key concept or tag. Property: term.
• Edge Labels: CONTAINS_KEYWORD (Document → Keyword) with a relevanceScore property. REFERENCES (Document → Document) can create a citation network.

Labels for financial or audit graphs tracking flows between entities.

• Transaction: A vertex representing a financial event. Properties: amount, currency, timestamp, transactionId.
• Account: A vertex representing a wallet, bank account, or ledger. Properties: accountId, balance, type.
• Edge Labels: FROM_ACCOUNT and TO_ACCOUNT connect the Transaction vertex to the involved Account vertices. This structure allows for efficient fraud detection via pattern matching on transaction chains.

Labels for IT infrastructure, microservices, or supply chain dependency graphs.

• System or Service: A vertex for a software component. Properties: name, version, status, owner.
• Dependency: Often modeled as an edge label, not a vertex. Example: DEPENDS_ON.
• Edge Properties: The DEPENDS_ON edge can have properties like protocol (HTTP, gRPC) and requiredVersion. This graph enables impact analysis; querying all downstream dependencies of a failing system is a simple traversal.

A vertex schema defines the blueprint for a category of nodes in a property graph. It specifies the label (e.g., Person, Product), the allowed property keys with their data types, and any constraints. This is analogous to a table definition in a relational database, providing structure and governance for node data.

• Purpose: Enforces data integrity and enables efficient indexing.
• Example: A Customer vertex schema might define properties for customer_id (String, unique), name (String), and lifetime_value (Float).

An edge schema defines the structure for a category of relationships connecting vertices. It specifies the relationship type (e.g., PURCHASED, WORKS_FOR), the permitted source and target vertex labels, and the properties the edge can carry.

• Purpose: Governs the semantics and validity of connections in the graph.
• Example: A WORKS_FOR edge schema might specify it can only connect a Person vertex to a Company vertex and can have properties like start_date and title.

A property key is the name or identifier for a specific attribute that holds a value on a vertex or edge. While a label categorizes the entity type, property keys define its attributes.

• Key Characteristics: Property keys are defined within a vertex or edge schema with an associated data type (String, Integer, etc.).
• Usage: Enables filtering, sorting, and indexing. For example, a Person vertex (label) might have property keys like name, email, and date_of_birth.

A uniqueness constraint is a schema rule applied to a vertex label that ensures the value of a specified property (or composite of properties) is unique across all vertices of that type. It is a critical mechanism for preventing duplicate entities.

• Function: Enforces entity identity. Often applied to natural keys like employee_id or product_sku.
• Database Enforcement: When created, the database typically builds a supporting index to enforce the constraint efficiently.

A graph schema language is a formal syntax or language used to declaratively define the structure of a graph database. It allows data architects to specify labels, property keys, data types, and constraints in a machine-readable format.

• Examples:
  • Cypher's CREATE CONSTRAINT: Used in Neo4j to define uniqueness and property existence constraints.
  • Apache TinkerPop's Gremlin Schema: A DSL for defining schemas in Gremlin-compatible graphs.
  • Vendor-Specific DDL: Many graph databases offer their own Data Definition Language extensions.

Schema-on-write is a data modeling paradigm where data must conform to a predefined, rigid schema (including labels and property definitions) before it can be persisted to the database. This contrasts with schema-on-read approaches used in data lakes.

• Advantage: Guarantees immediate data integrity, consistency, and query performance.
• Graph Context: Writing a vertex requires specifying its valid label and ensuring its properties match the defined types for that label. This is the standard model for operational property graph databases.