Insight

Nowadays, the term ‘knowledge graph’ is used by many in many different ways. To make things worse, there are all sorts of associated terms to describe the concept, like ontology, property graph, and semantic networks or nets. A commonality is that knowledge graphs have to do with structured data and the specific structure of graphs. At our company, we define a knowledge graph as information representing something conceptual, expressed in two or more objects and their relationships, defining their context. For example, ‘a bicycle’ has as part ‘a frame’ is a singular knowledge graph of two objects, ‘a bicycle’ and ‘a frame’ and their contextual association, ‘has as part’. This basic structure to express information is also called a ‘triple’, and objects and relations are sometimes referred to as ‘nodes’ and ‘edges’. The length of a graph is unbound. In other words, there can be entire networks of interrelated graphs.

There are different reasons for using graphs, but most implementations are driven by the need for software to process data smarter. We want to be interoperable and scalable, or to put it in simpler words, we need software to exchange data anywhere, anytime, and not to be hindered by technical barriers regarding the amount of data. The drivers behind these drivers are the exponential growth of data and the desire to automate more (see What is FAIR data?).

To make this happen, we use the underlying mathematics of graphs by computers for inference and reasoning on information stored in the most generic way possible. If we want our software to process information, it needs to understand two things: its structure (where to find what where?) and its meaning (how to interpret this?).

Let’s start with the structure. A database can be visualized as a group of tables or, more practically, an Excel spreadsheet. The problem with databases is that the software developer creates many different tables and relationships between them. As you might have encountered when making an Excel spreadsheet, you become over-excited when it comes to relating different fields. That goes well for so long, but often, it’s hard to remember all these structures by heart.

The software, or you in the case of your spreadsheet, using the data (writing and retrieving) needs to know what table to find where and what data in what column. This is different for every software application when it is not complying with a familiar, agreed-upon structure. When you want to exchange data between software applications (or with your colleagues in the case of your spreadsheet), this chaos of data structures is a vast (and expensive) hurdle to overcome. The data needs to be transformed and often translated into a structure that can be used as a joint agreement.

Second, there is the semantics, or meaning, of the data. Without the ability to interpret which data means what, software can’t help. The trick is to be able to describe any meaning in the most generic data structure. By using formal language to describe semantics and using the structure of graphs at the same time, both people and computers can process the data. That is why, to exchange and share data, there are international IT standards for structures and semantics. The simplest and most generic structure is the graph. In tables (databases), a graph implies one table and three columns: object-relation-object or, better said: a graph-structured data model.

Although not the only way to store and process graphs, there is (for good reason) a family of databases called graph stores. Although there still is a degree to how interoperable graphs are implemented, they all share the graph as a basic structure. There are graph stores that allow for all sorts of metadata columns and even their own proprietary query languages to retrieve data from their graphs, and there are ‘highly FAIR’ graph stores that enable the use of international standards for semantics and communication, like the Resource Description Framework (RDF).

As far as the semantics go, these web standards of W3C also provide the basic formal language to express anything we like. You could see it as a dictionary of dictionaries that allows software to interpret logically what we say in ‘normal’ language.

Well, we do. Besides DBPedia, Wikidata, and Google Knowledge Graph we use knowledge graphs ourselves in developing software. Our software, Laces, enables its users to manage and share knowledge graphs online.

Laces takes care of all the complexity of graph databases and in-depth knowledge of logical inference and reasoning,, so its users don’t have to. Users can and should focus on expressing their domain knowledge in any way suitable for interoperability and scalability. For our users, that’s using knowledge graphs without the need to know.

Want to read more on graphs? Check out this white paper “Why sharing master data through Linked Data is the Future”.

References:

Like GraphDB: https://www.ontotext.com/knowledgehub/fundamentals/what-is-a-knowledge-graph/

The exchange of information between computers is essential for facilitating collaboration and streamlining processes across different stakeholders. For this to happen, computers must agree on how to interpret data, just like humans need to understand the language, vocabulary, and grammar used in a conversation. To interpret data, software requires uniform data, and data can only […]

Nowadays, the term ‘knowledge graph’ is used by many in many different ways. To make things worse, there are all sorts of associated terms to describe the concept, like ontology, property graph, and semantic networks or nets. A commonality is that knowledge graphs have to do with structured data and the specific structure of graphs. […]

What does FAIR stand for? FAIR is an acronym for Findable, Accessible, Interoperable, and Reusable. These topics are relevant to those wishing to reuse their data and have machines automatically find and process their data to help people do so. These so-called ‘FAIR Guiding Principles’ (for scientific data management and stewardship) were published in Scientific […]