participant project contribution #223

This PR extends the mapping applied to the aggregator's DB content to include the individual montary contribution for each project partner, which becomes a property of the project - organization relation.

A side consideration: in case of false positives produced by the Organization deduplication, we might end up merging different relationships bearing this information. IT WOULD BE A MISTAKE TO MERGE THEM, therefore in case of such event, the most reasonable approach seems to be a conservative one: not set any contribution information.

This PR extends the mapping applied to the aggregator's DB content to include the individual montary contribution for each project partner, which becomes a property of the `project - organization` relation. A side consideration: in case of false positives produced by the Organization deduplication, we might end up merging different relationships bearing this information. **`IT WOULD BE A MISTAKE TO MERGE THEM`**, therefore in case of such event, the most reasonable approach seems to be a conservative one: not set any contribution information.

I think the PR can be merged. Only one consideration: you say that when more than one organization bring information about the funded amount it would be safer not to show any contribution. I think we should check if the funded amount is the same. In that case we can map that value. It is different if we have two values that are not the same. In this case why should collect them somewhere to be used to improve the deduplication. One more thing: we need to consider all the relations that will be merged together to be sure that only once the funded amount is occurring, or if more than once, all the times has the same value

I think the PR can be merged. Only one consideration: you say that when more than one organization bring information about the funded amount it would be safer not to show any contribution. I think we should check if the funded amount is the same. In that case we can map that value.

As a matter of fact, question is not limited to the presentation of the funded amount. Taking any action in case of wrong organization deduplication would always imply drawbacks on the aggregated views. The only case that would not be affected is limited to the occurrence of exactly the same amount, but I'm not sure it might happen, and if it does would be by pure chance.

It is different if we have two values that are not the same. In this case why should collect them somewhere to be used to improve the deduplication.

I agree it would be helpful, the information would need to be dumped somewhere in such cases, but we'd need to be alerted as well, otherwise I doubt anyone will ever take a look at such data.

One more thing: we need to consider all the relations that will be merged together to be sure that only once the funded amount is occurring, or if more than once, all the times has the same value

I'm not sure I get what you mean here. Can you elaborate?

Overall, I think we could proceed with integrating the changes as they are, I just want to include some more to-the-point unit test, while to evaluate how to proceed in case of wrong organization dedup, we can verify to what extent this will occur by querying the actual graph data as soon as this change will be shipped to beta and the 1st graph built.

> I think the PR can be merged. Only one consideration: you say that when more than one organization bring information about the funded amount it would be safer not to show any contribution. I think we should check if the funded amount is the same. In that case we can map that value. As a matter of fact, question is not limited to the presentation of the funded amount. Taking any action in case of wrong organization deduplication would always imply drawbacks on the aggregated views. The only case that would not be affected is limited to the occurrence of exactly the same amount, but I'm not sure it might happen, and if it does would be by pure chance. > It is different if we have two values that are not the same. In this case why should collect them somewhere to be used to improve the deduplication. I agree it would be helpful, the information would need to be dumped somewhere in such cases, but we'd need to be alerted as well, otherwise I doubt anyone will ever take a look at such data. > One more thing: we need to consider all the relations that will be merged together to be sure that only once the funded amount is occurring, or if more than once, all the times has the same value I'm not sure I get what you mean here. Can you elaborate? Overall, I think we could proceed with integrating the changes as they are, I just want to include some more to-the-point unit test, while to evaluate how to proceed in case of wrong organization dedup, we can verify to what extent this will occur by querying the actual graph data as soon as this change will be shipped to beta and the 1st graph built.

Labels Milestones

participant project contribution #223

Reviewers

Step 1:

Step 2: