# Knowledge Graph Best Practices Guide | Data AI Hub
Canonical: https://social-archive.org/arc/3n9DfB2usx
Original URL: https://www.dataaihub.co/learn/knowledge-graph-best-practices
Author: Data AI Hub
Platform: web
Share mode: full
## Content
## TL;DR - **Start with use-case-driven modeling** — define the questions your graph must answer before designing the full ontology. A knowledge graph is a semantic model; the graph database is just where you store it. - **Entity resolution is non-negotiable** — duplicate nodes destroy trust faster than missing data. Resolution is a platform capability, not an ETL afterthought. - **Schema evolution is continuous** — plan for additive changes, versioning, and backward-compatible migrations from day one. Ontology changes follow the same rigor as API versioning. - **Data quality gates belong in the pipeline** — validate at ingest with [SHACL](https://www.dataaihub.co/learn/shacl) or constraints, not after users discover bad data in production. - **Governance beats technology** — assign stewards per domain, version ontologies in Git, and review schema changes like API changes. Neo4j, Stardog, GraphDB, Neptune, and Jena are interchangeable compared to modeling discipline. ## Why This Matters Most knowledge graph projects fail quietly. Not because Neo4j or GraphDB was the wrong choice, but because the graph became an unmaintainable tangle of duplicate entities, inconsistent relationship types, and ontologies nobody dared to change. A support team builds a graph to link customers, tickets, and products. Six months later, `Customer` nodes exist under four naming conventions, `RELATED_TO` edges mean different things in different domains, and a schema change breaks three downstream dashboards. The graph still exists — but nobody trusts it. A pharma team loads drug–target–trial data without [SHACL](https://www.dataaihub.co/learn/shacl) validation; 12% of `ClinicalTrial` nodes reference deprecated trial IDs. Compliance reporting fails an audit. Best practices are not bureaucracy. They are the engineering patterns that keep a [knowledge graph](https://www.dataaihub.co/learn/what-is-a-knowledge-graph) queryable, trustworthy, and evolvable as your organization learns what it actually needs from structured knowledge. They are the difference between a departmental experiment and an [enterprise knowledge graph](https://www.dataaihub.co/learn/enterprise-knowledge-graphs) that powers search, analytics, compliance, and [GraphRAG](https://www.dataaihub.co/learn/graphrag) / [RAG](https://www.dataaihub.co/learn/rag) consumers for years. The critical distinction throughout: **a knowledge graph is not a graph database**. Stardog, GraphDB, Neptune, Neo4j, and Apache Jena are storage and query engines. Best practices govern the semantic layer — ontology, identity, provenance, validation, and stewardship — that makes those engines worth operating. ## The Problem Knowledge graphs are deceptively flexible. Unlike relational schemas, you can add nodes and edges without migrations — which encourages organic growth until the graph becomes impossible to reason about. Three failure modes drive the need for disciplined practices: **Ontology sprawl.** Every team adds classes and predicates for their immediate need. `worksFor`, `employedBy`, `hasEmployer`, and `employeeOf` coexist as synonyms nobody consolidates. Queries become archaeology. Downstream [GraphRAG](https://www.dataaihub.co/learn/graphrag) pipelines retrieve inconsistent relationship types, and LLM answers contradict themselves. **Data quality decay.** Without validation at ingest, 15% of `Person` nodes lack email, `suppliedBy` edges point to deprecated vendors, and entity resolution duplicates accumulate weekly. Trust erodes silently until a compliance officer finds double-counted counterparty exposure or a [RAG](https://www.dataaihub.co/learn/rag) system cites a merged-but-wrong entity. **Schema change paralysis.** Downstream consumers hardcode relationship names. Changing `dependsOn` to `DEPENDS_ON` breaks [SPARQL](https://www.dataaihub.co/learn/sparql) queries in production. Teams stop evolving the schema; the graph fossilizes while business requirements change. **Graph-database confusion.** Teams optimize Neo4j indexing or Stardog cluster sizing while ignoring ontology governance. They have a fast graph store — not a knowledge graph. Performance tuning matters, but it cannot fix duplicate entities or missing provenance. Best practices provide **guardrails** — not to slow delivery, but to prevent rework that costs 10x more than upfront discipline. ## How We Got Here Knowledge graph best practices emerged from repeated project failures across semantic web, graph database, and enterprise data integration communities: **Diagram: Evolution of KG engineering practices** ``` flowchart LR A[Ad-hoc graph loads] --> B[Ontology standards / OWL] B --> C[SHACL validation] C --> D[MDM + entity resolution] D --> E[Governed enterprise KG] E --> F[GraphRAG + LLM grounding] ``` *Each generation added discipline after learning that flexible graphs without governance become unmaintainable.* | Phase | What teams learned | Practice that emerged | | --- | --- | --- | | **Early graph DB projects (2010s)** | Fast traversals ≠ trusted data | Use-case-first modeling | | **Semantic web adoption (2010s–2020s)** | OWL complexity kills projects | Minimal ontology, version in Git | | **Enterprise MDM integration (2010s–2020s)** | Golden records need graph relationships | Canonical identity + `sameAs` | | **SHACL standardization (2017+)** | Post-load cleaning fails at scale | Validate at ingest, quarantine violations | | **AI consumption (2024+)** | LLM extraction injects noise | Human-in-the-loop + SHACL before merge | | **Enterprise platforms (2020s+)** | Departmental graphs don't scale | Stewardship councils, named graphs, federation | Frameworks like [LangChain](https://www.dataaihub.co/tools/langchain) and [LlamaIndex](https://www.dataaihub.co/tools/llamaindex) make it easy to connect LLMs to graphs — but they do not replace modeling discipline. The graph you connect must be governed first. ## Architecture Best practices define the **semantic architecture** of a production knowledge graph — independent of whether you store in Stardog, GraphDB, Neptune, Neo4j, or Jena. **Diagram: Knowledge graph best-practices architecture** ``` flowchart TB subgraph Modeling["Modeling Layer"] UC[Use-Case Query Patterns] ONT[Minimal Ontology] ID[Canonical Identity Strategy] end subgraph Quality["Data Quality Layer"] SHACL[SHACL / Constraints] ER[Entity Resolution] PROV[Provenance on Every Fact] end subgraph Evolution["Schema Evolution Layer"] VER[Ontology Versioning in Git] DUAL[Dual-Write Migrations] IMP[Impact Analysis] end subgraph Governance["Governance Layer"] ST[Domain Stewards] REV[PR Review for Schema Changes] MET[Quality Metrics Dashboard] end subgraph Engine["Graph Database Engine"] DB[Stardog / GraphDB / Neptune / Neo4j / Jena] end UC --> ONT ONT --> ID ID --> SHACL SHACL --> ER ER --> PROV PROV --> DB VER --> ONT DUAL --> VER IMP --> REV ST --> REV REV --> MET MET --> SHACL ``` *The knowledge graph is the modeled, validated, governed semantic layer — the database engine is the bottom box.* ### Graph design principles #### Principle 1: Use-case-first modeling Do not model the entire enterprise before loading data. Pick one high-value use case — supplier risk, customer 360, document entity linking, fraud counterparty exposure — and model only the entities and relationships that use case requires. | Use Case | Core Entities | Key Relationships | | --- | --- | --- | | Customer 360 | Customer, Account, Contact | `hasAccount`, `primaryContact`, `ownsSubscription` | | Supply chain risk | Product, Component, Supplier, Country | `contains`, `suppliedBy`, `locatedIn` | | Fraud / compliance | Counterparty, Trade, SanctionList | `references`, `listedOn`, `holds` | | Life sciences | Drug, Target, Trial, Disease | `targets`, `tests`, `treats` | | Expert finder | Person, Skill, Project, Document | `hasSkill`, `workedOn`, `authored` | | Digital twin | Asset, Sensor, Event | `hasSensor`, `emits`, `triggers` | Expand the ontology when a **new use case** needs entities the current schema lacks — not when someone imagines a future need. #### Principle 2: Stable identity Every entity gets a canonical ID independent of source system identifiers. ``` # Bad - source ID as primary key (customer:CRM-8842) # Good - canonical ID with source links (customer:acme-corp-001 { crmId: "CRM-8842", billingId: "BILL-991" }) ``` Use `sameAs` ([RDF](https://www.dataaihub.co/learn/rdf)) or `SAME_AS` edges (property graphs) to link source records. Entity resolution merges duplicates into the canonical node. #### Principle 3: Typed, minimal relationships Prefer specific relationship types over generic ones. | Avoid | Prefer | Why | | --- | --- | --- | | `RELATED_TO` | `suppliedBy`, `authoredBy`, `dependsOn` | Queries filter on edge type; generics are unqueryable | | `hasProperty` edges for everything | Node attributes for scalar values | Properties on nodes are simpler; reserve edges for traversals | | Deep reification | Edge properties (LPG) or RDF-star | Reification adds triples for every edge attribute | > Tip Cap relationship types at what your query patterns need. If nobody traverses `mentoredBy`, do not model it until someone asks. #### Principle 4: Provenance on every fact Store where each assertion came from: - `sourceSystem` — CRM, ERP, manual steward, LLM extraction - `assertedAt` — timestamp of ingestion - `confidence` — for ML-extracted facts - `validFrom` / `validTo` — for temporal facts Without provenance, debugging wrong answers and satisfying auditors is impossible. ### Ontology design An [ontology](https://www.dataaihub.co/learn/ontologies) defines the vocabulary your graph speaks — classes, properties, constraints, and hierarchies. **Start minimal, version always:** 1. **Core classes** — 5–15 types covering your use case (e.g., `Person`, `Organization`, `Product`). 2. **Object properties** — relationships between classes (`worksAt`, `supplies`). 3. **Data properties** — scalar attributes (`email`, `foundedYear`). 4. **Constraints** — cardinality, required fields, allowed value ranges. Store ontologies in Git. Tag releases (`ontology-v1.3.0`). Downstream pipelines pin to a version. > Important Treat ontology changes like API versioning. Breaking renames require migration scripts and consumer notification. ### RDF vs property graph modeling | Practice | RDF (Stardog/GraphDB/Neptune/Jena) | Property Graph (Neo4j) | | --- | --- | --- | | Class definition | `rdfs:Class`, OWL | Node labels | | Relationship typing | Predicate URI | Relationship type | | Validation | SHACL shapes | Neo4j constraints, Cypher checks | | Hierarchy | `rdfs:subClassOf` | Label inheritance (varies by DB) | | Identity linking | `owl:sameAs` | `SAME_AS` edges | Pick one model per graph. Converting between RDF and property graphs in production is expensive — design for your query language and compliance requirements upfront. See [RDF vs Property Graph](https://www.dataaihub.co/learn/rdf-vs-property-graph). ## Step-by-Step Flow Follow this flow when designing, building, and maintaining a production knowledge graph: 1. **Document query patterns** — Write 5–10 questions the graph must answer. These drive schema design, not hypothetical future needs. 2. **Draft minimal ontology** — 5–15 classes, typed relationships, required attributes for [SHACL](https://www.dataaihub.co/learn/shacl). Review with domain expert. 3. **Define identity strategy** — Canonical ID format, `sameAs` linking, entity resolution thresholds. Align with MDM if present. 4. **Write SHACL shapes** — Required fields, cardinality, allowed enums. Run in CI against sample data. 5. **Build ingest pipeline with validation gate** — Map source → ontology → validate → resolve → publish. Quarantine failures. 6. **Load pilot dataset** — Real data for one use case. Run golden queries. Fix modeling gaps. 7. **Implement entity resolution** — Deterministic first, then fuzzy/ML, then steward review queue. 8. **Connect first consumer** — Dashboard, search, or [GraphRAG](https://www.dataaihub.co/learn/graphrag) pilot. Measure against KPIs. 9. **Establish stewardship cadence** — Biweekly ontology review, weekly quality metrics, PR review for schema changes. 10. **Plan schema evolution** — Additive changes freely; breaking changes via dual-write migration with impact analysis. **Diagram: Entity resolution flow** ``` flowchart LR A[Source Records] --> B[Normalize] B --> C[Blocking] C --> D[Score Matches] D --> E{Confidence} E -->|≥ 0.95| F[Auto-merge] E -->|0.70–0.95| G[Steward Review] E -->| I[Canonical Entity] G --> I H --> I I --> J[Audit Log Entry] ``` *Every merge is logged and reversible. Auto-merge only above measured precision thresholds.* **Diagram: Knowledge ingestion pipeline with quality gates** ``` flowchart LR A[Extract] --> B[Map to Ontology] B --> C[SHACL Validate] C -->|Pass| D[Entity Resolution] C -->|Fail| Q[Quarantine] Q --> S[Steward Fix] S --> D D --> E[Publish to Graph] E --> F[Update Metrics] E --> G[Sync Search / Vector Index] ``` *Validation before resolution before publication — never load first and clean later.* ## Real Production Example ### Retail: phased product knowledge graph A retail company models `Product`, `Category`, `Brand`, and `Supplier` in phase one — 10K SKUs from PIM with SHACL requiring `sku`, `name`, and `brand`. Phase two adds `Component` and `contains` for compliance (conflict minerals, restricted substances) without breaking changes — new classes and optional relationships only. Phase three runs entity resolution on duplicate suppliers ("Acme Inc" vs "ACME Corporation") with steward review below 0.9 confidence. **Quality gates:** Biweekly ontology reviews. CI-gated SHACL validation — failure rate > 0.1% blocks deploy. Weekly metrics: orphan rate, duplicate queue depth, staleness. **Outcome:** Compliance team queries restricted-substance exposure across 40K SKUs in seconds. [GraphRAG](https://www.dataaihub.co/learn/graphrag) answers "Which products contain Component X from Supplier Y?" with graph citations. [RAG](https://www.dataaihub.co/learn/rag) handles policy document retrieval; the graph handles structure. ### Financial services: fraud counterparty graph A bank builds a property graph in Neo4j for real-time fraud traversals while maintaining RDF canonical entities in GraphDB for compliance exports. Best practices enforced on both: - Canonical `Counterparty` IDs from MDM with `sameAs` links to trading system IDs - Typed relationships: `HOLDS`, `REFERENCES`, `LISTED_ON` — no generic `RELATED_TO` - Provenance on every edge: `{sourceSystem, recordId, assertedAt}` - SHACL validation on RDF layer before compliance reporting - Steward review for entity merges below 0.92 confidence **Outcome:** Fraud analysts traverse counterparty exposure in sub-second Neo4j queries. Compliance exports auditable RDF triples with full lineage. ### Life sciences: drug–target–trial linkage A pharma company models `(Drug)-[:TARGETS]->(Protein)-[:ASSOCIATED_WITH]->(Disease)` and `(Drug)-[:TESTED_IN]->(ClinicalTrial)` using RDF + OWL on GraphDB. Best practices: - Minimal ontology extended only when R&D teams need new relationship types - Ontology versioned in Git; ingest pipelines pin to `ontology-v2.4.0` - Entity resolution on drug names using InChIKey deterministic match + fuzzy fallback - LLM-extracted relationships from publications validated by SHACL before merge - Named graphs isolate internal R&D from licensed external data ### Government: citizen services graph A government agency connects benefits, tax, and permit systems. Best practices emphasize security and governance: - Named graph isolation per agency with query-time RBAC - No LLM-extracted facts without steward approval - Temporal edges (`validFrom` / `validTo`) for eligibility periods - Ontology evolution through public stewardship council with documented changelogs **Diagram: Ontology evolution workflow** ``` flowchart LR A[New Use Case Request] --> B[Gap Analysis] B --> C[Ontology Change Proposal] C --> D[Steward Review] D --> E[Git PR + SHACL CI] E --> F[Staging Validation] F --> G[Golden Query Tests] G --> H[Release Tag] H --> I[Consumer Notification] ``` *Schema evolution is a governed workflow — not ad-hoc triple injection.* ## Design Decisions | Decision | Option A | Option B | When to choose | | --- | --- | --- | --- | | Ontology depth | Minimal (RDFS) | Rich (OWL reasoning) | Minimal for most production; OWL when automated inference is worth latency | | Schema authority | Central ontology team | Federated domain stewards | Central for Best Practice ✅ **Best Practices** — Track quality metrics weekly, version ontologies in Git, enforce SHACL in CI, and maintain a golden query suite per use case. | Dimension | Requirement | | --- | --- | | **Use case scope** | Documented query patterns driving schema; no orphan classes | | **Identity** | Canonical IDs; `sameAs` links to sources; entity resolution pipeline | | **Ontology governance** | Git-versioned; PR review for new types; deprecation policy | | **Validation** | SHACL or constraints at ingest; CI gate on staging loads | | **Provenance** | `sourceSystem`, `assertedAt` on all assertions | | **Schema evolution** | Additive-first; dual-write for breaking changes; migration runbooks | | **Monitoring** | Validation failure rate, orphan edges, duplicate queue, staleness | | **Access control** | Subgraph permissions for sensitive domains | | **Documentation** | Data dictionary with class/property definitions and example queries | | **Engine ops** | Backups, cluster health — necessary but insufficient without semantic discipline | ### Data quality metrics to track weekly - **Orphan rate** — edges pointing to missing nodes - **Validation failure rate** — % of ingest batch rejected by SHACL - **Duplicate candidate queue depth** — unresolved entity resolution items - **Staleness** — % of nodes not updated within freshness SLA - **Attribute completeness** — % of required fields populated per class - **Ontology version drift** — consumers querying deprecated predicates **Diagram: Governance and security layers** ``` flowchart TB subgraph Gov["Governance"] ST[Named Domain Stewards] PR[Schema PR Review] CHG[Changelog + Impact Analysis] end subgraph Sec["Security"] ACL[Subgraph Access Control] AUD[Query Audit Log] end subgraph Qual["Quality"] SHACL[Ingest Validation] MET[Weekly Metrics Review] GOLD[Golden Query Suite] end ST --> PR PR --> CHG ACL --> AUD SHACL --> MET MET --> GOLD GOLD --> ST ``` *Governance, security, and quality form a continuous loop — not one-time setup.* > Important Assign a named steward per domain ontology. Anonymous shared ownership means nobody fixes data quality. ## Related Guides **Knowledge graph cluster:** - [What Is a Knowledge Graph?](https://www.dataaihub.co/learn/what-is-a-knowledge-graph) · [Knowledge Graphs](https://www.dataaihub.co/learn/knowledge-graphs) · [Learn Knowledge Graphs](https://www.dataaihub.co/learn/learn-knowledge-graphs) - [Enterprise Knowledge Graphs](https://www.dataaihub.co/learn/enterprise-knowledge-graphs) · [Enterprise Knowledge Graph Architecture](https://www.dataaihub.co/learn/enterprise-knowledge-graph-architecture) - [Ontologies](https://www.dataaihub.co/learn/ontologies) · [SHACL](https://www.dataaihub.co/learn/shacl) · [RDF](https://www.dataaihub.co/learn/rdf) · [SPARQL](https://www.dataaihub.co/learn/sparql) · [OWL](https://www.dataaihub.co/learn/owl) - [Graph Databases](https://www.dataaihub.co/learn/graph-databases) · [Property Graphs](https://www.dataaihub.co/learn/property-graphs) · [Cypher](https://www.dataaihub.co/learn/cypher) · [RDF vs Property Graph](https://www.dataaihub.co/learn/rdf-vs-property-graph) **AI consumption:** - [GraphRAG](https://www.dataaihub.co/learn/graphrag) · [GraphRAG Architecture](https://www.dataaihub.co/learn/graphrag-architecture) - [Knowledge Graph + LLM](https://www.dataaihub.co/learn/knowledge-graph-llm) · [RAG](https://www.dataaihub.co/learn/rag) **Tools and rankings:** - [Best Vector Databases](https://www.dataaihub.co/tools/rankings/best-vector-databases) · [Neo4j Vector](https://www.dataaihub.co/tools/neo4j-vector) · [LangChain](https://www.dataaihub.co/tools/langchain) · [LlamaIndex](https://www.dataaihub.co/tools/llamaindex) **Prerequisites:** [What Is a Knowledge Graph?](https://www.dataaihub.co/learn/what-is-a-knowledge-graph) · [Ontologies](https://www.dataaihub.co/learn/ontologies) · [Knowledge Graphs](https://www.dataaihub.co/learn/knowledge-graphs) **Next topics:** [SHACL](https://www.dataaihub.co/learn/shacl) · [Enterprise Knowledge Graphs](https://www.dataaihub.co/learn/enterprise-knowledge-graphs) · [Graph Databases](https://www.dataaihub.co/learn/graph-databases) ## Interview Questions 1. **What is the most important best practice for a new knowledge graph?** - Expected: use-case-first modeling with minimal ontology; load real data early; validate at ingest. 2. **Why is a knowledge graph not the same as a graph database?** - Expected: KG is semantic model (ontology, governance, identity, provenance); graph DB is storage engine. 3. **How do you handle schema changes without breaking consumers?** - Expected: additive-first; dual-write migration; version ontology in Git; impact analysis; deprecation window. 4. **Why auto-merge entity resolution cautiously?** - Expected: false merges are hard to reverse and corrupt all downstream queries; start conservative, measure precision. 5. **When would you use SHACL vs database constraints?** - Expected: SHACL for RDF graphs (Stardog, GraphDB, Jena); Neo4j constraints for property graphs; both at ingest. 6. **How do best practices enable GraphRAG and RAG?** - Expected: governed entities/relationships + provenance give AI systems trustworthy structure; [RAG](https://www.dataaihub.co/learn/rag) handles documents. 7. **What metrics indicate a graph is failing?** - Expected: rising duplicate queue, validation failure rate, orphan edges, declining query adoption, staleness. 8. **RDF or Neo4j for a new project — how do you decide?** - Expected: RDF for SHACL/OWL/federation/compliance; Neo4j for Cypher velocity and operational traversals. ## Key Takeaways - Model for concrete use cases, not the entire enterprise upfront. - **A knowledge graph is not a graph database** — Stardog, GraphDB, Neptune, Neo4j, and Jena store graphs; best practices govern the semantic layer above them. - Canonical identity and entity resolution are prerequisites for trust. - Validate at ingest with [SHACL](https://www.dataaihub.co/learn/shacl); measure quality continuously. - Schema evolution is normal — plan additive changes and migration paths. - Governance (stewards, versioning, PR review) matters as much as technology. - Provenance on every fact enables debugging, auditing, and confident [GraphRAG](https://www.dataaihub.co/learn/graphrag) / [RAG](https://www.dataaihub.co/learn/rag) grounding. - Compare vector tools for hybrid AI pipelines in [Best Vector Databases](https://www.dataaihub.co/tools/rankings/best-vector-databases). ## FAQs ### How do I start building a knowledge graph? Pick one use case, model 5–15 core classes, ingest a small real dataset, validate with [SHACL](https://www.dataaihub.co/learn/shacl), and iterate based on query failures — not hypothetical future needs. ### How detailed should my ontology be? Detailed enough to answer your use-case queries and enforce data quality. Avoid OWL complexity you will not use. Expand when new use cases require new types. ### RDF or property graph for a new project? RDF if you need standards compliance, linked data, and SHACL validation (Stardog, GraphDB, Neptune, Jena). Property graphs if your team prioritizes Cypher ergonomics and fast traversals (Neo4j). See [What Is a Knowledge Graph?](https://www.dataaihub.co/learn/what-is-a-knowledge-graph) and [RDF vs Property Graph](https://www.dataaihub.co/learn/rdf-vs-property-graph). ### How do I handle schema changes in production? Additive changes freely. Breaking changes go through dual-write migration with consumer notification. Version ontologies in Git with changelogs. ### What is the biggest mistake teams make? Over-engineering the ontology before loading data, combined with skipping entity resolution. Both erode trust before the graph delivers value. ### How do I measure data quality? Track validation failure rate, orphan edges, duplicate entity rate, attribute completeness per class, and data freshness against SLA. ### When is a knowledge graph the wrong choice? When your data is purely tabular with no relationship traversal needs, or when source data quality is too poor to invest in cleansing. Fix data foundations first. ### Can LLMs replace ontology design? No. LLMs can extract entities from documents, but ontology structure requires domain expertise and governance. Validate all LLM extractions before production merge. ### How do best practices differ for enterprise vs departmental graphs? Departmental graphs need Levels 1–2 practices (use-case ontology, ingest validation, basic stewardship). Enterprise graphs add federated governance, MDM integration, named graph isolation, and platform SLAs — see [Enterprise Knowledge Graphs](https://www.dataaihub.co/learn/enterprise-knowledge-graphs). ### Which graph database should I choose? The engine matters less than modeling discipline. Stardog and GraphDB excel at RDF/SHACL/federation. Neo4j excels at Cypher operational graphs. Neptune offers managed AWS. Jena offers open-source standards compliance. Choose based on team skills and compliance requirements — then apply the same best practices regardless. ## References - [W3C — SHACL Specification](https://www.w3.org/TR/shacl/) - [W3C — OWL 2 Web Ontology Language](https://www.w3.org/TR/owl2-overview/) - [W3C — RDF 1.1 Concepts](https://www.w3.org/TR/rdf11-concepts/) - [Protégé Ontology Editor](https://protege.stanford.edu/) - [Apache Jena Documentation](https://jena.apache.org/documentation/) - [Neo4j — Graph Data Modeling Guidelines](https://neo4j.com/docs/getting-started/data-modeling/) - [Stardog Documentation — Data Modeling](https://docs.stardog.com/)
## Media
1. image: https://social-archiver-api.social-archive.org/media/archives/arc/4iM5q4ALRx/media/0.png