Community på Sveriges dataportal

@Maria_Dalhage Jag tror på något sånt här:

• Gå före och visa hur det ska göras. Börja kräva att vi inte ska uppfinna saker som inmatningsformulär med formatering gång på gång på gång.
• Upphandla spetsiga konsult-team (2-3 utvecklare, 1 ux:are och en agil coach) som jobbar i team tillsammans med era existerande utvecklare, ux:are och coacher så att ni kan höja kompetensen tillsammans
• Kräv öppen och länkad data(gärna 5-stjärnig!)
• Kräv att utvecklingen sker i det öppna om inte grava sekretesskrav åligger.
• Uppmuntra nyttjandet av existerande öppna lösningar(se t.ex mitt inlägg om dataportalen)
• Gör små piloter och upphandla med DIS
• Jobba iterativt istället för vattenfalligt.
• Teamet borde kunna lansera efter 2-3 veckor, annars bygger de för stort.
• Strunt i appar, bygg webbar eller API:er. Appar är slukhål för tid och ska användas i specifika fall.
• Fokusera på CI/CD så att leveranser kan ske löpande, gärna 25-30 gånger per dag.
• Gör alltid det som levererar mest värde i varje stund.
• Sluta fokusera på Java bara. Använd det verktyg som är lämpat för uppgiften.

@Maria-Söderlind och @Maria-Söderlind, jag förstår att @Magnus-Sälgö inlägg kan kännas svåra att ta till sig eftersom de alltid är lite spretiga med okompletta meningar och har många bilder och punktlistor och upplevs vara för fokuserade på annat (andra myndigheter som gör fel, wikipedia och wikidata). Jag har läst och fattat vad han skriver och jag tänker att jag ska försöka mig på ett annat grepp för att förklara andemeningen.

De 2 stora poängerna som jag ser kan förklaras på detta sätt:

• Alla grepp ni tar för att inkrementellt förbättra anser Magnus är bortkastade eftersom ni inte tänker om arkitekturen.
• Magnus menar inte att ni ska lägga tiden på att länka till wikipedia själva utan vara smarta med hur ni specar datan och hur den publiceras så att rättningar kan införas enkelt istället för svårt.

Sättet att ta sig dit kan vara t.ex. dessa:

• Läsa på om 5-star open data
• Ta en genväg genom att använda er av wikidatas stora register av "samma som" istället för att börja från scratch.
• Se till att ha beständiga unika identifierar för allting.
• Bygg en ny data-plattform som bygger på triplett-idén och definiera upp lämpliga tripletter. Det är otroligt kraftfullt!

Visionen

Det @Magnus-Sälgö försöker påskina är inte att hacka ned på er eller vara en klagans person. Utan visa på att visionen är fel. Han älskar att ni publicerar data men önskar att ni 2022 har kommit så mycket längre i att länka samman data och behandla data som data.

Visionen bör alltså vara att istället för att prata om enskilda funktioner som tar lång tid att bygga och som ni kanske inte prioriterar, bygga ett system som låter alla engagerade användare med lätthet förbättra datakvaliteten till höger och vänster.

Om ni är fast i att förbättra portalen istället för att bygga om
Tips: Fundera på hur ni löser länkningen och visualisering av länkning. Låt forumet vara sitt egna system. Skapa inte en till diskussionsplats i form av kommentarer där man ska uppfinna trådning, formatering med mera igen, det är ju redan gjort i communityt.

Ni kanske kan börja och ta er till 4-stjärnig data genom att:

• publicera alla datamängder, datamängdsgrupper, organisationer och organisationsgrupper i dataportalen i listor(i JSON såklart) på dataportalen.
• lägg till ett fält i forumets trådskapande del som är "Handlar om" som gör uppslag i datamängder, organisationer och grupper av datamängder eller organisationer från dataportalen. Detta fält ska naturligtvis referera till id't som objektet har i dataportalen.
• Länka från forumet till dataportalen i varje tråd med "HANDLAR OM [datapublikation]" och exponera listor per datamängd och organisation ifrån forumet så att ni i dataportalen kan fråga efter trådar som:
• handlar om datamängden
• handlar om organisationen
• handlar om datamängdsgruppen
• handlar om organisationsgruppen

Då kan ni länka från datamängdens sida till relevanta trådar på forumet — i de olika grupper av inlägg som är intressanta och relevanta för datamängden

