Metadata
What information exists, where it comes from, who owns it, and how it changes.
Inventory · Ownership · LineageWhen this helps
Does this sound
familiar?
- Teams report different values for the same metric because calculation boundaries, exclusions, or definitions differ.
- You know where data is stored but struggle to explain its meaning, ownership, history, or appropriate use.
- An assistant lacks important context about business entities, operational dependencies, exceptions, or the source records behind an answer.
The work & its outputs
Make the meaning explicit.
Semantics
Agreed definitions for terms and metrics, including calculation boundaries and exceptions.
Glossary · Definitions · MappingsOntology
Domain concepts, their relationships, and the rules that give those connections meaning.
Concepts · Dependencies · RulesAn ontology is not automatically a graph database. Knowledge graphs and their storage are implementation choices; OWL is one formal language, not a mandatory dependency.
Metadata: know the assets and their origins
Identify the relevant tables, fields, documents, APIs, and other information assets. Record where they originate, who owns them, and how they move or change. A scoped asset inventory and lineage map give the work a practical starting point without requiring an organisation-wide catalogue project.
Semantics: agree what the information means
Define the terms and measures that matter to the chosen question. Record calculation boundaries, exceptions, units, and intended use. A business glossary or metric definition connects a shared name to an explicit meaning; source mappings connect that meaning to the information used to calculate or retrieve it.
Ontology: describe concepts and relationships
Model relevant domain concepts, identifiers, relationships, and rules at a useful level of detail. Distinguish equipment membership from operational dependency: being part of a line does not establish exactly how a failure affects it. The model stays anchored to business questions and supporting evidence.
Expert knowledge with context and ownership
Use focused SME workshops or structured interviews to examine real questions, unusual cases, and conflicting interpretations. Capture definitions with owners, evidence, applicable scope, and version or effective-date information where needed. Make unresolved differences visible so they can be decided by the appropriate people.
Mappings that a solution can use
Connect concepts to the relevant source fields, documents, or APIs. Choose how to represent that knowledge for the consuming solution, from governed mappings and retrievable documents to a graph where justified. An ontology is not automatically a graph database; OWL is one formal language, not a mandatory dependency.
A way to maintain the understanding
Define how changes to source processes, assets, and business definitions are reviewed and reflected in the model. Identify the owner, review triggers, and affected consumers. Shared meaning needs maintenance; a diagram alone cannot resolve every data-quality issue or guarantee an AI answer is correct.
The people who know the work belong in the plan.
Your business experts explain how terms, measures, and exceptions are used in practice. Data owners and technical counterparts help trace the relevant sources and access constraints. A decision owner resolves competing definitions where necessary. Allocate time for this participation and agree who will maintain the resulting knowledge after the review.
A sensible first engagement
Data & Business Knowledge Review
Begin with one domain or decision: a disputed performance metric, a recurring unanswered question, or information needed by an assistant. Assess the available metadata, definitions, relationships, and knowledge gaps before choosing the smallest useful next step.
- A scoped inventory of relevant information and important knowledge gaps.
- Priority definitions, entities, relationships, and source mappings.
- Ownership decisions and recommendations for maintaining or extending the foundation.
Illustrative exampleThe records are the same.
The records are the same.
The business measure changes.
The assumptions: Two machine outages affect the same production line. Either outage stops the whole line. Both records use the same date and time zone.
10:0011:0012:0013:00
Machine A
Machine B
Whole line
4 hours
Machine-event duration
Sum both machine outages.
3 hours
Elapsed line downtime
Merge the overlapping intervals.
Both values are useful. The business definition determines which question each value answers.
Connections need context.
THE KNOWLEDGE LAYERAC / 001
Business context,
made explicit.
Illustrative exampleData + meaning + relationshipsUseful context
Equipment membership and operational dependency are different facts. A component being part of a line does not establish the precise impact of its failure. These synthetic identifiers make the dependency explicit; a real engagement checks the relationship against source information and expert knowledge.
A few useful answers
Common questions.
Do we need a knowledge graph?
That depends on the questions and relationships the solution needs to handle. Some work is served by a glossary, explicit metric definitions, and source mappings. Choose graph storage when it addresses a defined need.
Will an ontology make our AI answers accurate?
It can supply important context, but accuracy also depends on source quality, retrieval, instructions, evaluation, and the task. Test the whole solution against representative questions and exceptions.
Can we start without documenting everything?
Yes. Choose one business question or domain and establish the definitions and relationships needed for that scope. Expand when additional knowledge has a clear use and an owner.