@ mattias ok nu fattar jag projektet har en yta bra.!!!..

Återkommer men det känns som man borde nog ta sig en funderare om det är massa csv filer som skall göra Sverige bäst i världen på Öppen data eller om vi skall gå tillbaka till ritbordet och ifrågasätta dagens svenska dataportal och att skicka dataset till Europeiska dataportalen data.europa.eu ...

Det lilla jag ser av Öppen data så har inte DIGG vuxit och kan underhålla tekniska lösningar (tänker på att det saknas styrning, felrapportering, se senast först verkar fortfarande vara skakigt, sökningen skulle man komma tillbaka med osv...) och samma känns med Europeiska dataportalen dom känns som samma andas barn att det är mer flashiga PDF:er och tweets än riktig verkstad....

Skall data konsumera 2021 i hela Europa så måste vi

enkelt ha stöd för flera språk

nyckelord för ett badvatten data skall i möjligaste mån också finnas i en kunskapsgraf eller liknande så man kan hämta datat på sitt språk med kopplingar/relationer... skicka fält som heter kommunkod till EU gör det nog inte helt enkelt för en italienare att förstå...

tror min lilla test med IoT device visar att det blir vildvuxet och vi måste pröva oss fram till bättre lösningar där kanske en karta över alla badvatten IoT är ett litet steg att förenkla...

även kommunikationen mellan aktörer måste mogna (bra att ni har en yta), jag har i veckan slagit mig blodig mot Havsmyndigheten och blivit smått deprimerad av att se hur bra det skulle kunna vara efter att ha kommunicerat med Havs motsvarighet på Europa nivå EEA och fått svar på 60 minuter där dom även pekar på liknande projekt --> detta spar veckor av dödsdömda försök

9d74d420-13e1-4aa5-a4fd-ee27c0f10c8c-image.png

0a29e395-608d-4394-9d59-72a1bb063fe5-image.png

Min erfarenhet att flytta metadata iform av penningtransaktioner där så visste alla vad vi flyttade och varför och saker hade specats i årtionden.... i ett öppet och "löst kopplat" landskap är detta 100 ggr svårare och skall sedan datat kunna hämtas av folk i hela Europa eller "galningar" som vill mäta vattentemperaturen för att se när isen kommer... så behövs mycket med tålamod och kommunikation

@jonor tycker eionet gör det snyggt med identifierare se bathingWaterIdentifier där man är tydlig "Methodology for obtaining data"

Must be a valid bathing water identifier in the "WFDProtectedArea" registry

i mitt hobby Projekt svenska badvatten försöker vi skapa denna i Wikidata tillsammans med Naturkartan, Badkartan IN OCH RÖSTA UPP alla kan vara med och Wiki världen är duktiga på att hantera versioner av data länk exempel, diskussionssidor, enkelt prenumerera/ pinga andra - saker som behövs om löst kopplade system/ personer/ organisationer skall kommunicera vilket TYVÄRR svenska myndigheter, kommuner verkar vara..:

personlig fundering badplatser varför låter man kommuner skicka in koordinater som finns på land och varför finns ingen kvalitetssäkring med Lantmäteriet och varför skickas dålig data till EU. Och varför ställs inte krav på Lantmäteriet att för badplatser ha id = bathingWaterIdentifier

saker vi hittat när man kollar på datat fel loggade med just koordinater vi inte tror på felet är även spårbart på objekt i Wikidata se SPARQL som hittar objekt för badplatser vi satt lägre rang på för att vi som lekmän inser att här vill vi inte bada alla dessa fel skickas sedan utan kvalitetssäkring till EU som inte heller kvalitetssäkrar sakerna känns mer och mer som DN artikeln är allt för sann

1ec972fb-aa54-49d4-8680-4327c601d2f2-image.png

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

@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

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

@maria_dalhage ja men konstruktiv hetta vill jag se 😉 se exempel nedan hur om man gör rätt med persistenta identifierare så kan forskning 1750 kopplas ihop med länkade data 2021

Jag gjorde i veckan en övning att koppla ihop Litteraturbanken <-> bilder som har semantisk interoperabilitet med WIkidata <-> forskning på Runstenar av Uppsala Universitet och Riksantikvarieämbetet dvs. många SILOS och många kockar och vi delar kanske inte helt samma världsbild plus att med all rätt finns ett Trust issue mellan domän specialister och hobby runeologer

se min artikel Structured_data_for_GLAM-Wiki/Roundtripping/KMB

Det intressanta här är att allt detta går rel. enkelt för att

runforskarna redan 1750 skapade persistenta identifierare till de olika runstenarna när nya runforskare hittade på nya nummer serier så refererade man till dom äldre nu i #Wikidata gödslar vi med ca 5000 identifierare vi kopplar ihop så denna forskning blir inte inlåst och vi kan koppla ihop allt som jag visar i artikeln så genom att dessa forskare redan 1750 flrstod vikten av persistenta unika identifierare och att vi idag 2021 sätter upp skyltar bredvid runstenar i naturen så kan även vi hobby runeloger ta bilder och förklara vad vi ser.....

Inlåsnings effekten = 0 även fast det är en bok Bautil från 1750

1139px-Bautil_936.jpg

