Validation and Reasoning

Validation and Reasoning

This page captures the design decision space around schema validation and inference. The topic is intentionally left open — no implementation is planned until the Graph API is designed and real use cases are clearer.

Design boundary

mGraphDB draws a clear line at the storage layer:

Layer	Responsibility	Status
Storage	Schema-less; stores any node/edge/property without constraints (REQ-05).	Core design
Validation	Check whether data conforms to a declared shape.	Future optional layer
Inference / reasoning	Derive new facts from existing data and an ontology (e.g. subclass transitivity).	Future, likely external

This split is well-established in the broader ecosystem. RDF triple stores are separate from OWL reasoners. Neo4j's constraint system is opt-in. The principle here: the storage engine should never reject a write because of a shape rule; that is the validation layer's job.

Candidate schema / validation languages

SHACL — Shapes Constraint Language (W3C)

Defines shapes: sets of constraints that nodes in a graph should satisfy. Validation is a query against the shapes graph; it produces a report of violations, not a write rejection.

• Pure validation — no inference, no closed-world assumption.
• Designed for RDF, but the concepts (shape node, target, constraint, severity) transfer directly to a property graph.
• Well-specified and tooled; mapping to SHACL later enables interoperability with the linked-data ecosystem.

ShEx — Shape Expressions

Similar goal to SHACL with a more concise, regex-inspired syntax. Popular in the biomedical / linked-data community. Also RDF-centric.

PG Schema (ISO/IEC 39075 — GQL)

A schema language designed specifically for property graphs, not RDF. Part of the emerging GQL (Graph Query Language) ISO standard.

• Closer to the property graph model used here.
• Still evolving; tooling is limited today (2026).
• Worth tracking as it matures — may become the natural standard for property graph schema.

JSON Schema (for property values)

Validates property values (strings, numbers, booleans, dates) against a declared type and constraints. Well-known, excellent tooling.

• Scope is narrow: value shapes only, not graph structure.
• Could be useful as a component of a larger validation approach, not as a complete graph schema language.

The in-graph shapes approach

The most architecturally consistent option for mGraphDB is to represent shapes as nodes and edges in the graph itself. A shape is just a node; its constraints are edges to other nodes (property name, cardinality, value type).

[Shape: Person]
    ── hasConstraint ──> [Constraint: name, minCount=1, type=STRING]
    ── hasConstraint ──> [Constraint: age,  maxCount=1, type=INTEGER]

This is exactly what SHACL does — it uses RDF triples to describe shapes. mGraphDB would use its own node/edge vocabulary to describe the same thing, keeping the model consistent ("everything is a node") and requiring no external schema language to be parsed.

Advantages:

• Zero additional concepts — shapes are stored and traversed exactly like any other graph data.
• Schema evolution is free: add, modify, or remove shape nodes without migrating the data they describe.
• Can map to SHACL or PG Schema later for interoperability.
• Validation becomes a graph query: "find all nodes of target X that violate a constraint attached to shape Y."

Open questions

These need to be answered when the Graph API is designed:

1. Scope: Is validation part of the core project, or a library built on top of the Graph API?
2. Language: Custom in-graph vocabulary, SHACL-compatible, PG Schema, or something else?
3. Mode: Report-only (produce a violation list), or can the API surface a validation hook that callers can use to guard writes?
4. Inference: Is basic inference (subclass/subproperty propagation) ever in scope, or always an external concern?
5. Ontology as data: An OWL-style ontology subgraph can live in the store today — it is just nodes. The open question is whether mGraphDB should understand and act on it, or leave that to a layer above.

Related requirements

REQ	Description
REQ-05	The storage engine is schema-less; no constraints enforced at write time.
REQ-04	A node may optionally carry a type reference to a class node.

Further reading

• SHACL W3C Recommendation
• ShEx specification
• ISO GQL / PG Schema
• General Concepts — schema-less design rationale