Önskemål: Ny rekommendation från DIGG om API:ers koordinatsystem

salgo60 ej aktiv

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

Björn Hagström

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

salgo60 ej aktiv

@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

Björn Hagström

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

salgo60 ej aktiv

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"

Exempel ett svenskt projekt

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

Björn Hagström

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

salgo60 ej aktiv

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

Björn Hagström

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

salgo60 ej aktiv

@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

jonass

@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/graphiql

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

salgo60 ej aktiv

@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

jonass

@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

salgo60 ej aktiv

@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

jonass

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

Ainali

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

Dennis_Priskorn

@björn-hagström sa i Önskemål: Ny rekommendation från DIGG om API:ers koordinatsystem:

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

Stämmer det verkligen? Ni kan skapa en Wikibase på 10 min. Jag har sett @salgo60-ej-aktiv göra det här: https://sweopendata.wiki.opencura.com/wiki/Main_Page (han skapade den medan vi chattade när han fick en idé). Ni skulle säkert kunna haka på där och lägga in er innehåll om ni vill

De lösningar ni valt verkar ge dålig spårbarhet, problem med arkivering, bristande överblick för de som deltar, m.m. Jag som deltar vill ha allt på ett ställe om det går. (som kontrast till er se Ainali som fick ett Vinnova bidrag för ett öppet data-projekt, ALL hans dokumentation finns på ett ställe: http://www.y2s.se/ som han fortfarande håller uppe).

I ert fall skulle ni kunna ha gjort en webbsida med både blogg och wiki. I bloggen skriver bara ni och bjuder in till samspel i Wikin. Sen skulle ni kunna länka på andra ställen till relevant innehåll om ni vill ha mera återkoppling och engagemang.

Kristine_

@dennis_priskorn sa i Ö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.

Hej!
Det stämmer vi har inte någon sådan kategori för generella önskemål. Anledningen är att vi inte skulle ha möjlighet att ta omhand eller besvara alla önskemål på ett bra sätt och därmed riskera att skapa felaktiga förväntningar hos våra forumanvändare.

Rörande din fråga om ett koordinatsystem, vill vi hänvisa till den myndighet som ansvarar för digital infrastruktur för geodata i Sverige, det vill säga Lantmäteriet. Den här sidan (extern länk) hos Lantmäteriet säger att SWEREF 99 är det officiella referenssystemet. Det finns också en text om förhållande till WGS 84. Koordinatsystem är en hel vetenskap, så för mer frågor och råd kring tolkning av information på den sidan, behöver jag hänvisa till dem som har det som expertområde.

Hoppas det förtydligar!

salgo60 ej aktiv

@kristine_ sa i Önskemål: Ny rekommendation från DIGG om API:ers koordinatsystem:

Koordinatsystem är en hel vetenskap

nja det blir ju det när ingen styr upp det... saker som ovan gör ju datat i princip omöjligt att hantera.....

Tror alla på DIGG från vaktmästare till GD skall ha koll att WGS84 är det vi kör som Öppna data om inte speciella krav finns.... Skall vi enkelt kunna skala Öppna data och hämta hem 10-30 miljarder per år så måste alla lyfta sig . Att saker som ovan produceras tyder på att projektet, DIGG, infrastrukturen inte är vuxna rollen är min ödmjuka åsikt.... istället för ett projekt som pekar framåt så är vi på ruta 0 och inser knappt våra egna brister....

Nina_

@salgo60-ej-aktiv Jag håller med om att alla behöver lyfta sig. Det måste vi göra tillsammans, DIGG kan inte åstadkomma en förflyttning på egen hand.
Jag är inte säker på att vi har en vaktmästare på DIGG, men en av våra mest insatta moderatorer sitter även i receptionen vid behov. GD har också koll, är min uppfattning.

Dennis_Priskorn

@kristine_ sa i Önskemål: Ny rekommendation från DIGG om API:ers koordinatsystem:

@dennis_priskorn sa i Ö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.
Hej!
Det stämmer vi har inte någon sådan kategori för generella önskemål. Anledningen är att vi inte skulle ha möjlighet att ta omhand eller besvara alla önskemål på ett bra sätt och därmed riskera att skapa felaktiga förväntningar hos våra forumanvändare.

Rörande din fråga om ett koordinatsystem, vill vi hänvisa till den myndighet som ansvarar för digital infrastruktur för geodata i Sverige, det vill säga Lantmäteriet. Den här sidan (extern länk) hos Lantmäteriet säger att SWEREF 99 är det officiella referenssystemet. Det finns också en text om förhållande till WGS 84. Koordinatsystem är en hel vetenskap, så för mer frågor och råd kring tolkning av information på den sidan, behöver jag hänvisa till dem som har det som expertområde.

Hoppas det förtydligar!

Nja, å ena sidan förstår jag att du gärna vill lämna över till "experterna" och slippa ta ställning å andra så gissar jag att du kanske inte testat och sett hur jobbigt mycket merarbete det innebär för oss datakonsumenter att svenska myndigheter envisas med SWEREF99 där det inte behövs.
Se tex här hur många linjer extra som måste skrivas för att konvertera https://gist.github.com/noahwilliamsson/682b0946088945192751

Det är även en miljöfråga. Alla CPU-cykler som vi nerströms måste göra extra pga. alla konstiga format vi måste konvertera kostar på miljön.
Jämför tex 100 konsumenter som alla måste för varje koordinat i en datamängd med 10000 poster göra 1s beräkning med att datautgivaren gör detta arbete 1 gång och delar en de facto internationell standard.

Jag förstår utmärkt att myndigheterna internt vill köra sina extra precisa hemsnickrade koordinatsystem, men tvinga det inte på användarna.

Jag önskar mig att DIGG klart och tydligt tar ställning och ber datautgivare att alltid ge geodata med WSG84 för datamängder på portalen för att underlätta för användarna. De som vill kan ge ut 2 parallella datamängder med både det hemsnickrade systemet och WSG84.