Knowledge Graph vs. Ontology: What Enterprise Data Products Need

Does an enterprise need a knowledge graph or an ontology?

A knowledge graph and an ontology are not competing technologies. They address different parts of the same problem.

A knowledge graph connects things and describes their relationships. An ontology defines the concepts, vocabulary, and rules that help people and systems interpret those relationships consistently.

A graph might connect a business objective to use cases, data products, owners, policies, and operational dependencies. An ontology helps establish what those connections mean: the difference between an objective and a use case, what qualifies as a data product, and how business ownership differs from technical responsibility.

The knowledge graph tells us what is connected. The ontology helps explain what those connections mean.

Enterprise data product operating models benefit from both. That does not mean an organization must spend years designing a comprehensive enterprise ontology before connecting its first business objective to a data product. A practical approach begins with the concepts and relationships needed for real decisions, then adds formality as the operating model grows.

What a knowledge graph does

Most organizations already hold substantial information about their operations. Strategic objectives live in planning documents; use cases are recorded in spreadsheets, presentations, and delivery tools; data products appear in catalogs or technical specifications; ownership sits in organizational systems; governance policies live in separate repositories.

The problem is usually not that information is missing. It is that the relationships between these pieces are difficult to establish and maintain. A knowledge graph represents relevant objects and their relationships in a connected structure.

Consider a bank with an objective to improve customer retention. The objective connects to a customer-churn use case, which depends on Customer 360 Profile and Customer Engagement Signals products. Both products have owners, interfaces, governance requirements, and lifecycle states. Customer Engagement Signals may itself depend on a product supplying digital interaction data.

Now consider retiring the digital-interaction product. An asset inventory may show technical dependencies. A connected business and product graph can also show the affected products, the use cases they support, and the business objective at risk. It makes the impact of a proposed decision easier to examine.

What an ontology adds

A knowledge graph contains relationships, but those relationships need meaning. One department might say a data product is “owned by” a business unit while another uses the same term for the engineering team operating its infrastructure. The wording is identical; the responsibilities are not.

An ontology defines concepts and the relationships between them. It can distinguish a business owner from a technical owner, a business objective from a use case, a data product from its individual assets, and a governance policy from a technical enforcement control. It can also define constraints and classifications that guide interpretation.

Formal ontology languages such as OWL support extensive semantic modelling and reasoning. RDF provides a graph-based data model, while SHACL supports validation of RDF graphs against defined constraints. These technologies matter when information must be exchanged and interpreted consistently across organizational and system boundaries.

Not every operational graph needs an elaborate ontology or a complete semantic-web implementation. A controlled vocabulary, clear object types, documented relationship meanings, and practical validation rules often provide enough structure for initial use cases. The important question is whether the organization has enough shared meaning to make relationships trustworthy and useful.

A banking example: connecting strategy to operational data products

Consider a bank reducing customer churn through three products: Customer 360 Profile, Customer Engagement Signals, and Customer Retention Indicators. Each has a definition, owner, lifecycle state, and contractual and governance commitments. The bank also has a retention objective and use cases for identifying at-risk customers, prioritising engagement, and evaluating outcomes.

A graph connects these objects. Customer Retention Indicators supports the churn-analysis use case; that use case contributes to the retention objective; the indicators product depends on the profile and engagement products. This lets teams ask which products contribute to an objective, which use cases depend on an at-risk product, whether work overlaps, and whose participation a lifecycle change requires.

An ontology, or a sufficiently structured semantic model, keeps the relationships consistent. A product dependency is not the same as a business contribution. A product owner is not the same as a governance approver. Without those distinctions, even an impressive graph visualization can produce misleading conclusions.

The business value comes from combining connected information with clear meaning.

Why a large enterprise ontology is not always the best starting point

Some semantic initiatives attempt to define every business concept, relationship, attribute, hierarchy, and rule before the model is used in an operational workflow. This has valid uses, particularly in domains with strong interoperability requirements, complex regulation, or established domain ontologies.

For an organization improving data product portfolio management, however, a complete enterprise ontology can create substantial work before visible operational value. Definitions become subjects of prolonged negotiation while immediate business problems remain unresolved.

A more practical foundation is a limited set of purposeful objects: business objectives, use cases, data products, owners, policies, dependencies, lifecycle states, and decisions. Their relationships answer questions that enterprise leaders, product managers, governance teams, and delivery teams already ask.

The semantic model should grow in response to real requirements. If ownership is interpreted differently across teams, introduce explicit ownership roles. If lifecycle transitions require evidence, define states and requirements. This does not reject ontology engineering; it applies it where it creates immediate value and adds formality when justified.

Minimum Lovable Semantics: enough meaning to operate responsibly

Minimum Lovable Semantics follows the same reasoning as Minimum Lovable Governance: establish enough shared meaning for reliable operations without requiring a perfect representation of the entire enterprise before work can begin.

Define the concepts people and AI agents need, establish the relationships that matter for decisions, and make those definitions explicit and machine-readable where appropriate. For a data product portfolio, clarify the meaning of an objective, use case, product, owner, dependency, governance requirement, and lifecycle state.

Ambiguous relationships should be avoided. Saying that a product is “related to” an objective is less useful than saying it supports a named use case that contributes to that objective. The more precise relationship gives people and systems a stronger basis for assessing dependencies and understanding why a product matters.

Minimum Lovable Semantics does not ignore semantic quality. It focuses semantic discipline on what matters now, keeps the model understandable, and extends it as operational requirements grow. Formal ontologies remain valuable when stronger consistency, reasoning, interoperability, or validation is needed.

Why AI agents make semantic context more important

A human product manager may know a product supports customer retention because the relationship came up in meetings. An AI agent does not automatically possess that context. A catalog, documents, and search tools may not explain how objectives, use cases, products, responsibilities, policies, and lifecycle decisions relate.

Without explicit context, an agent can identify a technically relevant dataset while overlooking a product's intended purpose, operational limitations, or governance restrictions. A graph provides connected business and product information; a semantic model helps the agent interpret its meaning.

For a proposed change to Customer Engagement Signals, an agent can prepare an impact assessment, identify affected stakeholders, and recommend appropriate reviews. It needs the graph to find dependencies and use cases, and the semantic model to distinguish technical dependencies from business contributions and governance responsibilities.

Connected context does not guarantee correct reasoning. Information may be stale or incomplete, and an agent can interpret evidence incorrectly. Enterprise agents need current operational state, source provenance, defined permissions, auditable activity, and human review for consequential decisions. A graph improves available context; it does not replace governance or independent validation.

A graph must represent living operational context

A static relationship diagram can explain an architecture. An operational knowledge graph must reflect change: objectives change, use cases are approved or discontinued, products move through lifecycle stages, owners change, dependencies evolve, and governance decisions introduce requirements.

Without current state and recorded decisions, the graph becomes another outdated documentation repository. This matters even more when agents rely on it. An agent assessing a candidate needs to know whether a similar product is operational or retired, who owns it, and whether the portfolio has unresolved governance issues.

A useful model combines stable definitions with changing operational information. Semantics explain what objects and relationships mean; lifecycle and governance information explains current condition; provenance and decision evidence explain where information came from and why a conclusion was reached.

Where Maysano fits

Maysano uses a knowledge graph to connect business objectives, use cases, data products, ownership, governance, dependencies, lifecycle, versions, and delivery context. It is the connected business and product operating layer between enterprise strategy and existing data-management environments.

Maysano does not replace a data catalog, warehouse, lakehouse, or enterprise metadata platform. Those systems continue managing the assets, technical metadata, and data services for which they are responsible. Maysano focuses on the relationships that explain why products exist, which business needs they support, who is accountable, how they are governed, and what is happening throughout their lifecycle.

Agents work with structured portfolio information to identify candidates, examine dependencies, prepare specifications, identify missing relationships, and support governed delivery. Explicit object definitions and relationship semantics make that context interpretable; governance controls, activity records, and review processes make agent-supported work accountable.

Maysano also builds on open standards managed under the Linux Foundation's LF AI & Data umbrella, including the Open Data Product Specification and related standards. These machine-readable definitions structure individual data products and their commitments; Maysano connects them to portfolio context, business objectives, use cases, governance, and lifecycle.

What Maysano does not replace

Maysano does not replace an enterprise ontology program where broader semantic integration or reasoning is needed. It does not replace specialised semantic-modelling tools, knowledge-engineering platforms, or authoritative vocabularies maintained elsewhere. Existing systems should remain authoritative for their information: catalogs for metadata, data platforms for storage and processing, security systems for access enforcement, and business applications for transactional information.

When an enterprise already maintains ontologies or semantic definitions, they should inform how relevant concepts and relationships are interpreted in Maysano. The purpose is to connect information required for product and portfolio decisions, not reproduce the full enterprise knowledge environment.

How should your organization get started?

Start with decisions you want to improve. For data product portfolio management, identify a small number of objectives and the use cases that support them. Connect those use cases to the data products they need, then add ownership, dependencies, lifecycle states, and relevant governance requirements.

Define each object type and relationship clearly enough that different teams interpret it consistently. Test the model against practical questions: which products support an objective, which use cases depend on a product approaching retirement, where ownership is missing, where products overlap, and which reviews a change needs.

If the model helps people answer those questions and take appropriate action, it is already creating operational value. Add formal semantics, validation rules, and ontological structure as more systems and use cases make them useful.

From connected information to connected decisions

The distinction matters, but enterprises should not treat a knowledge graph and ontology as a technology competition. A graph connects information. An ontology establishes shared meaning. Governance and lifecycle management keep that information useful in operational decisions.

For data product management, the goal is to connect business demand with the products, ownership, controls, and delivery activities needed to respond. AI agents make these connections more important: they need machine-readable business context, interpretable relationships, current state, and traceable evidence.

Start with the relationships that matter, define what they mean, and keep them connected to the decisions being made. More formal ontologies can strengthen that foundation when requirements demand precision and interoperability.