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
These migrations add the contact data from CLB production that was modified in
that app during the time it was available. These migrations perform the
following actions, in the specified order:
1. Delete all contact data for the 8 modified sites
2. Import the data extracted from CLB production for the relevant organisations
Done in separate migrations for worship and non-worship organisations.
3. Correct a phone number literal that contained spaces for some reason
Add the migrations to create the necessary memberships for the newly added
municipalities and OCMWs. These new organizations were added as part of a hotfix
after the memberships were added to development. Consequently, the migrations
inserting these organizations are performed **after** the migrations introducing
membership data. Therefore, we need to add some additional migrations
specifically for these new organizations.
When removing memberships some `org:hasSubOrganization` or `org:linkedTo`
triples may remain in the triplestore. These migrations add jobs to delete such triples.
Triples for the predicates `org:hasSubgOrganization` and `org:linkedTo` are
produced by OP for other apps to consume. Therefore, they should not be deleted.
These two migrations were accidentally placed in the `migrations` folder instead
of the appropriate `2024` subfolder. These migrations have already been executed
on all environments.
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.
