Hej, jag tittade på leverantörsfakturor.csv från DIGG.

https://www.dataportal.se/sv/datasets/760_1544/leverantorsfakturor

Det verkar som textfilen har en systemspecifik kodning (Windows-1252 eller ISO-8859-1?).

I metadatan står att formatet är text/csv, men jag hittar inte någon information om teckenkodningen.

Webbadress för åtkomst
https://catalog.digg.se/store/1/resource/33
Format
Vanliga mediatyper
CSV (.csv)

Borde inte teckenkodningen vara UTF-8 eller anges uttryckligen i metadatan så att konsumenten kan avkoda innehållet korrekt?

Lade märke till också att frågan om en standardteckenkodning togs upp i utkastet till specifikation för badplatser som refererades i en annan tråd:

6 . CSV-formatet
Det enklaste formatet att stödja är CSV formatet enligt RFC4180.
Utöver det som sägs i RFC4180 krävs alltid att informationen är uttryckt med teckenkodning UTF-8.

@björn-hagström DIGG verkar ju använda GitHub, men jag har sett att en del offentliga verksamheter använder GitLab också, kan det vara så att GitLab föredras/rekommenderas med tanke på juridiska aspekter? Intressanta frågor som kanske förtjänar en egen tråd.

@josefinlassi Ja det låter ju som identifierare bör ligga under något namn avsett för registerföring och mer långsiktig förvaltning, då ligger kanske arkivmyndigheter eller dataförvaltare nära till hands. Jag gissar att det klarnar mer när man börjar använda URI:er och ställa frågor mot dem eller vill koppla ihop dem för egen del. Om DIGG ska stödja och hjälpa organisationer i detta behöver man nog kunna förklara hur det fungerar, gärna inbegripande exempel och fallstudier. Tack för tipsen om rekommendationer.

Apropå trådämnet, har dataportalens API-register URI:er och kopplingar till Wikidata?

@kristine_ Ok, innehållet kanske borde ses över lite i en del andra avseenden också.

En del fakturanummer verkar ha formaterats som talvärden med vetenskaplig notation.

Här en icke kredit-faktura med negativt belopp? Jag vet inte om sånt händer, men det var ett udda fall i posterna.

I samband med det undrar jag också om talformatet för kolumner finns angivna i metadatan, eller hur vet man vid maskin-inläsning om komma eller punkt används som decimalavgränsare?

@nina_ Jag tror en bidragande orsak till att tonen kan verka hård eller kritisk är att det skrivs så lite här från DIGG eller representanter från andra offentliga verksamheter. Många frågor som som riktar sig till offentliga verksamheters aktiviteter på området ignoreras och lämnas obesvarade vilket blir en källa till frustration för den som hoppas på information om eller inblick i den eventuella utvecklingen. Forumet kan förefalla ganska övergivet och mer som en bock i någon checklista, eller en annonstavla för interna verksamheter, än något allvarligt menat försök att kommunicera öppet. Jag är faktiskt förvånad över det låga intresset från DIGG själva som driver dataportalen att besvara eller engagera sig i diskussionerna här. Tycker ni att engagerade användare av datamängder och API:er bara ska diskutera sinsemellan här får ni nog räkna med att det klagas en del över att den ena sidans huvudaktörer i ekvationen lyser med sin frånvaro.

Om ni vill se ett bättre klimat här tror jag det är värt att satsa på ökad närvaro och att visa ett intresse i att diskutera och besvara synpunkter och återkoppling från intresserade användare.

Så länge det inte rör sig om personangrepp ska väl annars en offentlig institution kunna tåla ett visst mått av kritik från missnöjda medborgare, och utöver att endast klaga på tonläge eller ordval också försöka bemöta detta med en trovärdig argumentation och vilja att föra resonemang kring de tjänster man producerar.

Ni kan gärna försöka förtydliga syftet med det här forumet annars, vilka typer av frågor och svar som är lämpliga att dryftas här, jag har själv undrat om jag kanske har missuppfattat det.

@maria_dalhage Är det konsultbyråer som skriver rapporterna? Det ser ut att vara mycket management-terminologi och maskinöversatt engelska i texten tycker jag.

@ainali sa i Identifierare och relationer:

@jonor sa i Kategorisera API:er efter datasort:

Apropå trådämnet, har dataportalens API-register URI:er och kopplingar till Wikidata?

Vad tänker du att de ska koppla mot/länka till? Olika datasorter i Wikidata (exempelvis Q7300787 (realtidsdata) )?

Jag tänker mig t.ex. att det kan gå att hitta datamängder jag är intresserad av via Wikidata. Jag provade att söka efter kommunernas dataportaler och fick upp en lista där bl.a. Stockholms dataportal dök upp. Där kunde jag sedan leta vidare efter data.

