In the UK, there’s an old saying “Don’t wear your coat indoors, or you won’t feel the benefit when you go out”. In the same way, it’s good to know what you need to have in place to feel all the benefits knowledge graphs can bring.
Based on our experience, we’ve found that there are some common stumbling blocks. Let’s have a look at those.
Why
You need to make sure the people in your organization know the why of the knowledge graph project. If they know why they are doing it, they’ll be in a better position to deliver what they’ve been asked to do. At any stage of the project, they’ll know if what they are doing is taking them closer or further from their goal. And, when they reach inevitable stumbling blocks, they’ll be able to make informed decisions.
Data integration
If your organization’s idea of data integration is printing out multiple reports and manually cross-referencing them, you might not be ready for a knowledge graph. As great as knowledge graphs are, if you have records of materials still on paper, they won’t magically get scanned, OCR’ed, recognized, and incorporated into the graph. You need to do some work before you implement the technology and, thankfully, there are tools that can help with that.
Excel spreadsheets
Often, after we’ve brought together data that was isolated, and we are either showing something in a novel way, or just recreating something that already existed, but is now in a knowledge graph, one of the first questions is, “Can I export that to Excel?” But when we ask, “Why do you need this?, sometimes the answer is, “We don’t know.” You need to get the knowledge out of people’s heads, keep it in the graph, and make it repeatable. If you can’t do it, you might not be ready.
Magic bullets
We’ve also met people who’ve been “internally evangelized” and are pinning their hopes on inferencing, and ontology thinking, and all that magic. But while all those are important, they are not the be-all and end-all. As cool as inferencing can be, the superpowers of knowledge graphs start early in that 80% of RDF and SPARQL, and maybe a bit of SHACL, if you want to use some shapes. If you don’t have this understanding, maybe you are not ready, yet.
Ivory tower modeling
We’ve seen too many models developed by isolated ontologists that don’t survive the first battle with the data. There’s a famous saying by a statistician, George Box, “All models are wrong, but some are useful.” So, how do you know whether your model is useful? How do you measure its utility? If you are waiting for it to be perfect before it’s unleashed, how will you ever know? You need to be able to answer these questions before you can start a knowledge graph project.
Fear of the unknown
Some potential users are afraid of that new “graph stuff”. In such cases, you can argue that it’s not new at all. Propositional Logic has its foundations in 350 BC, with Aristotle. He outlined the first three laws: the law of identity (that A is A), the law of contradiction (that A is not B), and the law of the excluded middle (that A is A or B is B). That’s a 2500-year-old thinking that is at the core of triplestores and reasoners and it’s been around for longer than many other things we readily use.
Resistance
At the start of every innovation and change, there’s usually an organizational civil war. There always are some well-meaning but misguided entrenched attempts within an organization that is undergoing a transformation. As our technology demonstrates – use case after use case – that it needs a fraction of the resources of existing approaches, the old guard gets nervous. So expect resistance from the old guard. Better if you can ensure that everyone is pulling in the same direction before you start implementing any changes.
The term “graph”
You should be aware of some confusion around the term “graph” and make it explicit what it entails very early on. In fact, we had one executive at a client who was probably a few weeks into the project, when we realized that when we said “graph,” they thought we meant “charts”. They thought we were offering some sort of Power BI alternative. So, we’ve learned our lesson.
AI will solve it
We’ve seen a massive increase in interest in LLMs and ‘AI’. But LLM without guide rails could lead to unbridled hallucinations. As a statistical model, LLM inherently is random. Is that how you want to run your business?
Semantic knowledge graphs combined with LLM allow you to bridge the gap – querying your well-curated and conformed data with natural language. It means driving ontology to generate the SPARQL, but also the reverse. If you ask it to generate a response, and maybe it hallucinates, you can then constrain the response it gives you, from the well-curated data in your graph. And I think both of those are natural synergies.
Data quality
Knowledge graphs thrive on clean, well-structured data, and they rely on accurate relationships and meaningful connections. If your quality is so poor it looks like a piece of abstract art, you’ll have some work to do. You’ll need to take a step back, focus on data cleansing and quality assurance, and ensure that your data is accurate, consistent, and up-to-date. Fortunately, Graphs, RDFs, SHACL, and SPARQL are superb tools for helping you clean the data. With things like named graphs, layering the data, testing those what-if scenarios, and checking the state is fantastic.
Delivery methods
Sometimes organizations are stuck in a battle between traditional “waterfall” and modern “agile” methods. At its core, agile methodology is a Deming Cycle: Plan, Do, Check, Act. It builds upon consolidation through standardization. This is where a knowledge graph with ontologies can help your organization grow.
Really.
So, if you still live in a very waterfall-y world and you want to know everything you need to do upfront, you might not be ready. That’s why we try to go to where the work is done (gemba). When we get into the room with the people who will be using the tool, we can have direct feedback. This will allow us to try the next experiments.
What we’ve learned from these Deming Cycles is that faster feedback wins every time. If you have to wait three to six months before you can have a review of whether or not this technology is allowed to go through, you are not ready for it. So, we try educating the people we meet along the way, not to view their challenges as an impediment, but as another opportunity to grow.
High-level buy-in
If your CDO or CEO thinks that SPARQL is some sort of exotic bird, you might not be ready. You’ll need to educate them and get them to learn the benefits by small, demonstrable feedback, repeatedly.
The cloud
If your organization thinks they are moving to the cloud, but they are doing everything in the same way they always did, you’ve missed the point. If there are six-month lead times to get a machine in the cloud, you are doing it wrong. Be aware of these organizational hindrances and look at ways to avoid or improve them. We have projects about mapping infrastructure for more efficient moving to the cloud and we can help you there, too.
RDF pipelines
You also need to ensure you’ve got quality in your RDF pipeline. How do you do that? We find that as great as SHACL is at ensuring the data quality, testing the RDF pipelines is another matter. We are using a tool called MustRD, which is open-source, but not yet public. It’s an RDF ontology, with a Python execution engine. It can run transformation and SPARQL, loading datasets, and ensuring that SPARQL does what you say it does at query or transformation time.
Access
You need to have access to your data before starting a project. Then, once you are inside, you need to be able to access all the siloed data sources. We’ve had clients where it took three months to get a login to the systems. Waiting is a waste. If it’s going to be a big battle to get that, you might not be ready.
As-is versus to-be
Sometimes we find that people are not clear about whether they are trying to model some as-is state or a to-be state. So, you need to be clear about it. You need to know what you are doing and why you are doing it. Are you building it to prove a point so you know if to go left or right at the next move? Or are you stamping widgets, with refined machinery? You need to be honest upfront about how much effort should be expended. You don’t need a fully-fledged project if you are just experimenting.
Key Takeaways
So, what do you need to do to make sure you have all the necessary things in place to feel the benefit of your knowledge graph?
Start with “why?” Knowledge graphs can indeed transform your business, but you might require and, actually, should expect institutional changes. Experimentation is important, but be explicit when you do. Don’t fear growth. Progress is good, so don’t miss out. Try and get your C-level buy-in, and try to prove it down at the ground. And don’t drown in paper stacks. Let your knowledge graphs work.
Still not sure how to start? Contact Us
This blog was published on the 14th of February with our partners Ontotext.
