What is the difference between a hypergraph and a knowledge graph?
Hypergraphs can connect more than two nodes with an edge. Traditional knowledge graphs connect exactly two nodes with one edge, in what is called a triple. A set of triples can be used to represent a hypergraph when bound to a model.
Most knowledge graphs try to represent complexities that go beyond traditional triples. In the same way as we can express information as columns and rows in tables, we can encode knowledge as elements and connections between them in a knowledge graph. Hypergraphs enable more expressive graphs in a native form, by introducing hyper-elements that connect more than two elements together with a single edge, as a native construct.
In this article we will explore the native implementation of hyper-elements in a DFRNT-hosted hypergraph. We will also explore alternative ways of thinking about hypergraphs in other graph engines.
Hypergraphs vs Knowledge graphs
The hypergraph is the exotic brother of the traditional knowledge graph. Due to how they are often expressed only mathematically, many feel they are hard to understand and use, hope this gives some clarity.
Most knowledge graph implementations treat each set of two “vertex” nodes and the edge connection between them as one unit, the triple. And such triples are at the core of every knowledge graph implementation, it makes sense to call them a "knowledge atom", the smallest unit of knowledge.
What makes knowledge graphs that support hypergraphs different, is that more than two nodes can be connected by the same edge. This feels strange at first.
Once we grasp what's we are going to explore, we can use this to our advantage. Similar constructs are created routinely in knowledge graphs, approximation such hyper-elements.
Modelling relations between blogposts
Let’s illustrate this with the simple example where we have one blogpost, that carries outgoing links to a set of related blogposts. Adding outgoing links like this is a nice and quick way to help the reader find relevant content, and for us to keep them reading materials on our website.
This is traditionally modelled in a knowledge graph as multiple triples having an edge, relatedTo, one for each linked blogpost ID. It works and is an way of serializing a hypergraph in useful ways.
When modelling this relationship in a hypergraph however, we make this relationship explicit. The same edge actually connects all of the blogposts using a hyper-element. This hyper-element, the hypergraph edge, connects a set or list of related blogposts, using one edge, we may call it relatedTo.
Using a set or a list, depends on whether there is a semantic relationship that should be upheld, where a set indicates an unordered list, and a list would be ordered.
When serializing such hypergraph objects, they are collapsed into RDF triples, encoded as a JSON-LD document.
Going beyond the simple Set hyper-element
We mentioned the set or list for the elements at the far edge of such a directed hypergraph edge. What if we want more complex arrangements, or undirected edges?
In DFRNT, there is even the ability to build a hyper-element with one edge that connects to an nth-dimensional array of values, controlled by the information model, which is far beyond what is needed in this simple example of a blogpost, although the list could also be seen as a 1-dimensional array.
DFRNT is primarily used for directed graphs, where edges have one node bound to the object it belongs to (shares lifecycle with). When modelling undirected hyper-elements that form a hyper-edge between arbitrary sets of nodes, a connector object should be created and such objects have a lifecycle that is separate from the objects they connect.
This approach is similar to how many-to-many undirected relationships are formed in a traditional relational database. Cardinalities should be used to ensure the hypergraph model is correct and prevents loose connection objects in the graph.
Such undirected hyper-element edges can be ensured to be a correct graph by setting a minimum cardinality of two, and to go beyond the single connection to a hypergraph edge, a minimum cardinality of three.
Hypergraph elements can even have patterns for their arrangement as high-dimensional arrays, or just as simple sets that have no pattern or lists that imposes an order.
Comparison with traditional knowledge graphs
The difference between formally encoding the hypergraph in a platform such as DFRNT, that properly supports them, is that they are formally correct representations, whereas implementing them in traditional knowledge graphs such as label property graphs and most RDF triple stores would encode them directly as many triples or connections to emulate a hypergraph.
This is due to that most RDF triple store implementations and label property graph do not have a guard that ensures adherence to an information model and don’t have such hyper-elements as first class citizens. This comes only when a schema can be formally upheld with a guard or where the structural integrity of the hypergraph is enforced by other means.
Conclusion
DFRNT is a hypergraph engine, thanks to its guarded knowledge graph implementation. A key part of the excellent support for hypergraphs is that the hyperedges share their lifecycle with the object they belong to.
The lifecycle of an object in DFRNT is that it is always guarded to be accurate to the schema by the core engine, including for changes of it. When the object id is deleted, all of the triples it contains are deleted as well.
It is only when the graph is observed or serialised as JSON-LD documents that the hyper-elements become serialised as individual representational triples, the core engine treats them as hyper elements until queried, as the hyper-elements are connected together internally through the information model and ensured to follow the conventions.
In DFRNT, an edge that is modelled with a set of values, fluently moves from a triple when only one node is connected, to a hyper-element when many are connected, and this is transparent to the user and managed internally by the model.
