According to Wikipedia, a hypergraph is a generalisation of a graph in which an edge can join any number of vertices. In topic maps terminology, that would be the equivalent of an association connecting more than two topics together (as opposed to a normal association that asserts a relationship between exactly two topics).
Typically, relationships are established between two entities. Just to establish some terms and definitions, in graph theory, the entities are called “vertices” or nodes and the connections between them are called “edges”. In topic maps-terms the entities are called “topics” and the relationships that connect the topics together are called “associations”. Different names, same thing.
So, an example of a typical relationship would be between workplace colleagues, Jane and Peter, respectively; something like this:
Jane ↔ Peter
An association in the topic maps paradigm is a multi-level structure. First of all, an association has a “type”. A type can be anything conceptually, but in technical terms it is a reference to another topic (which is part of what makes topic maps self-referential and self-contained). So, looking at the above “Jane ↔ Peter” association we could say it is of type “work” — work would be the identifier for a topic that represents the generic concept of “work”.
In addition to a type, an association has members. Members are, for all intents and purposes, collections. What’s more, members also play a “role” — each role would be the identifier for a topic that represents the concept of that role. Let’s look again at the the above example of the relationship between Jane and Peter, a web developer and graphic designer, respectively:
Jane [web-developer] ← work → [graphic-designer] Peter
All of the nouns in the association (that is, Jane, web-developer, work, graphic-designer and Peter) are topic identifiers. The two members identified by their roles, “web-developer” and “graphic-designer” respectively, are collections that can contain one or more references to other topics. So, this is the crux of being able to express hypergraphs with topic maps: an association has two or more role-based members and each member can have one or more references (to other topics). Let’s examine the example of these colleagues with Anne, the manager and her team, Jane, Peter and Paul and see how the relationships between them could be expressed as a hypergraph association:
- Association of type work
- Role of manager
- Reference to Anne
- Role of software-developer
- Reference to Jane
- Reference to Paul
- Role of graphic-designer
- Reference to Peter
- Role of manager
The above hypergraph association could be decomposed into the following separate non-hypergraph associations:
- Anne [manager] ← work → [software-developer] Jane
- Anne [manager] ← work → [software-developer] Paul
- Anne [manager] ← work → [graphic-designer] Peter
- Jane [software-developer] ← work → [graphic-designer] Peter
- Jane [software-developer] ← work → [software-developer] Paul
- Peter [graphic-designer] ← work → [software-developer] Paul
So, now that we understand the distinction between normal associations vs. hypergraph associations we can take a look at them within the context of Contextualise (no pun intended).
One of the reasons why Contextualise didn’t provide support for hypergraphs is their perceived complexity. Most people think it is confusing to use only one association to connect more than two topics as it requires a good understanding of the association’s multi-level data structure (as described above).
What’s more, associations are first-class citiziens in TopicDB (and by extension, Contextualise), which implies that they are addressable just like topics (actually, in TopicDB associations are also topics). The point being that each specific relationship, because of its addressability, can have its own biography. So if topic “A” connects to “B” and to “C”, even with the same relationship type, they are really separate connections. So, if a hypegraph association is used to make the connection between topics “A”, “B” and “C” the ability to have a separate biography for the relationship between each topic is lost. That being said, hypergraph associations are very practical. That is, adding more members to an existing association or more topic references to an existing member is quick to do and enables the succinct expression of rich relationships between several topics. So, the reason for having support for hypergraph associations in Contextualise is one of convenience.
An association in Contextualise, by default, is always a non-hypergraph association. To create a hypergraph association you have to modify an existing non-hypergraph association. This is accomplished by drilling down into a specific association and either adding another member or, alternatively, drilling down further into a specific member and adding another topic reference.
If you have any feedback with regards to the hypergraph association feature in Contextualise, or if you come across a bug then just let me know by creating an issue in the Contextualise repository on GitHub.