Coherent Cooperative Games – Modeling with confidence

Coherent Cooperative Games – Modeling with confidence

Much of our research at Viev has gone into a class of game called a Coherent Cooperative Game. As the name suggests, the game is one that is played with Coherence and Cooperation between the players.

We will get back to Coherent Cooperative Games (CCGs), but best to first describe the context in which we speak and what is not a CCG.

The modeling function, using methodologies such as Fact-Based Modeling (FBM), is inextricably intertwined with the workings of logic. Languages such as Object-Role Modeling (ORM) work under First-Order Logic (FOL). While, naturally, the models produced as an end result of the modeling function must be logical, the question arises “Logical to who?” and “In what context?”.

Both are relevant questions in a modeling and mathematical sense, as we shall see.

The Context of Modeling

Anyone who has worked in large corporate environments and for long enough knows the scenario well. A person responsible for modeling solutions and defining architecture holds a great deal of knowledge and relative power. Their decisions influence the outcome of programmes and projects. Their decisions define the context of future discussions about the solutions and architecture they define. When that same person hogs (does not readily share) knowledge to the detriment of other people reliant on that knowledge, the gap in relative power is broadened. Often this lack of knowledge sharing is to the detriment of the entire organisation, but profitable to the player who holds the knowledge.

While a scenario well known and appreciated by those who do feel the affects of knowledge withheld, we speak here of a paradigm which closely matches that which may be modelled under the mathematics of ‘games’.

A deepening of the scenario more closely reflects that experienced by modelers at one time or another, and we will give it a name, “You don’t understand what I am talking about” or ‘YDUWIATA’. In this scenario, those responsible for modeling solutions and defining architecture not only disadvantage other players by not sharing knowledge, but gain a secondary psychological payoff by somehow making other players feel stupid. This may be done by drawing incomprehensible diagrams or writing documents that are equally incomprehensible or vague, leaving others to their own devices to try and decipher the meaning of the shared knowledge in order to fulfil the goals of a programme or project. In essence, the YDUWIATA player is neither playing a ‘Coherent’ or a ‘Cooperative’ game. Often making no effort to make themselves understood YDUWIATA players effectively win at their own game. All very good if you are the YDUWIATA player, but we propose that YDUWIATA players ultimately disadvantage a practice and themselves.

Modeling languages such as ORM, on the other hand, and some would argue, the UML, have been designed to disambiguate knowledge sharing and to assist in the capture of knowledge as ‘meaning’. That is, those languages have been designed to reduce incidence of disparate knowledge of a domain, by documenting and sharing that knowledge in a common format readily understood by all players.

The scenarios painted above frame a well understood paradigm of where models are shared, often unsuccessfully, but where the paradigm is perhaps not so well understood as being a game. The context of what we cover in this work is knowledge sharing by way of models, and in the context of ‘games’.

Why Games?

It is easy to recognise within the scenario proposed above, that some sort of game is being played by the knowledge-hogger. As humans we readily recognise the concept of ‘payoff’, and the payoff within the scenario is that of holding influence-power and, in many cases, a higher salary without any of that being shared with other players. Arguments as to whether either are deserved by the player are outside the scope of this work, but undoubtedly any player that actively wins at that kind of game…has played a winning strategy…for them.

Outside the world of logic and mathematics, psychologists refer to a game as a series of moves that have a gimmick or payoff, like tricking someone. YDUWIATA has the gimmick of the YDUWIATA player never revealing what they are truly talking about, if even they know themselves, and a payoff of holding relative power.

Mathematical games have very similar terminology and model ‘real-world’ games in many respects by default. So much so, that we use them here to describe a paradigm and to design a way forward that works for all players.

Indeed, we have already introduced within this text many of the terms common to both psychological and mathematical games. ‘Payoff’, ‘knowledge’, ‘sharing’, ‘withholding’, ‘players’. These are all terms found equally within games people play and mathematical games.

It is not the purpose of this work to analyse why there is such similarity between games people play and mathematical games, but enough to say that the whole sphere of mathematical games burgeoned from modeling real-world scenarios of games that people do play (e.g. poker, war-games).

The purpose of this paper is to focus on a specific class of games, Coherent Cooperative Games.

Games and Pay-off

To cement that “what we do when we model” is to play a game, we refine what we are talking about.

Firstly we restrict ourselves to ‘data modeling’. Although the theory is extensible to ‘process modeling’, that is not what we focus on here.

Secondly we restrict ourselves to a specific class of data modeling; modeling in First-Order Logic (FOL).

If you use a modeling language such as ORM, you are already working under FOL, and each ORM Model that you produce is reproducible as a set of sentences in FOL. This was proven in the thesis that first formalised ORM; Dr Terry Halpin’s doctoral thesis, "A logical analysis of information systems : static aspects of the data-oriented perspective".

We then introduce the notion that “It has already been done”. Sharing an ORM Model between two players is the equivalent of playing a modified mathematical game known as an Ehrenfeucht Fraisse Game (EFG or EF Game).

Within an EF Game one player shares a series of mathematical sentences with another player without telling them what language they are using. It is the objective of the second player to either identify the language in use, or find an interpretation under another mathematical language which suitably fits the set of sentences received.

The second player is called a ‘duplicator’, because if they find conforming structures within a language other than that actually being used by the first, they achieve the payoff of ‘winning’ the game.

In layman’s terms, when you share an ORM Model that you have produced with someone, you do not expect them to have an interpretation other than the one you have, and you certainly do not expect them to spoil the show by finding some interpretation of your model that has a completely different meaning, but which is also consistent with the diagram that you have shared with them.

i.e. The whole idea of sharing ORM Models is that there is only one correct interpretation of the shared model, under the rules of ORM. We do not diverge here into the possibilities of one or both of the players involved simply not knowing the rules of ORM.

i.e. ORM, as a language, was designed such that all players ‘win’ when they share a common understanding of ORM when interpreting models shared under ORM. EF Games, on the other hand, are ‘win-lose’ or what are known as zero-sum games, with a winner and a loser.

In the main scenario painted at the beginning of this work, at least some kind of win-win is taking place, unless an architect’s knowledge-hogging eventually leads to the collapse of an organisation (win-lose), and by that we cement the notion of a game being played when knowledge is shared (or not), and that of there being a ‘payoff’.

Zero-Sum Games, EF Games and “What is going on?”

In the scenario we first painted, especially where a player plays WDUWIATA and produces incomprehensible diagrams, we paint a scenario that approaches a Win-Lose or Zero-Sum game. One player wins, while the other player effectively loses. Quite obviously this cannot be good for business (in the long term) or for sharing models.

When data modeling, and especially when data modeling, it would seem apparent that the aim of the game is to have a win-win scenario. When data modeling is concerned we want other players to know exactly what it is that we are talking about. Data modeling is a form of communication, and communication comes at a cost unless the sender and receiver share a final model that approaches the notion of having a single shared model of the Universe of Discourse (UoD) between the sending and receiving party.

Let us, for example, take a scenario where a modeller only models for themselves. e.g. They may be documenting a system that they are working on for later reference. It seems obvious that, being both sender and receiver of the model, the modeller has a clear intention of achieving clarity over a model and with one singular interpretation. Otherwise the modeller would not be able to go back over old documentation of a model and understand what it is they have modelled.

The same is true when more than one player is involved. The objective is to share a model under a clear communication, in what we are calling a ‘game’, and by one that is not an EF Game. i.e. The sending party does not want the receiving party to have any interpretation other than the one that they have.

NB We do not say, “The sending party does not want the receiving party to have any interpretation other than the one that they intended”, because in mathematics, logic is extensional, not intentional. The sender may very well intend one interpretation, but by extension, the receiving party may find another.

Which leads to the question, “Well, what is going on when we share models?”.

If we limit ourselves to the sharing of ORM Models, we have a scenario where both the sending and receiving party must have a working knowledge of ORM to both interpret a shared ORM Model in the same way. The process of sharing a model is one of delivering the structure of a model from the mind of the sender to the receiver. It is knowledge sharing, while working under the guise of a win-win game where both sender and receiver have a working knowledge of ORM.

