For what my opinion is worth, I encourage you! I have been a fan of the semantic web since day zero, and I worked with their Knowledge Graph while working at Google. In order promote the tech, I am working on an app (for iOS and macOS) that will walk new users through using SPARQL against endpoints like WikiData and DBPedia. My email is in my profile, contact me and we can set up a phone call sometime.
I'm using neo4j to integrate this set with HR and financial allocations data to show the direct exposure of business applications to their budgets, and provide a rough value at risk on a per branch basis, and create big scary graph viz clouds of vulnerabilities that all point to the person responsible for them, mainly to get people to get off their asses and patch their shit.
I'm also using queries of the graph to auto-generate hierarchies of jira epics and stories and assign them to the business owners so we can track remediation across the whole enterprise in both jira and azure devops.
It has produced a navigable organization map and we can run queries like, show me the vulnerability exposure of this division based on the aggregate risk of the applications deployed by its branches, and show me who is responsible for fixing it. Show me the sr. manager who has the most vulnerabilites roll up to them by their jr. managers, etc.
Here, what part of your problem wouldn't be solved by a DB with a table of vulnerabilities, a table of branches and divisions, and a table of people?
A query can fetch the images and apps used by a division, then use that to query the vuln database.
I mean, I understand the problem is not super simple, but I fail to see what knowledge graphs bring to it?
When I need a performance problem solved, I'll hire an engineer to reimplement it, but until then, I can analyze the data at the business level. Right now I just need a rope across a river to see what's on the other side and not a bridge. :)
So yeah, the types of problem a db system solves are db problems, even if its using a semantic network model instead of a relational model
Some even support techniques like inferring "new" wisdome that was not implicitly moddeld.
In the end you could solve all that on other ways like making the application smarter and using a "not so smart" db system. But i am not an expert in that topic...
However, reality is on this project, all the input data exists in spreadsheets, which means you have to normalize it into your graph ontology data model. The SaaS here would be something like Graphene or hosted Neo4j.
If there were a graph model for something like powerBI for graphs, that could be a play. Else, it's more of a high dollar consulting solution.
Finding that SaaS in enterprise is limited because most enterprise people live in spreadsheets, which are both orders of magnitude more sophisticated, yet stunted compared to SaaS. But for all it's limitations, excel is turing complete, and your CRUD application never will be, even if the users don't know what that means. Enterprise tech is about generating data to drive conversations, it isn't about solving problems because managing that problem is somebody's job.
If a CIO came to me and said "fix my company," I would say, "sure, give me your data, then 6-12 months to herd all your cats" and I could do it. Nice lifestyle, but there's no exit in that.
SaaS is in the works.
A single host can probably handle a billion nodes or so. Our largest in-production graph is about a third of that.
We primarily get pulled in as a component for projects that use as part of:
* Asset management, whether sec, IT, manufacturing specs, pharma, metadata stores, config systems...
* ML model unification (e.g., how Google translates between many systems)
* Knowledge bases/search for both people & for algorithms. Wikis, recommendors, ... .
There are less common scenarios we see that I also expect to explode, like massively bootstrapping ML systems via weak supervision. GraphDBs & compute are also used for what I consider non-knowledge graph scenarios, likely scaling some compute tasks. Exciting times!
I tried selling it but until now it has proven hard to explain what the benefits are, arguably it needs more work to be really useful.
In industry Google use it (they coined the term), otherwise I don't know. In the open data world DBpedia is the reference and is the target of a lot of inbound links.
Google's Knowledg Graph seems to have given knowledge graphs their name in the first place.