Outcome-Based Method for Identifying Problem Similarity

How To Find Similar or Identical Problems on The Map, matters.global, mapsmap and other connected problem graphs/maps.

Outcome-Based Method for Identifying Problem Similarity

This article is part of a series on building The Map, a map of the world’s problems, developed by the mapsDAO community. The first part contained a draft of the basic building blocks of the protocol and its architecture. This part shows how the system deals with similar, identical and potential duplicate information.


In any decentralized and crowdsourced system, information overlap is a major problem. How do you identify duplicate or very similar information? One approach is to systematize information and find duplicates by looking at all members of any given category of the system. Another approach is to use outcome-based methods to identify similar and duplicate information.

Defining Problems in the MapsDAO protocol

Problems are defined by users of the system and written to a blockchain. Connections between problems emerge from the specific properties of the problem definitions. You can read more about how this works in the first part of this series. A problem is defined by creating a description of the problem and a set of conditions that need to be met in order to consider the problem solved. You can think of this set of conditions as future desired states of the world. Once these states are reached, we can consider the problem solved.

Problem Similarity via Solution Conditions

In such a system, two problems can be considered identical, if their sets of conditions are identical. The descriptions of the problems do not matter in this case, because the desired outcome of solving the problems is identical.

If the sets of conditions are overlapping but not identical, the two underlying problems are similar but not duplicates.

The degree of certainty in defining similarity is varying with the hardness of the conditions used and increases the more conditions are needed to consider the problem solved.

Take for example a condition that references an outside oracle, for instance a KPI published by a government agency (i.e. “Percentage of obese adults in US population”). Any condition based on this data will be easier to evaluate than say a vote of a panel of experts. But taken by itself only, such a condition cannot be used to establish similarity or identity, i.e. many problems can have the desired outcome of a less obese population. However, by looking at sets of conditions, these problems are mitigated. 


Looking at the effect on the overall system that the solution of a problem has, can provide great insight into their similarity or identity. The mapsDAO protocol enables this kind of approach via its sets of conditions that form part of the problem definition.
You can join the mapsDAO community here.