What are Knowledge Graphs?

Knowledge graphs are used to describe people, things, ideas and anything else you can imagine. They capture knowledge in a way that both humans and computers can understand.

For humans it is intuitive to communicate using graphs. Graph objects can store data to describe them and references to other objects in the graph. Graphs can be jagged and incomplete, because that's how our brains work when we're trying to understand something new.

The use of knowledge graphs by computers is quite exciting because they are reliable, flexible and able to scale to high volumes. The reason web searches are getting smarter and more consistent is an open knowledge graph called schema.org that describes the most common search terms. Facebook and LinkedIn are two giant social graphs.


More and more enterprise level companies are turning to semantic knowledge graphs to organize, query, and run tasks on company data. They use knowledge graphs as a stepping stone to machine learning and artificial intelligence. 


At nSymbol, we think it is high time that small and medium size businesses, and even individual people, have the opportunity to capture their data in a knowledge graph and then have fun doing things with it.   


Please note that the functionality described on this page is not yet available - but it is close.

Please see our Release plans page for more.

What do knowledge graphs look like


There are several technologies that can be described as knowledge graphs. Most notably this includes graph databases and semantic models. Tag uses semantic models which are able to support automated reasoning. Automated reasoning is a type of artificial intelligence. When you create a knowledge graph in Tag, you use terms and structures that can communicate with other semantic sources (e.g., open data from data.gov, geonames.org, or other international databases). In this way, when you add a bit of data to your graph, like for example, the name of your hometown, a whole bunch of other information can be imported or linked (if you choose - you are in control!) without you having to manually enter it. The more data you add, the richer and smarter your model becomes.


You can make a knowledge graph by mastering four simple concepts: Classes, properties, instances, and values 

Classes and properties: things and the terms that describe the things

Knowledge graphs provide a way to describe people, things or ideas.

A class is an object in the graph (big blue circle) that describes a type of entity by giving it a name - that's it. It's a name you use to refer to this type of entity when relating it to other entities. Class names are unique within a knowledge graph. For example, "Dog" can be a class, so can "DogHouse" and "Frisbee."


A class is associated with, or linked to, properties that describe things you know about it. For example, a Dog class could have several useful properties including name, breed, size and color. This is shown as a graph below.

This graph contains three classes: Dog, DogHouse and Frisbee. Properties are used to store data and make connections between classes.

The green rectangles represent data properties. Entities that belong to a class may be expected (not required) to store data values for all data properties.

The blue rectangles represent object properties. Entities that belong to a class may be expected (not required) to store references to other entities for all object properties.

Instances: examples of the thing

Entities that belong to a class are called instances. They are objects in the graph that may belong to one or more classes.

Data is often incomplete and information may not be stored for all properties. Graphs are like that. You can even refer to entities that are not defined in your knowledge graph. The technology is designed to be resilient in this way, and encourages flexibility over strict rules of use.

Some instances have names just like classes. The name must be unique in the knowledge graph, and must be different than all class names. Names allow more than one entity to reference a specific instance.


You don't always want names. If each row in a CSV represents an instance, no one wants to name them. It's this dual role of instances that sometimes trips people up - sometimes an instance is an object, and sometimes it's just a row in a CSV. For the computer, either way, it's just a collection of named data values to work with.

Anonymous instances do not have names. They can store data values and object references, but can't be looked up by name in the graph. Both types of instances are shown below.

Rover is a named instance of the Dog class. It's name in the graph (Rover) is unique.

The dog house and three frisbees are anonymous. They store useful information but do not deserve the visibility of a named instance in the graph.

In another knowledge graph named frisbee instances may be useful (e.g., if the author plays disc golf).


The discussion so far has been a bit misleading. It talks about unique names in a knowledge graph, but that wouldn't be specific enough when combining more than one graph. What if a dog walker has a graph containing Dog, and that is combined with a graph for training seeing eye dogs, which probably has different properties.

This is resolved by embracing the URI. A URI is just like a Web URL except it doesn't have to refer to a downloadable resource. URIs are used for identification only and to declare ownership over a knowledge graph, or entity within the graph.

These two classes of Dog have the same local name within their own graphs, but when addressed using URIs you have a combination of graph identifier and the local name. For example, the following two classes can be safely used together in a graph.



In fact, these classes could be entirely different and share no properties in common. One could be written in English, one in French (although it would probably be named Chien). It's simply coincidence that both classes share the same local name.


The bulk of information stored in most knowledge graphs are property values. As discussed earlier, there are two kinds of properties: data and object.

Data properties store values that can be stored as a string of characters. It could be words, numbers, dates, image data or anything that can be typed into a simple text editor.

Object properties store URIs which identify entities known to the graph. This is a critical aspect of graph technology, because it allows the computer to efficiently connect multiple entities (hint, it turns URIs into numbers and solves algebra equations with them). This efficiency is what allows giant graphs like Facebook to function so well, even with an enormous volume of instances and properties in the graph.

Adding values to the example graph looks like this.

We now have much more detail. Rover has one dog house and one frisbee - both are anonymous instances (labels start with "_i").

He also has a height and two colors stored as data properties.

All shapes in the graph can be selected much like logic bubbles in the smart content example. This allows the author to change the structure of the graph (classes and properties) or the content of the graph (instances and values). It also lets you hook up actions.

What can you do with a knowledge graph

Knowledge graphs are ideal for organizing information. They can be used to define a model of real world objects that can be explored and queried. They can be used to create data dictionaries or taxonomies. They can even support back and forth interrogation using rule engines to explore a knowledge base.

This is also a great technology for connecting information. Our Public resources page lists several well-known public knowledge graphs. These graphs contain information that drives business process (e.g., health billing codes). You can create custom knowledge graphs that link to key entities in public graphs, or link to other custom graphs of partners and customers. You can also link to things are not technically knowledge graphs (you only need to provide unique URIs).

A side benefit of using RDF/OWL is automated reasoning. For example, you can define a Mammal class and Dog subclass. When you create a subclass it inherits all properties that are linked to the parent (and all of its parents/superclasses). This way a "fur" property attached to Mammal can be reused by Dog, Cat and many other classes. Note that this is a very simple example of automated reasoning and much more is possible.

In addition to all that, Tag lets you attach actions to knowledge graph entities. This can help you automate business process and reduce the occurrence of errors or delays. Attaching actions that trigger smart content can be particularly useful.

For example, imagine creating an instance for each supplier of a key part, and linking everything needed to fill out an order for that supplier to each instance. Data properties can store any string, including paths to documents in your file system. Users of the graph could select a supplier using any criteria that makes sense, then generate a purchase order with all the right codes filled in using smart content.

You used to need programmers to setup something like this. Now you don't with a bit of help from Tag.


Summing up

This discussion has only scratched the surface of what's possible with knowledge graphs. Some topics not yet covered:

  • Storage: how to store large models efficiently and share over a network or the web

  • Editing: how to link classes, properties and instances - and add data

  • Rule engines: how automated rule engines can be defined using graph entities

  • Machine learning: how graphs can help define a problem space for ML models

We'll be providing more content when the knowledge graph module is released.

nSymbol Technology Inc. is a startup company operating out of Alberta, Canada. 

© 2021 by nSymbol Technology Inc.