Önskemål: Ny rekommendation från DIGG om API:ers koordinatsystem
-
Hej, hittade ingen lämplig kategori för att önska mig något från DIGG.
Jag skulle vilja se en rekommendation om ETT koordinatsysm som alla myndigheter som publicerar geodata uppmanas på det kraftigaste att följa så vi slipper 13 olika koordinatsystem i API-jungeln.
Nån fågel har viskat i mitt öra att WSG84 används av de flesta andra så det har väldigt brett stöd typ överallt i öppna källkodsprojekt. I fallet att det inte är precist nog (eller på annat sätt olämpligt), då bör det nog finnas som en valmöjlighet tänker jag för de som ändå har halvkassa mobiler de navigerar med och struntar i cm-precision)
På förhand tack!
-
@dennis_priskorn instämmer ....
jag har haft kontakt med ett 30 tal kommuner om position på deras utegym see issues. De få gånger man får kontakt med en kompetent person som vill hjälpa till Issue 13 och som kan GIS så kan det bli helt galet när man säger helst WGS84....
Tror steg 1 är att man börjar ange projektionen med ex. EPSG som är om jag fattat rätt en auktoritet och " Spatial Reference System Identifier" så att alla som hämtar datat förstår vad man får... jag får ofta en koordinat och sedan skall man gissa.....
-
ex. EPSG:3008 som motsvarar kart projektion SWEREF99 13 30
-
Hoppa morgondagens presentation 12 okt 2021, 10:00–12:00 kan peka med rakhand på termkataloger och få slut på klippa klistra specar.
- "14 okt 2021, 09:30–12:00" finns Vägledning för specifikationer av öppna datamängder som drivs av NSÖD men vet inte vilket mandat NSÖD har projektet känns väldigt flummigt och verkar kört i 2 år utan metod och backlog och nu har man efter 2 år när projektpengarna snart är slut kommit på att det kanske vore bättre med en metod... är min trötta tolkning.... rätta mig om jag har fel
-
-
@salgo60 Du har fel, det vi nu gör inom NSÖD är att samla erfarenheter från projektet tillsammans med en omvärldsbevakning.
-
@björn-hagström sa i Önskemål: Ny rekommendation från DIGG om API:ers koordinatsystem:
samla erfarenheter från projektet tillsammans med en omvärldsbevakning.
pinga när det finns något så man förstår vad ni gör och varför NSÖD skall göra detta. Det lilla jag såg av projektet vid specande av badvatten, utegym var att det saknades tankar om metod och någon typ av informationsdesign. Tror det behövs en chefsdesigner med pondus som pekar med rakhand..... nu är ni 2 år in i NSÖD och det känns inte som ni varit tydliga vilka kompetenser som behövs utan ni försöker uppfinna hjulet igen.... dagens API byggblock gav mig en känsla att ni inte får draghjälp av det dom gör...
Fråga: vore intressant varför NSÖD/Metasolution är så spretiga med koordinater som första frågan handlar om. Hur tänker ni?
- väldigt virrigt med värdemängd WGS84 på den andra decimaltal
- varför olika namn
- hur refereras ett fält i en spec om man vill inte göra copy&paste (--> att nya fel dyker upp)
- tanken med en global definition av termer/kolumner som återanvänds i olika specar dataset och har unika persistenta identifierare är det EU använder som jag pekade på
- specar på svenska (termnamn på engelska), inga referencer till centrala defitioner känns inte genomtänkt eftersom dataset skickas till European Data Portalen
i fallen ovan torrsimmar ni med att skapa nya specar utan data?!?!!? varför inte styra upp det? Om någon vill bygga vidare på speacarna vore det inte enklare om man kan peka på att jag återanvänder fält x,y,z
Jag gissar att vi inte pratar samma språk jag försökte peka på det i "Eionet Data Dictionary" där jag direkt fick tag på ansvarig för en term och sedan skapar vi samma som denna term i Property:P9616 där vi har definitione på flera språk en, sv, ar, zh vilket känns som typ ett baskrav för öppna data....
Både Eionet Data Dictionary och WIkidata specar fältet en gpng sedan ingår det i flera dataset .....
Lycka till och även om ag inte finns här på portalen mer så går det att skicka frågor om ni vill ha feedback...
-
Annan variant i Livsmedelskontroller
liknande specat i Måltidsinformation men känns otydligt med SWEREF och dom olika projektioner som finns
gör ni inte detta onödigt virrigt? nu definieras "samma fält" i varje spec med lite olika "smak" finns det en tanke hur detta skall administreras? Känns även udda att extern konsult är uppsatt som ansvarig. Om data kommer ned till Europa portalen skall dom köpa extern konsult eller tecknas supportavtal med firma Hagström....
-
Roade mig med att återanvända definierade egenskaper i Wikidata och skapade ett enkelt utegym schema skrivet i ShEx tog 10 minuter lade sedan till 1200 svenska utegym / karta svenska / engelska jmf ovanstående specande i flera månader inget data....
EntitySchema:E280 (en) - Utegym
- schemat har unikt namn E280 men kan ha label på olika språk
- wdt:P625 pekar då på egenskapen för koordinat som är tidigare definierat en gång och används för "alla Wikidatas" platsers koordinater osv...
- ovanstående schema i ShEx kan du validera dataset med ....
- nog så viktigt om du skall hämta in dataset från hela världen (jmf Open Street Map dom har > 15 000 utegym deras beskrivning Tag:leisure=fitness_station)
Antal objekt i Wikidata som använder P625
- geocoordinates of the subject. For Earth, please note that only WGS84 coordinating system is supported at the moment
-
@salgo60-ej-aktiv Fråga 1-4: Det finns idag ingen samordning/standardisering för hur datafält ska definieras och vi har heller inte varit konsekventa i våra egna specar som du noterar. Vi har ingen möjlighet att bestämma hur andra ska göra i sina specar men vi borde absolut kunnat vara med samstämmiga i våra egna specar. Jag tror att förklaringen ligger i att det är olika personer/team som skapat dem även inom NÖSD.
5: Språklagen säter upp begränsningar för vad vi kan göra på andra språk och det är heller inte alltid lätt att översätta svenska begrepp och för svensktalande förlorar man ofta nyanser om begreppen är på engelska.
När det gäller kontaktperson (det är rätt stor skillnad på "kontaktperson" och "ansvarig" som du kallar det) så är jag det under den återstående projekttiden (tidigare hade vi en annan konsult där). Efter det får vi se. Men vem som helst är fri att ta vidare arbetet utan att prata med någon av oss som varit inblandade i framtagandet nu. Det stora problemet vi har är den långsiktiga förvaltningen av dessa specifikationer men vi hoppas att det kommer lösningar på det.
-
@björn-hagström design reviews och bra projekt metoder ser till att saker blir enhetliga....
Språklagen argumentet köper jag inte. 2021 kör tom med IKEA kunskapsgrafer och flerspråkighet dvs. fel design beslut... ni måste ha med folk som @Dennis_Priskorn som skriker skitdata eller kör WGS84 eller kör kunskapsgrafer.... jag ser mer och mer samma mönster som med kulturdata att det saknas engagemang och ingen reagerar när saker görs fel ...
- Björn Hagström på grekiska med fallback en / serbiska / arabiska....
Ser en fara att datat blir oanvändbart utanför Sverige och om andra gör samma "fel" så kan vi "inte använda" deras data
-
@salgo60-ej-aktiv VI har rätt små möjligheter att som projekt skapa kunskapsgrafer och få dem att leva över tid. Projektformen är begränsande.
-
Det vore bra att ha alla organisationers roadmap, backlogs så man vet vad andra tänker så kanske ni kunde hjälpa varandra.... hur gör Norge ,Danmark, Finland med koordinater.... känns system fel om alla länderna jobbar i SILOS
-
egen Wikidata är gratis och kallas Wikibase https://wikiba.se/
-
EU kör en wikibase se artikel "Wikibase as an Infrastructure for Knowledge Graphs: the EU Knowledge Graph" se linkedopendata.eu "The EU Knowledge Graph"
- jag frågar Max som skapat EUs Wikibase installation om federation dvs. kan vi koppla ihop oss med dom vilket fungerar.... vilket vore enormt snyggt att kunna koppla ihop alla länders olika kunskapsgrafer.... gör man det blir det ännu viktigare att man jobbar med koordinater på samma sett etc...
-
-
@salgo60-ej-aktiv Det handlar inte om mjukvaran i sig utan om att installationen behöver förvaltas över tid och det har projekt svårt att göra.
-
@björn-hagström mmm borde vara en input till DIGGS backlog att detta behövs...
Gissar att era specar ni levererar också har ett framtida undehållsproblem.....
-
@salgo60-ej-aktiv Ja förvaltningen av våra specar och allt vi tar fram inom NSÖD är vår största utmaning. Vi har haft det på agendan sedan dag ett då vi visste att det skulle bli ett problem och vi har jobbat för att hitta bra hemvister. Ibland har vi gjort det genom att samverka med DIGG som tar över visst material (inte specar) och att publicera resultat på platser som inte är beroende av projektet (som detta community).
Vi har också förhoppningar om att det kommer finnas någon som kan fortsätta arbetet. Målet har varit att hitta något permanent men risken är att det blir i projektform igen. Inget är klart så vi får se hur långt vi når.
Skulle DIGG kunna sätta upp en plattform för kunskapsgrafer som hela offentliga sektorn skulle kunna använda (typ en motsvarighet till wikidata)? Skulle det vara en vettig utveckling? Typ en fjärde funktionalitet på dataportalen utöver data, begrepp och specifikationer?
-
@björn-hagström sa i Önskemål: Ny rekommendation från DIGG om API:ers koordinatsystem:
förvaltningen av våra specar
Gissar att verksamheten som äger datat skall äga specarna. Mönstret Single Source of Truth (SSOT) (Wikipedia) är väl det vi hoppas på skall ske och då borde det vara tydligt vem som skriver en spec och äger den.... nu verkar det vara lite High Chaparral och ingen dansar i takt....
Skulle DIGG kunna sätta upp en plattform för kunskapsgrafer
Är inte alls säker att DIGG är rätt eller vad DIGGs roll/mandat är.... för mig är steget enormt från dagens csv filer på svenska till att knyta ihop information... borde vara en naturlig del om man utreder grunddata i samhällets tjänst vilket gjorts de senaste 20 åren... kanske dax att inse att det inte räcker med att ladda upp specar
Produkt: Finns lite olika lösningar som jag inte testat. Amazon har en db du kan köra i molnet, Google verkar hoppat i säng med Neo4J som startades av en svensk kille Emil Eifrem deras lösning finns i molnet...... går att testa gratis
Dom som försökt
Kungliga Biblioteket startade 2012? ett projekt LIBRISXL där man skulle utveckla ett nytt katalogsystem LIBRISXL som borde ha blivit en kunskapsgraf. 2019 skrevs denna rapport "Leaving comfort behind - Libris" hur illa det gått och 2021 ser jag inget ljus i tunnelm. Dom hade/har några enormt skarpa personer i Peter Krantz och Niklas Lindström men gissar en organisation med massa oldschools bibliotekarier som har svårt för det nya och kanske mindre vana att driva utvecklingsprojekt har blivit mer eller mindre ett haveri.... och med @Dennis_Priskorn ord massa "skitdata" jag brukar säga RDF med massa textsträngar...Europeana projekt som starta 2012 med vision länkade data och knyta ihop Europas alla museer, men tycker mig se ett scope creep då man slutat prata lika mycket om "Linked data" utan verkar hoppas på AI.... en:Wikipedia beslöt att inte länka dom då kvaliten är för dålig för en.Wikipedia -> för stort steg för folk ute på museerna och RAÄ är min tolkning...
skulle DIGG kunna sätta upp en plattform för kunskapsgrafer
Känns naivt då vi ser hur saker drivs idag och hur andra misslyckats
- lyssna på hur Google jobbar med sin kunskapsgraf - ISWC keynote Jamie Taylor Google det krävs mycket kommunikation och enormt skarpa hjärnor är min tro....
Tror man Google Amazon Airbnb, Über, Linked in (hur dom jobbar datadrivet), youtube gör rätt och det är något för Sveriges Öppna data så gissar jag att man skall fundera över hur organisationen, plattformar skall se ut
- vilken typ av skills man behöver och vilket skill gap som finns
- vilka problem man skall lösa
- fundera över vad som görs i övriga Europa så man inte springer åt fel håll
- ?!?!?!
Jag hoppas Jobtech börjar springa åt detta håll men deras user case känns enormt svårt. Lite intressant att läsa vad Linked in gör med ML, recommender systems, kunskapsgrafer och deras vision som verkar innefatta hela världens alla företag, arbetskraft
-
@salgo60-ej-aktiv Jobtech arbetar som sagt för fullt med att relevanta begrepp och information för matchningen ska hänga ihop enligt grafteorier.
Ett enkelt exempel skulle kunna vara vårt fråge-API:
https://taxonomy.api.jobtechdev.se/v1/taxonomy/graphiqlProva att köra frågan:
query MyQuery {
concepts(type: "ssyk-level-4") {
id
preferred_label
type
ssyk_code_2012
narrower(type: "occupation-name") {
id
preferred_label
type
}
}
}I detta fall plockas alla relationer ut som finns under en officiell yrkesnod.
-
@jonass snyggt men ni saknar språkkod eller ?!?!?
Vore kul och se hur Linkedins modell är deras mission är att samla in alla världens jobb, alla skills, alla skolor, alla personer.... presentation
Den presentation jag såg hade dom 12TB data och enormt bra svarstider
-
@salgo60-ej-aktiv Om jag får kosta på mig att vara lite rolig, jo alla språkkoder finns i vårt API. https://taxonomy.api.jobtechdev.se/v1/taxonomy/main/concepts?type=language
-
@jonass bra start
KB verkar ha gjort tvärtom har alla varianter i sitt data ex. August Strindberg JSON-LD där August finns på massa olika språk men man får gissa vilket.... livet med en teknisk skuld och gammalt data som inte städats....
Ps. känner mig lite skyldig att jag aldrig mappar era yrken till WD men får lite strukturell ångest vad som är bäst se tweet
Pss. Exempel Polis = Q384593 json --> 89 språk i Wikidata
som en entity graph
-
@salgo60-ej-aktiv 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. 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.
-
@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.
@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.
