Reasoning with Big Knowledge Graphs: Choices, Pitfalls and Proven Recipes

Ontotext has been doing knowledge graphs way before the term became popular. Their main advantages are that they allow us to link data across different datasets and to use semantic schema and semantic metadata to describe this data, so that both humans and machines can interpret it.

Essentially, knowledge graphs can be seen as a combination of three well-established paradigms in computer science: as a database that can be queried, as a big network structure that can be analyzed and as a knowledge base where new facts can be inferred.

Now, let’s consider the following example sentence: “My Local Cafe is a network of independent coffee shops”, illustrated on the diagram below.

Through inference, a knowledge graph can provide additional information that is not explicitly stated (follow the dashed orange arrows!). This can be information about companies, i.e., that Big Bucks Cafe controls Global Investment Inc., which controls My Local Cafe. Or about geographic location, i.e., that Big Bucks Cafe is located in Seattle, Global Investment Inc. is in West Bay and my Local Cafe is in New York. This information can be further supplemented by the facts that Seattle is in the state of Washington and New York is in the state of New York, both of which are part of the U.S., while West Bay is a district in Grand Cayman – one of the the Cayman Islands.

Given the right semantic schema (known as ontology) behind it, a graph database engine can infer additional facts and relationships, which can then be added to the knowledge graph. This enables you to discover multi-hop relationships or other patterns that might otherwise be difficult to catch. If, for example, you want to know which companies in the U.S. control another company in the U.S. through a company in an offshore zone, many databases can work it out for you. But a graph database with inference, like Ontotext’s GraphDB, makes it much easier and faster to put the data together and execute such queries.

Graph databases, based on the RDF model, deal with both the semantic schema and the instance data as a single graph structure so that queries can span across schema, data and metadata. In formal semantics, which uses Semantic Web standards like RDF Schema and OWL, the semantic schema defines the meaning of the different classes and types of relationships. The instance data on the other hand maintains information specific to individual instances – typically entities like people, organizations and locations or abstract topics and concepts like the number Pi, the musical style Ska and The Istanbul Convention.

The example above shows the schema part of the graph in green – a class hierarchy (Woman is a subclass of Person, which is a subclass of Agent) and some definitions of relationships (childOf, parentOf and relativeOf). And in orange is the specific instance data like the fact that Ivan is childOf Maria. There are also a couple of system primitives used to define the semantics of property definitions in blue: SymmetricProperty and InverseOf.

Based on the explicit facts, a graph database engine can automatically infer other facts and relationships (illustrated again by the dashed line arrows). For example, if Woman is subclassOf Person and Person is subclassOf Agent, the engine will infer that Woman is subclassOf Agent, because subclassOf is a transitive property. Going further, if Maria is an instance of Woman, then Maria is also an instance of Person and Agent.

So far, we have encoded some very basic object-oriented semantics using logic and rules. But we can go even further. If Ivan is childOf Maria and the schema describes this relationship as the reverse of parentOf, then it can be inferred that Maria is parentOf Ivan. And because parentOf is a special case of relativeOf, which is defined as a symmetric property, then Maria is relativeOf Ivan and Ivan is relativeOf Maria.