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

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.

ej aktiv

@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

ej aktiv

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

ej aktiv

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.

ej aktiv

@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

ej aktiv

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

tomasmonsen

@tomasmonsen Hej allesamman, då är vi klara med version 1 av vår Badplatsspecifikation!
[https://lankadedata.se/spec/badplatser/](link url)

Jag hoppas att ni tycker den är god nog att användas för att publicera data med, och jag hoppas att vi kommer att kunna släppa en uppdaterad version inför nästa säsong - Vi har en gedigen lista med punkter som kan göras bättre - vilket inte ska hindra dig från att leverera data redan nu!

Tack alla för hjälpen så här långt, det kommer komma fler frågor när jag börjar med version 2

ej aktiv

@tomasmonsen fick svar 14:50 från Hav idag se email

Ställde dessa frågor

Har ni motsvarade Eionet Data Dictionary era termer beskrivna med ägare och hur den skapas
Delar ni vår uppfattning att eran term NUTSKOD är illa vald för en badplats och bör ändras ? era planer?
Var ställer vi frågor som detta? finns ni på GITHUB?

jag uppfattar att dom inte svara på någon

Öppen data då det är som bäst.... deras svar tog 17 dagar och jag skickade ny fråga om varför inget svar

jämför detta med EU EEA 60 minuter och perfekt svar se email

tomasmonsen

@salgo60 Ja kvarnhjulen kanske mal långsamt ibland.
Vore ju bra om vi genom en korrekt påverkan kan få till ändringar som gör deras data bättre!

Vi har lagt upp specifikationen för badplatser på Github oxå, ska se om jag hittar dit igen.. hoppas kunna bedriva arbetet där framöver med version 2 och tillika den standard jag funderar på kring temperaturer i vatten, vad hette det ObserverdQuality - vi kanske kan skala/ärva lite från modeller som finns och komplettera med fält som gör att vi kan länka datat med entries på Wikidata och i Havs lösning?

ej aktiv

@tomasmonsen tackar

En fundering hur ser man koppling dataset och spec som används? Det är i specen många saker förklaras

dataset datasets/391_2066 "Badplatser i Lidköpings kommun"
- min task Svenskabadplatser/issues/158

Denna spec gissar jag har ovan nämda kravspec som grund men hämtar jag datat från www.dataportal.se så måste jag gissa vad fältet hov_ref betyder eller har jag missat något.

Fråga: Borde det inte finnas en koppling mellan datat och den spec som använda

tomasmonsen

@salgo60 Jo det finns det, en tanke iaf - den som publicerar datat ska i DCAT-AP nyttja attributet ConformsTo: https://www.w3.org/TR/vocab-dcat-2/#Property:resource_conforms_to
Gör man inte på det viset får man på annat sätt på distributionspunkten peka ut vilken spec man nyttjar. Så är vår tanke.
Vi har förklarat i specen att vi önskar att man gör på detta vis för att länka tillbaka till beskrivningen.
Jag noterar att vi kanske på annat sätt måste ta höjd för publicister som inte har metadata-taggat sin data på detta vis - kanske ett fält i själva datamängden som beskriver var specifikationen finns?

ej aktiv

@tomasmonsen coolt hittade under csv på datasets/83_2065

Känns som det borde visas i högerspalten... kanske och inte under ett av formaten...

kollar i hur det ser ut nere i Europa så verkar det vara försvunnit....
- https://data.europa.eu/data/datasets/https-catalog-skara-se-store-1-resource-9

Av det jag sett av svenska portalen för dataset och Europeiska så tycker jag det vore bra att kunna peka på en GITHUB yta där det kan finns kodexempel, möjlighet att ställa frågor, se en backlog....

ej aktiv

Nu dök länk dokumentation upp

som "Sidor"
https://lankadedata.se/spec/badplatser/ om man kör locale=sv
"Pages" om locale=en

Udda saker

nyckelord visas på svenska oberoende av språkinställning
1-1) kanske borde skicka med bathing waters som EEA kallar detta om inte data.europa.eu har språkstöd
1-2) vi tjatade lite tidigare att alla textfält borde ha språkstöd tar ni det steget så bör det lira ihop med data.europa.eu
1-3) här borde det om jag kör engelska locale=en pekas på specen på engelska med fallback svenska specen

Badplatser som API säger licens ej angiven medans CSV har Licence Creative Commons CC0 1.0 Universal

känns som denna process med metadata behöver lite omsorg. Gissar både i användargränssnittet och för den som matar in metadata och gärna att "någon som bryr sig" specar hur det borde fungera och stämmer av med alla intressenter....

mattias

Hej! @salgo60 @tomasmonsen
Specifikationen finns som sagt här: https://lankadedata.se/spec/badplatser/
Källkod finns på GitLab: https://gitlab.com/lankadedata/spec/badplatser
Ärenden: https://gitlab.com/lankadedata/spec/badplatser/-/issues
Ändringslogg: https://gitlab.com/lankadedata/spec/badplatser/-/blob/master/CHANGELOG.md

ej aktiv

@mattiashej tackar

min grej är att det borde sitta ihop med datat och hänga med ner till Europa dataportalen och då gärna skall datat, nyckelord, spec finnas på ett språk som folk förstår....

Jag har redan lyft in 2821 bad i Wikidata och markerat 530 badplatser på Open Street Map men hoppas att flera enkelt kan använda data och att vi får bättre data se feedback

https://www.wikidata.org/wiki/Wikidata:WikiProject_Sweden/Svenska_badplatser/Coverage2

ej aktiv

@ 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

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