- 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
Als je ooit aan projectplanning hebt gedaan zou je kunnen weten dat Douglas Hofstadter, in zijn boek Gödel, Escher, Back, een belangrijke wetmatigheid heeft geformuleerd die De Wet van Hofstadter heet:
Alles duurt langer dan je denkt, zelfs als je rekening houdt met de Wet van Hofstadter
In de praktijk is deze recursieve wet heel lastig te gebruiken. Ik gebruik meestal een niet-recursieve variant, die ook rekening houdt met de planning van een project:
Een zorgvuldig gepland ontwikkelingsproject duurt π keer langer dan je denkt. Als je niet zorgvuldig plant, wordt dit π2
- 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.
- Gegevens
Via twitter zag ik een heel cynische opmerking over het stellen van vragen na een wetenschappelijke lezing met een stroomschema dat de meeste mensen ontmoedigt om ook maar iets te vragen. Dit komt totaal niet overeen met mijn ervaring met het organiseren van symposia en congressen. Meestal zijn vragen zeer welkom en zijn mensen veel te verlegen om hun visies te delen. Ik heb daarom een weerlegging gemaakt in de vorm van het volgende stroomschema dat volgens mij een betere weergave is van de te volgen gedachtegang.
- Gegevens
Gedurende de afgelopen 4 jaar is Rotterdam Centraal Station volledig vernieuwd. Vaak heb ik foto's genomen (met de camera in mijn telefoon, sorry), met een focus op de gebeurtenissen rond spoor 1-3 waar het werk zowel begon als eindigde.
- Gegevens
Het programmeerwerk dat we in ons team kiezen, is als de hals in de zandloper die life science-onderzoek en -technologie vertegenwoordigt:
- Er zijn veel zandkorrels boven ons. Die vertegenwoordigen alle softwaretools die zijn ontwikkeld in life science-onderzoek.
- Beneden ons is een grote leegte. Dit vertegenwoordigt de behoefte aan breed toepasbare tools in de life sciences.
- Op de bodem liggen ook zandkorrels. Ze zijn goed geregeld. Deze vertegenwoordigen de huidige technologie: commercieel verkrijgbare tools en goed onderhouden open source-pakketten.
Hoe komt het zand van boven naar beneden? Via de ontwikkelingshals. Het is smal; slechts enkele academische tools halen de bodem. De stroom door de nek wordt aangedreven door:
- push: enkele academische groepen die de mogelijkheid en capaciteit hebben om hun tools beschikbaar te stellen
- pull: een paar bedrijven die ver vooruit kijken en de potentie van een academische tool zien en benutten
In onze zandloper van life science tools wordt voortdurend nieuw zand toegevoegd. En het meeste loopt na een tijdje over de beker. Sommige tools leveren nooit wat de auteur dacht dat ze zouden doen. Sommige zijn gemaakt om een enkel probleem op te lossen en worden terecht losgelaten als dat klaar is. Maar veel tools worden gepubliceerd en als wees achtergelaten. Alleen een selectie van tools die lijken nuttig te kunnen zijn voor een groter publiek, haalt de hals.
In de praktijk is de hals te smal. Er zijn veel meer waardevolle hulpmiddelen dan er kunnen worden aangepakt. Een team als het onze kan helpen om de hals groter te maken door bestaande onderzoekstools breder inzetbaar te maken ten dienste van levenswetenschappers met een duidelijke behoefte (wij noemen dat professionalisering). Maar het is soms moeilijk om financierende partijen te overtuigen om hiervoor te betalen. Het is ook moeilijk om onderzoekers te overtuigen om te werken aan het verbeteren van hun software: professionalisering levert geen nieuwe high-impact papers op. We werken eraan om de financiers ervan te overtuigen dat het beter is bestaande successen te professionaliseren dan ze opnieuw uit te vinden met nieuw onderzoeksgeld. En we werken eraan om de wetenschappers ervan te overtuigen dat professionalisering van hun output zal leiden tot hogere citatiescores op hun bestaande publicaties.
De wetenschap wil nieuwigheid. En het huidige Nederlandse financiële klimaat is gericht op toegepaste wetenschap, op innovatie in de samenleving. Kijk naar het diagram en je ziet dat deze moeilijk te combineren zijn. Innovatie begint waar nieuwigheid eindigt. De enige manier om de combinatie te maken, is door ontwikkeling mee te nemen.
Foto door graymalkn op flickr
- Gegevens
Heb je je ooit afgevraagd hoe je de vijf sterren in je fotocatalogus kunt gebruiken? Ik heb mensen horen zeggen: er zijn maar twee soorten foto's: foto's die je aan iemand zou kunnen laten zien, en foto's die je aan niemand zou laten zien. Is kiezen tussen nul en één ster niet genoeg?
- Gegevens
Vandaag ben ik er eindelijk aan toegekomen om Automator te gebruiken en een van de opdrachtregelscripts die ik al eeuwen gebruik een beetje gebruiksvriendelijker te maken.
Het probleem dat ik heb geprobeerd op te lossen, is het feit dat de PDF-bestanden die een Mac maakt normaal gesproken van zeer hoge kwaliteit en dus groot zijn. Als je iemand gewoon een document wilt sturen om op het scherm te lezen, is een veel kleiner pdf-bestand voldoende. Het open source-pakket "ghostscript" heeft een tool genaamd ps2pdf die kan worden (mis)gebruikt om de grootte van componenten voor PDF-bestanden aan te passen. Ik heb dit geïnstalleerd in /opt/local/bin met behulp van de "macports"-software.
Lees meer: Mac OS: PDF bestanden kleiner maken in the Finder