Halconia.
Let’s talk
Back to blog

What are knowledge graphs in manufacturing?

In this article, we use knowledge graph applied to manufacturing as a working definition for a representation of entities and relationships with a meaning…

Andrés Naves ·

In this article, we use knowledge graph applied to manufacturing as a working definition for a representation of entities and relationships with a meaning documented through vocabularies; we will explain it with RDF, a data model that allows formulating statements about resources and combining them with vocabularies or conventions that provide semantic information (RDF Primer).

In our hypothetical example, machine M and component C will be physical resources, and a document with two revisions, D1 and D2, will provide the documentary resources that we will relate through RDF triples.

Start from the foundation in our previous article: Why integrate operational knowledge into industrial automation systems

What is a knowledge graph applied to manufacturing and how does it represent machines, components and documents?

RDF triples have three elements: subject, predicate and object. The subject and object represent the two related resources, while the predicate expresses the nature of their relationship (RDF Primer).

Our first hypothetical triple is Machine M — incorporates — Component C: the machine is the subject, incorporates is the predicate and the component is the object.

The second hypothetical triple is Component C — has documentation — Revision D2: the component is the subject, has documentation is the predicate and the current revision in the example, D2, is the object. In this RDF model, we have chosen incorporates and has documentation as local conventions of the example, not as normalized industrial terms.

When these triples are visualized as a graph, their subjects and objects form the nodes and their predicates form the links: the shared component connects the machine with the documentary revision.

How do we agree on identifiers and vocabulary without confusing an entity with its different revisions?

IRIs are global identifiers of resources (RDF Primer). The owner of an IRI can document what it intends to designate with it; in our hypothetical example, that specification would distinguish the machine, the component, the persistent document and each documentary revision through their respective identifiers (RDF Concepts).

Following the distinction illustrated by PROV-O, in our model each revision has its own identifier and both are concrete forms of a persistent document with a common reference (PROV-O).

PROV-O defines a revision as a derivation whose result is a revised version of an original entity. We apply that definition through prov:wasRevisionOf: the current revision is the subject of this relationship and the previous revision is its object (PROV-O).

The property prov:specializationOf relates a more specific entity to another whose aspects it fully shares. We apply it to each revision with respect to the persistent document when both versions are modeled as more specific forms of that same document, following the distinction illustrated by PROV-O.

W3C recommends assigning identifiers to the versions and to the complete series of a dataset; in our example we apply that separation to the document as a modeling decision (Data on the Web Best Practices).

Before creating identifiers, we propose searching for other suitable ones that already exist; if we need to create new ones, we will follow the URI persistence patterns recommended by W3C (Data on the Web Best Practices).

According to W3C, it is advisable to reuse terms from shared vocabularies, preferably standardized, to encode the data and the metadata.

How do we record where a claim comes from without turning its provenance into a guarantee of truth or permission to use it?

PROV-O allows building provenance chains with entities and activities: an activity may use some entities and generate others. In our example, a query activity uses the current revision and generates a record containing the documentary claim about the component (PROV-O).

The activity is related to the revision through prov:used, while the record is related to the activity that generated it through prov:wasGeneratedBy. In our example, prov:wasDerivedFrom would relate the record to the documentary revision from which it derives; PROV-O defines derivation as the transformation of one entity into another (PROV-O). To indicate responsibility, prov:wasAssociatedWith associates the activity with an agent and prov:wasAttributedTo attributes the generated entity to an agent.

In our model, these properties describe the generation and attribution of the record as an entity; we have not modeled the provenance of each triple separately. Naming a graph is not sufficient either: RDF does not establish formal constraints on the resource that this name designates nor on its relationship with the graph (RDF Concepts).

To interpret the name of a graph as the source of its data, readers need an additional convention, because RDF does not offer a standard way to convey that semantic assumption (RDF Primer).

Reference to primary sources allows investigating the reliability of a derived source, according to PROV-O. Furthermore, the logical inferences of RDF start from triples that the system accepts as true: a derived conclusion retains that dependence on the input information.

To review the usage permission in our pilot, we will consult the applicable license in addition to recording the attribution. W3C recommends providing a link or a copy of the license agreement that governs the use of the data. In this example we will review separately the license, the access rules and the technical approval of an intervention. In our model, we define the documentary predicate only to link the component with a revision; the validity, applicability and approval of that revision fall outside the meaning we have assigned to it.

How do we scope a pilot and what do we check before expanding it?

In this hypothetical pilot we review the representation of the relationships and the semantic coherence of the triples.

A first query would traverse the triples that relate the machine to the component and the component to the documentary revision, following their subjects, predicates and objects. Another would follow the provenance relationships from the record to the activity that generated it and the entity that activity used.

To review the versions, we would read the relation prov:wasRevisionOf between the current revision and the previous one, keeping their identifiers separate from the one corresponding to the persistent document. The joint reading of these relationships must preserve an agreed meaning: the RDF Primer explains that bringing together information with a common syntax is not enough to maintain its semantic coherence.

We leave outside the scope of this hypothetical pilot the physical verification of the installed component, the applicability of a revision to an intervention and the conditions of use; we propose to address them separately through an engineering review and a review of the applicable license.

Checks for the hypothetical pilot

  • Check that references to the same entity use the same identifier across the connected datasets.
  • Review the agreed meaning of the triples, in addition to their syntax.
  • Check that the history explains the changes between versions.
  • Verify that an application can process the provenance information.
  • Check that the license regulating the use of the data is provided.
  • Document the known quality and the problems detected in the metadata.

Sources