1280px-Book_Swedish_Runicinscription.jpg

det är detta tänk jag skulle vilja se är att vi har diskussioner om.... kultur Sverige startade 2012 med att diskutera detta och har enligt mig gjort massa misstag

fel kompetens i organisationerna avsaknad av tydlig vision jobbar inte med moderna plattformar som GITHUB och change management väldigt svårt att ta åt sig tänket med persistenta identifierare se hur flera 100 miljoner plöjs in i ett EU projekt Europeana som inte levererar

@björn-hagström detta flytta runt gör att alla externa länkar sluta fungera är min gissning.... känns som vi är tillbaka till detta att kunna logga frågor med unika idn.......

@salgo60 sa i HelpdeskID och ärendenummer:

design kyrkogården

Här kunde jag inte låta bli att googla lite. Vi hade faktiskt inte ett objekt på WD för detta koncept, men "design graveyard" verkar finnas tex här https://www.justinmind.com/blog/10-90s-websites-designs-you-wont-believe-existed/

Jag hittade även en vetenskaplig artikel som använder "graveyard data" som beskrivs som "discarded".

Så jag skapade https://www.wikidata.org/wiki/Q108616705 och länkade den

@kristine_
Jag håller med om att filter på uppdateringsfrekvens vore lämpligt att implementera.
Det hade underlättat väldigt mycket.
Är det något som är planerat?

@ainali Jag uppmanar dig att sluta använda handlingar.se tills att buggen jag beskrivit här är löst... Jag har inte lyckats kontakt hon som kör projektet än tyvärr.

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

@jonas-nordqvist sorry för tråd kap... gissar att som jan Ainali antyder att du får nog många varianter/förklaringar....

Bäst vore väl om det finns en arbetsmodell hos DIGG att saker som detta gör att dom skapar en task i sin backlog med ett unikt id

vi kan se backloggen prenumerera på vad som sker kommentera där vi får ett unikt task id på att detta ev. måste förtydligas med en rekommendation eller annat... när det gjorts får vi ett ping så jobbar vi med Wikidata där alla kan ställa frågor men det är Lydia Pintcher som prioriterar WIkidata backlog

Snyggast vore om "din" kommun jobba på samma sätt med en publik backlog som vi kan se och som pekar på DIGGs backlog.... jag skrev lite om dom tankarna under co-creation i en annan tråd....

Det är säkert bra med diskussioner med mer struktur och Facebook grupper men DIGG bör vara expertmyndigheten som fångar upp detta och pekar med rak hand i typ en instruktion vad som gäller....

@josefinlassi Hej igen! Jadå, fullt förståeligt 🙂 Allt gott!

@dennis_priskorn eller kanske bara begränsning

@salgo60 Om du vill ha underlag om NSÖD så är det ett Vinnova projekt. Vinnova publicerar inte projektdata/ inköp så som du frågar men det vore möjligt vad jag kan se. NSÖD har en egen tråd här på communityn, tror ditt förslag/ fråga ska läggas där så når du projektledaren Johan mfl. Nu känns det som vi lämnat specifikationen av Leverantörsreskontra. Vi plockar upp dina bidrag där.

@mattias Ja, du har rätt i att det är Community Edition av Odoo som är open source, men det är i alla fall tillräckligt bra för oss. Om jag fattar det är så är det inte någon egentlig begränsning i själva Odoo, men att många av apparna (som är vad de kallar olika tilläggsfunktioner) bara funkar på Enterprise edition.

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

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

Mer från fastighetslab det känns verkligen som dom har en vision och tänker digitalt

Välkommen till hackaton i Fastighetsdatalabbets arbetsgrupp
”Digital Tvilling - Testbädd - Tät Stad”
Torsdag 27 maj klockan 9 -12

ABB vill tillsammans med oss och på våra plattformar visualisera energiflödet i en stadsdel. Vi vill undersöka och visa på vad som är problemet med energidistributionen ur ett miljöperspektiv. Tillsammans vill vi hämta data ifrån befintliga databaser och kanske sätta in fler mätare i elnät och fjärrvärmenät och visualisera dessa data. Företrädesvis gör man detta med realtidsdata med hög noggrannhet.
ABB har mätare, kommunikationsutrustning och säkra dataplattformar för att hantera data. När data finns visualiserat så finns det massor med möjligheter för andra att göra analyser och komma med förbättringsförslag.
På samma sätt kommer vi att arbeta i de övriga grupperna nedan, med aktörer som har anmält sitt intresse för att bidra med teknik och kompetens.

Målet är att visa upp en 3D-bild av stadens struktur och flöden — och visa på vad som behöver hända för att leva upp till Klimatkontraktet.

Program
09:00 Bakgrund, Klimatneutrala städer/CIM/datalabbet och sammanfattning av det senaste seminariet.
09:15 Presentation av grupperna och indelning i utbrutna zoomrum
Spara energi i bostäder, digitalisering och sensorer
Samla in matavfall
Mobilitetshubb
Testbädd - Stockholm, Göteborg m fl
Utveckla digitala verktyg
Medborgardialog
11:45 Sammanfattning och nästa steg
12:00 Lunchpaus
12:30 Efterhack - De som vill fortsätter
14:30 Diskussion
15:00 Tack för idag