Property Graph

A node (or vertex) is the fundamental entity in a property graph, representing a distinct object such as a person, product, or event. Each node can have:

• A unique identifier
• One or more labels (e.g., Person, Product) to categorize it
• A set of properties (key-value pairs like name: 'Alice', age: 34)

Labels enable efficient filtering and indexing, while properties store the entity's attributes directly on the node itself.

A relationship (or edge) is a directed, named connection between two nodes that describes how they are associated. Every relationship has:

• A type (e.g., PURCHASED, WORKS_FOR) defining the nature of the link
• A direction (from a start node to an end node)
• Its own set of properties (e.g., since: 2023, amount: 150.50)

Unlike RDF, where relationships are just predicates, property graph relationships are first-class citizens that can carry data, enabling the modeling of rich, attributed interactions.

Properties are attributes attached to both nodes and relationships, stored as simple key-value pairs. This model allows for:

• Schema flexibility: Different nodes of the same label can have different property sets.
• Efficient storage and retrieval: Properties are stored natively with the graph element.
• Direct querying: Values can be filtered, sorted, and aggregated in queries.

For example, a Person node may have properties {name: 'Bob', department: 'Engineering'}, while a PURCHASED relationship may have {date: '2024-01-15', quantity: 2}.

Labels (on nodes) and Relationship Types provide semantic categorization and are critical for graph traversal and query optimization.

• Labels (e.g., Customer, Invoice) group nodes into sets. A node can have multiple labels.
• Relationship Types (e.g., SENT_TO, CONTAINS) define the semantics of a connection.

These are used in query languages like Cypher to quickly find starting points and constrain pattern matching. For instance, the query MATCH (p:Person)-[:LIVES_IN]->(c:City) uses labels and types to efficiently find all people and their cities.

The property graph model differs from the RDF model in several key ways:

• Properties vs. Reification: In RDF, attributing a statement (a triple) requires complex reification. In a property graph, relationships have native properties.
• Global vs. Local Identity: RDF uses global URIs for everything. Property graphs typically use internal IDs, with optional external keys.
• Schema Approach: RDF relies on external ontologies (RDFS, OWL). Property graphs often use an implicit, flexible schema via labels and types.

This makes property graphs highly intuitive for application developers modeling connected domain data, while RDF is optimized for global data integration and formal reasoning.

Property graphs are uniquely suited for uncovering sophisticated fraud rings and money laundering schemes by connecting entities across transactions. Analysts can model persons, accounts, devices, and transactions as nodes, with relationships like SENT_TO, OWNED_BY, and LOGIN_FROM. Key properties (e.g., amount, timestamp, location) are stored directly on nodes and edges.

• Pattern Matching: Queries can find circular payments, fast-paced transaction chains, or accounts sharing a device/IP address.
• Real-Time Analysis: Graph databases perform these complex multi-hop traversals in milliseconds, enabling real-time transaction blocking.
• Example: Identifying a mule account network by finding accounts that receive funds from many sources and quickly forward them to a common destination.

Powering 'customers who bought this also bought...' and content recommendations requires understanding intricate relationships between users, products, view histories, and categories. A property graph naturally captures this as a network.

• Collaborative Filtering: Model user-product interactions (PURCHASED, VIEWED, RATED) with properties like rating_score and view_duration. Graph algorithms like personalized PageRank or k-Nearest Neighbors can traverse this network to find similar users or items.
• Context-Aware Rules: Recommendations can be based on complex rules involving multiple entity types (e.g., 'recommend accessories for the laptop model the user researched, from brands they have purchased before').
• Dynamic Updates: New user interactions are simply new edges/nodes, allowing the recommendation model to evolve instantly.

Creating a unified 'golden record' for key entities like customers, products, or suppliers is a classic graph problem. Property graphs integrate disparate data silos by resolving entities and linking their attributes.

• Entity Resolution: Nodes represent candidate records from different source systems. Similarity algorithms compute match scores (stored as edge properties like match_confidence: 0.95), and a SAME_AS relationship merges them into a master entity.
• 360-Degree View: A query starting from a master Customer node can traverse to all related orders, support tickets, marketing interactions, and devices, with each relationship and node containing relevant operational properties (e.g., order_date, ticket_status).
• Data Lineage & Provenance: The graph itself maintains the lineage of how master records were created, providing auditability.

Modeling physical and logical IT infrastructure is inherently graph-oriented. Property graphs represent servers, switches, applications, services, and dependencies with high fidelity.

• Impact Analysis: When a Server node's status property changes to 'down', a query can instantly find all dependent Application and Service nodes via HOSTS and DEPENDS_ON relationships.
• Root Cause Analysis: Algorithms like breadth-first search can trace fault propagation paths through the network graph.
• Configuration Management: Properties on Router or Firewall nodes store config parameters. Relationships like CONNECTED_TO model network topology. This provides a complete, queryable map of the IT environment.

