@nina_ Hej, Att det skulle vara en avsiktlig design att inte kunna ångra efter formatering låter lite märkligt, skulle det i så fall vara en medveten trade-off för att spara tid eller uppnå någon annan funktionalitet?

Har ni en länk till GitHub repository för editorn? Det kanske finns mer information att hämta i issues-listan där.

Det vore intressant att veta vilka anpassningar ni har gjort för tillgänglighet, är det ändringar i programkoden som är tillgängliga som öppen källkod? Det låter som något som kunde vara lämpligt att dela med andra institutioner som har samma krav på sig.

@jonass sa i Önskemål: Ny rekommendation från DIGG om API:ers koordinatsystem:

Det är inte uppenbart hur mappningen bör göras. Ser att https://www.wikidata.org/wiki/Property:P8654 någon har laddat upp själva yrkesklassificeringen.

Ja egenskapen är själva nyckeln. Så på till exempel objektet polis (Q384593) kan man i egenskapen SSYK 2012 Standard för svensk yrkesklassificering (P8654) ange värdet 3360 så här.

chrome-capture.jpg

@jonass sa i Önskemål: Ny rekommendation från DIGG om API:ers koordinatsystem:

Hur skapas identifieraren för en ny "item" på WD? Oavsett så kan det vara lite vanskligt att underhålla en mappning över tid om vi inte tänker till.

Menar du själva Q-numret för ett objekt? Det är i princip bara ett löpnummer som utfärdas när objektet skapas. Förhoppningsvis kommer väl inte att SSYK2012 ändras speciellt mycket så underhållet borde vara minimalt? Jag inbillar mig att det är mer eller mindre en engångsoperation att göra mappningen.

@björn-hagström jag tror det var på grund av att du var inne under projektet bara, det vill säga under Måltidsinformation - Entiteter - Kontakt. Där såg du förmodligen att du stod med redan.

Däremot är det inte där informationen hämtas till Sveriges dataportal utan informationen som hämtas ligger under Måltidsinformation - Entiteter - Specifikation - Klicka på de tre prickarna - Redigera. Hoppas jag inte rör till det 🙂

@nina_ ok over and out jag tror inte vi är på samma sida att jobba med öppna prioriterade backlogs och strukturerat... du får flytta runt saker eller ta bort eller höra av dig om vill veta hur vi jobbade....

Tycker KB är ett bra exempel där alla inklusive KB har mycket att lära av... vikten av att ha rätt kompetens, strukturerad kommunikation med slutanvändarna, vikten att använda beprövade verktyg som backlogs med unika id:n för tasks.... dvs. samma problem vi har med kommunikationen med DIGG där jag tror en publik backlog spar enormt med tid för alla...

@nina_ det är galna utmaningar känner jag.... när ett projekt som NSÖD inte hittar rätt med koordinater efter 2 år hur skall då en kommun göra rätt... med 158 kommuner som inte ens har en /PSI sida

det kan vara så illa att det IKEA gör är det enda rätta att lyfta in nya kompetenser är ett måste.... om en budget på 16 miljoner med projektledning från ri.se och Vinnova blir ett magplask borde en haverirapport skapas och återkopplas varför reagerar inga "experter" på 2 år och var finns DIGG?? Vet att personer från DIGG suttit med vid NSÖD specandet... min erfarenhet skall man skapa kunskapsgrafer så är det 1000 ggr mer komplext än koordinater och skall man göra det ihop med andra så kan man inte ha dagens SILOS utan backlogs...

Finns tyvärr många liknande misslyckanden.... Kungliga Biblioteket startade 2012 med LIBRIS XL och inser själva att det inte blir bra, dom har stängt ned sitt diskussionsforum men där var folk enormt upprörda och det skrivs artiklar att uppdraget missköts.....

@ainali eller kanske lära myndigheter hur andra liknande myndigheter jobbar på ett effektivt sätt (säger han som gråter sig till sömns varje kväll att DIGG, Riksarkivet... inte ger mig unika id:n)

Att bygga tjänster som badkartan men för myndigheter blir mycket mera användbart om vi har unika ID:n för myndigheter i hela världen och deras tjänster. Kan vi sedan ha 5stardata och "samma som" med ex. Wikidata så kan insamlat data enklare kopplas ihop och analyseras...

@nina_ Ok håller med men lösningen är inte nya trådar i en diskussionsgrupp utan flera publika prioriterad backloggar löser detta problem.... diskussionsgrupper är i sin natur spretiga är min erfarenhet och saknar task id.... dvs. värdet är ringa... pratade igår med AI Sweden och dom ser samma problem och kör i allafall internt backlogs...

Tror det stora problemet är inte denna diskussionsgrupp utan bristen på öppna prioriterade backloggar som visar vad ex. DIGG

vad jobbar DIGG med och vad skall levereras och när ex. API hantering där det tydligt anges vad som är leverabler vad borde DIGG jobba med enligt andra dvs. oprioriterade items ex. hur skriver vi specar så det funkar i Europa koordinater skalar det att alla har egna "hittepå" standarder -> vad tycker DIGG officiellt finns det en rekommendation eller är det icke DIGGs bord
* hur skall koordinater anges för att fungera hos EDP med 39 andra länders dataset vi ser kvalitetsproblem på specar kan DIGG sätta en standard och ha reviews? dagens mönster med att alla kan ladda upp allt i det format dom gillar.... blir inte bra

@mattias Ok, tack för uppdateringen.