Ni bör kunna skapa en knapp som säger diskutera datamängden på communityt som länkar användaren vidare till en trådskapande del med datamängden förvald i det nya fältet

Om ni kan tänka er att bygga om dataportalen

Då skulle jag föreslå något i denna stil. Där man drar nytta av triplett-tänket som wikidata pionjärat

Använd dessa tekniker som backend:

• En Wikidata som metadata-lagring i dess SparQL
• En självhostad gitlab där grunddatan publiceras. Varje organisation eller organisationsgrupp publicerar sina fasta data i ett repo, när datan uppdateras så blir det en commit och ändringarna är spårbara,
• Har man strömmande data så behöver den i sig såklart inte publiceras på gitlab utan accessvägarna beskrivas i repot's README istället.
• Samma frontend som idag, men som ställer frågor mot SparQL istället
• Låt frontenden få ett publikt "redigera"-läge som länkar små redigera-knappar till data entiteten i wikidatan istället.
• Låt SparQL-fråge-systemet vara publikt tillgängligt

Modellmässigt så borde t.ex. dessa entiteter skapas som items (Q-värden)

• Datamängd
• Organisation

Modellmässigt så borde t.ex. dessa entiteter skapas som egenskaper (P-värden)

• Publicerad av

Då kan vi t.ex. utrycka tripletten:

- Q"Sysselsatta efter utbildningstidens längd och näringsgren. År 1999 - 2003" är P"Publicerad av" Q"SCB"

- Q"Sysselsatta efter utbildningstidens längd och näringsgren. År 1999 - 2003" är en (is_a) Q"Datamängd"
- Q"SCB" är en (is_a) Q"Organisation"

Helt plötsligt kan vi då ställa SparQL-frågor som:

? P"Publicerad av" Q"SCB"
? is_a Q"Datamängd"

Och få tillbaka alla entiteter som är datamängder och publicerade av SCB.
Här sätter bara fantasin gränserna!

Effekterna

• Vi kan ställa godtyckliga frågor om datamängden som är sveriges dataportals datamängdsmetadata.
• Vi kan definiera godtycklig metadata om datamängderna och snabbt bygga ut funktionaliteten
• Vi får beständiga identifierare till datamängderna (Q-värden och commit-hashar på gitlab)
• Vi får beständiga identifierare till den transparenta helpdesk-funktionaliteten på gitlab.
• Varje datamängd har en egen helpdesk på gitlab
• Alla kan skapa en PR/CR(pull request/change request/ändringsbegäran) och peka på exakt vad som är fel i en fast datamängd direkt på gitlabben. Rättningen är då en knapptryckning bort.
• Och många många fler.

Slutligen:

• Har jag tolkat dig rätt @Magnus-Sälgö?
• Vart det begripligt @Maria-Söderlind och @Maria_Dalhage?
• Om ni inte klarar av det, speca gärna "Förlsag till hur en '5-star open data-länkad dataportal baserad på öppen källkod och byggd öppet med öppen källkod, som är användarvänlig och tillåter en öppen diskussion och beständiga identifierare' kan byggas" i en DIS så kommer det komma bolag till er undsättning.

@jonass sa i Offentligkod.se, Vad är behoven för sajten och hur samlar vi de i en öppen backlog?:

Jag hoppas inte dagen kommer då vi blir tvungna att sätta upp gitlab.arbetsformedlingen.se. Finns en stor styrka i att kunna nyttja befintliga plattformar som syftar till öppenhet.

Det bästa vore kanske en gitlab.sweden.se eller gitlab.europa.eu som varje land och dess myndigheter kan lägga sin kod på Sharing is caring så att säga.

@jonass sa i Offentligkod.se, Vad är behoven för sajten och hur samlar vi de i en öppen backlog?:

Konkret är Gitlab:s servrar uppsatta inom de amerikanska gränserna.

Tack för ett bra svar!

Det var absolut inte menat som en någon slags attack eller så, utan ett genuint undrande. Dock tycker jag du nämner en springande punkt här. Det är vart servrarna är placerade, inte vilken domän som är knuten till tjänsten.

@jonass Jag håller med dig om att gitlab/github är en rätt uppenbart farbar väg fram. Jag undrar vad det är som gör att @Nina_ och @josefinlassi uttalar sig som de gör. Jag förstår inte vad som skulle vara hindret med en .com-domän specifikt. Att hantera en backlog med Gitlab issues vore väl perfekt? Att snurra iväg på en wiki separat från där koden är placerad vore spretigt imho. Förstår nog inte riktigt vad en wiki tillför i detta? Man vill ju gärna kunna prioritera och hantera entiteter.

