🆔LPDC integration

Lokale Producten en Dienstencatalogus

To comment on a FP:

Date, name: comment

Status Feature Passport

STATUS	OWNER	DATE
In proposal	Preliminary analysis: Sofie	16/03/2023
In refinement - Design Research
In refinement - Technical Research/Feedback
In development
In QA/ Testing
In Final state

EPIC: OP-2173: LPDC integration

Analysis

This part of the feature passport is owned by the analyst

Current state

• Information [NL] on LPDC (website ABB): https://lokaalbestuur.vlaanderen.be/lokale-producten-en-dienstencatalogus#:~:text=Informatie%20over%20die%20producten%20en,dat%20effici%C3%ABnt%20op%201%20plaats.

• Preliminary analysis of Sofie: https://miro.com/app/board/o9J_l9uYRTY=/?moveToWidget=3458764544968518544&cot=14 (most of the information is written in this feature passport)

LPDC is part of the application ‘Loket voor Lokale Besturen’.

LPDC: Overview of products and services

LPDC: Contact Point in the creation form of a new or existing service/product

LPDC Contact point: data

• E-mail (Email) > should be E-mail in dutch as well

• Telephone (Telefoon)

• Website (Website)

• URL (URL)

• Opening hours (Openingsuren) [no structured input] = information is not available in OP

• Address data:

  • Straat

  • Huisnummer

  • Busnummer

  • Postcode

  • Gemeente

  • Land > not yet in OP, but will be in the future (see ticket OP-1970)

LPDC Contact point: Current functionalities

• Create multiple contact points

  • Every time you add a contact point ('voeg contactpunt toe'), you can add address information ('voeg adres toe') (with the address data fields as mentioned above)

  • Not possible to add address information without adding a contact point first.

Voeg contactpunt toe in LPDC

Voeg adres toe (only visible once contactpoint is added) in LPDC

• Delete existing contact points

  • If you delete contact point 'verwijder contactpunt', address information will also be deleted automatically.

  • It's possible to remove only address information 'verwijder adres' without deleting contact point.

Verwijder contactpunt

Verwijder adres

Problems

• No possibility to re-use the data that is available via various sources

  • OrganisatiePortaal (ABB)

  • OrganisatieRegister Wegwijs (DV)

• No possibility to translate address details into other languages

  • LPDC has the need to translate addresses into other languages.

• No use of an address validator

  • In OP and also LLB we use the CRAB functionality, necessary to maintain data quality.

• No possibility to name ContactPoints

Current feedback from Sofie Merciny: Probably currently no possibility to name contactpoints in OP but not sure, to double check with Boris once back from his leave (31/07)

There is a need (at LPDC) to name contact points for services and products. This need arises from various reasons, including enhancing recognition, simplifying communication, and improving citizen experience.

Overall, giving a name to contact points for services and products can improve communication and interaction between the municipality and its residents, thereby strengthening overall service delivery. It fortifies the bond between citizens and their local government, contributing to a positive experience and a sense of engagement in municipal affairs.

It is essential to choose a name that aligns with the mission and vision of the contact point and is easy for citizens to remember.

The option to name contact points for services and products is a practical and strategic approach that can enhance service delivery and offers various benefits and valuable aspects:

• Recognizability: By giving a specific name to a contact point, residents and citizens can easily recognize and remember it, increasing awareness and accessibility of the service or product.

• Clear Communication: A name ensures clear communication about the contact point. Both internally within the municipal organization and externally to residents, a specific name helps everyone refer to the same contact point.

• Improvement of Citizen Service: A clear name can improve citizen service by enabling residents to easily find the right contact point for their specific needs, reducing confusion and enhancing service efficiency.

• Transparency and Trust: By naming a contact point, the municipality can promote transparency and build trust among residents. It shows that the municipality has a designated place where residents can address their questions, issues, or feedback.

• Efficiency and Organization: A name can also aid in streamlining internal processes and organization. It makes it easier for municipal employees to refer to specific contact points and clarifies the structure of service delivery.

• Marketing: Having a name for a contact point facilitates promotion and communication through newsletters, social media and other communication channels.

🤩 Expectations

As the product manager of LPDC/OP, we want to reuse data so that

1. OP can feed LPDC with information that is in the database of OP

2. LPDC can feed OP with information that is missing in the database of OP

🕵️‍♂️ Use Cases

🤔 Discussion points

What is the context/name of the contact point: a person, an organisation, a department, a team, ...?

• In OP contact details can be connected to a 'vestiging' of an organisation or to a person.

Which source(s) to use for LPDC contact points

• OP, Wegwijs and/or other

• OP will be the source for Wegwijs regarding contact information of local governments (epic: OP-1125) = WIP

None of the fields is mandatory

• In OP and also LLB we use the CRAB functionality so all the address elements are filled in.

• FYI: end-of-life CRAB is by the end of 2023 (see ticket OP-1225). We have to decide together with the other PM's to use 'Addressenregister' or 'BeSt-Add' instead.

Impact of a contact point deletion in LPDC?

• Deletion of contact point in relation to the product/service

  = No impact on contact information in other applications

• Deletion of contact point in general

  = update other applications

Do we want to included departments?

Solution

The next two parts of the FP can [sometimes] be worked on simultaneously

Design

This part of the feature passport is owned by the designer

User research

[If there is any user research preceding the wireframe mock-up stage, it needs to be documented here]

Mock-ups

[link to figma mockups + any explanation or extra documentation]

Technical

This part of the feature passport is owned by the technical team

• Use generieke terugmeldfaciliteit AP

• Serialize proposed changes as TTL in a string

  • Clear what is in/out scope of the proposed change

  • Workflow application will need to rdf diff to understand the proposed changes

  • In line with spec which focuses on literals

Alternatives which were not retained:

• Split everything up in a meldingsobject per attribute (cumbersome and increased complexity)

• Use MedlingBody to attach rdf. Bypasses the melding:huidigeWaarde and melding:voorgesteldeWaardewhich are at the core of the spec but only accept literals as range.

• Use a different spec. No better alternative found that justifies ignoring an existing OSLO standard.

After the designer and/or the technical team finish their task, a meeting follows where the solutions are presented. The team exchanges feedback and amends the feature passport where necessary.