Inrichting data map

[CorneeldH]

Probleem

De huidige mappenstructuur in data/ is verschillend gevuld en kan beter georganiseerd worden. Ik denk dat het goed is om data in de hoofdmap te houden.

Huidige structuur bij 1CijferHO main

data/
├── 00-metadata/     # Geëxtraheerde metadata (xlsx, json, logs)
├── 01-input/        # Alles door elkaar: data, demo, decodering, bestandsbeschrijvingen
└── 02-output/       # Geconverteerde bestanden

Alternatieve structuur (1CijferHO avans-feature-requests)

data/
├── 00-metadata/
├── 01-input/
├── 02-processed/    # Geconverteerde bestanden
├── 03-combined/     # Gecombineerd met decoderingsbestanden
├── 04-enriched/     # Verrijkte data
└── reference/       # Label-bestanden voor mapping

We willen binnen deze mappen een submap met "DEMO" en daarin bestanden met .."_DEMO".extensie en dan kan er in Streamlit / config worden bepaald DEMO-mode of niet.

Discussiepunten

• Wat is de juiste nummering? Moet metadata 00 zijn, of is een niet-genummerde map logischer?
• Metadata binnen /data of zelfstandig (zoals in https://github.com/cedanl/1cho_ins_preparation_r/ en https://github.com/cedanl/no-fairness-without-awareness/
• Referentie data (koppeltabellen), waar horen die?
• Data dictionaries onder metadata?
• Hoe verhoudt dit zich tot andere cedanl/Npuls repositories? Consistentie is wenselijk
• Moet reference/ (label-bestanden) ook genummerd zijn?

Overall

Het gaat me er niet om dat alles 100% eenheidsworst is, maar meer consistentie is wel prettig. Ik vind het ook belangrijker om een standaard te hebben en die te implementeren bij repositories rondom uitval en instroom (opschaling repo's). Dan kunnen we later de standaard omkatten of verder vorm geven.

@cedanl/admin iedereen is welkom om vibes te delen. Het hoeft niet volledig, maar als je ergens een mening over hebt, dan wordt het gewaardeerd

[Muhammet369]

Grote voorstander van structeren vd folders! Mijn voorkeur gaat uit naar zo simpel mogelijke structuur

data/
├── metadata/ # Geëxtraheerde metadata (xlsx, json, logs, datadictionary)
├── input/ # Hierbinnen eventueel raw/processed/combined/enriched/DEMO
└── output/ # Hierbinnen eventueel bestanden/dashboarding/MLmodel

[StevenRamondt]

Ik ben ook voorstander van een zo simpel mogelijke structuur.

Wat voor mij wel een aandachtspunt is bij een structuur met alleen input/ en output/, is dat we dan een deel van het overzicht op de data lifecycle verliezen. Omdat onze projecten sterk data-science gedreven zijn, moeten we vaak goed kunnen uitleggen waar data vandaan komt en welke stappen ermee zijn gedaan. Gebruikers en stakeholders vragen daar ook regelmatig naar.

Daarnaast kan het voor replicatie en onderhoud lastiger worden: als iemand later een stap wil aanpassen of een pipeline opnieuw wil draaien, helpt het als de verschillende stadia van data expliciet herkenbaar zijn in de structuur. We leveren op dit moment gewoonweg niet volledige en volwaardige applicaties. Mijn huidige gebruikers passen veel zelf aan.

Dus eenvoud vind ik belangrijk, maar ik zou wel willen dat de structuur nog voldoende inzicht geeft in de verschillende stappen in de dataverwerking. Misschien kan dat bijvoorbeeld door lifecycle-stappen binnen input/ duidelijk te onderscheiden?

[SKvdV]

Een optie is ook om, indien van toepassing, iets van brons, zilver, goud indeling te maken.
Brons = onbewerkte brondata (input)
Zilver = is de opwerking
Goud = de laag waarmee en waarop je analyses of andere uitwerkingen doet.

Reference data zou dan in de bronslaag kunnen.

Maar dan zit je een beetje met de output, is dit dan de goudlaag?

Verder vind ik nummeren van de mapjes persoonlijk wel duidelijk.

[Muhammet369]

Output data kan meestal indirect worden gebruikt door de business => Zilver
Als output data direct kan worden gebruikt door bijv. dashboard => Goud

[CorneeldH]

Je merkt hier al dat zilver en goud voor verschillende mensen andere betekenissen hebben. In een plaatje van InHolland kwam ik tot de conclusie dat veel van onze repo's NA goud zitten (zij volgden definitie van Shirley).

Als we een stap verder zijn met Analytics Platform en data opslag bij SURF dan zouden we daar wel dit soort lagen kunnen hanteren.

[CorneeldH]

Dank voor de input iedereen!

Zie de nieuwe standaarden: https://github.com/cedanl/.github/tree/main/standards, met daarin een aparte md over data structure. Nieuwe ideeën en updates kunnen in de repo worden besproken via issues en pull requests.

Het punt van brons / zilver / goud is wmb dus niet in repo, maar potentieel in data opslag. Zodra we daar concreet mee aan de gang gaan, kunnen we die dialoog weer opstarten.