Glossary term
Knowledge graph
A knowledge graph represents an organization's information as nodes and typed edges — the entities it cares about and the labelled relationships between them — so that questions about how things connect can be answered by traversing those relationships rather than by joining tables.
Also known as enterprise knowledge graphsemantic graphentity graph
In practice
The cleanest way to hold the distinction the category keeps blurring: the ontology is the schema, the knowledge graph is the populated instance data conforming to it. An ontology says a work order attaches to a device and a device belongs to a customer; the knowledge graph holds the several million actual work orders, devices, and customers, and the edges between them. In practice a graph is stored either as RDF triples with an OWL ontology over them, or as a property graph in an engine like Neo4j, and plenty of production graphs run with an ontology that was never written down — which is exactly how two teams end up with incompatible definitions of "customer" in the same graph.
On connection-shaped questions a knowledge graph is the right tool and nothing else comes close. Fraud rings, beneficial-ownership chains, supply-chain dependency, impact analysis across a network, entity resolution across a dozen source systems, and any question of the form "what is four hops from here" are native to a graph and awkward-to-impossible in a relational join. If that is the problem, the answer is a graph database, and no application platform substitutes for one.
The limit it shares with the semantic layer is the same one: a knowledge graph is overwhelmingly a read structure. It records that these things are connected; it does not declare who may change them, which operations are permitted, or what audit record a change leaves. ObjectStack approaches the connections from the other end — relationships are declared as typed fields on objects inside the application's own metadata, so the graph of the business falls out of the definition the application already runs on, rather than being a second store to keep in sync, and because that definition is a file in your repository it is an open business ontology rather than a graph inside someone else's platform. That is a claim about ownership and governance, not about graph analytics: ObjectStack is not a graph database and does not try to win deep multi-hop traversal.
Where this term is used
Pages and articles that put this term to work.
Product pages
- Data modeling Objects, relationships, validations, and formulas become tables, migrations, a query language, and REST APIs — with an object designer, an ER diagram, and datasource sync that federates existing databases in place.
- Analytics & reporting Aggregations, time series, funnels, and dashboards over the same governed objects the app runs on — with a widget-based dashboard designer and a band-based report designer, permission-aware by construction.
Articles
- 열린 기업 온톨로지: 비즈니스 의미 계층은 누가 소유해야 하는가 2025년 11월부터 2026년 8월까지 다섯 플랫폼이 비즈니스 의미 계층을 출시했고, 대부분 MCP 읽기 경로를 열었다. 그러나 정의 자체는 안에 남는다. 프로토콜은 열리고 정의는 닫혔다 — 소유권 질문은 더 날카로워졌다.
- 기업 AI Ontology: 비즈니스 정의와 런타임을 모두 열어야 하는 이유 2026년 6월 Ontology MCP가 GA로 전환됐다. 벤더들이 스스로 agent 인터페이스를 개방 프로토콜에 넘긴 것이다. 정의 계층도 뒤따르고 있다. 열리지 않은 것은 런타임뿐이다.
- CRM에서 시작하기: AI가 고객, 영업기회, follow-up 이력을 이해하는 방법 대부분의 CRM에는 고객, 영업기회, 연락처, 활동 이력이 이미 있습니다. 유용한 길은 데이터를 내보내 일회성 분석을 하는 것이 아니라, 권한 아래에서 AI가 그 비즈니스 객체를 이해하게 하는 것입니다.