The `shared` graph still contains some location triples introduced as part of
the municipality mergers. They were overlooked by the original cleanup
migrations because the `prov:Location` and `ext:werkingsgebiedNiveau` triples
were located in the `administrative-unit` graph, causing the `WHERE` clause to
not match these triples.
The initial version of the migration, incorrectly, inserted the triples linking
municipality and province locations in the administrative unit graph. This
corrects that behaviour putting the triples in the public graph along with all
location data.
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.
There is a 'double' instance of CKB Deinze in the database. One is active, and the other is inactive. This confuses systems, and it doesn't make sense that active organizations are linked (almost managed) by an inactive organization.
* Insert suborganization(s) belonging to non-active org to the active one
* Insert new membership belonging to the suborganization(s) and active org
* Delete memberships for non-active org
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.
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
`MaxConstructTriples` needs to bumped to the same value as `ResultSetMaxRows`
since `virtuoso` will check the value of the former variable first. By setting it
to 10000, we were severely limiting the number of triples that can be constructed.
The governing bodies for an AGB have the same legislature as the corresponding
municipality. This adds new time specialised governing bodies for the
new (current) legislature for Raad van bestuur and Algemene vergadering.
The governing bodies for an AGB have the same legislature as the corresponding
municipality. This sets the end date for the existing Raad van bestuur and
Algemene vergadering governing bodies.
For new frontend functionality concerning local involvements a worship user
should be able to read the status for municipalities and provinces. This
migrations moves these triples to the shared graph such worship users have read
access. The status for municipalities and provinces cannot be changed by users
so no write access is needed.
