Topic Relationships

Currently the topic relationship schema is completely manually generated by authors.

Authors establish topic relationships by searching for related topics, and manually creating a one-way relationship.

The disadvantages of this:

1. Labour-intensive and not scalable
A lot of links need to be made.

2. Prone to error
Anything that relies on humans will have mistakes.

3. Inconsistent
To give the end users a consistent experience, we need to establish standards for how topics are linked.
If we do that, then automating those linkages is the obvious path to go down.

Automating topic relationships

The Overview topic type can be used as a topic linking map.

This means that topics still need to be manually linked through the generation of an Overview topic, however: 

It means that topic relationships are dealt with in a single place, rather than individually in each topic.

So Concepts are linked in a Conceptual Overview topic, and Tasks are linked in a Task Overview topic.

When a Concept Overview topic is generated, multiple concepts are encapsulated in a discussion of their relationship. Each of the individual topics is related to the Concept Overview topic. The system can now infer a relationship between each of those topics. In other words, if a number of Concepts "n" are encapsulated by a Concept Overview, then n(n+1) relationships are established - reciprocally between each of the concepts, and between each concept and the Concept Overview.

If a Concept Overview encapsulates five concepts, then 5*6=30 relationships are created as each concept is related to each other concept. The increase in scalability is obvious. There are two paths that we can take in displaying these relationships to the end-user.

1. Inject a reference to each related concept
This means that when a user views one of the concepts in our example, it will have at least 5 injected relationships - one to each of its four related concepts, and one to the Conceptual Overview. If we do something similar for Task Overviews, then we should expect a similar number of related Tasks

2. Inject the reference to the Conceptual Overview, and remove the list of related Concepts to one click's distance
This may be a better approach. In this approach we inject references to related Conceptual Overviews. The user can then access the related Concepts from the Conceptual Overview, which acts as a hub or a higher-order node.

I suggest that we take the second approach. A Concept topic could be related to more than one Conceptual Overview, potentially leading to a huge number of injected links if we were to go down the individual link path.

A similar approach can be used for Task Overviews. 

Task Overviews encapsulate processes - optionally sequential lists of tasks that are performed together. When a Task Overview is created Task topics are related to the Task Overview. We can inject a reference to the Task Overview in the individual Task topics. 

We could also inject a reference to the next Task in the Task Overview, if it is a sequential one. We would need to consider how to handle the case where a Task appears in two different sequential Task Overviews.


The effect of creating topic relationships based on Overviews is to establish something akin to a hierarchical view. 

Overview topics then become the higher-order view, and individual topics are subordinate.

In Browse Navigation lists, presenting the Conceptual and Task Overviews would provide a more structured view than simply a list of topics whose relationships are encoded within them. It synthesises a higher level of order and makes it apparent to the user up front, rather than requiring them to discover it through browsing individual topics. It also reduces a long list of tasks whose relationships are unclear to a list of Task Overviews that should map more closely to the user's problem space, rather than to an unstructured view of the solution space. It also solves the problem of hiding subordinate tasks which have no independent role outside of a specific process.

In the case where a topic exists that is not encapsulated in a Conceptual or Task Overview, we generate a compiler warning. This topic will still be discoverable through Search, but it will not be related to any other topic. It could still be presented in browse lists, by displaying all Overviews, followed by all "orphaned" topics.

The advantages of encoding relationships through this method of encapsulation in Overviews is the synthesis of a higher level of order. This brings more structure to the output and reduces the number of links per page for the user. It also brings consistency and automation to relationships between individual topics.

The disadvantage is that related topics are no longer inline, but are removed at a click's distance. 

On the balance the advantages appear to outweigh the change to the user browsing paradigm; especially given the decrease in manual linking and the increase in consistency.

Recommendation: Adopt the relationship model that uses Overview topics as node points, and inject references to the Overview topic into the individual topics.

References still need to be related individually and injected inline.

Once we get the prototype up, we need to examine the effect on topics that are tagged as cross-cutting technologies / concerns. If they are not included in Overviews that cross-cut tech/concern, then their discoverability is reduced.

At this point we are linking tasks up to Task Overviews, and Concepts up to Conceptual Overviews. 

This is the primary mechanism for relating topics.

Ad-hoc "peer-to-peer" linking is an exception.

Deferring.