Sveriges dataportal, DIGG - Myndigheten för digital förvaltning
Sök data Nyheter Om oss Community
  • Hem
  • Kategorier
  • Senaste
  • Taggar
  • Populära
  • Användare
  • Grupper
  • Sök
  • Ser ut som din anslutning till %1 gick förlorad, vänta medan vi försöker att återansluta.
  • Registrera
  • Logga in

Navigering

    1. Hem breadcrumb link
    2. Stefan Wallin
    • Profil
    • Följer 0
    • Följare 1
    • Ämnen 3
    • Inlägg 27
    • Bästa 16
    • Grupper 0

    Stefan Wallin

    @Stefan Wallin

    Senior utvecklare i privat sektor boendes i Sundsvalls-området. Har åsikter, förmedlar dem på Twitter: https://twitter.com/Stefan_Wallin

    25
    Rykte
    18
    Profil-visningar
    27
    Inlägg
    1
    Följare
    0
    Följer
    Gick med Senast online
    Webbsida www.stefan-wallin.se Plats Sundsvall

    Stefan Wallin Sluta följ Följ

    Bästa inläggen skapade av Stefan Wallin

    • RE: Förslag till nationell API-profil på Utvecklarportalen

      @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å!👏👏🤩

      postat i Data
      Stefan Wallin
      Stefan Wallin
    • RE: Communityskapande i Dataportalen - fler funktioner eller inte?

      @Jonas-Nordqvist jag tror du missförstår mig och Magnus. Visst har vi åsikter om datakällorna som publiceras på dataportalen, men ämnet här är ju att diskutera ett förslag till communityskapande funktioner i dataportalen. Våra invändningar i stort är att istället för att bygga kommentarer frikopplat från datamängden bör man fundera på hur livscykeln runt de publicerade datamängderna fungerar och hur man jackar in communityt där om man faktiskt är seriös på att uppnå en fungerande engagerade community.

      Jag(och förmodligen även Magnus) menar att dataportalen borde vara en datamängd i sig som kan dra nytta av att visa vägen för hur OpenSourcekulturen kan anammas i datapublikation.

      Tänker direkt tillbaka på en annan funktion man bad om återkoppling på (filtrering och gruppering av data-källor där det från DIGG's önskan vara att begränsa till något smalt och unikt istället för brett och sammanlänkat)

      I det fallet man är seriös på målet fungerande community snarare än på målet bygga en kommentarsfunktion, så kanske man ska fråga sig vad det är för interaktioner communityt är intresserad av att bidra med.

      För mig är det viktiga i publicerad grunddata:

      • att den håller hög kvalitet.
      • att varje enskilt dataobjekt går att länka till och från som "samma-som"
      • att existerande fel pekas ut tydligt
      • att processen runt datan går att lita på
      • att datamängderna går att hitta

      För att uppnå detta behövs:

      • att varje objekt i datan går att referera till otvetydigt med korrekta persistenta identifierare
      • att felrättningar kan skötas transparent så att datan går att lita på & processen för att skicka in rättningar blir tydlig
      • att det går att berika datamängderna med metadata från communityt så att fler kan hitta dem.

      Vart det tydligt eller oklart?

      postat i Feedback på dataportal.se
      Stefan Wallin
      Stefan Wallin
    • RE: Anonym användning av öppna apier

      @jonass

      Behovet av API-nycklar
      Jag har lite svårt att förstå syftet med varför API-nyckeln ska behövas. Min magkänsla är snarare att detta är någon slags säkerhetsteater. Dessa är de potentiella syften jag kan utläsa:

      1. Möjlighet att ur ett driftsäkerhetsmässigt sätt begränsa trafiken mot användare
      Om vi inte kan kräva en registrering med identifiering före uthämtning av API-nyckel så finns inte heller en realistisk teknisk möjlighet att med hjälp av API-nyckeln effektivt strypa påverkan på driftsäkerheten. Med min erfarenhet av bl.a. DDOS-attacker på några av sveriges största nyhetssajter så kan jag säga att det bästa sättet är utan tvivel att samarbeta med stora DDOS-skydd eller helt enkelt göra tjänsten så snabb och uppskalad att driften ändå inte blir problemet man behöver lösa med API-nyckeln.

      Exempelvis med den föreslagna lösningen så ska nycklar inte krävas för tillgång. Då kan man tänka sig att en försvarsmekanism är att när man utsätts för problematisk trafik tillfälligt blockera all trafik som inte har API-nyckel och bara servera till de med API-nycklar. Problemet är att en attackerare kan göra så att det ser ut komma från nästan vilket IP-nummer som helst och dessutom slumpa vilket IP-nummer som används för varje förfrågan. För varje förfrågan så kan även en attackerare generera upp en ny slumpad nyckel eftersom nyckelrymden är stor.

      I övrigt anser jag att rate-limiting i kombination med en uppskalad tjänst är hygiennivån för ett öppet konsumerat API precis som @salgo60 föreslår.

      2. Möjlighet att debitera för högre servicenivå
      I din lösning har du angett alla parametrar som en användare behöver för att med relativt hög grad kunna tillförlitligt gissa sig till en användares API-nyckel(hashas url till användarkonto), det räcker med att jag skapar ett eget konto med en API-nyckel och testa mig fram till vilket krypto som används eftersom jag har all kunskap som behövs eller kan tillämpa statistiska metoder för att gissa salt med mera motmetoder.

      En alternativ lösning (eftersom centraliserad öppen-data-api-nyckel är en bra idé om API-nyckel krävs för tillgång) skulle kunna vara genererade 2stycken uuid (client_id och client_token) som är helt slumpade men lagrad på ditt community-konto.
      Isåfall måste en lista med priviligerade tjänster och deras token etableras som får verifiera client_id och client_token mot en api-nyckels-verifierande tjänst etableras som övriga myndigheter(de priviligerade tjänsterna) kan använda.

      En vidareutveckling på en sådan lösning skulle kunna vara att den centrala tjänsten tillhandahåller samtliga API-nycklar som en data-källa och en webhook-baserad lösning(förmodligen med en AMQP eller liknande lösning i botten som data-garant) för att kontinuerligt informera de priviligerade tjänsterna om nya och borttagna API-nycklar. Detta skulle lösa ett problem med driftsäkerheten för att vi inte har en single point of failure(SPOF) i API-nyckel-verifierings-tjänsten utan varje myndighet kan ha sin egen instans av den gemensamt ägda öppen-källkods-tjänsten.

      Om vi inte skulle se denna API-nyckelslösning som en autentiseringslösning öppnas nämligen en potentiell attackyta där en elak 3:e part kan överanvända api-användarens nyckel vilket beroende på debiteringsmodell kostar den godartade användaren pengar utan att så menades.

      3. Möjlighet att för registrerade betalande kunder hålla en separat instans
      Detta är en solid anledning att använda någon form av teknisk autentisering eller identifiering. Så att inte en attackerande part påverkar de betalande 3:e parternas prestanda likt det klassiska noisy-neighbour-problemet som är vanligt inom moln-infrastruktur.

      Angående val av headers

      FROM-headern
      Jag tycker detta verkar vara ett missbruk av en existerande header. Att använda en header på ett sätt som det inte är avsett är generellt inte att rekommendera. Om ni väljer att skapa upp e-post-adresser som client-id så kan det vara en god idé. T.ex:
      <user-uuid>@api-users.dataportal.se. Jag skulle rekommendera att använda from-fältet i kombination med Authorizationfältet som kan innehålla en token, exempelvis en JWT-token om ni vill på något vis scope:a token till vissa öppna API:er då ni kan skicka med scopes i JWT-tokenen och dela den nyckeln till den kryptokrafiska hashen av JWTn's innehåll med priviligerade tjänster.

      Det står utryckligen i MDN:

      You shouldn't use the From header for access control or authentication.

      I HTTP-standarden är det ganska tydligt att det borde vara en e-post-adress.

      The "From" header field contains an Internet email address for a
      human user who controls the requesting user agent. The address ought
      to be machine-usable, as defined by "mailbox" in Section 3.4 of
      [RFC5322].

      postat i Data
      Stefan Wallin
      Stefan Wallin
    • RE: Hjälp folk att bada i sommar med Öppna Data! (Tips och hjälp behövs)

      @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.

      postat i Efterfråga data och API:er
      Stefan Wallin
      Stefan Wallin
    • RE: Hur skyndar vi på digitaliseringen?

      @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.
      postat i Arbetssätt och organisation
      Stefan Wallin
      Stefan Wallin
    • Federerade persondata-API:er

      Jag skulle vilja få tillgång inte bara till öppna data, utan också skyddad data men som handlar om mig själv, så jag kan bygga tjänster där medborgarna kan utgå från sin egen data.

      Exempelvis skulle jag vilja:

      • kunna begära ut vilka personnummer och organisationsnummer jag har rätt att agera ombud åt.
      • kunna hämta ut min vab-kalender från FK så att den kan integreras med min kalender
      • kunna hämta ut min skattedata

      Ett förslag till hur detta skulle kunna fungera är att DIGG hjälper till att samordna ett sätt att där jag som medborgare med hjälp av e-legitimation kan genomgå en oauth-liknande flöde och ge en tjänsteanvändare möjlighet att ge en tjänst tillgång till min och de entiteter jag är ombud för's persondata eller organisationsdata inom det offentliga. Det bör kunna finnas ett enhetligt sätt att göra detta snarare än att varje myndighet ska ta fram detta själva.

      postat i Efterfråga data och API:er
      Stefan Wallin
      Stefan Wallin
    • RE: Hur skyndar vi på digitaliseringen?

      @Jonas-Nordqvist jag vet inte riktigt hur du vill att jag ska tolka ditt svar, menar du att jag skulle behöva jobba som IT-chef i en politiskt styrd organisation för ”att få perspektiv” på mina orimliga åsikter?

      Eller menar du kanske att alla som jobbar nu har en annan lista med svar än min? Eller kanske rent av samma lista med svar men får ändå ”inget” gjort?

      Oavsett tänker jag att regeringen pekat ut riktningen för länge sedan: ”…Sverige ska bli bäst på digitalisering…” men nuvarande arbetssätt ger inte det resultatet är min observation. Vi har bett om postnummer som öppna data i över 15 år nu…

      postat i Arbetssätt och organisation
      Stefan Wallin
      Stefan Wallin
    • RE: Specifikation för leverantörsreskontra klar

      @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?

      postat i Öppna standarder och format
      Stefan Wallin
      Stefan Wallin
    • RE: Offentligkod.se, Vad är behoven för sajten och hur samlar vi de i en öppen backlog?

      @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)

      postat i Öppen källkod
      Stefan Wallin
      Stefan Wallin
    • RE: Hjälp folk att bada i sommar med Öppna Data! (Tips och hjälp behövs)

      @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.

      postat i Efterfråga data och API:er
      Stefan Wallin
      Stefan Wallin

    Senaste inläggen av Stefan Wallin

    • RE: Hur skyndar vi på digitaliseringen?

      @Jonas-Nordqvist jag vet inte riktigt hur du vill att jag ska tolka ditt svar, menar du att jag skulle behöva jobba som IT-chef i en politiskt styrd organisation för ”att få perspektiv” på mina orimliga åsikter?

      Eller menar du kanske att alla som jobbar nu har en annan lista med svar än min? Eller kanske rent av samma lista med svar men får ändå ”inget” gjort?

      Oavsett tänker jag att regeringen pekat ut riktningen för länge sedan: ”…Sverige ska bli bäst på digitalisering…” men nuvarande arbetssätt ger inte det resultatet är min observation. Vi har bett om postnummer som öppna data i över 15 år nu…

      postat i Arbetssätt och organisation
      Stefan Wallin
      Stefan Wallin
    • RE: Communityskapande i Dataportalen - fler funktioner eller inte?

      @Jonas-Nordqvist jag tror du missförstår mig och Magnus. Visst har vi åsikter om datakällorna som publiceras på dataportalen, men ämnet här är ju att diskutera ett förslag till communityskapande funktioner i dataportalen. Våra invändningar i stort är att istället för att bygga kommentarer frikopplat från datamängden bör man fundera på hur livscykeln runt de publicerade datamängderna fungerar och hur man jackar in communityt där om man faktiskt är seriös på att uppnå en fungerande engagerade community.

      Jag(och förmodligen även Magnus) menar att dataportalen borde vara en datamängd i sig som kan dra nytta av att visa vägen för hur OpenSourcekulturen kan anammas i datapublikation.

      Tänker direkt tillbaka på en annan funktion man bad om återkoppling på (filtrering och gruppering av data-källor där det från DIGG's önskan vara att begränsa till något smalt och unikt istället för brett och sammanlänkat)

      I det fallet man är seriös på målet fungerande community snarare än på målet bygga en kommentarsfunktion, så kanske man ska fråga sig vad det är för interaktioner communityt är intresserad av att bidra med.

      För mig är det viktiga i publicerad grunddata:

      • att den håller hög kvalitet.
      • att varje enskilt dataobjekt går att länka till och från som "samma-som"
      • att existerande fel pekas ut tydligt
      • att processen runt datan går att lita på
      • att datamängderna går att hitta

      För att uppnå detta behövs:

      • att varje objekt i datan går att referera till otvetydigt med korrekta persistenta identifierare
      • att felrättningar kan skötas transparent så att datan går att lita på & processen för att skicka in rättningar blir tydlig
      • att det går att berika datamängderna med metadata från communityt så att fler kan hitta dem.

      Vart det tydligt eller oklart?

      postat i Feedback på dataportal.se
      Stefan Wallin
      Stefan Wallin
    • RE: Communityskapande i Dataportalen - fler funktioner eller inte?

      @Maria-Söderlind delvis även dig, framförallt din kommentar om:

      Att kommunerna ska lägga resurser på att koppla ihop sitt öppna data med WD - känns det verkligen korrekt? Är det verkligen detta de kommunala pengarna ska läggas på?

      Vad jag ville kommunicera, men kanske missade att tydliggöra. Är att det inte alltid måste vara Wikidata som organisation offentlig sektor(ni?) ska samarbeta med och lägga tid på, utan att ni kan skapa er egna Wikidata och webbbaserade Git-repon när ni publicerar data och därmed enkelt och strukturerat kunna ta emot feedback, rättningar OCH HJÄLP från engagerade medborgare. Därmed skulle ni slippa göra allt jobb själva och istället utnyttja kraften i Crowdsourcing. Superbra framförallt när det gäller alla sorters kartdata eller kart-knuten data som representeras av fysiska ting i vår omvärld(bad, gym, skolor, skolmåltider med mera kan alla ses som kartdata). Men just ihopkopplingen som wikidata är så bra på är något offentlig sektor behöver bli mycket bättre på. Här menar Magnus och jag att en genväg ni kan ta är att använda en wiki som bassystem istället för att uppfinna egna som kostar dyrbar utvecklingstid och långa inköpsprocesser.

      Så istället för att lägga tid på att koppla ihop egen data med Wikidata så kan ni ge medborgarna verktyg för:

      • att skapa SammaSom-kopplingar som ni kan godkänna med en knapptryckning
      • att använda riktiga persistenta unika identifierare som kan kopplas mot externt
      • att använda existerande öppen källkods-mjukvaror för helpdesk-ärenden med egna persistenta identifierare. Dessa ärenden bör kunna vara helt publika och transparenta. Inspireras gärna av Github/Gitlab eller använd en egenhostad Gitlab för ändamålet.

      Här @Maria_Dalhage kan DIGG ta ledartröjan och tillhandahålla mjukvaran där resterande offentlig sektor kan bjudas in och agera. Skapa primära offentliga kontaktvägar och rekommenderade metoder.

      postat i Feedback på dataportal.se
      Stefan Wallin
      Stefan Wallin
    • RE: Hur skyndar vi på digitaliseringen?

      @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.
      postat i Arbetssätt och organisation
      Stefan Wallin
      Stefan Wallin
    • RE: Communityskapande i Dataportalen - fler funktioner eller inte?

      @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.
      postat i Feedback på dataportal.se
      Stefan Wallin
      Stefan Wallin
    • RE: Offentligkod.se, Vad är behoven för sajten och hur samlar vi de i en öppen backlog?

      @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.

      postat i Öppen källkod
      Stefan Wallin
      Stefan Wallin
    • RE: Offentligkod.se, Vad är behoven för sajten och hur samlar vi de i en öppen backlog?

      @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.

      postat i Öppen källkod
      Stefan Wallin
      Stefan Wallin
    • RE: Offentligkod.se, Vad är behoven för sajten och hur samlar vi de i en öppen backlog?

      @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)

      postat i Öppen källkod
      Stefan Wallin
      Stefan Wallin
    • RE: Förslag till nationell API-profil på Utvecklarportalen

      @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å!👏👏🤩

      postat i Data
      Stefan Wallin
      Stefan Wallin
    • RE: Hjälp folk att bada i sommar med Öppna Data! (Tips och hjälp behövs)

      @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.
      postat i Efterfråga data och API:er
      Stefan Wallin
      Stefan Wallin