The discription of the background above appears a little vague for my likeliness. Please allow me to recur on some of the points made.
Already from the title can be depicted what the suggestion is here: To integrate two bodies of work and to equal out their difference for mutual rapprochement.
In that sense the understanding of the case given is determined by the objects we are looking at: Is it to merge two up until now conflicting visions of a mapping inventory, or do we rather infer our approach from that case and generalise it into a strategy for not only federated geodata, but data catalogues.
Dig into https://github.com/ec-melodies for ideas.
Synchronisation is resourceful and always comes at a price.
Experiences from distributed systems engineering confront us with a high unlikeliness of successful easing here.
The challenges surrounding immutable infrastructure involve not the pattern itself nor the implementation in the runtime, but rather the process, human organization, and tooling that needs to be in place.
What Are the Central Challenges with Immutable Infrastructure?
The question may then transpose into how to express a shared understanding about (1) what a TransforMap Atlas is and (2) which minimal agreements have to be made for interoperability of those?
If you have read
you will have witnessed a report on how processual premisses give direction to such a synchronisation effort. Up until now I am only aware of
to tackle the organisational challenge imposed by merge conflict resolution.
Then instead of CKAN related solutions, we may also think of
Where do those go and how can they be kept useful for the wider context?
This can be automated.
I suggest we move the pieces of the conversation above which entail Librepay into a new topic.