Det viktiga är väl att det finns en tydlig väg för andra att bidra till datamängden? Förslagsvis med en steg-för-steg-guide eller en programmatiskt mallad PR/MR som du kan länka till från sajten. Om du dessutom har CI/CD på plats så behöver du bara godkänna MR så är det ute. (Se ex.vis denna hur man kan malla PR/MR: https://sparkbox.com/foundry/better_pull_requests_merge_requests_with_templates)

@kristine_ ni säger att ni vill ta emot synpunkter på ett strukturerat sätt. Men ändå vill ni ha en enkät med fritext. Varför publicerar ni inte API-profilen som ett gäng markdown-filer i ett publikt repo på exvis github eller gitlab så att kommentarer kan göras i kontext?

”Tala till de lärde på de lärdes vis och till apor på apors vis”.

Jag vill passa på att berömma att ni öppnar upp för feedback i en såpass tidig fas ändå!🤩

@tomasmonsen angående CSV vs. JSON så håller jag med om att JSON vore att föredra.

Jag förstår ditt verksamhetsproblem med vart datan kommer ifrån. Om man bara vill komma igång så gör du ett JSON-Schema, klistrar in på https://www.jeremydorn.com/json-editor i "Schema"-rutan och då får du GUI högst upp.

Högst upp till höger har du en direkt-länk-skapande länk, när du matat in ditt JSON-schema så kan du länka in ditt JSON-schema i editorn och dela den länken med personalen som ska fylla i.

Process:

1. Personalen laddar om länken
2. Personalen fyller i formuläret
3. Personalen klickar på JSON-boxen högst upp.
4. Personalen kopierar JSON-koden och klistrar in i ert samlingsdokument/tabell
5. Nästa badplats, börja om från steg 1.

@salgo60 sa i Hjälp folk att bada i sommar med Öppna Data! (Tips och hjälp behövs):

@istyf du har en bra identitet i NUTS - Nomenklaturen för statistiska territoriella enheter (Wikidata property:P605) och det finns bra data hos Havs- och vattenmyndighetens i Sverige med API. Jag lägger nu upp dom badplatser dom definierat i Wikidata se github.com/salgo60/Svenskabadplatser

• Fundering skapar vi med Öppen Data massa data SILOS ser massa dataset om badplatser som laddas upp utan att referera NUTS --> blir massa DataSILOS känns feltänkt att dubblera det jobb som en myndighet med tydligt ansvar gör som en del av sitta uppdrag deras API har kopplingar till vattenprover etc. länk API detail request
• jag kopplar badplatserna till Open Street Map och även sociala medier, sjö ett bad finns vid, vilken landform den finns på oftast ö, om badet finns i ett Naturreservat....

Jag hade i veckan kontakt med Havs- och vattenmyndighetens i Sverige och citat

1: Ja det är unika persistenta ID som vi har, med reservation för att vi har flyttat enstaka bad från en kommun till en annan, då får badplatsen också ett nytt ID eftersom kommunens id-nr är del av ID:t. Samt om en kommun av någon anledning markerar ett bad som inaktivt och sedan registrerar ett nytt med samma namn och koordinater så kommer det ”nya” att ha ett nytt id. BORDE inte inträffa, men kan ju hända…

Är inte nyckeln i detta problem att det finns badplatser som inte havochvatten har prickat ut och hur en större mängd distribuerade organisationer som sedan skapar nya sådana identifierare utan att skapa id-krockar?

@jonor sa i Hjälp folk att bada i sommar med Öppna Data! (Tips och hjälp behövs):

@stefan-wallin [...] Jag förstår att Riksantikvarieämbetet håller reda på sina egna id-nummer, som refereras från Wikidata-objektet i ditt exempel, men jag förstår inte betydelsen av "lokala" i sammanhanget, innebär det att de inte är publicerade som URI:er, men kopplas till ett Q-nummer på Wikidata?

Med lokala så syftar jag helt enkelt på system-lokala unika persistenta identifierare. I kontrast till en global unik persistent identifierare. Med lokaliteten så syftar jag till att många olika organisationer kan ha sina egna identifierare utan att börja med någon slags sammanslagningar eller liknande då vi riskerar duplikat när andra organisationer identifierar samma objekt.

En global identifierare är en identifierare som många aktörer knyter sig till och riskerar skapa dubletter av i ett på något sätt publikt redigerbart system (inte nödvändigtvis wiki, kanske git-repo med PR eller annat system för kors-organisations-förändring). För att en global identifierare ska blir relevant krävs det att datan där håller hög kvalitet och accepteras av många organisationer inom samma bransch för kunna skaffa sig en sådan status.

Exempel på system som håller sådana globala identifierare skulle kunna vara OSM eller Wikidata.

Vi skulle även kunna resonera som så att vi i sverige vill ha ägande över en nationell persistent identifierare. En sådan skulle vi kunna kalla en regional eller nationell persistent identifierare. Där skulle t.ex. DIGG eller RAÄ sätta upp en egen wikibase-instans dit alla kommunala och regionala system knyter sina persistenta identifierare till. Denna wikibase-instans skulle sedan kunna vara en instans dit externa system som OSM eller wikidata knyter an till. Detta skulle också kunna möjliggöra korskoppling av datapunkter mellan olika myndigheter. T.ex. kanske lantmäteriet, en kommun och havochvatten vara intresserade av samma badplats. Då skulle kunna vara intressant att knyta ihop dessa system utifrån den nationella persistenta identifieraren.

@jonor den där introduktionen pratar ju om RDF som är 4e nivån i 5-star data. Länkad data är när vi kopplar ihop dem.

På wikidata har du till exempel det jag kallar "lokala identifierare" om vi tittar på https://www.wikidata.org/wiki/Q10717929 längst ned där du har RAÄ-nummer t.ex.

Läs gärna mer på 5stardata.info och ställ fler frågor om det är oklart.

@salgo60 Känns som att du bör skicka in ett mail som hamnar hos registratorn och ber de lämna ut persistenta identifierare eller kontaktuppgifter till den tekniska förvaltaren hos havochvatten snarare än att fastna i PR-maskineriet som är svenska myndigheters sociala-medie-konton.

@stefan-wallin Är man lite extra gnetig kan man nog slänga in alla bad som både OSM och havochvatten har plus de som VGR har i en postgis eller liknande och hitta vilka som skapar geo-konflikter och därmed hitta överlapp. Tyvärr har jag inte riktigt tid över i livet att göra det själv, men kan gärna rådge om någon skulle vara intresserad av det.

Jag svarar här också, svarade först på twitter: https://twitter.com/Stefan_Wallin/status/1387785992996859908

Är man gnetig så kan man nog mappa upp baden som @havochvatten (verkar inte finnas här på dataplattformen) använder i sin tjänst badplatsen.

En xml-fil med alla bad som havochvatten har koll på:
https://badplatsen.havochvatten.se/badplatsen/api/feature/

Där ser baden ut såhär:

<wfs:member>
  <hav-miljoovervakning:badplatsen gml:id="badplatsen.fid-58b61a0b_1791e1e86d2_2165">
  <hav-miljoovervakning:NUTSKOD>SE0441273000000001</hav-miljoovervakning:NUTSKOD>
  <hav-miljoovervakning:NAMN>Vesljungasjön</hav-miljoovervakning:NAMN>
  <hav-miljoovervakning:KMN_NAMN>Osby</hav-miljoovervakning:KMN_NAMN>
  <hav-miljoovervakning:PRTPG_GEOPOSITION>
    <gml:Point srsDimension="2" srsName="http://www.opengis.net/gml/srs/epsg.xml#4326">
      <gml:pos>13.7674095026078 56.4212500165633</gml:pos>
    </gml:Point>
  </hav-miljoovervakning:PRTPG_GEOPOSITION>
  </hav-miljoovervakning:badplatsen>
</wfs:member>

Den stora frågan är ju om man ska använda gml:id eller NUTSKOD som persistent identifierare. Om någon av dem nu går att lita på

NUTSKOD verkar ju i alla fall användas i deras kart-tjänst badplatsen, https://badplatsen.havochvatten.se/badplatsen/karta/#/bath/SE0441273000004182, så vi kan ju hoppas att det är en semi-persistent identifierare. Sen saknas ju många bad, men det är säkert en bra början.

@istyf sa i Hjälp folk att bada i sommar med Öppna Data! (Tips och hjälp behövs):

En metod för namngivningen kan till exempel vara någon form av namespace som se.toreboda.anlaggningar.badstrand.217

Vad syftar toreboda på, en kommun? Vad händer om kommunen slås ihop med grannkommunen, ska identifieraren ändras då? Isåfall är den inte persistent imho. Vad händer om anläggningen slutar vara kommununderhållen och istället överlåts i privat ägo, vad händer med källsystemet som håller referensen då? Är den fortfarande persistent?

Enklast är nog att försöka ha en gemensam referensdatabas över persistenta identifierare, t.ex. Wikidata

Sen kan man ha lokala persistenta identifierare också, men då behöver de kopplas ihop.

Är det någon som känner till en specifik standard för hur man kan uttrycka sina API-specar i ett maskinkonsumerbart format där fälten är entiteter à la länkade data men ändå har ett litet fotavtryck på överföringsmängden.

Säg t.ex att jag vill lägga upp ett API för att publicera nyhetsbilder(obs: inget som finns på någon roadmap hos oss!). Då skulle bilden kunna föreställa olika objekt typ personer och platser

Exempelvis skulle en bild av Ardalan Shekarabi kunna representeras såhär:

{
image: url,
caption: {
sv: “”
},
description: {
sv: “”
},
people: [
{
name: “Ardalan Shekarabi”,
sameAs: “Q4787806”,
}
]
}

Men hur gör man ett API som en länkaddata-aggregator kan förstå instinktivt snarare än ytterligare ett sätt att speca ett API?

@eric vart rapporterar jag brister? Har ni publicerat källan till specen på github eller gitlab eller så där vi kan anmäla issues, för diskussion eller komma med förbättringsförslag?

@josefinlassi sa i Kategorisera API:er efter datasort:

Och missförstod jag dig här ovan när du skrev att en "exclude funktionalitet", som del av en mer avancerad sök, ändå skulle göra det enklare att filtrera fram intressanta datamängder?

Jag tycker det är bra att ha, men är inne på samma linje som @salgo60 att bygga varje sätt att filtrera en i taget är lite synd att ni ska behöva lägga tid på. Snarare är det bättre att ha eller skapa ett generellt sätt att ställa valfri filtrering av valfri metadata-punkt om api:erna.

Jämför gärna med wikidata query eller med prisjakt som har väldigt många olika flexibla sätt att filtrera en stor databas på baserat på just metadata.

@sven-erik beroende på hur stora datamängderna är så skulle jag överväga att bara publicera på samma plats men göra filen längre med fler objekt i den yttre arrayen som får representera varje månadsschok.

Alternativt så publicerar ni filer maskinläsbart på förutsägbara urlar:
2021-01.json
2021-02.json
2021-03.json
Et.c.

Jag rekommenderar att inte komplicera det så mycket och bara göra rådatan tillgänglig till en början, gärna med en v1 i pathen så att ni kan versionera API:et ifall ni ändrar formatet framgent.

@josefinlassi lite synd att ni känner att ni måste jobba vidare med en exclude-funktionalitet. I en korrekt vald arkitektur så skulle, som @salgo60 redan påtalat, det redan fungera.

T.ex. om ni skulle ha en wikibase-installation som bas så är det bara ytterligare ett attribut som ni kan lägga på och det måste inte finnas på alla API:er. Då skulle vi kunna låta våra pengar gå till exempelvis att bygga wikigames som hjälper administratörer och frivilliga att fylla i uppgifterna i schyssta gui och låta API-nyttjare filtrera med sparql-frågor, eller till och med bygga schysta sparql-filtrerings-gui:n

"antal datapunkter" är på sätt och vis ett konstigt attribut eftersom det oftast ändrar sig över tid. Även antalet kommuner har ju ändrats över tid (1952 var det över 2000 kommuner i Sverige). Det är ju även så att inte bara storleken utan även hastigheten är intressant för att uppfatta eventuella skalningsproblem eller om datan är omfattande nog.

För "dessa datamängder bygger på samma specifikation" så är du ju inne på det som @salgo60 pratar om när det gäller persistenta identifierare av specifikationen och en referens till den identifieraren bör finnas med i filtreringsurvalet och data-mängden.

@salgo60 Det är en separat tråd i mina ögon. Starta gärna en tråd om det. Superviktigt ämne, men det har inget att göra med "hitta ett intressant dataset i en okänd mängd av dataset". Ur ett systemförvaltarperspektiv är det såklart intressant men det ser jag inte som samma use case och det är heller inte syftet med min fråga. Att dataset är ihopkopplade över världen löser ju nämligen inte heller mitt problem.