Knowledge graphs are pretty abstract mathematical objects, and training someone how to build a really good knowledge graph could potentially take months or years of training.
It turns out though, that when it comes to building a knowledge graph specifically to describe how a particular piece of software should work, if we simply build a prototype of the software we want, in any no code tool on the planet, that can be exported to Json, then we will have designed a knowledge graph by definition.
In other words, If we were to use NoCodeXYZ.com to design a little prototype app that does exactly what we want, and then export it to a Json file - my-project.json, and then delete the original app on NoCodeXYZ.com, then the only place that the decisions about how that app worked still exist would be, by definition at this point, in that Json file.
This could be shown to be true (by definition) by Re-Importing the my-project.json file back into NoCodeXYZ.com. If the resulting app does everything that we want, then we can infirm that 100% of the knowledge, about how the app should be have must have been embedded somewhere in that Json export.
Indeed, I would go a step further, and argue that given these underlying facts, we should always be able to build a Knowledge Graph from the Json export provided - and that if this knowledge graph is then shared with the "Actual" development team - most of the "Specification Documentation" will become entirely unnecessary, because, rather than constantly having to hard-code all of the actual rules into their code, in language, after language, after language - they can simply write their rules relative to the facts defined in the Json file available at design time.
This this in mind, we can have an English Specification Report (which is generated from the Knowledge Graph), and then code in 10 languages, which each also reference the knowledge graph. And then, when the decisions change (as they always do) we can simply update the knowledge graph and then regenerate the Specification Report and Json file - and all 10 languages are now back on the same page.
By contrast... if the code in those 10 languages was all just hard coded, following rules written down in an English specification document, when a decision changes, this is the traditional method of implementing said change:
1) A decision changes
2) A change request is made which describes (in English) what changed. This change request is now out of synch with the original Design Specification, because the original spec is not usually updated/kept up to date as decisions change.
3) This change request gets scheduled into some subsequent sprint, when the various developers who implemented the original logic can be assigned to jump back into their code, and implement the change requested.
4) Once changed, they now submit the code to be tested and released.
5) IF any bugs are discovered, the process repeats and we go back to step 2.
Now, to be clear, this is not to say that the steps described above will never happen when the project has a knowledge graph, it's just that they will need to happen dramatically less often, because many/most of the decisions can simply reference the knowledge graph - which avoids tight coupling between those decisions, and the various technical contexts and environments in which that decision is expected to be implemented in.