@jonass tackar för svar.

Jag tror du måste ha nya laguppställningar alla trivs inte att jobba agilt och kan inte axla den rollen är min erfarenhet.... en utmaning med öppna data är att det är löst sammansatta nätverk där det måste byggas upp förtroende, våga jobba ihop dvs, det jag prata om co-creation

Att starta försiktigt med ett hack där man fysiskt träffas kan vara en bra mjukstart....

Spännande.
En hel del WordPress-relaterat publicerat synes det.

Blir ännu "galnare" om detta skall skalas till Europa nivå och enligt alla powerpoints så är väl det målet med öppna data. Finns det "egen definierade" fält på 29 språk som man skall förstå där informationen om projektion finns i fältnamnet på lokalt språk kanske skrivet med ett annat skriftsystem som serbiska/ grekiska.... och sedan sitta och översätta motsvarande SWEREF koordinater till WGS84 för att samköra data... känns som vi 2021 borde veta bättre....

lista Europa verkar vara 91 stycken "Coordinate Systems" dvs. @Dennis_Priskorn önskan om WGS84 bör eftersträvas....

Jag ser dock inte vem som styr upp detta... mer ser jag vilka som trasslar till detta 😉

@nina_ jag skuter ut mig ur detta forum så blir det lugnare 😉 ...

Jag tycker det verkar helt galet att levereras så lite, den goda diskussionen som Björn och andra pekar på ha jag missat....

Blev tyvärr inte tryggare efter dagens API presentation som säkert är bra att ha men som också som det sas är mycket gammal skåpmat, jag ser inte att hur detta skall göra att massa kommuner som idag inte ens har en psi-data sida skall bli digitala.... jag saknar en känsla av urgency

@erika-strandberg Toppeninitiativ. Nominerat! Kan du förtydliga "öppen teknik"? Är öppen dokumentation till API? Backend som öppen källkod? Fri mjukvara?

@jonass tackar jag lyssnade på Swedish JobTech "2020-09-30 Vad innebär datadrivna arbetsmarknadstjänster?" tipsa gärna om fler bra dikussioner/föredrag

Gissar att alla vinner på om vi delar vad som fungerar eller inte...

Inom Wikivärlden testas det en hel del ML och en lärdom var att Bias ställer till det så alla bilder med präster klassificerades som "katolska präster" troligen på "fel" träningsdata.... men vi har klottersannering som verkar funka bra...

@salgo60 Känner så igen strip 2! Men det finns en risk med ettan. Om det agila arbetet handlar mer om metod och mindre om att hantera projektrisker och krav så kommer resultatet att fortsatt utebli. skillnaden är att man inte ens kommer att kunna diskutera från ett perspektiv av utebliven leverans utan att vi tar det sprint för sprint. Jag är för att arbeta agilt. Men ur mitt perspektiv handlar det inte om Scrum vs vattenfallsmetoder. Utan om beställarkompetens. Intern som extern. Är det tydligt vad man ska åstadkomma? Finns det sätt att mäta progress och effekt? Kan man avbryta en dålig idé? Kommer resultaten att kunna återanvändas av andra? Går det att ändra lösningen över tid? Kommer jag följa arbetets progress och påverka resultatet löpande?

@salgo60 sa i Här kommer höstens NOSAD- workshops!:

@dennis_priskorn sa i Här kommer höstens NOSAD- workshops!:

+1 Jag håller helt med. CSV är bra.

Hur hanterar du flerspråkighet snyggt dvs. 1 fält med många språk.... finns det bra mönster i csv? att skapa nya kolumner för varje språk känns galet.... i Måltidsinformation verkar man skapa om hela filen för varje språk vilket känns bäddat för att skapa fel och inkonsistens.... plus erfarenhetsmässigt är det enklare att ha datat i samma fil och sedan välja visa multispråk fältet på det språk man förstår jmf zh, ar och sv allt data i Q317877 men visar fälten och term namnen på valt språk med fallback en....

8243b23d-7632-434f-acbd-19e301e71160-image.png

Kollar du på projektioner så är har man valt nya fält för varje projektion se Måltidsinformation

Läser vi hos LM "en framtid kommer således all information att vara lägesbestämd i SWEREF 99. Läget kan dock redovisas i tretton olika plana koordinatsystem"

Hur ska det specas csv... med 13 nya fält? En fil för varje projektion....

55ec5f85-788d-48d7-abee-1bec886ec0bb-image.png

Tänker jag fel?

Nä, som vanligt har du en poäng!

CSV passar inte bra för flerspråkighet. JSON är något bättre, men bäst är nog en graf likt Wikibase där många språk understöds på alla "things".

Jobbigt med 13 olika koordinatsystem! Hoppas DIGG kan göra nån typ av rekommendation så alla myndigheter publicerar i endast ETT koordinatsystem (för digitala kartor).

Kul med några som gör saker som går att använda!!! snyggt ned prenumerera...

@pernillan kul finns det projektytor/backlogs till dessa projekt eller kör alla sin egen "metod"

@joho68 Jag håller med dig men det är regeringen som bestämmer om hur myndigheter ska finansieras och det är de som behöver besluta om förändringar. För Bolagsverket hjälper det inte att Skatteverket sparar pengar om Bolagsverket inte kan betala lön till sina medarbetare. Påtala behoven för regeringen tycker jag. Om du har konkreta exempel som dessutom är underbyggda så är det jättebra.