Logical Schema

Entity types, often called classes or vertex types, define the categories of real-world objects or concepts represented in the graph. They are the fundamental building blocks, analogous to tables in a relational model.

• Examples: Person, Product, Organization, Event.
• In RDF/OWL, classes are defined using rdfs:Class or owl:Class.
• In a property graph, they are typically implemented as vertex labels.
• A well-defined set of entity types establishes the core vocabulary of the domain.

Relationship types define the permissible connections between entity types. They capture the semantics of how entities are associated.

• In RDF, these are properties (predicates) like foaf:knows or schema:worksFor.
• In a property graph, these are edge types or relationship labels like PURCHASED or REPORTS_TO.
• They have a domain (source entity type) and a range (target entity type).
• Defining relationship types explicitly encodes the business logic and knowledge of the domain into the graph's structure.

Attributes are the descriptive properties assigned to entities or relationships. The logical schema defines the allowed attributes and their data types for each entity or relationship type.

• Examples: A Person entity type may have attributes name (string), birthDate (date), and employeeId (integer).
• In a property graph, these are property keys.
• In RDF, literals (strings, numbers, dates) are attached to subjects via properties.
• Specifying data types (e.g., xsd:string, xsd:dateTime) ensures data quality and enables correct query operations.

Logical schemas often define taxonomies through inheritance hierarchies, allowing for the organization and specialization of types.

• Subclassing (rdfs:subClassOf, owl:SubClassOf): An Employee is a subclass of Person. This implies that all constraints and properties of Person apply to Employee.
• Sub-properties (rdfs:subPropertyOf): hasCEO can be a sub-property of hasEmployee, meaning every CEO connection is also an employee connection.
• These hierarchies enable powerful inheritance-based reasoning and more concise, organized schema definitions.

Constraints are rules that enforce data quality and business logic at the model level, ensuring the graph remains consistent and meaningful.

• Cardinality Constraints: Restrict the number of relationships. (e.g., a Person can have exactly one biologicalMother).
• Uniqueness Constraints: Ensure a property value is unique for all instances of a type (e.g., employeeId).
• Domain/Range Constraints: Enforce that a relationship only connects specific entity types.
• Value Type & Pattern Constraints: Ensure a property value matches a regex pattern or is within a specific range.
• Tools like SHACL (Shapes Constraint Language) are explicitly designed for defining such constraints in RDF graphs.

In expressive logical schemas (ontologies), formal axioms define logical rules that enable automated inference of new facts.

• Inverse Properties: Declaring that hasParent is the inverse of hasChild. If A hasParent B is known, the system can infer B hasChild A.
• Transitive Properties: Declaring ancestorOf as transitive. If A ancestorOf B and B ancestorOf C, the system infers A ancestorOf C.
• Property Chains: Defining that hasUncle is equivalent to hasParent ◦ hasBrother.
• Disjointness: Declaring that Male and Female are disjoint classes (an individual cannot be both).
• These axioms, defined using languages like OWL, transform a passive data structure into an active knowledge base.

Models user interactions and content. Core entity types include Person and Post. Key relationship types are FOLLOWS (between Person nodes), LIKES (Person→Post), and AUTHORED (Person→Post).

• Constraints: A uniqueness constraint on Person.userId.
• Property Examples: Person nodes have properties like name, joinedDate. FOLLOWS edges can have a since timestamp property.
• Cardinality: A Post can have only one AUTHOR (one-to-many from Person to Post).

Connects customers, products, and behaviors for personalized suggestions. Central entity types are Customer, Product, and Category.

• Relationship Semantics: PURCHASED (Customer→Product), VIEWED (Customer→Product), BELONGS_TO (Product→Category).
• Key Properties: Product nodes include sku, price, brand. PURCHASED edges store quantity and purchaseDate.
• Inference Path: A recommendation can be generated by traversing Customer-PURCHASED->Product-BELONGS_TO->Category<-BELONGS_TO-OtherProduct.

Tracks hardware, software, and dependencies. Core entities include Server, Application, Database, and Employee.

• Dependency Modeling: HOSTS (Server→Application), DEPENDS_ON (Application→Database), OWNS (Employee→Server).
• Critical for Impact Analysis: A schema like this enables rapid traversal to answer "Which applications are affected if this server fails?"
• Property Examples: Server nodes have hostname, ipAddress, osVersion. DEPENDS_ON edges may have a connectionString property.

Integrates biological entities for research. Standard entity types are Gene, Protein, Disease, and Drug.

• Semantic Relationships: ENCODES (Gene→Protein), ASSOCIATED_WITH (Gene→Disease), TREATS (Drug→Disease), INTERACTS_WITH (Protein→Protein).
• Uses Rich Ontologies: Often aligns with public ontologies like the Gene Ontology (GO) or Disease Ontology (DOID) for standardized typing.
• Enables Discovery: Paths like Drug-TREATS->Disease<-ASSOCIATED_WITH->Gene help identify novel drug targets.