Coherent Cooperative Games

If I develop an ORM Model and share it with you, and both you and I have a working knowledge of ORM, and we both interpret the ORM Model in the same way, then at the very least we play a ‘Coherent Game’. I am not holding back and knowledge about the UoD. And we both effectively ‘win’ in a win-win game by interpreting the model in the same way when that game is ‘Cooperative’.

But is there a missing piece?

There is, believe it or not, when we do not acknowledge that which we most often do unconsciously when receiving a model for interpretation.

If I already know what an ORM Model looks like, and I find a piece of paper lying on the ground in a park somewhere with an ORM Model drawn on it, I would likely say, “Ah, that is an ORM Model” and likely then go about interpreting the model.

If I know what ORM is, and know the rules of ORM and interpret the model under the rules of ORM, most often I unconsciously forget the step of identifying that what I am looking at is an ORM Model.

But if I knew nothing of ORM or what the symbols on the piece of paper meant (under ORM), then I would be none the wiser and likely to find the diagram as cryptic as any hieroglyphics was to an early archaeologist. I might interpret the diagram in a completely different manner than that which was ‘intended’.

In that scenario, the game of communication lacked ‘Cooperation’. I did not interpret the model under the intended language.

We can go one step further, where I do know what an ORM Model looks like, I do understand the rules of ORM, and then go about interpreting the model with some other set of rules. i.e. I am deliberately not cooperating.

So, we introduce the notion of Coherent Cooperative Games (CCGs) to data modeling as a means of defining that which we intend to achieve under the guise of 'Data Modeling'.

A Coherent Cooperative Game is one where: 

“If you play, there is only one kind of play, and that is on each play you must play such that the other player wins”.

To achieve complete Coherence, we would send, with each ORM Model, a descriptive text reading: “This is an ORM Model”, such that the receiving party would know what it is they are looking at, and that of course, relies on the receiving party being privy to one other language; in this case, “English”.

While that might sound like overkill, the writer invites the reader to download one of the many documents intended to define the UML modeling language, and where those documents contain such statements under a diagram as “A diagram of <such and such>”, without defining what kind of diagrammatic language the diagram is drawn under leaving the reader none the wiser as to where to begin to interpret the diagram; all of which is as cryptic as saying “I’ll teach you another language, by speaking in that language and only that language and won’t even tell you what that language is”.

While CCGs might sound like common sense, how many times when modeling have we heard the extrapolation of YDUWIATA…i.e. “You don’t understand what I am talking about”? There are also those that argue of common sense that nothing is less common. We argue here that both positions are to be avoided at all costs within your practice.

Adopting Coherent Cooperative Games

If we take as a premise that all of data modeling should be defined as a win-win game, where all players win by sharing a common understanding of what it is that is being modelled, here are a few steps to improve the Coherent Cooperativeness of your organisation and practices:

1. Promote Coherence: Share knowledge of the Universe of Discourse openly and actively. Do say “This is an ORM Model of <such and such>”

2. Promote Cooperation: Provide ready access to material so that all players can learn the languages under which you model;

3. Promote Win-Win: CCGs have only one play, and that is that on each play you must play such that the other player wins. Do not hog or withhold information. Do share openly and actively. Make sure you are playing such that the other player wins.

Implement these practices so that you and the others that you share models with may model with confidence.

What makes Coherent Cooperative Games different?

If we accept that the practice of sharing data models under the framework of 'Data Modeling' is a game, and one that is played most seriously by data modeling professionals, CCGs differ from almost all other games. While all games have a payoff, nearly all games have a winner and a loser. CCGs on the other hand enforce payoffs where all players are winners.

Further use for Coherent Cooperative Games

In a later work the writer will share the knowledge of use of CCGs to achieve the sharing of any language that can be interpreted under FOL, under one language of FOL. E.g. Sharing Entity Relationship Diagrams under the metamodel of an ORM Model.

i.e. CCGs have mathematical application beyond the social application of achieving data modeling prosperity.