While RDF is the standard for open semantic webs, property graphs are extensively used for building enterprise knowledge graphs, especially when performance and rich attribute modeling are priorities.

• Unified Data Fabric: Integrate structured databases, unstructured documents (via extracted entities), and business glossary terms into a single connected graph. A Document node can be MENTIONS a Product node and a Regulation node.
• Context-Aware Search: Move beyond keyword matching. A search for 'side effects of treatment X' can traverse the graph: find the Drug node 'X', follow its TREATS relationship to a Disease node, then find all SideEffect nodes connected to that drug.
• Inference & Discovery: New relationships can be inferred by analyzing paths and patterns, enriching the knowledge base.

Global supply chains are complex networks of suppliers, manufacturing plants, distribution centers, transport routes, and products. Property graphs model this dynamic system with temporal and geospatial attributes.

• Route Optimization & Risk Analysis: Model Route segments as edges between Location nodes, with properties for cost, transit_time, and risk_score. Graph pathfinding algorithms (e.g., shortest weighted path) can calculate optimal shipments.
• Disruption Propagation: A delay at a Port node can trigger queries to find all Shipment nodes (state: 'in_transit') planning to use that port, and then recursively find affected downstream Order nodes.
• Bill of Materials (BOM) Explosion: Represent a product's composition as a hierarchical graph. A query can rapidly aggregate cost or identify single-source supplier risks by traversing CONTAINS relationships.

The standard data model for the Semantic Web, representing information as subject-predicate-object triples. Unlike property graphs, RDF is a labeled directed graph where nodes and edges are URIs or literals, and it lacks built-in support for properties on edges. It forms the universal foundation for linked data and semantic integration.

• Core Unit: A triple (e.g., <Person> <worksFor> <Company>).
• Key Distinction: Properties are first-class entities (predicates), not attributes attached to relationships.
• Primary Use: Creating globally interconnected, standardized data webs.

A declarative graph query language developed for Neo4j, specifically designed for property graph traversal and manipulation. Its intuitive ASCII-art syntax allows engineers to visually express graph patterns within the query itself.

• Pattern Matching: Uses syntax like (a:Person)-[:WORKS_FOR]->(b:Company) to find paths.
• Property Access: Directly references node and relationship properties using dot notation (e.g., a.name, r.since).
• Primary Use: The native query language for Neo4j and other property graph databases.

A specialized database architected for the efficient storage and retrieval of RDF triples. It is the RDF analogue to a property graph database, optimized for SPARQL queries and semantic reasoning over large-scale triple datasets.

• Data Model: Stores billions of subject-predicate-object statements.
• Query Engine: Built for complex SPARQL pattern matching and inference.
• Key Systems: Include Apache Jena Fuseki, Stardog, and Amazon Neptune (RDF mode).
• Primary Use: Hosting enterprise knowledge graphs built on RDF/OWL standards.

A database management system that uses graph structures (nodes, edges, properties) for semantic queries. It is the overarching category that includes both property graph databases (like Neo4j) and RDF triplestores. The core innovation is index-free adjacency, where each node contains a direct pointer to its connected nodes, enabling millisecond traversals regardless of graph size.

• Storage Types: Native graph storage vs. relational or NoSQL backends.
• Query Paradigm: Focus on relationships and paths, not joins.
• Primary Use: Applications where relationships are first-class citizens, such as fraud detection, recommendation engines, and network analysis.

The formal name for the property graph model, emphasizing its two key features: labels on nodes (defining types or roles) and properties on both nodes and relationships. This model is defined by a concrete meta-model (vertices, edges, labels, properties) and is the basis for the ISO/GQL standard query language initiative.

• Core Components: Nodes (with labels), Relationships (with a type and direction), Properties (key-value pairs).
• Standardization: The driving model behind the Graph Query Language (GQL) standard, aiming to be for graphs what SQL is for tables.
• Primary Use: The precise technical model implemented by Neo4j, Amazon Neptune (PG mode), and JanusGraph.

A community-driven extension to the RDF standard that introduces a concise syntax for making statements about other statements. This allows RDF to natively represent provenance, confidence scores, and temporal attributes on triples—functionality that is intrinsic to property graphs via relationship properties.

• Core Syntax: Uses <<s p o>> to denote a quoted triple that can itself be the subject or object of another triple.
• Bridging Function: Aims to bring property-graph-like capabilities (annotated edges) into the RDF ecosystem.
• Primary Use: Enriching RDF knowledge graphs with metadata about facts, such as source, validity period, or belief degree.