Knowledge graphs in industrial machine vision: connecting technical knowledge in a traceable way
In industrial machine vision, running an algorithm and displaying a result is not enough. A reliable technical decision must also make clear which inspection task is being addressed, under which constraints a method was selected, which source supports that choice and how the result was validated. Knowledge graphs can provide a practical connection layer for this information.
Based on my experience with industrial machine vision, Python and knowledge graphs, I see their main value in making relationships between technical knowledge, system components and available evidence explicit. This can support both engineers and AI systems. It does not replace engineering judgement or testing on the real system.
What is a knowledge graph?
A knowledge graph represents entities and their relationships in a machine-readable structure. The W3C Resource Description Framework (RDF) models statements as triples consisting of subject, predicate and object. In simplified terms: a camera captures an inspection feature, an algorithm processes an image and a result is confirmed by a validation test.
The graph visualisation is not the important part. What matters is that concepts have explicit meanings and relationships can be queried. The system can then store not only which algorithm is used, but also why, under which conditions and within which verified range.
Why does this matter for industrial machine vision?
A machine-vision solution emerges from the interaction of optics, sensors, lighting, mechanics, calibration, image acquisition, algorithms, thresholds and quality assurance. In conventional documents and spreadsheets, this information often lives in separate places. The dependencies remain in the heads of individual experts.
A knowledge graph can make the decision chain explicit:
- The inspection task defines the relevant feature or defect.
- The feature creates requirements for resolution, contrast, field of view and lighting.
- Those requirements justify the camera, lens and illumination selection.
- Acquisition conditions and image characteristics constrain suitable algorithms.
- Parameters and decision rules link to sources, assumptions and measurements.
- Validation results show what is supported and which gaps remain open.
This turns isolated facts into a technical relationship. If a surface or field-of-view requirement changes, affected decisions can be identified systematically.
A practical example: segmentation and calibration
A fixed threshold can be sufficient for simple segmentation. The official OpenCV thresholding documentation distinguishes global, adaptive and Otsu-based methods. Selecting a method alone does not demonstrate that it is suitable for the actual image material.
A knowledge graph can link the choice to lighting conditions, expected contrast distribution, the example dataset, the OpenCV version and defined test results. If illumination is non-uniform, the graph can expose that a global threshold is only conditionally suitable and requires further validation.
The same principle applies to geometric measurement. The OpenCV camera-calibration documentation describes estimating a camera matrix and distortion parameters from corresponding object and image points. A knowledge graph can record which calibration belongs to which camera-lens configuration, when it was created and for which measurement it is valid. This does not automatically prevent a wrong assignment, but it makes the assignment visible and testable.
Standards for a reliable technical knowledge base
- RDF: represents knowledge as a directed graph of resources and relationships.
- JSON-LD: serialises linked data in a JSON-based format that integrates well with web and software projects.
- PROV-O: represents provenance, for example the test or document from which a statement originated.
- SHACL: defines machine-checkable constraints for RDF graphs, such as requiring every approved decision to have a source and validation status.
- SOSA/SSN: provides concepts for sensors, observations, procedures, observed properties and features of interest.
These standards are not ends in themselves. A small project can begin with a narrow vocabulary and a few carefully defined relationships. The structure must answer concrete questions rather than merely move existing documents into a new format.
What AI can do better – and what it cannot
An AI system can use a well-designed knowledge graph to find relationships and connect answers with available sources, conditions and open gaps. A meaningful question could be: “Why was this camera selected for the inspection task, and which assumption has not yet been confirmed on the target system?”
A reliable answer must expose the chain from requirement to rule, source and validation. If evidence is missing, the answer should state not directly supported or still to be verified. An unknown relationship must not be replaced by a plausible-sounding assertion.
The boundary is clear: a knowledge graph is neither a trained vision model nor a production approval. It improves traceability and consistency, but it cannot create missing evidence. Industrial validation still requires real images, target hardware, calibrated settings, defined criteria and measured results.
A pragmatic six-step starting point
- Define the questions: decide which technical decisions the graph must explain.
- Limit the vocabulary: begin with inspection task, component, parameter, rule, source, result, gap and validation.
- Assign stable identities: camera configurations, datasets and tests need persistent identifiers.
- Record provenance: connect every relevant statement with its source and creation context.
- Validate quality rules: check mandatory relationships and permitted values automatically.
- Test real questions: the graph is useful only when domain experts can verify its answers and reasoning chains.
Conclusion
Knowledge graphs do not make industrial machine vision automatically intelligent. Used correctly, however, they connect technical decisions with their preconditions, sources, limits and evidence. This makes knowledge reusable, changes easier to manage and AI-supported analysis more controllable.
The greatest value does not come from the largest number of nodes. A small, verified knowledge base is more useful for engineering decisions than a large graph full of unsupported statements.