Getting to Know the Knowledge Graph

Knowledge Graphs.... The topic shyly sneaked into the Emerging Technologies presentations by your favorite strategy consultancies. Complex? Hard to adopt? Niche?

Or maybe not really. We are dedicating this newsletter to the powerful concept that, we believe, should have been at least as hype as AI. Hopefully, by the end of this story you will be able to make informed decisions around Knowledge Graph adoption. Let's start our traversal of the wonderful universe of Semantics!

What on earth is a Knowledge Graph?

Imagine: you are explaining your business to someone who has absolutely no knowledge about it. You need to keep your sentences simple and short, and you need to specify the meaning of every word you are using. To make it even easier to grasp, you are bringing up examples to illustrate your story.

Effectively, you are reading out the content of your enterprise Knowledge Graph! By going from one topic to another, and connecting the data points to each sentence, you are navigating (or, as they say, "traversing") your business information universe. This is exactly what knowledge graphs are for!

By stating the things of relevance to your business and the ways they relate to each other, and defining each thing and relation, you are creating an Ontology: a static model of your business universe. Other ways to refer to ontology are "Information Model" or "Knowledge Model" - or even "Semantic Model", where "semantics" means "meaning". The reason for that name is that the meaning of each thing, its property, and its relations to other things, is captured and stored together with the model itself.

If you read our newsletter about Metadata, you will understand why we can say that "at least a part of business metadata is natively embedded into your knowledge graph".

At least a part of business metadata is natively embedded into your knowledge graph

And by providing examples, you are connecting your model to your data, effectively populating your universe.

The power of Knowledge Graphs

By now, you may be thinking: "But we already do data modeling!". You may even think of the times you were part of the discussions around Conceptual Data Models or Business Object Models, acting as a business expert whose story was being captured in a diagram of connected Information Objects.

Knowledge Graphs are not just about models. We think the easiest way to define a knowledge graph is: a machine-readable information model populated with the actual information. This means, they combine the information about how your business is organized with the actual data.

A Knowledge Graph is a machine-readable information model populated with the actual information.

Here is why Knowledge Graph approach is different from traditional approaches to data you are used to.

Everything is data

Ontologies - the model parts of Knowledge Graphs - are not just drawings representing the way your business is organized.

When the Ontology is created, the information about your business universe is captured in a way that can be stored and processed by the computer. You can write queries to get the answers from them - just the way you would write a query to get the data out of your system!

For example:

What is a Location, and what attributes do we store about them, and what are the different ways Locations can relate to Products (with definitions, please)?

But you don't need to stop at just definitions. You can include anything into your ontology: for example, the owners of each piece of knowledge, the processes that require that knowledge, confidentiality tags for each topic etc. And all of it will be machine-readable!

For example:

What attributes or relations of Product are marked as Strictly Confidential, and what is the meaning of these attributes and relations? Include the translation of these definitions into French. Who are the people I can talk to about these topics, and what are the processes that use these topics?

If we define "data" as information that is captured in a way machines can use it to automate business processes, we can say that:

With Knowledge Graph approach, every piece of knowledge becomes data!

When the actual data - in its most traditional meaning - is added, it is connected to the information model in the same exact way different things in the model are connected to each other. Now you can even write queries that combine business questions with questions about data!

For example:

Give me the list of all Locations in the Netherlands with their names and addresses and production capacities, as well as the definition of "production capacity" and the unit in which we measure it, and add the Products that can be produced at each location, plus the definition of what it means to "produce a Product", plus a confidentiality tag for everything I asked for, and the name of the expert I can approach to talk about it.

It is such an important notion that we will repeat it again: with Knowledge Graphs, your information models are data. Your business glossary is data. Your metadata is data. And of course, your data is also data. And you can use all of that data to automate processes and create new digital products.

Speed and Agility

Unlike Conceptual Data Models, Ontologies capture attributes ("properties") of things as well. Because the data will be connected to the models, ontologies don't stop at "main attributes", but capture any and all of the attributes that you will need to support your business goal.

Since ontologies are directly "populated" with data, they are, effectively, Conceptual, Logical, and Physical data models at the same time!

This means you need less effort to go from business understanding to data processing.

Also, since the model is connected to the data, you can very easily see what is impacted in case the model changes - making analysis really quick. Migration required? You can run an update command that will modify your model AND rearrange your data to fit your new model at the same time - with just a single query!

Data Democratization

Ontologies should always contain the definitions - not only for things, but also for attributes and relations. This is an enormously powerful thing to do.

As humans, we don't think in nouns. We don't frame our needs for information as "Customer. Product. Location"; instead, we use sentences: "Customers that buy Products to be picked up from a Location".

