I understand the idea, I think, but I don't know what problems they actually solve. When would I want to consider building a knowledge graph, or using an existing one in a project?
It's more than just a graph database, which is typically misunderstood by most devs (including me), when they start looking at this.
However designing an Ontology is hard, just as getting a good database schema is hard, failure of most systems is the data model builds up tension over time, which leads to code complexity/hairballs, effort in adding new concepts to the model, operational work arounds, which then start to poison the data quality (start adding freeform text to store 'data').
There is no god given ontology or one way of modelling the world, crowdsourcing is a good approach, but looking at this one you can see some questionable practices (tradeoffs to be fair), and there is a big gap in people who have skills and experience.
You'd think that systems teams could be able to predict whether something works with something else, but you'd be wrong. Systems architecture is still mostly a matter of faith, right up until it crashes against the reality of operations and maintenance.
The traditional way of making a family of systems goes like this. A containerized group of systems guys make a big graph, and show how product variants X Y and Z are 98% equivalent, so they can use the same tooling, the same procedures, etc. Downstream, the org is mandated to take this on faith, even when (and after) the FoS has been falsified by experience in the field, on the production floor, and in the repair station. This isn't just expensive; it's dangerous as hell.
Knowledge graphs are one path towards falsifiable product architectures. You have a pile of procedures, each set is specialized, and the graph, properly configured, is a snapshot of just how related those products are.
Another angle is data warehousing the product data with the aim of creating an "Equivalence Factor" for an arbitrary subset of assemblies. When it goes below a certain factor, the assemblies are NOT the same product, and they should be handled accordingly. That "Equivalence Factor" is something I'm still working, but it includes: O&D, materials, density, mass, interfaces, topology, dissassembly, tooling, fasteners. One of the hard sells is that the number is not a solid number - it's a baseline, part of a check, and it's got a range. People like hard yes or no answers, but with Equivalence Factor I can at least give you some probabilities of maintaining a system as it's configured.