Recht op dataportabiliteit <--> uniek product?

[Rekcor]

Wij zijn op het werk aan het worstelen met het recht op dataportabiliteit van de gebruikers van onze webapplicatie.

Bij het recht op dataportabiliteit moeten organisaties de gegevens verstrekken in een vorm die het voor betrokkenen makkelijk maakt om hun gegevens te hergebruiken en door te geven aan een andere organisatie. Organisaties zijn daarom wettelijk verplicht om de gegevens in een gestructureerd, veelgebruikt en machineleesbaar formaat te verstrekken.

Wat als je een uniek product hebt? Dan is er geen andere organisatie en ook geen veelgebruikt formaat.

[TheFes]

Wat er niet is, kan nog komen.
Stel, een concurrent gaat een vergelijkbaar product maken, en één van jullie klanten wil overstappen.
Dan moeten ze hun data in een gestructureerd, veelgebruikt en machineleesbaar formaat kunnen krijgen (dus bijvoorbeeld een csv, en niet een of andere obscuur bestandsformaat wat alleen via jullie product te openen is)

[Croga]

Rekcor schreef op woensdag 6 september 2017 @ 09:12:
Wat als je een uniek product hebt? Dan is er geen andere organisatie en ook geen veelgebruikt formaat.

Ook dan kun je nogsteeds XML gebruiken. Dat voldoet aan al deze eisen. Er is geen standaard voor de structuur in dit geval dus zul je die zelf moeten creëeren. Als je systeem goed opgezet is zou serialisation al genoeg moeten zijn.

In mijn ervaring bestaan er echter geen unieke producten. Het feit dat jullie het nog niet gevonden hebben betekend niet dat er geen standaarden beschikbaar zijn.....

[Stoelpoot]

Ze geven zelf al een voorbeeld van bijvoorbeeld een API. Hieruit maak ik op dat bijvoorbeeld JSON of XML al wordt gezien als een 'gestructureerd, veelgebruikt en machineleesbaar formaat'. Wat JSON/XML eigenlijk ook precies is. Maar misschien is zelfs een SQL export al voldoende.

[SambalBij]

Ik denk dat ze met deze omschrijving een formaat als CSV of XML bedoelen. Dat is gestructuureerd (maar je kunt zelf de structuur bepalen) veelgebruikt en machineleesbaar.
(Wat niet mag is de data voor de betrokkene aanleveren uitgeprint in rode letters op zwart papier, en dan iedere letter ook nog in een ander lettertype, om scannen en OCR bewust extra moeilijk te maken)

[Rekcor]

Ok, ja het gaat dus om de exegese van het woord 'veelgebruikt'. XML is veelgebruikt, maar mijn eigenbedachte XML-schema wordt alleen door mij gebruikt. Is een dergelijk bestand dan 'veelgebruikt'?

[Wish]

Rekcor schreef op woensdag 6 september 2017 @ 09:48:
Ok, ja het gaat dus om de exegese van het woord 'veelgebruikt'. XML is veelgebruikt, maar mijn eigenbedachte XML-schema wordt alleen door mij gebruikt. Is een dergelijk bestand dan 'veelgebruikt'?

Wat dacht je van een .csv file... ook best veel gebruikt . Best wel serieuze opmerking overigens - zodra er standaarden zijn voor data portabiliteit zul je ze onder de AVG moeten gaan aanbieden (als er iemand om vraagt). Maar zoals je al zegt: heb je een uniek product, dan is er ook geen standaard om aan te conformeren.

Veel van de AVG gaat eigenlijk over CYA (Cover Your Ass): je moet kunnen aantonen dat je al het mogelijke hebt gedaan om aan de regelgeving te voldoen. Je kan er dan ook mee wegkomen om alvast een procedure te bedenken en uit te tekenen. En dan pas daadwerkelijk een eerste keer uitvoeren op het moment dat een persoon daarom vraagt. Kom je dan wel de technische consequenties tegen.

[Rekcor]

Dank!

CYA, mooie term om te onthouden :-).

[F_J_K]

Rekcor schreef op woensdag 6 september 2017 @ 09:48:
Ok, ja het gaat dus om de exegese van het woord 'veelgebruikt'. XML is veelgebruikt, maar mijn eigenbedachte XML-schema wordt alleen door mij gebruikt. Is een dergelijk bestand dan 'veelgebruikt'?

Zolang je alle documentatie bijvoegt is XML (of csv) veelgebruikt en de combi van de XML en documentatie bruikbaar. Wel zorgen dat de documentatie altijd correct en uptodate is

Verder eens met Wish in "Recht op dataportabiliteit <--> uniek product?" - als het amper tot niet voorkomt heb je geen volautomatische functie nodig zoals bijv Google en Facebook dat hebben.

[Rekcor]

Dank.

Wat we hebben gedaan is gekeken hoe veel werk een handmatige export ons kost (hoogstens 2 uur), dat vermenigvuldigt met het aantal te verwachten verzoeken (0), en dat vergeleken met het bouwen van een oplossing á la Google/Facebook (minimaal 120 uur werk).