https://w.wiki/3HTp

Sedan vore det intressant att veta om jag kan inkludera den nuvarande nationella dataportalen i sökningen också.

Dock ser ämnesmärkningen i de nationella portalerna ganska sporadisk och ojämn ut så långt jag sett. Jag föreställer mig att det kunde finnas möjligheter till friare kategorisering och koppling, och mer kraftfulla och enhetliga sökverktyg, om informationen finns representerad på Wikidata.

Jag tänker också på fallet där jag skulle vilja hitta datamängder av samma typ från Sverige och andra länder som jag skulle vilja göra jämförelser mot.

Jag vet inte hur informationen om kommunernas dataportaler hamnat i Wikidata, om det är av ideella krafter eller offentligt sanktionerat, men jag tycker det verkar värdefullt att den kan göras åtkomlig där för meta-sökning över spridda informationskällor.

Frågan om realtidsuppdateringar är väl också intressant. Samlas data in löpande till Wikidata från public service och andra som publicerar nyhetsartiklar och media t.ex.?

Det ser ut som det går att skapa egna etiketter för nya trådar i forumet.

Samtidigt som man skapar en tråd under en existerande huvudkategori kan man ju då lägga till en etikett för den kanal man vill samla inläggen inom, och senare nå den via sidan för "taggar", eller via etiketten i trådrubriken.

Exempelvis finns redan etiketter för NOSAD, Internetstiftelsen, regioner, kommuner m.fl.

Etiketter visas i inläggsrubriker:

@salgo60-ej-aktiv Aha ok, hade inte sett uppföljningen. Det gäller då att veta lite mer om hur systemet samlar ihop datan när man konstruerar frågor.

Med etiketter:
https://tinyurl.com/ye8lt2u2

@josefinlassi

appropå persistenta identifierare så har vi med det i vägledningen för att tillgängliggöra information.

Innebär det att man ska äga ett domännamn för att skapa identifierare, eller hur ser praxis ut? Finns det exempel på hur detta tillämpas och organiseras?

https://www.digg.se/utveckling-av-digital-forvaltning/oppna-och-delade-data/offentliga-aktorer/vagledning-tillgangliggora#forbered_informationsmangden_for_anvandning

Beständiga identifierare bör utformas som URI:er, (Uniform Resource Identifier), enligt formatet:
http(s)://{domän}/{typ}/{koncept}/{referens}
Inom vissa sektorer/områden kan det vara relevant med specifika typer av identifierare.

@vesstrom Tack, jag ser gärna en öppen dialog då jag även är intresserad av att ta del av andras synpunkter och erfarenheter och följa diskussionen.

@vesstrom Jag förstod utan större problem det övriga innehållet på sidan om hypermedia fram till det sista stycket. Där introduceras plötsligt begreppet "händelser" utan någon särskild motivering när man tidigare pratat om transaktioner, länkrelationer och typer.

Jag gick direkt in på sidan om hypermedia, så jag vet inte om man möjligen refererar underförstått till något som tas upp i andra delar av API-handledningen. Eller handlar det om att överföra befintliga RPC-liknande API:er till ett hypermedia-baserat gränssnitt?

De exempel som förekommer på sidan handlar om organisationer och kontotransaktioner, och där det gäller egna relationstyper anges svenska uttryck som "insättning" och "uttag" (är det realistiska exempel?).

Varför inte i så fall nämna "insättning, uttag och överföring" som exempel på domänspecifika typer då de redan tagits upp i ett sammanhang. Om nu detta också utgör ett exempel på vad man vill kalla "händelser" så kanske det uttrycket kan nämnas redan där det finns en kontext, t.ex. koppla det till ordet "transaktioner" som annars verkar användas för exemplen med "insättning", "uttag", "överföring", "edit", "replace", "delete".

"Olika typer av händelser" skulle kanske tydligare beskrivas av "representera domänspecifika händelseorienterade operationer som relationstyper/transaktioner" eller något liknande, och samtidigt referera till exemplen med kontotransaktioner (domänspecifika) och organisationer (standard).

Något som också är oklart är varför det är asterisker i relationstyperna, är det kanske ursprungligen märkspråk för fetstil i exemplet?

Inklistrat som vanlig inläggstext:

{"rel": " insättning", "href":"/konton/12345/insattning"},
{"rel": " uttag", "href":"/konton/12345/uttag"},
{"rel": " överföring", "href":"/konton/12345/overforing"}

{
     "kontonummer":"12345",
     "balans": 100.00,
     "_links":[
         {"rel": " **insättning**", "href":"/konton/12345/insattning"},
         {"rel": " **uttag**", "href":"/konton/12345/uttag"},
         {"rel": " **överföring**", "href":"/konton/12345/overforing"}
     ]
}

