LPDC vanuit Loket voor Lokale Besturen
Project in collaboration with Digitaal Vlaanderen, ABB and VVSG
Problem & Context
Problem to solve
Governement provides products and services to the public and needs to communicate these. Both on a local level, and on a inter-governmental level. These products and services are often analogue, sometimes they vary. They are inspired by Federal or Flemish law, or local law.
As you understand, this is a time consuming process that misses continuation due to a lack of capacity or need to focus.
For the Flemish government the IPDC, containing both local and Flemish products and services, is hard to mainain, as there is no overview of all local services provided by individual governments.
Therefor, a new IPDC process serves next principles:
Up-to-date: by using LBLOD building blocks, we ensure an up-to-date process for the product catalogue as making a besluit regarding a product/dienst is legally mandatory. This is obtained by enabling LPDC within loket for Lokale besturen to provide input to IPDC, Besluitsjabloon and local websites or LPDC-catalogues.
one-stop-input : Local governments need to manage and publish products, this content is relevant in local, inter-governmental and other media elements. Moreover products & services are decided by local government entities (i.e. besluit van een gemeenteraad), where variables should be in line with the product definition.
hedge / deadline : a European Verordening dictates the obligation to inform about the basic services/products of all governments before early December 2022. (Single Digital Gateway or SDG) To conform to this information need, Europe obliges local governments to post the relevant product information on a portal (i.e. youreurope.eu), in English. As such translations are to be provided with respect to the local "taalwetgeving".
Key results
Value chain(s)?
What to measure?
How many % of our userbase is using it?
How many local copies of products and services are created?
How is the distribution of that number over all users?
How many drafts are there vs how many published?
How many fields get changed, by how much (on AVG)?
How is the distribution of that number over all users?
How many services are created from a vierge template?
How many make it all the way to a publish version?
How many new services were added to the IPDC (per timeframe)
How many users can publish all the mandotory services?
Context
In figures: Over 300 local authorities will start to make instances based on concepts. Not all concepts are ready yet, but in total we envisage 150 concepts within SDG.
Assuming local authorities will have 50 products/services to documentate, we reckon to manage around (300*50=) 15.000 instances.
Assuming local authorities will have 150 products/services to documentate, we reckon to manage around (300*150=) 45.000 instances, only for SDG products/services.
Core concepts
A service or product is described through a product card (fiche), having a title, description and more.
A product card is normally defined within IPDC, and contains the name of a service / product and some standard provided information. This is called a concept.
User value
Based on this concept, a local authority can start to define it's own derived products/services, (though the product fiche has always the same structure):
Or by integrally take the concept and add some local parameters (e.g. location or price)
Or by changing more aspects.
When saving an adapted and filled-out concept locally, the document turns into a local instance of the concept.
Requirements
IPDC collects flemish products/services and local products/services. As such, IPDC wants to collect new LPDC products as instances of a concept.
If a concept doesn't yet exist in IPDC (LPDC). A local authority (LA) can make it's instance based on a vierge product fiche concept template. It will be used as a new concept for other local authorities when syncing the LA-LPDC with IPDC.
For SDG concerned services, a translation is provided within the concept, but each local authority may differ from it.
Some products and services are mandatory to provide for a local authority, some are optional. e.g. Issueing an e-id card is mandatory, having a LEZ is not.
An instance has several statusses, as a "besluit", i.e. draft, geaggendeerd, published. We should re-think the Gelinkt Notuleren wording of "concept" in order not to spread fog on the "concept" word (as draft is concept in gelinkt notuleren).
An instance will need versioning. Basically the versioning concerns a published version, while a preperation is made for a new published version, being a draft. Alternative: none or cloning an existing instance and rename it. (Though the URI will differ)
Categorisation of products and services
A. Categories
Each theme collects sub-categories to categorise products/services offered by governments. e.g. D. Verblijf in een andere lidstaat
A product or service offered by a local government could be linked to a category or sub-category. A (sub-)category can contain multiple products and services
Linked to a category? it concerns a "basic service" and it should be published to the youreurope-portal in English via LPDC to IPDC to the youreurope-portal.
Not linked to a category? it's not part of the deadline, though we should envisage in 2nd run to collect the product information in order to complete our LPDC/IPDC.
B. Target audience
In the impact mapping of "Kwaliteitsvolle besluiten" there is a difference between services focussing towards organisations/bedrijven, and services for citizens (burgers)
Technical context
We agreed to use the "ICEG" datamodel for this. ICEG is a collaboration between Flemish and Federal government bodies regarding standardisation. (see https://dt.bosa.be/nl/over_bosa/nieuwsberichten/iceg_werkgroep_datastandaarden_levert_eerste_resultaten_op) There is a process going on to transform this ICEG datamodel for services/products to an OSLO-counterpart.
ABB focuses on LPDC within loket, and the data synchronisation towards and from (1) IPDC (2) LPDC-dienstenleveranciers and (3) Gelinkt Notuleren sjablonen.
Scope
ABB focuses on LPDC within loket, and the data synchronisation towards and from (in order of priority)
(i) IPDC
(ii) LPDC-dienstenleveranciers and
(iii) Gelinkt Notuleren sjablonen.
LPDC-ABB is a module inside Loket voor lokale besturen. LPDC without the "-ABB" suffix is traditionally used for the existing local product and services catalogues as developed by software providers and web agencies.
POC scope
pagePOCMVP scope
pageMVP LPDCFuture roadmap
Manage a local product catalogue
Create a draft
Publish
Valid from > to
Versions
Edit and/or republish an already published product
Use IPDC concepts to create instances of a product
Search/filter in the IPDC catalogue
Select a IPDC product (concept)
Overwrite default content
Fill in empty mandatory fields
E.g.: Cost
Add needed translations (NL > EN)
New products can be created but should always be based on an existing concept
Structure of the published products follow ICEG datamodel
see "mapping GPDC op ICEG model.xlsx" under documents
Research done
Personas: https://miro.com/app/board/o9J_l6u2Hn0=/
Data model mapping: see "mapping GPDC op ICEG model.xlsx" under documents
Documents:
Example of a full product catalogue https://www.brugge.be/producten
Goals
Define an MVP to be developed in this spurt
Scope the input module features
Future exploration for LPDC
As Figma prototype
Value stream
Gelinkt melden en publiceren
How to measure
Can Europe harvest the products
Can IPDC harvest local instances
Can local governments define their local products
Glossary
| Word | Meaning |
|---|---|
IPDC | Interbestuurlijke producten en diensten catalogus |
LPDC | Lokale producten en diensten catalogus |
Single Digital Gateway (SGG) | "YourEurope" portaal of https://ec.europa.eu/growth/single-market/single-digital-gateway_en |
Concept (IPDC) | This is the original concept. E.g: requesting an eID |
Instance (IPDC) | This is the enrichment/adaptation of the original concept |
ICEG | |
GPDC | ? |
Feature description
V1 prototype (deprecated):
V2 prototype (WIP):
Still unclear
| Question | Date asked | Input | Decision |
|---|---|---|---|
Discussion needed over content and data model: which content is editable, does meta data exist (categories, etc.), ... | 25/02/2022 | See "Data modal mapping" document. Still unclear what fields are mandatory, translatable. What do we do with "valid from/to" and versions? | We follow the ICEG mapping excel file/ |
How does the publish flow work: is there a validation step? | 25/02/2022 | Status: - draft - "geagendeerd" (put on agenda) - stopgezet - published | |
Which fields need translations? Are titles included? | 25/02/2022 | See question on data model. Will be indicated. | All text fields can be translated. Only ICEG mandatory fields need a translation. |
Are certain products mandatory? Do we indicate that? | 25/02/2022 | Yes, mandatory products will be indicated | |
What is the scope? What user problems to solve? | 28/02/2022 | Problem statement and scope will be improved by Bart | |
Who can we ask questions to? Who is our client here? Who is our user? | 28/02/2022 | IPDC (Wouter), Lokale besturen, Gelinkt notuleren | |
Which concept is used for new products (e.g. electric charging stations in Gent)? | 01/02/2022 | To be discussed with Wouter | We will provide a blank concept for each category as a starting point. |
Do we need to support versions in this phase? (products can have a "valid from>to date" so a new version can be created while the old one is still published) | 01/02/2022 | To be discussed with dev. | No. |
Future of this feature
See future exploration.
Communication
Gebruikerssessie
Usertesting
Last updated
