- Gegevens
De term "uitbijter" is gebaseerd op verborgen aannames. Een heel andere manier om hierover na te denken, is dat het punten zijn die niet passen bij je begrip van de verdeling van fouten die ten grondslag ligt aan de data-acquisitie.
Helaas gaan we vaak ten onrechte uit van een "normale" (Gaussische) verdeling van fouten. Wist je dat in een "normale" verdeling een afwijking van 11 sigma veel, veel, veel minder waarschijnlijk is dan een afwijking van 10 sigma? Klopt dat met je ervaring? Niet de mijne: afwijkingen van 11 sigma zijn in de praktijk ongeveer net zo waarschijnlijk als afwijkingen van 10 sigma. Ik zie geen van beide als uitbijters, ze vertellen je alleen dat je foutenverdeling niet "normaal" is.
In 1971 beschreven Abrahams en Keve (10.1107/S0567739471000305) een prachtige manier om het foutmodel te verifiëren: sorteer de fouten en maak, gebaseerd op de aanname dat ze een normale verdeling volgen, een grafiek (Normal Probability Plot) van hun waarde tegen hun verwachte waarde. De resulterende plot zal naar verwachting een rechte lijn zijn. Als dit niet het geval is, betekent dit dat de fouten geen Gaussische verdeling volgen.
Ik heb hier zelf last van gehad in mijn onderzoek. En voor mij was een zeer goede oplossing om de normale distributie te vervangen door een Student-distributie (10.1107/S0108767309009908). De beste parameter ν van die verdeling kan worden afgeleid door de Probability Plot te lineariseren. Door die procedure te volgen was het voor mij niet meer nodig om eventuele “uitbijters” te verwijderen: alle datapunten konden gebruikt worden in een analyse (10.1107/S0021889810018601).
Uitbijters bestaan niet. Als je denkt dat dit wel het geval is, begrijp je je foutmodel waarschijnlijk niet goed. En een goed begrip van je foutmodel kan je veel meer vertellen dan je kunt leren door uitbijters te verwerpen door het toepassen van een of andere empirische regel.
[Dit bericht is geschreven na het lezen van een door AI gegenereerde gids over het omgaan met uitbijters op LinkedIn.]
- Gegevens
Met betrekking tot het beheer van onderzoeksdata vertel ik mensen vaak hoe belangrijk het is om een dataset te beschrijven als "wat het is" in plaats van "hoe je het gebruikt".
Een voorbeeld dat mij al een tijd geleden werd gegeven door een biobankexpert in Nederland was de beschrijving van een röntgenfoto van de borstkas: hoogstwaarschijnlijk kan zo'n beeld zowel worden gebruikt om het bot in de wervelkolom te bestuderen als om de toestand van de grote slagaders (bijvoorbeeld de aorta) te bekijken. Als een dergelijke röntgenfoto wordt verkregen, is het waarschijnlijk dat deze slechts voor één doel is gemaakt, maar dat sluit hergebruik op het andere gebied niet uit. Om de herbruikbaarheid van de gegevens te optimaliseren (zie de FAIR-principes), moet een thoraxfoto het label "thoraxfoto" krijgen en niet "röntgenfoto van de wervelkolom", zelfs als deze voor dat specifieke doel is gemaakt.
Ik denk dat dit vergelijkbaar is met een "boekenkast". De meeste "boekenkasten" zijn eigenlijk "planken". Die planken kunnen gebruikt worden om boeken in op te bergen, maar kunnen ook voor andere doeleinden gebruikt worden. Om de vindbaarheid van de juiste opbergoplossing in de winkel te optimaliseren, zou het handig zijn als het label geen specifiek gebruik uitdrukt.
Onlangs hoorde ik nog een heel mooi voorbeeld van hetzelfde principe in een aflevering van de SE-radio-podcast: Functienamen bij het schrijven van computercode. Het verbetert de menselijke leesbaarheid van computersoftware (en dus de onderhoudbaarheid) sterk als elke functie wordt genoemd naar wat het doet, in plaats van naar hoe het wordt gebruikt. Het voorbeeld uit de podcast: noem de functie niet "reformat_email", maar noem hem "remove_double_newlines" als dat is wat hij doet.
Ik heb iemand ooit horen zeggen "Onderzoekers zijn heel slecht in staat de mogelijkheden voor hergebruik van hun eigen data te beoordelen". Het is waar: een onderzoeker die de aorta bestudeert, zal op zijn eigen röntgenfoto's niet eens de ruggengraat zien, laat staan nadenken over manieren waarop de gegevens kunnen worden hergebruikt door botonderzoekers. Ik denk dat het labelen van een dataset met hoe deze wordt gebruikt hier een gevolg van is. Een getrainde bibliothecaris/archivaris, met training in classificatiesystemen, zal zo'n fout snel doorzien en een betere naamgeving voorstellen.
- Gegevens
Verhaal 1. De European Open Science Cloud had zijn lanceringsbijeenkomst in Wenen op 23 november 2018. Lezingen vertegenwoordigden grote (honderden miljoenen euro's) Europese wetenschappelijke projecten gericht op één onderwerp, en vertelden het publiek hoe belangrijk de EOSC zal zijn.
Verhaal 2. Ik beantwoord graag vragen op Quora. Laatst vroeg iemand of het ongezond is om in een vochtig klimaat te leven. Het kostte me 2 uur om gegevens over klimaatvochtigheid en verwachte levensduur te vinden, beide per land samen te vatten en te correleren. Ik kon voor slechts 46 landen beide nummers vinden.
Mijn conclusie? Een goed functionerende European Open Science Cloud zal vooral zeer nuttig zijn om de antwoorden op kleine vragen te versnellen door het mogelijk te maken verschillende datasets uit verschillende bronnen te koppelen. De grote projecten die hun eigen petabytes aan data verzamelen, zullen precies hetzelfde kunnen doen, met of zonder een science cloud. Maar de meeste wetenschap bestaat uit veel kleinere vragen, waarbij mogelijk gegevens worden samengevoegd tot oplossingen voor grote maatschappelijke doelen. Dit soort projecten zijn het meest gebaat bij datasets die voldoen aan standaarden. Zij zullen profiteren van de EOSC. En daarom is het jammer dat de stem van dergelijke projecten niet vertegenwoordigd was tijdens het lanceringsevenement.
- Gegevens
Ja!
Er is een interessant verschil tussen hoe risico's vaak worden benaderd in een onderzoekslaboratorium waar veel gegevens worden verwerkt en in een chemisch laboratorium. Veel mensen die met data werken, lopen regelmatig tegen problemen aan, zoals het niet snel kunnen vinden van data of het niet exact kunnen reproduceren van resultaten, maar denken ze vaak dat deze problemen een integraal gevolg zijn van het werken met grote hoeveelheden data en herkennen ze deze problemen niet als problemen met de datamanagementpraktijk en -voorbereiding. Het equivalent in een chemisch laboratorium zou zijn dat onderzoekers denken dat dagelijkse branden en explosies van nature horen bij het werken met chemische verbindingen, in plaats van deze te erkennen als een gevolg van slechte laboratoriumpraktijken en slechte voorbereiding.
Ook is er weerstand tegen de invoering van een datamanagementspecialisme omdat veel onderzoekers denken dat datamanagement relatief eenvoudig is. Iedereen heeft thuis een computer en velen houden fotobibliotheken bij. Deze ervaring vertaalt zich echter niet direct in het kunnen werken met grote hoeveelheden data in een lab:
- Gegevens in het lab zijn vaak 1-3 ordes van grootte groter dan een fotobibliotheek thuis. Een onderhoudsklus die een uur kost voor fotobibliotheek zou zich vertalen in meer dan 6 maanden werk in een groot data-intensief project. Hierdoor is er echt behoefte aan andere benaderingen.
- Gegevens in een fotobibliotheek bestaan uit JPG-bestanden en misschien RAW-bestanden, en deze bestanden hebben eenvoudige 1-op-1-relaties. In het lab zijn er veel meer verschillende soorten data en de relaties zijn veel complexer.
- Een fotobibliotheek wordt meestal door één persoon onderhouden. In het lab wordt door verschillende mensen aan dezelfde data gewerkt, en ze moeten allemaal op de hoogte zijn van alles wat de anderen doen.
En inderdaad, zelfs in een fototheek thuis kan men niet altijd even snel vinden wat men zoekt.