Add election results for lists, not just candidates

[piemonkey]

Overview

The model for this is very basic and is basically a hack to get this stuff to work. The results themselves come from extracting the relevant parts from a csv of the raw election results and processing them into a ttl. The only way to validate that the results are the expected ones is by matching multiple strings as we have no identifiers to compare to.

Draft as I'm unsure about the data and it needs a frontend release.

connected issues and PRs:

Jira ticket: https://binnenland.atlassian.net/browse/GN-5315
Corrects: lblod/frontend-gelinkt-notuleren#784
Frontend PR: lblod/frontend-gelinkt-notuleren#790.

Setup

Needs to be tested with a version of the frontend that uses the data.

How to test/reproduce

In the frontend, check that syncronisation works and produces the correct ordering based on fracties.

Challenges/uncertainties

Why do we not have this data in a linked format?!?

Checks PR readiness

• UI: works on smaller screen sizes
• UI: feedback for any loading/error states
• Check cancel/go-back flows
• Check database state correct when deleting/updating (especially regarding relationships)
• [x ] changelog
• no new deprecations

[abeforgit]

I'm a bit surprised by the structure, it seems you duplicate a lot of info we already have
is there a reason you're not just attaching the new "stemcijfer" information onto "Kandidatenlijst" instances we already have? (e.g. http://data.lblod.info/id/kandidatenlijsten/ae8bb367-6abc-4fa6-98be-88a438280d7c)

[piemonkey]

I'm a bit surprised by the structure, it seems you duplicate a lot of info we already have is there a reason you're not just attaching the new "stemcijfer" information onto "Kandidatenlijst" instances we already have? (e.g. http://data.lblod.info/id/kandidatenlijsten/ae8bb367-6abc-4fa6-98be-88a438280d7c)

I did it this way to as much as possible separate this essentially unlinked data from the actual linked data in the triplestore. If we do the matching by names and create actual links from it, I worry that it will be mistaken for data that is based on something more than 'hey these names are the same, they must be the same'. So, I decided to do all the matching in the queries instead, so that it's clear where they're coming from.

[abeforgit]

ok fair, but still I feel its a lot of data we don't need? like all the names and such

[abeforgit]

we could also keep it in a separate graph to make sure we know where it's coming from

[piemonkey]

I suppose I could remove the extra data. I included as I was worried that I'd need to do more to validate that I've got the correct result. I guess we should add back in if it turns out to be needed.

[abeforgit]

still lots of duplicates:

<http://example.com/kieslijst-result/10000> a ext:KieslijstResult ;
    ext:kieskring "Grimbergen" ;
    ext:lijst "SamenGrootGrimbergen" ;
    ext:stemcijfer 1856 .

<http://example.com/kieslijst-result/10001> a ext:KieslijstResult ;
    ext:kieskring "Grimbergen" ;
    ext:lijst "SamenGrootGrimbergen" ;
    ext:stemcijfer 1856 .

<http://example.com/kieslijst-result/10002> a ext:KieslijstResult ;
    ext:kieskring "Grimbergen" ;
    ext:lijst "SamenGrootGrimbergen" ;
    ext:stemcijfer 1856 .

<http://example.com/kieslijst-result/10003> a ext:KieslijstResult ;
    ext:kieskring "Grimbergen" ;
    ext:lijst "SamenGrootGrimbergen" ;
    ext:stemcijfer 1856 .

<http://example.com/kieslijst-result/10004> a ext:KieslijstResult ;
    ext:kieskring "Grimbergen" ;
    ext:lijst "SamenGrootGrimbergen" ;
    ext:stemcijfer 1856 .

<http://example.com/kieslijst-result/10005> a ext:KieslijstResult ;
    ext:kieskring "Grimbergen" ;
    ext:lijst "SamenGrootGrimbergen" ;
    ext:stemcijfer 1856 .

<http://example.com/kieslijst-result/10006> a ext:KieslijstResult ;
    ext:kieskring "Grimbergen" ;
    ext:lijst "SamenGrootGrimbergen" ;
    ext:stemcijfer 1856 .

<http://example.com/kieslijst-result/10007> a ext:KieslijstResult ;
    ext:kieskring "Grimbergen" ;
    ext:lijst "SamenGrootGrimbergen" ;
    ext:stemcijfer 1856 .

<http://example.com/kieslijst-result/10008> a ext:KieslijstResult ;
    ext:kieskring "Grimbergen" ;
    ext:lijst "SamenGrootGrimbergen" ;
    ext:stemcijfer 1856 .

<http://example.com/kieslijst-result/10009> a ext:KieslijstResult ;
    ext:kieskring "Grimbergen" ;
    ext:lijst "SamenGrootGrimbergen" ;
    ext:stemcijfer 1856 .

[elpoelma]

I indeed understand not wanting to store this as linked data, as it is created by matching the names of the municipalities and candidate-lists. Of course, this is also (kind of) the way LMB must have converted it too linked-data, so...
Whether we link it or not, based on this data a lot of legal documents are created anyway, so I don't really see why we shouldn't link it.
Additionally, I would indeed also link these results only the the candidate-list names and muncipality names, and not the candidates themselves.

[abeforgit]

suggestion: if you preprocess the excel to have only one row per result we need,
and then after inserting run something like:

SELECT count(distinct ?result) WHERE{
?unit a besluit:Bestuurseenheid.
?unit skos:prefLabel ?unitName.
?fraction org:linkedTo ?unit.
?fraction ext:geproduceerdDoor ?candidateList.
?candidateList skos:prefLabel ?listName

?result a ext:Kieslijstresult.
?result ext:kieskring ?unitName.
?result ext:lijst ?listName.

}

you should then get the same count as the amount of rows in the excel I think

[piemonkey]

still lots of duplicates:

Fixed.

[elpoelma]

I think these migrations will work as expected. Just some side notes:

• We seem to be targetting fracties/kandidatenlijsten in general here, and not for a specific legislative period. This should however (in practice) not be a problem, as fractions/kandidatenlijsten of previous periods do not have the ext:geproduceerdDoor link, so we only target the next period anyway.