# The Neo4j Ontology Graph Specification: A pragmatic, open, AI-first approach > Source: > Published: 2026-11-05 19:57:17+00:00 # The Neo4j Ontology Graph Specification: A pragmatic, open, AI-first approach 7 min read We’re announcing the [Neo4j Ontology Graph Specification](https://neo4j.com/docs/ontology-graph-spec/), an open-source specification for representing domain knowledge in a machine-readable form that enables interoperability and automation across data, applications, and AI systems. Ontologies are critical components of AI systems and enterprise applications, and the Neo4j Ontology Graph Specification makes domain knowledge easy to describe, share, and use across Neo4j Graph Intelligence Platform. Neo4j’s experience with ontologies has been shaped by years of working with customers to: - Make domain knowledge and its semantics explicit - Use ontologies as shared models for knowledge graph construction - Improve retrieval in GraphRAG applications We’ve also developed [software](https://neo4j.com/labs/neosemantics/) to support interoperability with W3C standards such as RDF, RDFS, and OWL. The Neo4j Ontology Graph Specification builds on this experience, bringing rigor and interoperability to a representation designed for today’s graph and AI applications. ## Pragmatic: Focused on practical value An ontology gives people and systems a shared, well-defined understanding of a domain and helps organizations build applications. The Neo4j Ontology Graph Specification provides a clear, accessible, and machine-readable way to describe entities, relationships, properties, and business meaning. We designed it to fit naturally into the workflows teams use to develop, integrate, and operate applications. Pairing rigor with practical use, our approach brings structure and consistency to knowledge graph development, simplifies integration, and makes the knowledge in graphs easier to understand and use. ## Interoperable: Embracing a broad ecosystem W3C standards for knowledge representation, including RDFS, OWL, SKOS and SHACL, have made foundational contributions and will continue to play an important role. At the same time, the ways organizations use ontologies are expanding. Teams use them to describe data consistently across operational and analytical systems, and to give AI agents the context they need to interpret and work with it. You can see different versions of this in Palantir Foundry, Databricks Genie Ontology and Microsoft Fabric IQ. Foundry connects business objects and relationships with operational actions. Databricks combines governed business semantics with knowledge snippets drawn from data assets and usage. Fabric IQ defines business entities, relationships, properties and constraints. The implementations differ, but they point to a shared need: explicit, machine-readable domain knowledge that data systems and AI can use. This broader range of uses brings additional requirements. Ontologies need to capture enough domain meaning to support validation, integration, retrieval and other forms of automation, and make that meaning usable across systems, applications and AI agents. The Neo4j Ontology Graph Specification reflects this broader use: it offers a graph-oriented representation with documented mappings to selected RDFS and SHACL constructs, while adding constructs for a wider range of application scenarios. The goal is to make knowledge more accessible, interpretable and reusable across technologies. ## AI-first: Ontologies for a new generation of architectures A schema tells an agent what exists, not what it means. An agent querying a graph needs to know that “Account” could mean a bank account or a payment account, that people might refer to it as a “bank account,” and that an IBAN identifies it. The Neo4j Ontology Graph Specification captures this context alongside the graph structure, giving people, applications, and AI agents shared definitions for business concepts. ## One ontology, many uses The same ontology can serve several purposes. The database can enforce it as a set of constraints on data. Teams can write ontology-driven logic and use it to derive or enrich data, or give applications and agents context for interpreting and working with information. These uses can coexist, and the specification provides a shared way to describe the knowledge behind them. This enables teams to write and maintain one ontology specification and use it everywhere. ## What’s included in the Neo4j Ontology Graph Specification The specification describes a graph’s domain model in a single document, JSON or YAML, validated structurally against a published JSON schema. Versioned schemas are immutable ([/1.0.0/schema.json](https://neo4j.com/docs/ontology-graph-spec/1.0.0/schema.json)); a /current/ alias always points at the latest. The core primitives: - **Nodes and relationships** , keyed by stable IDids, with identifying, implied and optional labels, descriptions and aliases - **Properties** using the full Neo4j type system, including temporal, spatial and vector types - **Cardinality** at each relationship end - **Constraints** (existence, uniqueness, key, property type) with shorthands that expand into full constraint objects - **A reference field** on every element, linking back to external definitions like public standard ontology terms or documentation - **Named extensions** for indexes, display hints and data-source mappings, so tooling concerns stay separate from the model itself A small example in YAML: ``` schema: "https://neo4j.com/docs/ontology-graph-spec/1.0.0/schema.json" id: "fraud-ontology" name: "Fraud detection" version: "1" nodes: person: label: Person description: "A customer or account holder" aliases: ["customer", "account holder"] properties: email: type: STRING description: "Primary contact email, used for account notifications" unique: true account: label: Account description: "A bank or payment account" aliases: ["bank account"] properties: iban: type: STRING description: "International bank account number" key: true relationships: person-owns-account: type: OWNS description: "Legal ownership of an account by a person" from: { node: person } to: { node: account, min_count: 1 } ``` The spec is versioned semantically: Breaking changes require a major version, and additions arrive as backwards-compatible minors. SDKs for JVM, JavaScript, and Go are available today in the [open source repository](https://github.com/neo4j/ontology-graph-spec). ## Building for the next generation of intelligent applications We believe the future of knowledge graphs will draw on established standards while evolving to meet new applications and needs. Our contribution is the Neo4j Ontology Graph Specification: pragmatic by design, open to a broader ecosystem, and built with AI-native applications in mind. We invite the community to explore the specification, contribute to its development, and shape how knowledge graphs are modeled and used in the next generation of intelligent applications. ### Getting started Write a model for a graph you already run, check it against the JSON Schema with any validator (for example, `check-jsonschema --schemafile https://neo4j.com/docs/ontology-graph-spec/1.1.0/schema.json your-model.yaml`), and tell us what you couldn’t express. The specification is open source under Apache 2.0: open an issue, follow releases, or contribute on GitHub. ### New capabilities for devs, data engineers, and knowledge engineers - If you build apps, you get a plain YAML or JSON file, checked against a published JSON Schema and readable through SDKs for JVM, JavaScript/TypeScript and Go, that defines your nodes, relationships, constraints and indexes in one place. - If you’re a data engineer, the same file carries your constraints, indexes and data-source mappings, and built-in validators check that the schema can be created in Neo4j and that the mappings can be used to import data. - If you’re a knowledge engineer, you can capture concepts with definitions, synonyms, hierarchies (a Customer implies a Person) and links to the standard terms they correspond to, in a versioned file that people and tools both read, without maintaining separate glossaries. - If you work with the W3C stack, we have not defined an RDF-based serialization (we may do it in the future), but the documentation explains how RDFS and SHACL concepts map onto it, and its reference field links each element back to the standard terms you already use. - If you build agents, descriptions, and aliases, tell your agent what Account means and what else people call it, so it works from the domain’s meaning and not only from the labels it finds in the schema. - If you lead a data team, you can define your domain once, as a versioned, open-source (Apache 2.0) file that people, tools, and agents all read, so there is one definition to review and keep current. **To learn more about the Neo4j Ontology Graph Specification, take a look at our** **documentation****. For a deeper dive into ontologies, check out our upcoming NODES session, “****Native ontology management in Neo4j****.”**