Modeling Consensus and Disagreement

If you didn’t know it before, let me tell you that consensus is a big thing in Sweden. Looking in a dictionary, consensus is defined as “agreement among all the people involved” and it is rare for Swedes to leave a meeting room before it has been reached. Honestly, it’s to the point where meetings can become very tedious, but perhaps the inefficiency of the meeting itself is weighed up by the benefits of having consensus when leaving the room. I think the jury is still out on that one though…

When it comes to databases, there is an unspoken understanding that there is consensus among those who want to retrieve information from it. There is consensus on what the information represents, what it means, and which constraints are imposed upon it. But, can we be sure that is the case? Wouldn’t it be nice if we could write down a timeline where we could prove there are intervals of consensus interspersed by intervals of disagreement? How great would it not be if this was possible to deduce from the information itself?

This is where transitional modeling comes to the rescue. Let’s dig deeper into its two constructs, the posit and the assertion, which enable the modeling of consensus and disagreement. First, this is the structure of a posit:

[{(id₁, role₁), … ,(id_N, role_N)}, value, time]

Every id_i is a unique identifier, meaning that it uniquely represents a thing in whatever it is we are modeling. Once a thing has been assigned an id, it belongs to that thing alone for all eternity. In a posit, it is possible that id_i = id_j  but the roles must be unique. The value is either a primitive value or an instance of some complex data type. The time is either a primitive or a fuzzy value. Let’s clarify this by looking at some examples:

[{(Arthur, beard color)}, red, 1972-1974]
[{(Arthur, address)}, {street: AStreet, zip code: 1A2B3C, …}, 1972]
[{(Arthur, husband), (Bella, wife)}, <married>, 1999-09-21]

Posits do not differentiate between properties and relationships. They both share the same structure, but properties are easy to recognise since they only have a single role and id. The interval 1972–1974 in the second posit means that the information is imprecise, and expresses that since sometime within that interval Arthur grew a red beard, not that his beard was red between those years. If the color of the beard changes, a different posit would express this, along with the time the change occured. As can be seen, the address is a complex data type in the form of a structure. In the marriage relationship the angled brackets around the value <married> indicates that it is a complex data type, which in this example is a value from an enumeration.

The data types were picked specifically so that some parallels to traditional database modeling techniques can be drawn. That beard color is the name of an attribute in Anchor modeling, possibly on a Person anchor, of which Arthur is an instance having a surrogate key as the unique identifier. That address is a satellite in Data Vault, since the value structure is basically a bunch of attributes, possibly on a Person hub, where Arthur may have some hash or concatenation as its unique identifier. The marriage relationship is a knotted tie in Anchor modeling, where the knot constrains the possible values to those found in the enumeration, or a link in Data Vault, connecting Persons to each other.

Posits are neither true nor false. They just are. This is where the magic happens though. First, in order to be able to reference the posits, let’s give them some names. In practice these could be their memory addresses in an in-memory structure or some identity column in a database table.

p₁ = [{(Arthur, beard color)}, red, 1972-1974]
p₂ = [{(Arthur, address)}, {street: AStreet, zip code: 1A2B3C, …}, 1972]
p₃ = [{(Arthur, husband), (Bella, wife)}, <married>, 1999-09-21]

Now we introduce the positor as someone or something that can have opinions about posits. It could be a human, it could be a machine, or it could be something different, as long as it can produce assertions. An assertion has the following structure:

!(id, posit, reliability, time)

The id is a unique identifier for the positor who has an opinion about a posit. Positors are part of the same body of information and may be described by posits themselves. The reliability expresses with what certainty the positor believes the posit to be true and is a real value between -1 and 1. Finally, the time is when the positor is making the assertion. As it turns out, reliabilities have some interesting properties, such as it being symmetric and can be used to express opposite beliefs. Somewhat sloppily expressed, negative reliabilities correspond to putting a not in front of the value. For example:

!(Me, “beard is red”, -1, Now) = !(Me, “beard is not red”, 1, Now)

This comes in handy, since storing the complement of a value is often unsupported in information storages, such as databases. If another assertion is added for the same posit but by a different positor, it can express a consensus or a disagreement.

!(Me, p₂, 1, Now)
!(You, p₂, 1, Now)
!(Me, p₃, 0.75, Now)
!(You, p₃, 0.5, Now)

So it seems both Me and You are in complete agreement on the address of Arthur and we can declare consensus. However, Me thinks that there is a 75% chance that the marriage posit is true, while You only believe that the chance is 50%. Here some additional guidelines are needed in order to determine if this means consensus or not. At least it can be determined that we are not in complete agreement any longer.

You are, due to the symmetrical nature of reliabilities, stating that there is a 50% chance that Archie and Bella are not married. It is easy to be mislead into believing that this means it could be any value whatsoever, but that is not the case. You are stating that it is either “married” or “not married”, with equal probabilties, but the enumeration could contain an arbitrary number of values, each of which would be a valid case for “not married”, making “married” more likely than the rest. This is not the same as the following assertion:

!(Else, p₃, 0, Now)

Here Else is stating that it has no clue whatsoever what the value may be. This is useful, as it makes it possible to retract statements. Let’s say that Else also asserted that:

!(Else, p₃, 1, Before)

It seems there was a time before, when Else was certain that the marriage took place as posited. Now Else has changed its mind though. This means that Now there is no consensus, if we look at Me, You, and Else, but Before there was. The full treatment of posits and assertions is available in our latest paper, entitled “Modeling Conflicting, Uncertain, and Varying Information”. It can be read and downloaded from ResearchGate or from the Anchor Modeling homepage. There you can find how You can refrain from being contradictory, for example.