Hjälp folk att bada i sommar med Öppna Data! (Tips och hjälp behövs)

tomasmonsen

@salgo60 Hej jag har fått svar från Tillgänglighetsdatabasen, här finns deras API: https://td.portal.azure-api.net/

Verkar vara gratis att registrera sig, men det krävs nyckel så APIt är inte helt öppet, ska regga mig och se om vi kan läsa ut unika IDs på de olika platserna.

@tomasmonsen tackar jag extraherade det nesta se GIST

min oventskapliga koll vilka som kopplar badplatser till Tillgänglighetsdatabasen så är Göteborg duktiga och länkar deras sida (dock har GBG störigt långa URL;ar
- Exempel Wikidata sökningar badplats <-> Tillgänglighetsdatabasen
  - karta
  - statistik

Exempel på annan fördel att ha dataseten i en Kunskapsgraf att man vet vilket data som är en badplats och vilka som länkar ett visst ställe som ex. Tillgänglighetsdatabasen. Och med en sökfrågan förstår

Rösta på ny Wikidata egenskap - bathingWaterIdentifier

tycker ni föreslagna egenskapen är bra så in och rösta länk
- har ni inte konto registrera er
- ex. syntax för positiv röst är
  {{S}} - ~~~~

Bilder på badstränder
Uppmuntrar er att dela bilder på era badstränder med fria licenser. Variant är att ladda upp direkt på WIkicommons

** exempel hur jag kopplat ihop bilder för badplatser dvs. vi anger att en bild avbildar en badplats som finns i Wikidata
*** mer om hur bilder hanteras med strukturerad data video

Finns det några visionärer med pondus inom Öppen data som kan styra upp badvatten och lite till här finns en utlysning med drönare, naturism....

Användning av positioneringsdata från exempel mobiltelefoner, fordon, fartyg för att kartera friluftsliv och naturturism.
Användning av luft- och vattendrönare vid insamling av data.
....

Utlysningen

Utlysning av forskningsmedel om digitalisering som stöd för en hållbar förvaltning (synteser)

jonor

@tomasmonsen Ok, jag tänkte att man kanske kunde få en URI under dataportal.se eller liknande namnrymd som förvaltas långsiktigt av DIGG i samband med att man registrerar en datamängd, som en form av stödtjänst, men jag är faktiskt inte riktigt klar över vad som förväntas av en registerhållare för beständiga identifierare.

tomasmonsen

@jonor Ja det hade varit toppen om någon myndighet kunde ta på sig det jobbet, att upprätta mängder av unika IDn som datapublicerare kan få "hämta ut". Tror inte att man vågar/vill ta på sig ett sånt jobb, så jag får "hitta på" en metod för att skapa ett unikt ID. Funderar på att skapa ett kopplat till geografiska platsen, alltså en kombination av siffror från koordinatsystemet...

Du kanske kan sätta ihop en sån förväntan och presentera för Digg De kanske är sugna på att upprätta en sådan databas - skulle tänka mig att det skulle vara uppskattat av många!

tomasmonsen

@salgo60 Jag har fått svar från Tillgänglighetsdatabasen och det verkar inte som om man har beständiga IDn för sina objekt heller. Det närmaste vi kommer är det URL som de har för varje plats, som ju delvis består av namnet på verksamheten som datamängden beskriver, så det känns inte heller helt stabilt över tid (saker kan ju byta namn..).

Tyvärr kommer jag därför att behålla attirbutet "td-url" i min specifikation för att man iaf i bästa fall kan peka ut verksamheten mha ett URL till TillgänglighetsDatabasen.

@salgo60 ang. "bathingwaterIdentifier" - är det alltså ett format som är precis samma som NUTSKOD som Havs- och vattenmyndigheten har skapat som ska lagras på det attributet, eller är det ett attribut för badvattenidentifikation där man kan skriva vad som helst?

Jag vet inte när själva IDt skapas - det blir bara ett ID om man väljer att publicera i deras datamängd och det kan nog inte vem som helst göra samt att inte alla badplatser är skapade där. Är det ett format som Havs- och vattenmyndigheten helt själva skapat och hittat på kanske det inte funkar för icke-eu-land eller eu-land som saknar samma motsvarighet till myndighet?

tomasmonsen

Detta inlägg är raderat!

@tomasmonsen nix vet ej jag samlar frågor på hög se Svenskabadplatser/labels/Havs- och vattenmyndighetens

Tomas har du ett GITHUB användarid så kan jag lägga till dig i projektet...

tomasmonsen

@salgo60 TGBMonsen, lägg gärna till mig. Jag är ingen fantom på Github men kanske kommer att bli. Det här projektet har varit väldigt lärorikt!

@tomasmonsen du är tillagd testa gärna hej vilt så du får en känsla av GITHUBs fördelar/brister och möjligheter. Säg till så kan vi dela skärm så kan jag visa hur snyggt Our World in Data sammanställer > 200 länders Covid vaccineringsdata i GITHUB se min beskrivning om detta

Jag nås på telegram salgo60 , twitter salgo60 eller lite olika nummer 0735152802 0705937579

nytt WD egenskapsförslag för Badkartan finns att rösta på

tomasmonsen

Hej igen allesamman, nu är det "final push" till leverans av specifikationen och några frågor kvarstår som jag behöver ha hjälp med, framför allt språk:

Språkstöd - Hur ska jag erbjuda språkstöd för fler än ett språk.

Min ide: Lägg till "lang_code" som attribut, använd ISO639-1 för att sätta en kod "EN" t.ex. och då måste resten av filen vara på engelska. Den som då har behov att dela data på fler språk än ett får skapa flera filer och använda olika spåk i dem, och berätta med lang_code vilket språk filen är på. Man får sedan i metadata med DCAT-AP markera vilket språk filen har.

Andra idéer: Skapa fler språkfält, där du valfritt kan lägga upp till 5 olika språk, fritextfälten skulle då behöva utökas med 4 till och varje sådant fält ha en språkkod kopplat:

descripition_1 kopplas med attribut lang_code_1. Du skriver på svenska i "description_1" och sätter "SE" i lang_code_1.
Description_2 kopplas med attribut lang_code_2. Du skriver på arabiska i "description_2" och sätter "AR" i lang_code_2.
...osv.

Finns det andra ideer? Tänk på att formatet är flatfil typ CSV för att underlätta för dataproducenten som troligen ofta inte har verktyg att hantera JSON-objekt med arrayer av värden...

Hilfe!

Länk till specen: https://docs.google.com/document/d/1GxNucD_E_eoHnlyJAL3tjCel-BdWvwF5TB_lYl7bs94/edit?usp=sharing

(Skriv gärna kommentarer och skapa förslag direkt i dokumentet)

Dennis_Priskorn

@tomasmonsen sa i Hjälp folk att bada i sommar med Öppna Data! (Tips och hjälp behövs):

Hej igen allesamman, nu är det "final push" till leverans av specifikationen och några frågor kvarstår som jag behöver ha hjälp med, framför allt språk:

Språkstöd - Hur ska jag erbjuda språkstöd för fler än ett språk.

Min ide: Lägg till "lang_code" som attribut, använd ISO639-1 för att sätta en kod "EN" t.ex. och då måste resten av filen vara på engelska. Den som då har behov att dela data på fler språk än ett får skapa flera filer och använda olika spåk i dem, och berätta med lang_code vilket språk filen är på. Man får sedan i metadata med DCAT-AP markera vilket språk filen har.

Andra idéer: Skapa fler språkfält, där du valfritt kan lägga upp till 5 olika språk, fritextfälten skulle då behöva utökas med 4 till och varje sådant fält ha en språkkod kopplat:

descripition_1 kopplas med attribut lang_code_1. Du skriver på svenska i "description_1" och sätter "SE" i lang_code_1.

Description_2 kopplas med attribut lang_code_2. Du skriver på arabiska i "description_2" och sätter "AR" i lang_code_2.

...osv.

Finns det andra ideer? Tänk på att formatet är flatfil typ CSV för att underlätta för dataproducenten som troligen ofta inte har verktyg att hantera JSON-objekt med arrayer av värden...

Hilfe!

Länk till specen: https://docs.google.com/document/d/1GxNucD_E_eoHnlyJAL3tjCel-BdWvwF5TB_lYl7bs94/edit?usp=sharing

(Skriv gärna kommentarer och skapa förslag direkt i dokumentet)

Jag tycker som Magnus att ni ska frångå CSV och göra nestlad JSON istället. CSV är so yesterday och ganska inflexibelt. Om kommunerna inte klarar av att leverera JSON istället för CSV då är det ändå dödfött från början skulle jag säga.

Kolla själv på exemplet Magnus gjort: https://gist.github.com/salgo60/f306fa23c28e2678928b2c1e9be78689

Det formatet ligger för övrigt mycket närmare exportformatet i JSON från Wikibase som syns här https://www.wikidata.org/wiki/Special:EntityData/Q5.json.

De som byggd Wikidata har lyckats skapa ett semantiskt system som kan hantera den komplexitet som vi möter i världen. Att inspireras av dem kanske kan vara en nyckel till framgång. Många professionella inom IT-industrin jobbar redan mot Wikidatas olika API:er och använder datan på olika sätt (t.ex. Google) och det betyder att om ni använder nestlad JSON då använder ni något när en industristandard för informationsutbyte.

Se även Sello.io som har liknande nestlad JSON där språkfält också är nestlade se https://docs.sello.io/#getting-products

Dennis_Priskorn

Tomas svarade i Google-diskussionen som inte arkiveras så därför får ni en kopia här för eftertiden:
"Anonym
20:54 30 apr.
•
Kommentarer av
Vald text:
description
Där det förekommer fritext vore det kansek smart att ha möjlighet att utöka med andra språk?
Dennis P
Dennis P

+1 Vi lever i en värld med många språk. Alla i Sverige pratar inte bra svenska. Turister tex.
10:07 1 maj
Isak Styf
Isak Styf

Bra tanke, men då kanske det kan vara en idé att hellre styra det via requesten med Accept-Language eller liknande. CSV blir ganska begränsande för att hantera flera språk.
20:38 3 maj (redigerad 20:32 4 maj)
Tomas Monsén
Tomas Monsén

Jag gillar idén men det blir svårt att implementera i CSV då det skulle behövas flera olika fält för att tillåta översättningar av text. Hur många olika spåk ska jag isåfall skapa fält för? Jag tänker mig att det blir upp till implementatören att använda fältet så som denne vill.

I metadatat för datakällan, metadata som taggas med DCAT-AP, kommer man att kunna ange språk på datat. Där står det om det är svenska eller engelska.

I dataspecifikationen finns bara två fritextfält och det är relativt enkelt att lägga till ett fält för ett annat språk. Jag skapar ett som heter description_altlang där man kan skriva ett alternativt språk (förslagsvis engelska). Du kan där skriva vilka språk du vill och den som sedan konsumerar datat får välja vilket av fälten (description = svenska) och (description_altlang = annat språk) vilket som ska användas. Rekommendationen blir engelska men du kan skriva vilket du vill.

Kan det funka som en lösning?
11:00 6 maj
Tomas Monsén
Tomas Monsén

Jag har beslutat att rekommendera dataproducenten att översätta description till engelska, alternativt publicera ytterligare en engelsk version av datamängden istället.

Vad tror ni om det?
12:38 7 maj
Isak Styf
Isak Styf

Jag tycker att det låter bra.
13:17 7 maj
Tomas Monsén
Tomas Monsén

Vi behåller den, förtydligare att man kan skriva en översättning och/eller förse icke-svenskspråkiga med en variant på filen med annat språk. Engelska, franska, tyska, finska, norska osv. .
15:11 7 maj
Tomas Monsén
Tomas Monsén
Markerad som löst
15:11 7 maj
Magnus Sälgö
Magnus Sälgö
Öppnad på nytt
att inte stödja flera språk känns 1990... vi vill ha det i datat och inte några konstigheter med att ropa med olika "Accept-Language" se GIST tror det bara är att inse att turister folk i Sverige inte alla pratar svenska https://gist.github.com/salgo60/f306fa23c28e2678928b2c1e9be78689
06:15 I förrgår
Tomas Monsén
Tomas Monsén

Du får gärna hjälpa mig att förklara hur jag på ett bra sätt ska kunna ha stöd för flera språk - jag tänker mig att som specifikationen ser ut nu kan du ange och skriva den på vilket språk du vill, och sedan får du i metadatat i katalogen specificera vilket av de olika språken du önskar?

Eller ska fritextfälten följas av en språkkod där du som producent av datat först skriver in fritexten och sedan i språkkoden anger vilket språk det är skrivet på typ "The beach is located... " språkkod: EN ?

Jag behöver häjlp med förslag på hur jag ska lösa det rent praktiskt annat än så jag tänkt genom metadatat i publicerande katalog.
13:56 I går
Tomas Monsén
Tomas Monsén

Jag har tittat på ditt förslag och det är jättesnyggt, problemet är att vi samlar data som en CSV - det är det formatet jag måste förhålla mig till eftersom jag inte tror att det finns verktyg i kommunerna för att bygga nästlade JSON med arrayer av värden för attribut. Om du kan komma på ett bra sätt att göra det i CSVn som sedan blir enkelt maskinläsbart är jag all ears, men jag vet inte hur. Det enda jag kan tänka mig nu är att jag

: Lägger till 3 ytterligare fält för allt som är fritext.
: Lägger till 4 ytterligare fält som anger vilket språk fritexten är skriven på.

Då får man möjlighet att ange 4 språk per fil, och du kan välja själv vilka språk, genom att sätta språkkodningen i "kodfältet".

description_1
lang_code_1

description_2
lang_code_2

...

Kan det funka? Hur många sådana behövs isåfall ?
10:11 I dag
Magnus Sälgö
Magnus Sälgö

skippa CSV dumt krav 2021 är mitt svar viktigare med tydliga krav som man uppfyller
12:55 I dag
Tomas Monsén
Tomas Monsén

Hej då kommer det inte att bli någon data publicerat tyvärr, så jag får välja en halv-mesyr där jag önskar att innehållet språkkodas mha metadata.

Det finns inga verktyg mig veterligen jag kan sätta i händerna på en "vanlig" tjänsteperson i kommunen som kan generera en sådan utfil/utdata. Datat finns inte i verksamhetssystem som kan leverera data i detta utdataformat. Det kommer, om jag byter detta utdataformat, att ta flera år att få ut någon data, om ens någonsin.

Tyvärr är vi, enligt min bedömning, i det läget i ÖppnaData-Sverige att detta är den minst dåliga vägen fram för att över huvud taget få ut någon data.
15:13 I dag
Tomas Monsén
Tomas Monsén

Jag blir tvungen att klippa av tråden här och rekommendera att den som behöver publicerar fler filer med språkkodning satt på dcterms:language property i DCAT-AP som vi rekommenderar att man använder för att metadatatagga sin distribution. Jag har flyttat hela frågan om språk till "Appendix D, Restlista". Kika gärna där och lägg till förslag på fler förbättringar som vi ska försöka få med till nästa version av datamodellen/Specifikationen!""

#########################

För mig verkar detta mycket intressant. Det ger ett litet inblick i hur myndighetspersoner resonerar när de designer och bygger system och lösningar.

Hur svårt är det då att skapa nestlad JSON egentligen kanske du som inte kan programmera frågar?

Svaret är att om du har ett minimum av kunskap i t.ex. Python då går det alldeles bra med 5-10 minuters arbete.

Det enda det kräver är

basala kunskaper om JSON
kunskap om loopar
möjlighet att skriva ut från programspråket till disk i giltigt JSON-format.

Jämför det med CSV:

kräver basal kunskap om tabeller och deras rader och kolumner
kräver basala kunskaper i kalkylarksprogram
kräver kunskap om exportfunktione ni ett kalkylarksprogram

Min bedömning är att det är marginellt svårare att exportera i JSON än i CSV och att det är väl värt mödan om ni frågar mig.

Min gissning är att en elev i gymnasiet som har en kurs i programmering skulle kunna fixa att skapa en nestlad JSON på 1 timme.

Om kommunerna inte klarar av att anställa folk med basala kunskaper om programmering, databehandling, datahantering och dataexport i standardiserade format och enligt specifikationer då är det någonting som måste åtgärdas genast.

Nog med prat nu: Såhär skapar du en nestlad JSON á la Magnus:
Ladda ner Pycharm på din dator
Skapa ett projekt
Läs https://csharpskolan.se/article/nastlade-loopar/
Klona eller kopiera denna kod och kör programmet

import json
from pprint import pprint

# Simple example of nestled JSON generation

raw_data = [
    dict(
        id="SE0441273000000001",
        en='bathing place näsholm',
        sv='badplats näsholm',
    ),
    dict(
        id="SE0441273000000002",
        en='bathing place kastholm',
        sv='badplats kastholm',
    )
]

# detta är vår dictionary som håller all data som ska skrivas till disk
data = {}
public_baths = []
languages = ["en", "sv"]
for bath in raw_data:
    entry = {}  # dictionary
    entry["Eionet bathingWaterIdentifier"] = bath["id"]
    names = {}  # dictionary
    for language in languages:
        if language in bath.keys():
            names[language] = {'language': language,
                               'value': bath[language]}
    entry["name"] = names
    public_baths.append(entry)
data["public_baths"] = public_baths
pprint(data)
with open("sample.json", "w") as outfile:
    outfile.write(json.dumps(data))

Output:

{'public_baths': [{'Eionet bathingWaterIdentifier': 'SE0441273000000001',
                   'name': {'en': {'language': 'en',
                                   'value': 'bathing place näsholm'},
                            'sv': {'language': 'sv',
                                   'value': 'badplats näsholm'}}},
                  {'Eionet bathingWaterIdentifier': 'SE0441273000000002',
                   'name': {'en': {'language': 'en',
                                   'value': 'bathing place kastholm'},
                            'sv': {'language': 'sv',
                                   'value': 'badplats kastholm'}}}]}

Stefan Wallin

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

Personalen laddar om länken
Personalen fyller i formuläret
Personalen klickar på JSON-boxen högst upp.
Personalen kopierar JSON-koden och klistrar in i ert samlingsdokument/tabell
Nästa badplats, börja om från steg 1.

@stefan-wallin snyggt !!!

nästa problem är hur kommer detta att skala?
- skall 290 kommuner ladda upp egna JSON i DIGGs dataportal vilket känns som det skulle bli omöjligt att skala och hämta data känns som vi är tillbaka till detta med När kommer kunskapsgrafen

Vi kopplar nu in Europeiska badvatten på Wikidata lite långsamt SPARQL

På Wikidata i vår kunskapsgraf kopplar vi in i Sverige

badkartan.se där man kan läsa vad folk tycker om badet WD Property:P9615
Instagram som har identifierare för platser WD --> ve kan se biklder från badet Property:P4173 Instargram location ID
Eionet bathingWaterIdentifier Property:P9616 som är term hos Eionet dataelements/99263 och visas upp på deras karta men även används av svenska Hav och deras karta

Fattigmans länkad data med browser plug in

video hur man kan hoppa mellan alla ovanstående siter pga att data i Wikidata används UTAN att saker finns kopplade/kurerade på den webplats vi är
plug-in Entity Explosion
Exempel recension Morgonbryggan

plug-in Entity Explosion

Hav om Morgonbryggan

senaste provtagning

Badvattensprofil med kontaktpersoner och tillsyn

Hur det ser ut på Open StreetMap relation/12699000 som är kopplad till Wikidata Q106707013

Instagram plats locations/722470 = Torekov

Det vi saknar är att nyhetsmedia vaknar till liv och kommunerna så att vi kan se

SVT anger metadata TVinslag om samma som bad = SE0441278000000137
- se topic badvatten i Media
Att DN och andra tidningar etc. har artiklar med ämne samma som SE0441278000000137
- idag har vi följande nyhetsrelaterade egenskaper ca 30 stycken
att en kommun som tar ett beslut om ett bad säger ämne samma som SE0441278000000137
- idag finns denna info och möjliga källor för problem lite halvhjärtat i Havs API contaminationSources / plannedMeasure men som textsträngar ex Kaanan badet SE0110180000001837

tomasmonsen

@stefan-wallin Hej och tack, det där var en fin funktion, jag har börjat bygga en egen liknande applikation, dock hårdkodad efter specifikationens format, inte baserat på schema.

@tomasmonsen kul hur går tankarna att detta data skall konsumeras och att ni skapar en kunskapsgraf? Dagens "lösning" jag ser med dataset som skall laddas upp för 290 kommuner på dataportalen.se skalar inte och är i princip omöjlig att konsumera, hitta saker på osv.... känns inte som någon tänkt till. Min tro är att vi måste tidigt och tydligt i ett projekt för kommuner peka på bra mönster så att vi inte får 290 kockar som skapar sin egen soppa...

krav man bör ha är bl.a.
- enkelt att konsumera datat
- enkelt att kommunicera med varandra/felrapportera - inte email utan riktigt system med helpdeskid
  - det skall i datat finnas var man felrapporterar jmf hur Wikidata beskrivs i Wikidata där bugghanteringssystem anges Q2013
- enkelt att se status på datakvaliten se exempel det projekt jag satte upp för Europeiska badplatser med Eionet bathingWaterIdentifier se Wikidata:WikiProject European Bath Waters
- kunna konsumera datat på andra språk än svenska
- API
- versionshantering av data och API
- tydlig datakatalog med ägare för olika termer jmf eionet-data-dictionary

Bra exempel hur andra jobbar är Trip Advisor Vouliagmeni Beach samma som Wikidata Q107099269 där vi har egenskap Property:P3134 "TripAdvisor-ID" = 12828542

Verkar som TripAdvisory har en egen kunskapsgraf där dessa saker kopplas in --> att man kan leverera saker kopplade till denna punkt för badplatsen på flera språk etc....

engelska https://www.tripadvisor.com/12828542
grekiska https://www.tripadvisor.com.gr/12828542
tyska https://www.tripadvisor.de/12828542
arabiska https://ar.tripadvisor.com/12828542

Hjälpa folk att hitta is dvs. prediktera när vaken upphör

satte upp en Wikibase sandbox med de IoT jag hittat som mäter vattentemperaturer vid badplatser - iot-device.wiki.opencura.com
- säg till om det finns flera eller lägg upp era jag hittade bara API för Södertälje och Karlskrona som har API
- vad skall ett bra IoT API ha för data/dokumentation?
- hur gör vi så saker blir enkla att "konsumera"? ramlar detta under några pågående projekt om ja var hittar vi vad dom gör eller inte gör
karta IoT i WIkibase som jag hittat för badvatten