{
  "kontonummer":"12345",
  "balans": -25.00,
  "_links":[{
    "rel": "insättning",
    "href":"/konton/12345/insattning"
  }]
}

@kristine_ Vad menas med användande av händelser och motsvarande händelsenamn i detta stycke? Det känns lite taget ur sitt sammanhang, så det vore bra med något exempel. Jag kan inte hitta namnen i den lista från IANA som refereras?

https://dev.dataportal.se/sv/rest-api--profil/hypermedia/#link_relation_type

Vid användande av olika typer av händelser, ska motsvarande händelsenamn användas som Link Relation Type ( t.ex. activate , cancel , send , …).

@dennis_priskorn sa i Statens budget som länkad data?:

@dennis_priskorn sa i Statens budget som länkad data?:

Det finns lösningar för metadata-städning, men min gissning är att inga/få av våra myndigheter har koll på denna risk i dagsläget...

Skickade just en epost till Regeringskansliets IT-säkerhetschef Jens Storberget och frågade om de har koll på risken med PDF. Han har varit många år på FRA så han har nog koll, men i mina ögon är PDF inte värt riskerna när det finns bra alternativ som tex. TXT i Markdown format som kan exporteras direkt från ordbehandlare och garantera noll läckning av metadata och dessutom är mycket lättare att maskinavläsa.

Säkerhetsstrategin på regeringskansliet kanske består i att inte svara på några frågor, security by obscurity.

https://sverigesradio.se/artikel/ekot-kunde-mejla-som-forsvarsministern

I ett mejl skriver Regeringskansliets säkerhetschef Fredrik Agemark de inte kan gå in på hur säkerhetsarbetet ser ut, men att de har olika säkerhetslösningar och anpassar åtgärderna efter olika risker.

@jonass Jag har inte någon praktisk erfarenhet, men såvitt jag förstått verkar HATEOAS påminna mer om hur webben redan fungerar. I det avseendet borde det ju kännas mer intuitivt eller bekant för en användare, och utvecklingsmässigt mer likna designen för en webbplats eller webbapplikation där klienten är en webbläsare. Att gå från inget API direkt till HATEOAS kanske i så fall kan vara enklare än att bygga om ett befintligt API med statisk specifikation?

Projektet med SL:s nya API verkar visserligen ha drabbats av förseningar, om nu detta kan ha ha att göra med valet av API-design är svårt att veta såvida de inte rapporterar öppet om utvecklingsarbetet.

https://www.trafiklab.se/news/2020/2020-06-26-new-sl-apis/

The API is RESTful and supports HATEOAS implying simpler error handling and navigation of information.

The new SL API ”Public transport information Region Stockholm” replacing today’s 7 SL APIs at Trafiklab

The new SL API has been delayed to Q1 2021. We will update you when we know more.

SL launched its first open APIs in 2014 and today there are 7 APIs with a functionality that has gradually been extended. These services have been used extensively, and SL has received valuable feedback that has been used as part of the basis for the design of the new open SL API.

Ni kanske borde ha "samma som" för nedanstående etiketter i forumet?

• https://community.dataportal.se/tags/öppna data
• https://community.dataportal.se/tags/öppen data

@angela Görs det någon uppföljning angående detta, finns det innehåll eller slutsatser att ta del av? Jag kan inte hitta något om det på webbplatsen.

https://www.esv.se/utbildningar-och-seminarier/seminarier-och-konferenser/datalabbet-resultaten-i-staten/

11.20 Hur fortsätter vi framåt?

Clas Olsson, generaldirektör ESV

@siha Jag skulle gärna vilja ha geometri för körvägar och spårvägarnas sträckning när det gäller lokaltrafiken, så turerna/linjerna kan läggas ut på en stadskarta.

Exempel för Stockholm med geografiskt korrekta linjesträckningar:
https://mitt.sl.se/resources/maps/geographics/2020/view.aspx?id=7510.Innerstan&name=Stockholms innerstad

@salgo60-ej-aktiv sa i Textdata och delning av statliga utredningar för maskinell analys:

Så myndighetsvisionen är presentera text som text inte med layout.... känns mer 1985 än 2021... man var till och med inne och snurra på att HTML som också är layoutorienterat skulle vara en väg framåt.... känns som DIGG borde vara ett kompetenscenter som deltar och pekar med rak hand...

Trots allt, HTML och Markdown är väl textformat som ligger nära till hands för att publicera strukturerade dokument på en betydligt högre nivå än PDF, med stöd för tabelldata, länkar och relationer mellan dokument. Wikidata beskriver ju information om och referenser till resurser, medan resurserna existerar i form av webbsidor som exempelvis artiklar på Wikipedia.

Finns det några tankar eller rekommendationer kring HATEOAS i relation till OpenAPI/Swagger angående självbeskrivande API:er?