Se linked in. Jag driver 2 företag i dagsläget.
Inspirerad av FK och DIGG enligt dokumentet. Heja Norrland! 
https://github.com/Sundsvallskommun/riktlinjer-oppenkallkod/blob/main/riktlinje/README.md
Bliver spännande att se vilken myndighet som är först ut med open source officer eller Wikimedian-anställd... Jag har sett en som nyligen lagt ut annons för halvtids Wikimedian. Mycket positivt, hoppas de hittar nån!
@björn-hagström sa i Önskemål: Ny rekommendation från DIGG om API:ers koordinatsystem:
Så din slutsats är att offentlig sektor inte ska arbeta med kunskapsgrafer?
Intressant fråga. Nu är den tyvärr lite för generell för att den går att svara på. Överlag skulle jag personligt säga att när stora organisationer som WMF brottas lite med att få till sin graf (och likaså KB, om än något mindre lyckat om ni frågar mig) så bör en offentlig organisation vara beredd på att ta in nytt folk med rätt kunskaper för att kunna göra det bra.
@magnus och jag tvivlar på att den kunskapen finns idag inom offentliga organisationer. Regeringen skulle kunna be DIGG göra ett grafcampus/grafexpertcenter där olika grafdatabaser testas och där kunskap byggs upp och som andra myndigheter sen kan lära sig från och luta sig mot när det behövs.
Grafer är annorlunda jämfört med RDBMS-system och har många fördelar, men det finns även falluckor och utmaningar med att få det att skala.
Grafer är bra på att länka mellan saker och vara en auktoritet som man kan referera till (och det är just därför att det ger mening med en gemensam myndighetsgraf där både personer och saker i svensk förvaltning beskrivs).
Grafdatabaser är inte lika bra på att hålla tusentals temperaturvärden eller vad annars folk brukar hälla in i relations-databaser. Då är det bättra att från grafen länka dit sånt finns, precis som Wikidata börjat göra och som Google gissningsvis gör dem med.
Grafen är alltså spindeln i nätet dit man går för att få veta vad som hänger ihop med vad och sen kan man därifrån hoppa vidare till andra resurser.
Tex skulle en myndighetsgraf kunna ha ett objekt för Naturvårdsverket och en länk för vardera av deras APIer och dokumentationen för dessa.
Även generaldirektören skulle kunna länkas med startdatum för anställning, m.m.
Även beslut som tagits skulle kunna länkas, m.m.
Om en myndighetsgraf ska lyckas så måste många människor vara med att mata den. Med Wikibase går det utmärkt att hålla ordning fast många kockar finns i köket. En ny graf hos DIGG innebär att medarbetare på flera nivåer i alla andra myndigheter måste läras upp och introduceras till att mata och korrigera grafen.
På Wikidata är det runt 22k dagliga användare. För en svensk myndighetsgraf skulle jag gissa att 10-100 på en dag räcker och kanske 1000 olika på ett år (detta beror på ambitionsnivå, man kan ju börja lågt och bara ha en graf med alla politiska organisationer och deras APIer tex).
Ännu en utmaning är att det vad jag vet inte forskas i grafer eller finns folk inom akademin i Sverige som kan grafer bra (om ni hittar nån så länka gärna!).
Ett grafforskningscenter kanske inte vore en dum idé heller?
@erik-viklander Tack! Jag deltog precis lite via min mobil och Midori webbläsaren från Fdroid. Det fungerar klockrent, intuitivt och enkelt.
Jag gratullerar till ett välvalt system och än så länge är jag nöjd användare.
Jag hittade ett svenskt bidrag från MIUN här om själva processen att släppa öppna data http://miun.diva-portal.org/smash/record.jsf?pid=diva2%3A1359760&dswid=-9111
För folk som är intresserade av att släppa data på Nivå 5 (dvs. länkad data) kan jag rekommendera att ta en titt på:
Det är i mina ögon helt essentiellt att myndighetspersoner tillägnar sig kunskap om (eller anställer nån som har koll på) ontologi, semantiska webben samt de koncept som nämns ovan för att kunna höja nivån på datan som de vill släppa som öppen data.
Ni som sitter på datan måste först annotera/matcha ihop den med andra datamängder och sen släppa. En möjlig mängd att matcha mot är Wikidata som blivit en nod i nätvärket av semantiska data och växer så det knakar.
Om ni börjar göra detta så är min gissning att ni väldigt snabbt inser behovet av en egen graf där ni kan stoppa in sådant som inte passar in i Wikidata och som ni sen kan länka permanent till när ni annoterar era dataposter.
@maria_dalhage Hej, jag vill gärna anmäla mig men jag har ingen lust att göra det via Zooms hemsida. Jag uppfattar det som en integritetsvidrig proprietär tjänst och jag skulle helst vilja att ni själva fixar en videokonferensinfrastruktur som inte spionerar på användarna och lämnar ut mig till amerikanska myndigheter bakom min rygg.
Det finns flera bra FLOSS lösningar för videokonferens som tex Rocket.chat och Big Blue Button.
Jag valde att inte registrera mig i väntan på svar om hur ni vill göra för att skydda deltagarnas integritet.
#schrems2 #personlig_integritet #floss
@nina_ Hej, tack för att du beskriver hur ni jobbar. Det låter ju bra tycker jag. 
Har du kikat på hur Wikimedia Foundation gör när det gäller workboards och öppenhet?
Som standard är ALLT öppet hos dem. Dvs. jag kan se alla ticket/tasks, alla arbetsytor (kanban), all kod som publiceras och av vilka medarbetare (via Gerrit), all kod som används för att hålla servrarna uppe och välfungerande (puppet och ant och sånt), m.m.
Ibland händer det att en säkerhetsincident eller lucka upptäcks och då ändrar en admin synligheten så att just den tickets innehåll döljs från utomstående. Så snart problemet är åtgärdat så öppnas den så alla kan se.
Det här påminner om radikal öppenhet som Audrey Tang bidragit till att införa i Taiwan på regeringsnivå (läs och häpna!), se https://www.oxfordinsights.com/insights/2020/11/20/taiwans-answer-to-digital-government-a-global-blueprint
Värt att anmärka är att till skillnad från WMF så har ni utmaningen att ni jobbar med surt sparade/tjänade pengar som tagits mot hot om fängelse som skattemedel av en om möjligt ännu mindre öppen statlig myndighet.
Detta gör nog en STOR skillnad i hur ni bemöts av omgivningen. Om ni misslyckas med något då är det slöseri med skattemedel. Om WMF misslyckas då är det slöseri med donationer som getts frivilligt. Är jag missnöjd kan jag bara låta bli att donera nästa år.
Med er så kan jag inte styra något som helst, det enda jag kan göra är vädja (vilket funkar dåligt i kontakt med myndigheter vanligtvis) eller kritisera (vilket också funkar halvdåligt men lite bättre än att vädja). Inom WMF kan jag påverka en hel del, både genom val till styrelsen för hela föreningen, men faktiskt också genom att ifrågasätta val som görs, föreslå ändringar och prata direkt med produktägaren för tex. Wikidata när jag upptäcker något som funkar halvdant eller som sticker i ögonen. Inte sällan är det andra som tycker till och jag inser att mitt förslag nog inte var det bästa eller att jag kanske missat nått när jag gjorde min analys. I samverkan når vi nya höjder varje vecka och systemen förbättras eftersom.
I erat omvärdssystem så funkar det såhär: Vart fjärde år kan jag välja i ett i mina ögon heltrasigt valsystem från 1800-talet, men som är väldigt väldigt långt från direktdemokrati som det ser ut idag. Ni styrs av (ineffektiva) politiska beslut (med bristande unika identifierare och noll mätbarhet). Vissa beslut tas bakom ryggen på allmänheten, andra kommuniceras öppet, inte sällan bryts lagen vad jag sett av myndighetspersoner och inte sällan bliver det ingen påföljd.
Ingen av politikerna pratar i dagsläget vad jag har hört om öppen digitalisering (fast vi har en digitaliseringsminister?), radikal öppenhet, kunskapsgrafer eller nått i den stilen. Jag har såklart valet att kasta min värdefulla fritid i ett politiskt system genom att engagera mig, men av flera personliga skäl väljer jag att avstå.
När vi medborgare skriver här på detta forum är det i mitt fall i denna kontext som jag skriver utifrån. Det kan vara bra att veta.
Vi/jag vill väl, men verktygen för att nå dit vi önskar är bara så himla dåliga. Insynen vi medborgare har idag är nära 0 hos både er och andra myndigheter och beställarkompetensen hos vissa myndighetspersoner i ansvarspositioner likaså vilket leder till kassa halvtrasiga IT-system överallt.
Jag undrar också om detta är första forumet som någonsin skapats av en svensk myndighet. I så fall är ni med att skriva historia, det kan ju vara att om flera myndigheter hade liknande forum eller öppna ärenden och diskussioner på Github-liknande system så skulle det inte vara så mycket "tryck" på detta forum?
@salgo60 utbildningsvärlden kör skräpdata. Iallafall vad jag sett i universiteternas datamängder som skickas till KB.
Källan måste förbättras.
Ta ett exempel: Varför har inte alla svenska högskoleanställda som publicerar orcid än? Hur svårt kan det vara att ha unika id?
Varför har universiteten eller rektorskollegiet inte ett API där jag kan få ut namn, orcid, wikidata id, och en lista på publikationer med DOI?
Hur svårt kan det vara att fixa?
@jonor sa i Wikibase and the EU Knowledge Graph as an use case:
Det ser ut att finnas en hel del klurigheter i SPARQL att läsa in sig på, och körordningen är ju inte helt uppenbar, men kanske en tumregel är att körning av grupperade satser sker inifrån och ut. På Wikidata finns väl en förenklad query builder också, men jag vet inte hur långt man kommer med den, om det t.ex. skulle gå att formulera federerade frågor.
Japp, klurigt är det. BlazeGraph har hemsnickrat syntax också som inte är med i specifikationen också (tex named subquery som behövdes här).
Det går inte i dagsläget med Query Builder vad jag vet. SPARQL är en hel vetenskap verkar det som och det är en rätt brant inlärningskurva på språket tycker jag och ingen har gjort en överblick vad jag sett över vilka motorer som finns och vad de stödjer och inte. Dags för att bygga ut https://en.wikipedia.org/wiki/Comparison_of_triplestores med en ny tabell för vilka SPARQL features motorerna implementerad?
Om du vill kan du skapa ett ärende på https://phabricator.wikimedia.org/ för Query Builder och fråga efter stöd för federering
@maria_dalhage @jonass När vi jobbar mot Wikimedia servrar i Wikidata finns liknande behov och problemställningar.
De öppna APIerna på Wikidata serverar miljontals svar per månad.
De som använder tjänsterna uppmanas att ge sig till känna genom att höra av sig först. Ytterligare är det ett krav att sätta User-Agent header vilket jag tycker bättre om än att "missbruka" HTTP-Referer.
If you want to make a lot of API calls, and perhaps run very busy and active bots, talk to wiki admins ahead of time, so they do not block you. See list of Administrators of Wikimedia projects. Read more about this topic on API:Etiquette.
https://m.mediawiki.org/wiki/API:Etiquette
https://meta.m.wikimedia.org/wiki/User-Agent_policy
Personligt tycker jag det är helt OK att nån bliver blockad om de vill skickar enorma mängder frågor och vägrar identifiera sig på något sätt. IT är en mycket värdefull samhälls-/organisationell resurs som kostar på miljön och det är värt att designa verktyg och program så att de belastar minst möjligt.
Själv får jag ibland skriva om verktyg för jag har helt enkelt skrivit dem för ineffektiva/långsamma.
Hej
Jag snöade in i förre helgen på att uppdatera alla busshållplatser i Härnösands kommun efter att ha sett den här nyheten: https://harnosand.se/5.114c15b717d22a2d5e51b98.html
Tyvärr så upptäckte jag att datan som Din Tur delar (licens CC0!) är mindre bra.
Jag saknar tex:
Jag upptäckte även gammal data i 1 fall och rapporterade det som till dem. Tyvärr har de ingen öppen backlog eller bra och öppen ärendehantering så jag kan se om andra redan rapporterat felet jag hittade och hur de presterar över tid när det gäller att hålla kvaliteten.
Jag får lite känslan att jag är den första någonsin som tagit en närmare titt på deras data. Jobba i vakuum är inte optimalt, så jag slängde in allt jag gjort på FB Openstreetmap Sverige och fick värdefull återkoppling! 
Jag konkluderade att:
Jag har följande ide:
Hur vore det om de började med hittelön om nån hittar fel i deras data. WDYT? Är det nått som skulle kunna höja kvaliteten och öka intresset för samspel?
Hej, tänkte bara dela min glädja över att det i specifikationen finns en introduktion till Wikidata och förklaring till hur fältet används.
WikiData
På initiativet Wikidata (https://www.wikidata.org) görs ett gediget arbete för att kunna länka och bygga kunskap utefter data. Genom att göra den här specifikationen kompatibel med Wikidata genom länkning hoppas vi kunna bidra till att höja kvaliteten i Wikidata och i specifikationen. Vill du att dina utegym i kommunen syns bättre i dessa plattformar - se till att bilder på utegym finns tillgängliga med med fri licens som CC-0 och/eller ladda upp bilder på WikiCommons.
Använd fältet “wikidata”, egenskap nummer 8 i denna specifikation, för att länka till det objekt i Wikidata som beskriver utegymmet. Det kan komma att finnas ett ID i Wikidata för varje utegym.
Wikidata-id anges med en så kallad “Q-kod” och börjar med bokstaven Q och följs sedan av ett antal siffror. Detta är det unika ID som utegymmet har i Wikidatas databas. Om det inte finns en Q-kod för ditt bad, rekommenderas du att lägga till utegymmet på Wikidata och länka dit.
Om utegymmet finns med i Wikidata öppnas fler möjligheter t.ex. rita en karta över svenska utegym och länka till andra datakällor. Rekommendationen är därför att du skapar ett objekt på Wikidata som beskriver ditt utegym. För mer information hur det går till, se projektet Wikidata:WikiProject_Outdoor_Gyms. Notera också att i Wikidata finns även ofta bilder av utegymmet.
Jag skulle vilja lägga till att organisationer inte själva måste skapa objekten på Wikidata. Det finns en mängd frivilliga som gärna bistår och delar man bra data med CC0 då kommer det troligtvis synkas inom timmar/dagar om man tar kontakt på tex. en projektsida.
Vill en organisation skapa objekt på WD rekommenderar jag att ni gör det i tandem med frivilliga och berättar först hur ni tänker och frågar om input och förbättringsförslag. Sen kan ni skapa ett 50-tal objekt och fråga igen om återkoppling. Därefter kan resten läggas upp när ni fått återkoppling.
Så gör datastory och andra som jobbar aktivt med Wikidata sen flera år.
Mycket kommunikation finns på Telegram och det underlättar om ni finns med där också i relevanta grupper. Se https://meta.wikimedia.org/wiki/Telegram
This day will cast light on open data as the ‘fuel’ to be reused for shaping Europe’s digital future. Challenges and benefits of reusing data and making it interoperable will be discussed along with other related topics.
The thematic sessions are divided as follows:
Thematic session 1: Creating open data ecosystems. Open data has demonstrated to be the key element of innovation to shape our digital future. In order to unleash its potential, governments need to implement open data policies to ensure trustworthy data-sharing. In order to support this, this session proposes insights on how projects that contribute to the open data policy.
Thematic session 2: Data for people. In the digital transformation, citizens play an essential role in this process. This thematic session will highlight the importance of citizen engagement and projects with a special user-oriented approach.
Thematic session 3: Facilitating data reuse. In order to ensure open data, there has to be acceptance and implementation of some principles and strategies. In this session, we will focus on the enabling factors as FAIR principles of data, data literacy, and other projects to ensure interoperability.
@salgo60-ej-aktiv sa i Wikibase and the EU Knowledge Graph as an use case:
- Lucas 1 juni 2021 "Wikidata Live Querying"
Den hade jag inte sett! Tack för tipset
https://op.europa.eu/en/web/eudataviz/home
OBS krockar med NOSAD på internetdagarna
@angela tack för tipset! Jag har anmält mig.
Hej
@mattias sa i Utegym som öppna data - hur du publicerar:
Utegym - ODS-exempel
Exempel på data publicerad enligt specifikationen i filformatet ODS.
Utegym - XLSX-exempel
Exempel på data publicerad enligt specifikationen i filformatet XLSX.
Kan du/ni motivera varför dessa binära format tillåts? De riskerar att läcka metadata om organisationen t.ex. användarnamn, m.m.
Jag anser att det är en onödig säkerhetsrisk förutom att de är mycket mera krångliga att integrera i andra lösningar jämfört med t.ex. JSON.
@jonor sa i Wikibase and the EU Knowledge Graph as an use case:
Det ser ut att finnas en hel del klurigheter i SPARQL att läsa in sig på, och körordningen är ju inte helt uppenbar, men kanske en tumregel är att körning av grupperade satser sker inifrån och ut. På Wikidata finns väl en förenklad query builder också, men jag vet inte hur långt man kommer med den, om det t.ex. skulle gå att formulera federerade frågor.
Japp, klurigt är det. BlazeGraph har hemsnickrat syntax också som inte är med i specifikationen också (tex named subquery som behövdes här).
Det går inte i dagsläget med Query Builder vad jag vet. SPARQL är en hel vetenskap verkar det som och det är en rätt brant inlärningskurva på språket tycker jag och ingen har gjort en överblick vad jag sett över vilka motorer som finns och vad de stödjer och inte. Dags för att bygga ut https://en.wikipedia.org/wiki/Comparison_of_triplestores med en ny tabell för vilka SPARQL features motorerna implementerad?
Om du vill kan du skapa ett ärende på https://phabricator.wikimedia.org/ för Query Builder och fråga efter stöd för federering