Property Key

A property key serves as the unique name for a specific piece of data attached to a vertex or edge. It is the atomic unit of a property graph's schema, analogous to a column name in a relational table.

• Key-Value Pair Structure: The property key defines the 'key' in the key-value pair, where the 'value' is the actual data (e.g., name: "Alice", timestamp: 1714070400).
• Semantic Role: The key itself carries meaning, defining what the attached value represents (e.g., dateOfBirth, purchaseAmount, confidenceScore).

Property keys are defined within a vertex schema or edge schema, which specifies allowed data types and constraints. This provides structure and data integrity.

• Data Type Enforcement: A schema can mandate that a salary key must have an INTEGER value, while a department key must be a STRING.
• Constraint Foundation: Uniqueness constraints and cardinality constraints are often applied based on property keys to enforce business rules (e.g., email must be unique across all Person vertices).

Property keys are the primary target for creating graph indexes. Indexing a key allows the database to find vertices or edges by property value without a full graph scan, dramatically accelerating lookup queries.

• Lookup Optimization: An index on the employeeId property key enables instant retrieval of a vertex when querying WHERE employeeId = 'E12345'.
• Composite Indexes: Multiple keys can be combined into a single index for queries that filter on several properties simultaneously.

It is critical to distinguish a property key from a label. A label categorizes the type of a vertex or edge (e.g., Person, WORKS_FOR), while a property key defines an attribute of that instance.

• Label = Type: A vertex has a label like Product. This defines its class.
• Property Key = Attribute: That Product vertex has property keys like sku, price, and weight. These define its specific characteristics.
• Query Implications: Queries often filter by label first (MATCH (p:Product)) and then by property values (WHERE p.price > 100).

The use of property keys varies between schema-on-write and schema-on-read approaches, offering a trade-off between rigor and agility.

• Schema-on-Write: Property keys must be pre-defined in a strict schema. Attempting to add an undefined key (e.g., color to a Person vertex) will result in an error, ensuring data consistency.
• Schema-on-Read: Property keys can be added dynamically to any vertex or edge at any time. The structure is interpreted during queries, offering maximum flexibility for evolving or heterogeneous data.

In the RDF triplestore model, the analogous concept to a property key is the predicate in a subject-predicate-object triple. While similar, there are fundamental differences in philosophy and capability.

• Property Key: Exists within a self-contained vertex/edge structure. A vertex holds its own properties locally.
• RDF Predicate: Defines a relationship between two resources (the subject and object). Properties are expressed as separate triples (e.g., :alice :hasAge "30"^^xsd:integer).
• Key Difference: Property graphs natively support properties on relationships (edges), which is a complex pattern to model in pure RDF.

These keys uniquely identify and describe the primary entities in a graph.

• id or uuid: A system-generated, globally unique identifier for a vertex or edge, ensuring referential integrity.
• name: A human-readable label for an entity, such as a person's full name or a product's title.
• email: A unique contact identifier for a Person or User vertex, often used for lookups and authentication.
• sku (Stock Keeping Unit): A unique alphanumeric code for a Product vertex in inventory or e-commerce graphs.

Keys that track the lifecycle and history of graph elements, essential for auditing and temporal queries.

• createdAt and updatedAt: ISO 8601 timestamps recording when a vertex or edge was created and last modified.
• validFrom and validTo: Timestamps defining the active period for a fact in a temporal knowledge graph, enabling historical queries.
• version: An integer or semantic version string tracking revisions of an entity's state, supporting schema evolution and rollback scenarios.

Properties that quantify or qualify the connections (edges) between vertices, adding semantic depth.

• weight or strength: A numerical value (e.g., 0.75) on a KNOWS or SIMILAR_TO edge, often used in graph algorithms like PageRank or community detection.
• since: A date property on a WORKS_FOR or MEMBER_OF edge, indicating when the relationship began.
• role: A string specifying the function within a relationship, such as "project_lead" on a ASSIGNED_TO edge between a Person and a Project.

Keys for storing coordinates and spatial metadata, enabling location-based queries and analytics.

• latitude and longitude: Decimal degree coordinates for a Location or Store vertex.
• address: A full textual address, which can be geocoded into separate components (street, city, postal code) as individual properties.
• geohash: A compact string encoding of geographic coordinates, useful for efficient proximity searches and spatial indexing.

Properties that describe the origin, quality, or administrative status of the data itself.

• source or sourceUri: A URL or system identifier documenting where the data originated, a key aspect of semantic data governance.
• confidence: A score (e.g., 0.0 to 1.0) indicating the reliability of a fact, often populated by entity resolution or knowledge graph completion algorithms.
• lastVerified: A timestamp showing when the property value was last confirmed against a trusted source.

Examples of specialized property keys from key enterprise verticals.

• Finance: amount, currency, transactionDate on a TRANSFERRED edge.
• Healthcare: dosage, frequency, startDate on a PRESCRIBED edge in a clinical knowledge graph.
• Supply Chain: quantity, unitCost, estimatedArrival on a CONTAINS edge between a Shipment and a Product.
• Cybersecurity: severityScore, firstSeen, ttp (Tactics, Techniques, and Procedures) on an INDICATOR_OF edge.