Semantic Links

There is a rarely used feature in Qlik Sense called “Semantic Links”. Here’s how they work.

Normally, selections are made explicitly by clicking on the field values that are interesting. There is, however, also a way to make selections indirectly through semantic links. These are similar to field values, but with the difference that they describe the relations between the field values rather than the field values themselves.

A click in a normal field represents a selection in this field, whereas a click in a semantic field is a selection in another field.

Say, for example, that you have a table listing the US presidents as your data source:

Loading this is simple enough, and you can easily create a dashboard:

But navigating the data could be a challenge. Once you have a president selected, you may ask “Well, who was before him?”

But this question is clunky to answer. You will need to look at the sequence numbers of the presidents and manually select the the number previous to the possible one. Ideally, you should instead have some kind of navigational element that helps you select ‘successors’ and ‘predecessors’ directly.

Enter the Semantic Links.

The Semantic links are like fields but can never hold a selection – they can only perform a selection in another field. But that is exactly what you want! You want to click on ‘Predecessor’ and thereby select the person that was predecessor. So, if you have ‘Abraham Lincoln’ selected, and click on ‘Predecessor’, the engine will select ‘James Buchanan:

In QlikView, the Semantic links look like buttons in list boxes – they represent possible actions. In Qlik Sense they (erroneously) look like normal filter panes:

Note that ‘Predecessor’ is greyed out in the above picture, since George Washington didn’t have a pre­de­cessor. The action “select predecessor” isn’t defined for ‘George Washington’. Hence, the logical infe­rence works also for semantic links.

The semantic links need to be defined in the script: They are created by loading a semantic table containing the relations between the instances in a field – in addition to the data table itself.

The semantic table should contain exactly four columns. The load statement could be of the form

Semantic Load
   <Instance>                            as InstanceID,
   <RelationName>                   as Relation,
   <RelatedInstance>               as InstanceID,
   <InverseRelationName>      as Relation,
   Resident <Table>;

Note that field 1 and 3 are named the same and that field 2 and 4 are also named the same. Field 1 and 3 contain the IDs for the two records that have a relation, and they link to the data table. Field 2 and 4 contain the names of the relations and the names of the inverse relations, respectively.

The load statement in the “Presidents” example would be

This Load statement will produce the following table, where the first row defines the relations between president number 1 and president number 2, and the subsequent rows define the relations between the following presidents:

When this table is loaded with the “Semantic” prefix, the Qlik engine will use this information for the semantic links.

Alternatively, the Semantic load can have all four fields different. Field 1 and 3 are still links to the data table, and field 2 and 4 are still names of relations. But in this case the Semantic load produces two semantic fields instead of one. This enables you to use the names of the presidents as values in two fields “Predecessor” and “Successor”.

This would result in the semantic fields “Predecessor” and “Successor”.

Note that for this to work, you need to have an additional key field in the data table: “No as No2”.

Semantic links are rarely used today, but for some data models they are an excellent way of creating navigational elements. They are especially useful when handling hierarchies. But more about that in a later blog post.

HIC