TMRM Exegesis: Maps and Merging

Continuing with our tour through the TMRM we can now look into complete maps. Once we have namely collected a number of TMRM proxies into a set, we can actually call that already a subject map.

A decent implementation of subject maps will maybe take care that every proxy label used within a proxy inside a particular map has a corresponding proxy in the same map, but the TMRM itself does not concern itself with this.

Generic Merging = Set Union

Since at this level maps are simply sets, we can use the set operations intersect and union to build new maps. In both cases no special magic (such as merging) happens: Proxies are only regarded to be the same if they are actually identical, i.e. have exactly the same properties.

So even if we know that two proxies are about the same subject, they will remain separate, such as

A0FCBED := { shoesize => 42, beard => white }

CFE14CD := { shoesize => 42, beard => long }

I use here artificial labels such as A0FCBED for demonstration only.


Only if --- from a particular point of view --- two proxies should be regarded the same, then merging will have to be considered. From an abstract point, merging has nothing to do with two or more maps. It is a process which conveys a certain view of an existing map.

To model the whole process formally, TMRM first requires an application to detail the proxy merging. That itself has two aspects:

  • should two particular proxies be merged or not, i.e. should they be regarded equivalent?
  • and if so, how would a resulting, combined proxy look like?

Both aspects are represented in the TMRM via a binary operator between proxies. It returns a new proxy, but is only defined for certain pairs, i.e. those which should be merged. For all other pairs the operator remains undefined (partial operator).

Applied to our pair of proxies above, the result could be:

FDE78CC := { shoesize => 42,
             beard => white,
             beard => long }

but also

87A4FC3 := { shoesize => 4200,
             beard    => long-n-white }

or also

CC34AED := { chicken => runs-over-the-road }

There is no requirement in TMRM that the original properties are to be honored and will have to reappear in the merged proxy in some form. In some cases they might, in others, say, when merging geographical regions, the computation to arrive at a new region perimeter can be quite complex.

And there is also no requirement that the decision whether to merge proxies in the first place is only based on properties or property values of the two proxies involved. The merging operator can also depend on knowledge from an --- otherwise unspecified --- environment. In practical terms that might be an external lookup database.

Merging = Projection

Once such a merging operator is defined (the TMRM calls it bowtie), then it is used to look at an existing map. With these glasses on, some proxy sets will collapse into one merged proxy, others will be left alone. The end result will be a new map, implicitly connected to the original one via the glasses, i.e. that particular view.

It is worth noting that with such a merging projection all existing statements where the unmerged proxies are involved remain untouched. There is no magic relabeling done behind the scenes in that a new, merged proxy replaces all its original unmerged proxies everywhere in the map.

This is to keep the view as truthful to the original map as possible. If an implementation needs such relabeling, then it has to do that in an additional step not detailed by the TMRM. But it has to be a conscious decision as it may potentially distort existing information.

Full Merge = Rien ne va plus

After a view of a particular map has been computed, the same (or a different) merging operator can be used again. The process of view projection can be repeated until no further merging can be detected (fully merged map).

Posted In