A decision needs more than a matching paragraph.
Consider a supplier disruption. A useful answer may need to connect a supplier’s legal identity, the components it provides, the products that use those components and the teams responsible for alternatives. Finding documents that mention the supplier is one step. Establishing the relationships needed for a decision is another.
This is where an enterprise ontology can help: it makes selected business concepts and relationships explicit. The objective is a shared model that supports a real workflow, rather than a model of everything the organisation knows.
What ontology contributes.
Ontology provides definitions and relationships that can be reused across sources. A knowledge graph represents connected facts using those concepts. In a suitable implementation, this can make identifiers easier to reconcile and decision paths easier to inspect.
OWL is a formal ontology language; SHACL describes conditions for validating RDF data. They serve different roles. Neither establishes that a business claim is true merely because the data is structurally valid. Source quality, interpretation and expert review remain essential.
Three decisions to explore.
- Financial exposure: connect an issuer event to instruments and portfolio holdings, preserving the relevant point in time.
- Supply-chain impact: connect suppliers, components and products, while recording gaps in dependency coverage.
- Operational ownership: connect a business service to its systems, owners and applicable policy documents.
These are illustrative candidate workflows. Feasibility depends on source coverage, identity quality, permissions and the availability of domain reviewers.
Ontology does not make an AI answer automatically correct.
A graph can contain outdated facts or incorrect links. A retrieval process can omit relevant evidence. A language model can still produce an unsupported statement. Provenance helps a reviewer investigate where information came from; it does not certify the information’s truth.
Microsoft’s GraphRAG work illustrates one family of graph-based retrieval approaches. It should not be treated as proof that any ontology-based system will outperform simpler retrieval on your workload.
Make the business case measurable.
Identify a recurring decision, its owner and the current process. Estimate the time spent reconciling definitions or searching for evidence using observations from your team. Avoid assuming savings before measuring the baseline.
Then agree what a useful improvement would mean: fewer unresolved entity matches, better-supported answers, faster investigation or clearer ownership. Review operating cost, latency and maintenance alongside quality. The result may justify expansion, a revised approach or stopping.
What an expert engagement should produce.
Ask for competency questions, a source inventory, model assumptions, mapping rules, validation findings and representative query or retrieval paths. Agree an evaluation set and review failure cases with domain experts.
Before production, establish who owns changes, how access restrictions are enforced, how sources are refreshed and how the system is monitored. A well-scoped pilot should help you make that next investment decision.
Primary references
- W3C OWL 2 overview — formal ontology language.
- W3C SHACL Recommendation — RDF graph validation.
- W3C PROV-O — provenance representation.
- Microsoft GraphRAG documentation — graph-based retrieval approach.
These sources support the technical foundations. They do not endorse SDS or establish SDS customer outcomes.