Models transactions, accounts, and parties to identify suspicious patterns. Key entities are Account, Transaction, Person, and Merchant.

• Money Flow Tracking: SENT (Account→Transaction), RECEIVED (Transaction→Account), OWNS (Person→Account).
• Temporal Properties: Transaction nodes have amount, currency, timestamp. OWNS edges have a validFrom/validTo for temporal history.
• Analytics Foundation: This schema supports graph algorithms like community detection to find clusters of colluding accounts.

Organizes digital assets with rich metadata. Core entities are Article, Author, Tag, and Category.

• Hierarchical & Tagging Relations: WROTE (Author→Article), HAS_TAG (Article→Tag), SUBCATEGORY_OF (Category→Category).
• Flexible Tagging: Tag nodes allow for a folksonomy (user-generated categorization) alongside the formal Category hierarchy.
• Query Patterns: Enables faceted search via queries like "Find all Articles by Author X that have Tag Y within Category Z."

The physical schema is the concrete, implementation-specific realization of a logical schema. It defines how the abstract data model is physically stored and accessed on disk or in memory.

• Key Details: Specifies file formats, indexing strategies (e.g., B-trees, LSM-trees), partitioning schemes, and data encoding.
• Relationship to Logical Schema: A single logical schema can be implemented by multiple physical schemas across different database systems (e.g., Neo4j vs. Amazon Neptune).
• Performance Impact: Choices in the physical schema directly determine query latency, storage efficiency, and scalability.

A graph schema language is a formal syntax used to declaratively define the structure and constraints of a logical schema.

• Purpose: Provides a machine-readable and often human-writable specification for vertex types, edge types, property keys, and data constraints.
• Examples:
  • Cypher's CREATE CONSTRAINT: Used in property graphs (e.g., CREATE CONSTRAINT FOR (p:Person) REQUIRE p.id IS UNIQUE).
  • PGQL's Schema Definition Language: A standard for the Property Graph Query Language (GQL).
  • Apache TinkerPop's Gremlin Type Definitions: For defining schema in JanusGraph or other TinkerPop-enabled systems.
• Advantage: Enables schema validation, automated documentation, and tool-assisted data modeling.

RDF Schema (RDFS) is a foundational semantic extension of the Resource Description Framework (RDF) used to define lightweight ontologies, serving as a logical schema for RDF triplestores.

• Core Constructs: Provides basic vocabulary (e.g., rdfs:Class, rdfs:subClassOf, rdfs:domain, rdfs:range) for organizing entities and properties into taxonomies.
• Function: It defines classes of resources and the properties (predicates) that can be applied to them, establishing a type system for RDF data.
• Inference Enablement: RDFS axioms allow for basic semantic reasoning, such as inferring that an instance of a subclass is also an instance of its superclass.
• Contrast with Property Graphs: While a property graph's logical schema defines labels and property keys, RDFS defines classes and properties with formal inheritance semantics.

SHACL is a W3C standard for validating RDF graphs against a set of conditions, effectively defining a rigorous, constraint-based logical schema.

• Primary Role: Schema validation. SHACL shapes define the expected structure, data types, value ranges, and cardinality for nodes in an RDF graph.
• Key Features:
  • Property Constraints: Mandate the presence, datatype, and allowed values of properties.
  • Logical Constraints: Support AND, OR, NOT operations.
  • Closed-World Assumption: Can declare that only specified properties are allowed on a node.
• Analogy: For RDF, SHACL serves a similar purpose to the combination of a relational CREATE TABLE statement and CHECK constraints, ensuring data quality and integrity.

Schema mapping is the process of defining transformation rules that align elements of a source data schema (e.g., relational, JSON) with the target logical schema of a knowledge graph.

• Core Activity: Creating correspondences between source fields/columns and target graph entities, relationships, and properties.
• Techniques:
  • Direct Mapping: A field customer_name maps to a name property on a Customer vertex.
  • Complex Transformation: A join between Orders and Products tables maps to a PURCHASED edge between Person and Product vertices.
  • Value Transformation: Converting string status codes to enumerated property values.
• Tools: Often implemented using ETL/ELT tools (e.g., Apache NiFi, custom Spark jobs) or dedicated semantic integration frameworks. It is the critical bridge between raw data and a populated graph adhering to its logical schema.

Schema evolution encompasses the strategies and processes for modifying a graph's logical schema over time without causing system failures or data corruption.

• Challenge: Applications and queries depend on a stable schema, but business requirements change, necessitating updates.
• Common Operations:
  • Additive Changes: Introducing new vertex/edge types or optional properties (generally safe).
  • Destructive Changes: Renaming or removing types, or making optional properties required (risky, requires data migration).
  • Refactoring Changes: Splitting a vertex type into more specialized subtypes.
• Best Practices:
  • Use versioned schemas to track changes.
  • Implement backward compatibility where possible.
  • Employ gradual rollout and data migration scripts for breaking changes.
  • Update associated indexes and constraints in tandem.