Hjälp folk att bada i sommar med Öppna Data! (Tips och hjälp behövs)
-
@jonor sa i Hjälp folk att bada i sommar med Öppna Data! (Tips och hjälp behövs):
inte sett riktigt att det skulle vara en huvudsaklig poäng att Wikidata stod för primära identiteter,
Wikidata är inte primär auktoritet utan refererar till auktoriteter som bekräftar det som står i Wikidata, dock är det bra om man anger samma som Wikidata.
-
Exempel på feltänk ör Kungliga biblioteket som har sedan 2012 drivit ett havererande projekt LIBRISXL där man skapat instruktionsfilmer för bibliotekarier där dom anger Wikipedia som källa vilket gör att hela ekosystemet havererar och Wikidata inte kan ha LIBRISXL som källa
-
Jag har blivit lite maniskt med detta med källor och trovärdighet så jag skickade frågan vidare till han som skapa Wikidata vilka visioner han hade
- Denny Vrandečić om källor video
-
-
Detta inlägg är raderat! -
@salgo60 @jonor @istyf @Stefan-Wallin @josefinlassi @Dennis_Priskorn
Stort tack till er för detta enorma engagemang för datamodellen och specifikationen för badplatser. Jag trodde nog inte jag skulle få så mycket feedback.
Jag har ändrat, bytt namn, flyttat, lagt till och tagit bort attribut om vartannat. Nu hag jag en modell som är bättre än förut men inte komplett såklart.
Här finns den ifall ni missat länken hittills som jag sent lade till i mitt originalinlägg:
https://docs.google.com/document/d/1GxNucD_E_eoHnlyJAL3tjCel-BdWvwF5TB_lYl7bs94/edit?usp=sharingJag står och väger mellan att skapa en datamodell som är "perfekt" och som är "kompatibel" med allt, fångar alla aspekter och fogar sig till redan befintliga modeller och plattformar. Tyvärr hamnar jag i avväganden om ifall jag ska sträva mot det eller sträva mot en modell som jag tror att våra medlemskommuner kommer att använda. Jag måste kanske fatta några beslut som gör det senare - med kvalité på modellen som nackdel.
Det som känns som stora frågan nu, innan jag fastställer version 1 i samråd med resten av arbetsgruppen för modellen i projektet Dataportal Väst är frågan om unikt persistent ID.
Det har kommit alla möjliga förslag - stryk det helt, hitta på något eget, använd en GUID-generator på internet, fråga HoV-myndigheten ifall ni kan få tillgång till deras databas och generera nya IDn där, skapa en egen databas där alla kan hämta ut IDn som behöver, skapa upp IDn i Wikidata på förhand och låt kommunerna använda dem när de publicerar, eller skapa en nationell databas med kunskapsgraf.
En del av alternativen funkar inte för då faller modellens kvalitet under vad som är godtagbart och en del ställer krav på en infrastruktur eller ideella krafter som inte finns.
Jag behöver fastställa ett unikt ID. Det finns inga ideella krafter som kommer att skapa Wikidatakonton och på förhand inför den här badsäsongen skapa upp IDn där, jag känner iaf inga sådana krafter. Vi kommer ej att kunna driva frågan nationellt i det här skedet.
Det jag kokat ned till nu är en av två lösningar
-
GUID-generator som ger ett 128bits "unikt" ID - finns risk för krock såklart men är liten
-
Ett helt påhittat system baserat på kommunkod som badplatsen finns på samt varianter av dess namn, typ "1473-TOREBODA-SANDVIKEN01".
Hur ska jag göra för att komma framåt och för att skapa en "mall" för våra kommande/tänkta datamodeller vi försöker skapa oss? Det lär inte vara första gången det här blir ett problem, vi har många modeller på lut som vi vill börja skapa och tillgängliggöra. Jag är rådvill. Hilfe!
-
-
@tomasmonsen Är det inte så att man får en URI för datamängden när den registreras på dataportalen t.ex.? Då fungerar den kanske som ett beständigt prefix för "lokala id" som ni genererar för posterna som därigenom kan refereras universellt. (Nu spekulerar jag väl lite fritt, men det känns som något man vänder sig till en registermyndighet för.)
-
-
Detta inlägg är raderat! -
Skapat ett förslag i Wikidata för EU identifieraren bathingWaterIdentifier
- se Wikidata:Property_proposal/bathingWaterIdentifier
- alla kan rösta som har ett wiki konto (går även utan konot tror jag men rekommenderas ej)
** Wikipedia skapa ett användarkonto
syntax för positiv röst:
-
{{S}} - ~~~~
-
mer om Svenska Badstränder jag lyfter in på GITHUB
-
@jonor Man får ett URI av Metasolutions katalogtjänst, för hela datamängden. Möjligt att den skulle kunna användas, men detta URI kan man även ändra på, vilket gör att det finns risk att det redigeras bort eller ändras över datats tid, då skulle URI vara en sak för hela datamängden/distributionen och inte ha koppling till IDt per rad/entitet. Jag förstår tanken och tycker det hade varit snyggt, men jag tror tyvärr inte det är stabilt nog. Det hade ju så klart varit önskvärt om katalogtjänsten hade ett centralt register som kunde provisionera ut nummer/identiteter via centralt register som garanterar unika värden. Detta finns ej i produkten men kanske kunde vara en förbättringsförslag. Man tar ju på sig ett stort ansvar med ett sånt register och frågan är om man vill ha det - jag frågar leverantören/pitchar idén.
Nu lutar det åt att jag får sätta samman ett namn av kommunkod och badplatsens namn.
-
@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 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årRö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
-
@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.
-
@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!
-
@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?
-
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...
-
@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å
-
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)
-
@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