PDC

[sytskevanhasselt]

Zie ook #32 (zoeken en vinden). We laten Elastic search de PDC API bevragen.

[rubenvdlinde]

• Wat samenhang met andere PDC ontwikkelingen

Wie hebben we nodig

• Architecten

19 Mei 12:00

[rubenvdlinde]

Oké korte samenvatting.

Voor het KCC is het belangrijk dat zowel informatie over producten en diensten (PDC) als vraag antwoord combinaties (VAC) beschikbaar en doorzoekbaar zijn.

Vanuit your europe wil de EU dat alle overheden hun producten digitaal aanbieden. In Nederland is dit via de rijksoverheid ondergebracht bij ICTU. Voor de Gemeente heeft de VNG een gemeenschappelijke voorziening gerealiseerd.

Aangezien overheden sowieso verplicht zijn product informatie hierop te ontsluiten is het zinnig om hierop aansluiting te zoeken.

[hannekevanderhorst]

Ruben
Wellicht handig voor de meeting van vanmiddag, ik heb best wel een mening over SDG en VNG ;)

Mijn voornaamste probleem met PDC baseren op SDG is dat SDG een beetje een slechte standaard is. Lang verhaal kort de EU heeft alle lidstaten gevraagd producten op een uniforme manier aan te bieden -> https://joinup.ec.europa.eu/collection/european-committee-standardization-cen/solution/dictionary-terminology-product-classification-and-description.

Logius heeft vervolgens besloten een eigen standaard te handhaven (en te vertalen) de VNG boed hier weer op aan en heeft ook (besloten te vertalen) en we gaan nu als gemeenten weer hierop aanbieden.

Gevolg is dat in al deze vertalingen van allerlij dingen wegvallen waardoor bijvoorbeeld de taxonomie niet meer goed werkt (dezelfde categorieën tussen bijvoorbeeld NL en BE voor rijbewijzen etc). En er gaten ontstaan in het datamodel (leges en kosten zijn volledig weggevallen) en verbanden/versies niet langer mogelijk zijn (huwelijk, partnerschap en omzetting zijn allemaal variaties op huwelijk). Het verhindert ook het uitleveren van halffabricaten (producten die samen een product zijn) die wettelijk zijn verankerd in DSO. Het geforceerde behoud van huidige standaarden (ipv van de vervanging daarvan zoals beoogd in het EU-SDG project) levert dan ook een eind object op dat nauwelijks nog te vertalen is naar het door de EU gebruikte ISO object -> https://schema.org/IndividualProduct. En verder integratie met de markt en partijen buiten de overheid verhinderd.

Waarom geen een leverancier of gemeente hierover aan de bel heeft getrokken is voor mij onbegrijpbaar maar goed.

Iets anders dat aandacht behoeft is dat het PDC vanuit Open Online wordt ontsloten via GraphQL, De NL API strategie, VNG Standaardisatie en SDG hanteren plain JSON-Rest. Die twee zijn in theorie niet uitwisselbaar zijn. Ik heb dus serieuze vraagtekens bij de stelling dat open online SDG volgt.

Dat gezegd hebbende, SDG is nu een standaard en die moet ondersteund worden. Mijn voorstel zou echter zijn om in het datamodel gebruik te maken van de ISO standaard en die tevens exporteerbaar te maken als SDG berichten (ISO -> SDG gaat veel makkelijker dan SDG -> ISO) daarmee blijven we in de kern bij internationale normen maar ondersteunen we het VNG/Logius gefreubel wel.

Overigens speelt exact ditzelfde verhaal ook bij productAanvragen, waar naar mijn weten de VNG zelf iets aan het verzinnen is ipv de EU/EU standaard te implementeren.

Enfin, food for thought ;)

[hannekevanderhorst]

MArtin:

Memo generieke PDC in relatie tot KISS
Het memo PDC is gericht op het ontwikkelen van een generieke PDC-component, waarmee we de PDC-behoefte vanuit vier projecten, waaronder KISS met één oplossing willen afdekken
Hiervoor zetten we een aparte opdracht uit.
Voor KISS:
• is inzet van deze generieke PDC een issue voor de doorontwikkeling
• ligt de standaard ontsluiting naar PDC in scope van de opdracht aan ICATT/Conduction. Concreet: lever een PDC-API (conform de SDG Standaard)

Vragen over EU standaard

1. Ik zie dat CWA 15294, Dictionary of Terminology for Product Classification and Description ingetrokken is op 2-3-2016. Is er een opvolger? Heb je die voor mij?
2. Je refereert ook aan het ISO object ‘Individual Product’. Dit is gericht op e-commerce producten. Het lijkt me nog al ver af te staan van c.q. niet handzaam als model voor gemeentelijke producten en diensten
3. Je spreekt je verbazing uit over het feit dat Logius/VNG niet de EU-standaard heeft gevolgd.
   Welke standaard precies?
   PS. Hun keuze heeft niet de publicatie van Nederlandse producten op YourEurope in de weg gestaan
4. Gaten in het datamodel. Dat is ook geconstateerd vanuit de ‘groep Den Haag’. Ook jouw opmerking over ketenproducten in het kader van DSO is relevant.
5. De vraag is wel of en hoe we bij het realiseren van standaard PDC API/informatiemodel kunnen profiteren van de EU standaard. Zie ook mijn opmerking onder 2

Ontsluiting Backend -> Frontend in Open Online
6. Hiervoor wordt GraphQL ingezet. In het kader van hergebruik heb ik de Open Online componenten benoemd met de vraag welke ingezet kunnen worden.
PS. In jouw reactie geef je aan hoe je aankijkt tegen GraphQL . Dat is dan duidelijk

Generieke PDC-component voor Dimpact met Open Online als basis. Dat betekent
A. Het bouwen van een standaard PDC API (volgens de SDG API).
 Die PDC API is er nu niet in Open Online
 De stelling dat Open Online de SDG volgt heb ik ook niet gedaan. We willen juist een PDC-component die dat wel doet. We nemen daarvoor Open Online als basis en ‘verbouwen’ die en voegen daar de SDG-API aan toe.
B. Inzet van CMS (Drupal) van Open Online als registratie voor PDC
C. Inzet van beheercomponent van Open Online

Praktische keuze
We volgen de SDG-API. Het onderliggend informatiemodel is vooral gericht op productbeschrijving. Dit laten we in tact.
We relateren daar een set van ontbrekende gegevens (zie bijlage 3 van het memo) aan toe.

AFSPRAAK
Tweewekelijks is een aantal gemeenten en leveranciers aan het werk op De Vloer in Utrecht. Op deze werkdag bespreken ze diverse onderwerpen.
Het voorstel van Vincent van Beek is om as. woensdag de PDC-API te bespreken. Ik ben er bij, maar het zou mooi zijn als jij ook aanwezig kunt zijn of in ieder geval wat nuttige vragen mee kunt geven.