The vision is (in Dutch, unfortunately) well summarised in https://lokaalbestuur.vlaanderen.be/gelinkt-publiceren-en-melden, the video. Also some information here: https://www.vlaanderen.be/agentschap-binnenlands-bestuur/blikvangers/lokale-besluiten-als-gelinkte-open-data These were the initial seeds; the project has grown in scope. Even though some of the initial goals still need realisation.
Development here is heavily data-driven. Data sharing between applications only work if data model is shared Hence the importance of data models. Always remember: if you dive into code for the first time, try having a clue about the underlying data model. Code is about managing data.
Unfortunately, not all data models are equally well documented. Not all documentation is in sync with the actually used model. There are official, unofficial and internal models.
So your control flow might look like this: official model? -> unofficial model? -> internal model? -> explore data. And even if you found an official model, you should explore the data to account for subtle differences.
Digital Vlaanderen manages the official models through an OSLO process; more (general) info may be found: https://data.vlaanderen.be/
But here is already some overview of the most important models.
Note: Once we deviate from official models, there needs to be more consistency in how these are published. I.e. They might have a separate page, a diagram somewhere, a readme in a repo or even the API-definition in mu-resource. Be bold and ask where to start.
Useful for mandatarissen module in loket and mandataten databank. https://data.vlaanderen.be/doc/applicatieprofiel/mandatendatabank/
Most useful in loket, module 'inzendingen voor toezicht'. Also Gelinkt-notuleren of course (official) https://data.vlaanderen.be/doc/applicatieprofiel/besluit-publicatie/ (unofficial extension) https://lblod.github.io/pages-vendors/#/docs/submission-annotations (internal, yet not so internal anymore extension) https://cloud.ruizdearcaute.com/s/sTXacrBtoDW3Rj5 mainly in use for the 'automatic submission'
Module 'eredienst mandatarissen' in loket and app-worship-organisations (unofficial extension) https://app.diagrams.net/#G1F2AWVdZbTR57WrDd7nX0ZEFo3BJAq6xQ
Module leidinggevenden in loket https://github.com/lblod/app-digitaal-loket/blob/master/config/resources/slave-leidinggevenden-domain.lisp
(to become official) https://test.data.vlaanderen.be/doc/implementatiemodel/ipdc-lpdc
background jobs (mainly harvester) https://github.com/lblod/job-controller-service
Note: Not everything is listed. Most can be logged in by using the mock-login: http://app/mock-login
Most production links you can get by replaceing lblod.info' by vlaanderen.be
qa: https://loket.lblod.info user manual (and other things) https://app.gitbook.com/o/-MP9Yduzf5xu7wIebqPG/s/-MUxLEJUEskn-COptDln/
qa: https://besluiten.abb.lblod.info/ backoffice app to check incoming decisions
The decisions aggreaged for the citizens qa: https://besluiten.lokaalbestuur.lblod.info
Backoffice app for decisions of erediensten qa: https://databankerediensten.lokaalbestuur.lblod.info
Public app for the citizens to check non-political positions qa: https://leidinggevenden.lblod.info/
Public app to check the political mandates. Q: https://mandaten.lokaalbestuur.lblod.info
Public repository (mainly SPARQL endpoint and subject pages) where public data is published as RDF Used mainly by vendors to re-uses the data. (Throw a SPARQL at it, gets triples back) qa: https://centrale-vindplaats.lblod.info/sparql
Just fronted app with extra documentation for vendors. It might be a handy resource. prod: https://lblod.github.io/pages-vendors/
App used to scrape (part) of the RDFa data published by local authorities. Feeds centrale vinplaats and later loket qa: https://qa.harvesting-self-service.lblod.info
The stub app used as a tool by vendors to test their integrations (for a subset of loket modules) Q: https://api.loket.lblod.info/
POC'ish app used as an experiment bed for building forms through a GUI Forms are an essential part of this project; we have a particular way of managing them cause there are many. It will become apparent over time. The form builder itself is experimental. The underlying technology (how they are defined) is production stuff. Q: https://poc-form-builder.relance.s.redpencil.io/
A central (internal) reports with SPARQL endpoint where data analysts can query data qa: https://qa.loket-data-warehouse.abb-bfg.s.redpencil.io
Extremely simple app, yet business critical for the correct working of the democracy. A form is hosted where citizens can make formal complaints. Q: https://qa.klachtenformulier.rpio-dev.s.redpencil.io
qa: https://gelinkt-notuleren.lblod.info/
Backoffice app, used as central endpoint to overview all organisations ABB must watch. Q: https://organisaties.abb.lblod.info
RDFa is a serialisation format for RDF, heavily relied upon in our exchange with data from local authorities (and thus vendors, i.e. 'software leveranciers') The spec may be found: https://www.w3.org/TR/rdfa-core/ The primer (less dense reading): https://www.w3.org/TR/rdfa-primer/ Playing (how RDFa converts to turtle): https://rdfa.info/play/ Real examples of playing with RDFa play
- from gn: https://publicatie.gelinkt-notuleren.vlaanderen.be/Linkebeek/Gemeente/fd144000-672f-11ed-aa41-655ffe22ddea/notulen
- from third party vendors: https://raadpleeg-aalst.onlinesmartcities.be/zittingen/21.1207.8069.1283/agendapunten/22.0202.7238.3495
Another serialisation format, which is used with some other third parties. It is easier to get started with if you are less familiar with RDF. However it has some serious potential drawbacks, hence we're not pushing it forward. Ony when the third party we're integrating with asks for it. https://json-ld.org/
Semantic web for the working ontologist.
get on top of your sparql to learn how to explore data. For backend services, you should learn how to enable the debug mode. Always have a working copy of your DB locally, so restoring issues is way faster