@salgo60 sa i Här kommer höstens NOSAD- workshops!:
Jag ser idag att det behövs enormt mycket stöd dels hur saker designas men även då man upphandlar konsulttjänster för att designa saker. Saker blir löjligt dåliga med klipp och klistra i Word specar sedan skickar man en faktura på 16 miljoner och en svag uppdragsgivare tror dom köpt något som egentligen är 10 minuters jobb...
Har också fått intryck att saker ofta är slarvigt specificerade i Word-dokument med inklistrade skärmbilder av tabeller/listor och liknande, men det finns säkert goda exempel med.
Varför ser vi Öppna data API:er designas med textsträngar där konsumenten av API:et skall göra jobbet med att koppla det till things känns som rollen API designers måste kombineras med verksamhetskunskap och grundläggande kunskaper av kunskapsgrafer.... nu känns det lite 70-tal med csv filer, textsträngar och inga backloggar...
Min fetning av något som jag tycker sätter fingret på ett viktigt mätvärde för nyttan med ett API eller dataset. Hur mycket jobb behöver konsumenten lägga på att tillföra mening, konsistens och fungerande referenser till relaterad data, och som rimligen kunde funnits med när datasetet skapades?
Kunskapsgrafer är bra och kan såklart tillämpas när det är lämpligt. Jag personligen tycker dock att CSV och enkla APi:er är underskattade. En gammal hederlig fil med bestående identifierare för informationsobjekten och ett känd metod för att hämta ytterligare information från andra API:er kommer man långt med.
Ett problem med CSV verkar vara att variationer i formatet ofta kräver analys från konsumenten, vilket ger minuspoäng enligt resonemanget ovan om att belasta konsumenten med tolkningsarbete. Anses det rimligt att CSV publiceras med Win-1252 teckenkodning, semikolon-avgränsare och kommasepararerade talvärden t.ex. utan att metadata specificerar detta? Finns det standardiserade protokoll för att analysera sådana variationer i formatet automatiskt, eller krävs manuell besiktning och konfiguration för att tolka datan korrekt?