- Migrations to create the necessary merger change events that represent the
merger of several police zones into three new ones
- Migration to update the status of the merged police zones to not active
When new organisations were added for some merged municipalities (see PR #442)
their `org:hasSubOrganization` link with the province was inserted in to the
`<http://mu.semte.ch/graphs/administrative-unit>` graph instead of the
`<http://mu.semte.ch/graphs/shared>`.
Consequently, when logged in as a worship user and either of these
municipalities were selected in a form, the corresponding province was not
automatically filled in. This is due to the fact that worship users cannot read
from the `administrative-unit` graph.
This migration moves the appropriate `org:hasSubOrganization` triples to the
correct graph such that the behaviour for worship and non-worship users is the
same again.
These migrations insert the merger change events that are needed for the 2025
municipality mergers.
The migrations executed by the `migrations` service insert the actual merger
change events for
- mergers where the resulting organisation is a new organisation (these were
added earlier in #442);
- mergers where the resulting organisation is an already existing, active
organisation; and
- the special case where the municipality Borsbeek is merging with the
municipality Antwerp, thereby creating a new district Borsbeek.
The migration executed by the `migrations-triggering-indexing` service updates
the status of the necessary organisations:
- the new municipalities/OCMWs/district are set from "Being founded" (nl. "In
oprichting") to "Active"
- the other municipalities are changed from "Active" to "Not active"
- organisations that simply remain active before and after the merger are *not*
updated
Set the end date for governing bodies for municipalities and OCMWs that are
involved in a municipality merger *and* will become inactive to 02 January 2025.
For the municipalities and OCMWs that remain active after the merger, the end
date has already been set previously.
It seems there were language tagged and non-languaged versions used
for the skos:notation from ADMS:identifier.
This migrations alings it, we don't want typed strings here.
See also DL-6343
A number of APBs were accidentally `org:linkedTo` all municipalities in
municipality and an APB for which:
- the APB is linked to more than 1 municipality; and
- the municipality does not match that of the APB's primary site.
The first condition avoids we remove `org:linkedTo` triples for APBs that were
created by the users, as these are only linked with a single municipality.
Originally the starting dates for the new governing bodies for the new
legislature was set to `2025-01-01` for all relevant municipalities, OCMWs,
districts, and provinces.
These migrations change that to more correct starting dates:
* For organisations that are **not** involved in mergers the new starting data
is `2024-12-02`, the first day installation meetings are allowed[1].
* For organisations that are involved in mergers the new starting date is
`2025-01-01`, the first work day of the new year on which the mergers take
effect. Note: this migration assumes there are no other start dates on
`2025-01-01`, so the migrations have to be run in the specified order.
[1] https://www.vlaanderen.be/lokaal-bestuur/organisatie-en-werking/gemeenteraad/installatie
For each of the governing bodies created by the migrations in the previous
commit, now add the corresponding mandates and functions.
Within a organisation some governing bodies share the same mandates. For
example, for municipalities the governing body "Burgemeester" and "College van
burgemeester en schepen" both refer to the SAME instance of mandates for
"Burgemeester" and "Aangewezen burgemeester".
To achieve this the some migrations contain a second `INSERT` clause in which
the other governing body that contains the necessary mandates is selected to be
able to determine the correct mandate URI. This only works on two conditions:
1. Migrations that depend on each must be executed in the correct order. For
example, the migration inserting the mandates for "College van burgemeester
en schepen" must be executed after that for "Burgemeester". The former will
reuse mandates created by the latter.
2. The UUID for the shared mandates is calculated in exactly the same way in
migrations that depend on each other.
The merged OCMWs as imported in #442 were lacking some governing bodies that are
used to relation funcations to. These migration add the missing governing
bodies for these OCMWs.
These migrations create the necessary time specialised governing bodies for
municipalities, OCMWs, district and provinces for the next legislature.
The migrations work by creating a new time specialisation, with an appropriate
starting date, for each abstract governing body associated with an active
organisation. For municipalities and OCMWs some instances are explicitly
filtered, these are municipalities (OCMWs) that will be merged with another one
as of 01-01-2025 and therefore will become inactive. The listed
municipalities (OCMWs) are extracted from data provided by business.
The municipality of Borsbeek will merge with the municipality Antwerp as of
01-01-2025. This will result in a new district Borsbeek part of municipality
Antwerp.
This migration adds that new district such that a URI is assigned to it and its
governing bodies are created. The information available at this time is limited
its (legal) name. Other core data, such as identifiers, and further information
such as site addresses will be added later by business.
- The previous version of the migrations lacked the triple actually linking the
new organisations with the placeholder for SharePoint identifier. This triple
was now added.
- Ensure the timestamp prefixes are unique by adding 1 second delay in between
generating each migration.
As part of the municipality mergers for 2025, four new municipalities and their
corresponding OCMWs will have new KBO numbers. Consequently, these organizations
need to be fully manually created.
This commit adds the migrations to import the organisations for the merged
municipalities and OCMWs such that their URIs can already be shared among
applications.
The currently imported data concerns:
- core data such as (legal) name, region, status, KBO, and OVO number
- the necessary governing bodies, with as starting date 2025-01-01
The NIS-codes (and associated data) will be added in future migrations when the
NIS2025 update has been released.
Other missing data, such as addresses and contact details, will be added later
on by business.
The Vlaamse Gemeenschapscommissie is a special kind of administrative unit, with
its own specific classification code (which was added in a previous commit). The
core data, address, and contact information was provided by the business.
Note: currently the province in the address is intentionally left empty. This
data will be provided (or entered) later by business.
- add the missing original organisation and matching change event result to one
merger change event
- remove the superfluous merger change event, except for its reused change event
result
The original migration to import the participants for public OCMW associations
contained a bug causing it to not match municipalities. More specifically:
- the type triple for municipalities is located in the `shared` graph;
- consequently the `FILTER EXISTS` statements to limit matches to administrative
units could not succeed for municipalities as the queries are limited to the
`administrative-unit` graph.
This new migration fixes this problem by changing the `FILTER EXISTS` into a
`FILTER NOT EXISTS` to exclude resourses of type `ext:KboOrganisatie`.
The migration importing related organizations for public OCMW associations was
incorrect in that it did not exclude resources of type `ext:KboOrganisatie`
being matched. This migration removes all incorrectly inserted triples.
