Reason to Merge
As I understand it, the reason to merge use cases is to reduce the number we have to consider and explain in other activities (requirements gathering, evaluating technologies, explaining motivation in survey and roadmap...) and should occur where use cases are similar.
What Merging Means
I interpret "merging" a non-exemplar case into an exemplar one to mean that we ensure each technical point/challenge raised in non-exemplar is present in the exemplar. The non-exemplar use case is not removed from the Wiki, but we can use a single exemplar where that's convenient. Use cases are "similar" if they raise similar provenance issues for the relevant dimension.
Paolo's case highlights two challenges: (P1) the process of producing data can be heuristic, so you need to know the source process to know how trustworthy the data is, and (P2) the information about the source process relevant to judging trustworthiness is domain and context-specific, so provenance technologies need to support the inclusion of such data.
Olaf's case is primarily about declaring and filtering on sources of data in terms of providers/owners, but touches on similar issues, i.e. (O1) the process of filtering based on source itself should be apparent as the user may not want to rely on it, and (O2) what "source" means is different in different contexts so should be apparent.
To merge the use cases, I would suggest to Olaf adding explicit technical challenges translated from Paolo's case. For example, first, it could be added to (O1) that the filtering process is based on information from the user about which source is trustworthy, and this may come from either good, extensive or irrelevant, minimal prior experience. Second, it could be added to (O2) that the different forms of provision and ownership of data (e.g. copied freely or under some license, directly or through a chain of many owners) means that the meaning of "source" must be apparent in each individual case.