Updated add province uri migration to avoid duplicates
Added a cleanup migration for adding province URIs to addresses
Updated the export,json config to expose the province URI of addresses
Fixing errors after review
Updated CHANGELOG
Refactored and corrected migrations, changed the timestamps
refactoring cleanup migrations
Refactored the cleanup add province migrations
Updated changelog to ensure db-cleanup-service picks up the new jobs.
The data on werkingsgebieden was largely duplicated across two graphs the shared
graph and administrative unit graph. Some exceptions were that werkingsgebieden
with level "referentieregio" were only in the shared graph, whereas
werkingsgebieden for new municipalities that resulted from the 2025 mergers were
only in the administrative unit graph.
This moves all the werkingsgebieden and their corresponding data to the public
graph, resolving the duplication in the process. Furthermore, the `public` and
`organizations` producers are update to only look in the public graph for
locations.
These memberships can be edited by users via the related organisations
page. If this data is kept in the read-only shared graph this leads to
unexpected behaviour when users (try to) remove such a membership. More
specifically, as the user has no write acces to the graph the request will be
silently ignored and the "removed" data will simply reappear after saving the
form.
As part of the 2025 municipality mergers some NIS2019 codes were linked to their
NIS2025 counterparts using `skos:narrowMatch` or `skos:broadMatch`, instead of
`skos:exactMatch`. Consequently, the initial insertion of the NIS2025 codes did
not update the NIS code for the werkingsgebieden linking to these.
The entries about the public producer changes accidentally ended up in the
v1.31.0 section but were not actually part of this release. This moves them back
to the unreleased section so they are correctly included in the next release.
A migration to flush the landing zones of consumers for bits of the data. Since this data is not actively maintained anymore by the producers, this might lead to obsolete information and confusion situations at the consumer side. Context: deploy story DL-6552
We do want to avoid inconsistencies popping up; i.e. bestuurseenheid
label gets upated, but that won't be reflected in the landing zone
since the information by the producers is not produced anymore,
potentially bringing very confusion situations