Notice how this sentence is different from "Customers that pre-order Products to be manufactured at a Location", or "Customers that buy Products to be delivered to a Location". The ways these three words - Customer, Product, Location - are connected can change the message completely!

The ability to model the story rather than concepts connected with lines is a prerequisite to Data Democratization.

It supports independent discovery of information, and, powered by metadata already available within the Knowledge Graph, allows your users to validate and deepen their business understanding without disturbing the business experts.

Business Optimization

Ontologies are inherently multidimensional - which means you can define a relation between two attributes, or two relations, or attribute and relation, or make an attribute the value of another attribute.

This allows you to model and maintain complex business rules that were previously living in rules engines (and would be majorly affected by model changes). The ability to mix the business rules with metadata and the data and feed them to your digital products allows you to create business optimization solutions with time-to-value of just a fraction of what could be expected in the world of traditional data.

In addition, Knowledge Graphs support a powerful concept called Reasoning. Reasoning allows the machine to "think like a human" by applying a predefined pattern. Reasoning can help identify the data and fill in the knowledge blanks.

"If it is yellow and it is a citrus, it is a lemon" is one example of reasoning that can be fully automated with Knowledge Graphs.

Knowledge Graphs are a powerful tool to support Operational Compliance and Self-Steering Process Value Chains.

What are the downsides?

All the knowledge, in one place, machine-readable, and connected to data: why is such a powerful concept not the standard in every enterprise out there?

Here, we will list some barriers to adoption that are holding the companies back from accelerating the value of their data and information.

The tech side

If you try to organize all the knowledge, with all the metadata, and the data connected to it, in an Excel file, you will very quickly discover that it is nearly impossible.

Relational structures - with the whole stack of traditional technologies supporting them - are not fit for Knowledge Graphs.

This is why Knowledge Graphs are using a different way of capturing and storing the data. Remember how in the beginning we said you would keep your story to short sentences? In fact, this is exactly what is happening under the hood. All of the knowledge - including the model and metadata, and the data itself - is stored in a set of 3-word "sentences" called triples. The triple consists of a subject (the "topic"), the predicate (the "what will be said about the topic"), and the object ("the statement about the subject"):

Product - manufacturedAt - Location .

Product - definition - "An output of the manufacturing process before packaging" .

ProductRecipe - confidentialityTag - Strictly Confidential .

Lines and lines of triples, together amounting to megabytes, gigabytes, even petabytes of data, are stored in a datastore called triplestore. There, specialized engines organize them, index them, and expose them when queried.

The queries are also nothing like your usual SQL queries. The language to "talk" to triplestores is called SPARQL. Instead of telling the engine what to take from where, it tells the engine how to traverse your knowledge graph and which "stops" to include into the result set.

All of that does not come with the traditional data toolkit.

Combined with what is perceived as a "rare and exotic" skillset, the technological novelty creates a serious barrier for adoption for Knowledge Graphs.

At Hakoona, we understand the struggle.

Our accelerators support gradual implementation of Knowledge Graphs based on free and opensource technologies.

By starting small and removing technology selection from the critical path, your organization can prototype its requirements, understand and confirm the needed skills, and deliver the enormous value that comes with Knowledge Graphs quickly and risk-free. When you are ready to select a licensed product, our approach makes the switch-over simple and seamless, with just a few days to complete.

That said, some of our clients prefer to stay on the opensource stack. There is nothing wrong with this option!

The people side

If you search for materials on Ontology Engineering, you will likely be confronted with long, academic, and hard to read texts.

Semantic Web, the concept behind Knowledge Graphs, has the perception of being too science-y to be accessible to a regular enterprise. Many Ontology experts are PhDs in Philosophy, Math, Linguistics, or all of the above (!). These profiles come with a significant price tag. This creates a worry many organizations take very seriously: can we staff our Knowledge Graph function, can we keep it staffed, and how hard will it be to scale it?

On the other side, the market is quickly filling with consultancies bringing technical skills without deep understanding on Semantic Modeling. This results in projects that fail to align to business requirements, or deliver unsustainable results. Gartner puts the failure rate of traditional Data initiatives at 75-80%; unfortunately, Knowledge Graphs - the concept that has all the power to make them a success - have the same meager success ratio.

Hakoona introduces the Agile Information Building method, that, coupled with our accelerators, removes the inherent complexity of Semantic Web, enabling anyone to become a successful Ontology Engineer.

Our clients establish and scale their Knowledge Graph teams by leveraging internal resources - such as Business Analysts and Data Architects. They get through our SemanticNatives Academy training, and graduate with full ability to create, support, and evolve Knowledge Graphs as well as spread the knowledge to others.

This removes dependency on external resources, mitigating the biggest risk associated with Knowledge Graph implementation.

In addition, Hakoona brings out-of-the-box models to capture all the knowledge you need in a quick and simple manner.

This way, you can deliver your foundational capabilities, guarantee data compliance, and create powerful business solutions on top of your Knowledge Graph quickly and efficiently.

The process side

Knowledge Graphs are powerful and flexible, solving a lot of challenges traditional approaches to data failed to solve for years.

But not the biggest one.

Any business, however you model it, is still a very complex thing with many different viewpoints. Forced consensus between these viewpoints is one of the biggest factors contributing to slow and messy analysis stages of any digital initiative.

For all their power, Ontologies are still facing the struggle of the traditional approach: they are a single model with a single set of terms and definitions that need to be aligned between different business silos.

Hence, the process of creating and maintaining Knowledge Graphs is not so different from a traditional data project, facing the same need for cross-silo consensus, potential terminology and granularity collisions, and complex governance organizations.

To overcome this, many organizations resort to two approaches. Below, we will talk about why these approaches introduce as many issues as they solve.

Layered ontologies

Layered ontologies are supposed to create a "common skeleton" of business understanding - the Core (or Enterprise) Ontology, whilst the details will be further elaborated in Domain Ontologies. In this way, every business silo is free to reflect their own understanding of the world, while cross-silo communication is enabled by going through the Core layer.

This approach does solve the need to have full cross-silo consensus. However:

• it still requires consensus on "core" level. Though it may seem relatively easy, just think about how many different definitions of "Product" there could be in a single enterprise.
• it requires very complex governance of core and domain ontologies and links between them. Think of a situation when something that was thought to live in just one domain is found out to be of relevance to other domains as well. When do we promote this thing into the Core layer? Who do we need at the table when taking this decision? How does it impact the data and the rules already sitting in our Knowledge Graph?
• it does not cater for differences in terminology between the silos. However elaborate the domains may be, the central glossary is still enforced by the Core layer. If you read our piece on Data Quality, you will know that you cannot control the vocabulary, and that forcing a common vocabulary only results in semantic data quality issues.

Industry ontologies

Adopting an industry model sounds like a great idea, doesn't it? After all, how different are the companies in the same industry? Probably, not that different. If someone outside of our organization already created a set of knowledge about how our business is structured...

Although reading an industry model can help the modeler onboard quicker, in practice, the adoption of industry models results in a lengthy and complex process of cross-fitting your business into an external structure and extending the said structure to better capture your business reality.

Industry ontologies are great tools for interoperability: they can be used as a "common language" for information exchange between the companies in the same industry. That said, every business is different. You don't want external models to guide yours.

Fortunately, there is a way to eliminate the governance limitations for Knowledge Graphs. In 2022, Hakoona ThinkTank introduced Knowledge Hypergraph: an approach to Knowledge Graph that allows you to capture the business knowledge in context, and supports the users and the systems in navigating between the contexts.

Knowledge Hypergraph allows you to capture every slice of your business exactly as the processes responsible for that slice see it.

It takes care of terminology and granularity, and provides every user with a familiar perspective while keeping the full overview of your whole business in the background. You can "wear the hat" of a person from a different business silo, and get a guided walk-through of their business reality.

It eliminates the need for continuous alignment between the silos, and makes cross-silo initiatives up to 80% more efficient.

The takeaways

• Knowledge Graphs capture and connect the knowledge about your business to its data. By creating a pool of machine-readable knowledge connected to your data, you can create powerful digital solution to support your business - in a fraction of time you'd need if you decided to do it in a traditional way.
• Knowledge Graphs are built and maintained by Semantic Architects, also known as Ontology Engineers, Knowledge Engineers, Linked Data Experts, or Information Architects. Whatever the name, the main specialization of these people is Semantics: the structuring of knowledge, and populating the resulting structures with data from your systems.
• Hakoona offers methodology and accelerators to ensure your organization can adopt Knowledge Graphs and staff your Knowledge Graph teams quickly, while minimizing the risks naturally associated with introducing an innovative approach.
• Our SemanticNatives Academy provides the education on Ontology Modeling and Semantic Integration, empowering your Analysts and Architects to become Ontology Engineers and operate independently.
• Our research made the next step in the Semantic Web discipline. Adopting Knowledge Hypergraphs will allow you to drastically reduce the effort of governing the vast body of business knowledge and data, while avoiding the pitfalls common to both traditional data management and traditional Knowledge Graphs.