Context
'Knowledge graph' sounds technical but the underlying idea is simple. Once you understand it, the choice between a knowledge graph and a relational database for asset information becomes obvious. A knowledge graph is to a relational database what the web is to a CD-ROM.
Relationships ARE the information, in our domain.
Explanation
Three things to understand:
The structure
Instead of storing data in tables of rows and columns, a knowledge graph stores it as a network of nodes (things) and edges (relationships). 'Pump-403 is part of System-A. System-A is located in Building-7. Building-7 is subject to Requirement-R-291. Requirement-R-291 is verified by Test-T-118.' That sequence is one path through a graph.
Why this matters for asset information
Asset information is intrinsically relational. A requirement is satisfied by a system; a system contains components; components are described by drawings; drawings are derived from specifications. The relationships ARE the information. A graph stores them natively; a relational database stores them as awkward foreign keys.
What it enables
Cross-silo queries become a single operation. 'Show me every requirement that affects equipment in Building-7' is one query on the graph. The same question against three separate databases is a week of integration work.
Once your data is a graph, the question changes from 'where do I look this up?' to 'what do I want to know?' That is the difference Weaver is built around, and the practical reason we made the architectural bet on RDF.