Community på Sveriges dataportal

Mer Spam filter problem denna länk fastna

hosted weblate org projects/openaedmap/website-translation

116f6690-46b8-487a-a98d-ede5fd41f966-image.png

Intressant 2 olika tidsstämplar

image.png

image.png

Ser av ett annat inlägg att jag missat en del aspekter av syntaxen, att kolon-tecknet i dokumentationen ingår i uttrycket, att det generella formatet är egenskap:värde, att det enbart är predikatet som behöver kortas av genom kodning, och att kolon-tecken behöver kodas i övriga delar av uttryck som t.ex. URI:er.

Kommentar gällande dokumentationen

Det skulle vara lättare att förstå om dokumentationen beskriver ett komplett sökuttryck med platshållare för värdet, och med exempel på tillämpning. Inget av fåtalet exempel långt ned på sidan innehåller heller en URI som värde vad jag kan se.

https://entrystore.org/kb/search/#indexed-information

metadata.predicate.literal.<md5>, metadata.predicate.uri.<md5> : Used to carry out queries for exact predicate-object combinations ...

Exempel på förtydligande:

metadata.predicate.literal.<md5>:<value>, metadata.predicate.uri.<md5>:<value>

metadata.predicate.uri.a2b4c6d8:https\://example.com/identifier

Frågeställning

För att återgå till det aktuella problemet; frågeparametern skulle då bli, med kodning för predikat och objektvärde:

metadata.predicate.uri.957f77a7:https\://www.dataportal.se/specifications/matsvinn/1.0

URL, med ytterligare URI-kodning av parametervärden:

https://admin.dataportal.se/store/search?type=solr&query=metadata.predicate.uri.957f77a7%3Ahttps\%3A%2F%2Fwww.dataportal.se%2Fspecifications%2Fmatsvinn%2F1.0&sort=score%2Bdesc%2Cmodified%2Bdesc&limit=50&offset=0&rdfFormat=application/ld+json

Resultatet ger en träff, en datamängd från opendata.umea.se som refererar till specifikationen för matsvinn, vilket verkar rimligt:

"dcat:landingPage": {"@id": "https://opendata.umea.se/explore/dataset/matsvinn/"}

Enklare API

Jag tycker dock att det verkar väl krångligt att konstruera dessa sökningar med kodningar i flera steg. Visserligen går det att automatisera i programkod och skapa ett gränssnitt (vilket då borde ha gjorts från början), men det vore att föredra om det fanns ett API där man kan skicka in frågor mer direkt och använda standard-klienter. Därför tycker jag också det vore lämpligt att koppla på SPARQL-API:et för sökningar i metadata, något som uppenbarligen ingår i den produkt som används för tjänsten.

@august sa i API-användning: Hämta alla dataset kopplade till en specifik organisation:

Det går istället att begränsa sökningen direkt för att enbart få dessa datamängder genom:

https://admin.dataportal.se/store/search?type=solr&query=(rdfType:http%5C%3A%2F%2Fwww.w3.org%2Fns%2Fdcat%23Dataset)+AND+public:true+AND+(metadata.predicate.uri.9259d4c1:http%5C%3A%2F%2Fid.kb.se%2Forganisations%2FSE2021000837)&offset=0

Jag lade till facetten metadata.predicate.uri.<md5> för att söka datamängdens utgivare. I det här fallet är predikatet 'http://purl.org/dc/terms/publisher', men en behöver skapa MD5 hash (och trunkera till 8 chars pga begränsningar i Solr). 'http://purl.org/dc/terms/publisher' blir då 9259d4c1. För mer info om indexeringen som sker via Solr, se: https://entrystore.org/kb/search/ . Där finns också mer info om alla möjliga sätt att söka mot lagringslösningen för admin.dataportal.se

@jonor jag tror Riksarkivets Tora projekt här samma motor och där var SPARQL stödet dåligt och när jag kollade igår så funkade det inte alls…. men som jag skrev på annat ställe är det inte mycket fart på det projektet

Jag gjorde där SPARQL federation med Wikidata för att kolla att all deras data om församlingar som också pekade på Wikidata var riktiga

alt text

PREFIX wd: <http://www.wikidata.org/entity/> PREFIX wdt: <http://www.wikidata.org/prop/direct/> SELECT DISTINCT ?instance ?TORA_label ?TORA_province_name ?wdLabel ?wdAdminLabel ?WDAdmin ?TORA_parishcode ?TORA_wd ?TORA_wd ?WD ?WDsame ?item ?Wiki WHERE { ?instance a <https://data.riksarkivet.se/tora/schema/ModernParish>. ?instance skos:prefLabel ?TORA_label . OPTIONAL {?instance tora:province_name ?TORA_province_name} ?instance tora:parishcode ?TORA_parishcode . ?instance rdfs:seeAlso ?TORA_wduri . BIND (REPLACE(str(?TORA_wduri),"https://www.wikidata.org/wiki/","") AS ?TORA_wd). BIND (REPLACE(str(?item),"http://www.wikidata.org/entity/","") AS ?WD). BIND( IF(?WD = ?TORA_wd, "Y", "N") AS ?WDsame). SERVICE <https://query.wikidata.org/sparql> { ?item wdt:P31 wd:Q1523821; wdt:P777 ?TORA_parishcode . OPTIONAL { ?item rdfs:label ?wdLabel. FILTER(LANG(?wdLabel) = "sv"). } OPTIONAL { ?item wdt:P131 ?WDAdmin. ?WDAdmin wdt:P31 wd:Q193556. ?WDAdmin rdfs:label ?wdAdminLabel. FILTER(LANG(?wdAdminLabel) = "sv"). } } FILTER (( STRSTARTS(str(?TORA_wduri), "https://www.wikidata.org/wiki/")) ) } order by ?TORA_label

@jonor testade att samla ihop saker i denna tråd fyll gärna på

@jonor @mattias jag tänker att ni säkert sett att det finns men någon som är inne här kanske inte har hittat dit. Det finns en lång kedja i NodeBB Community där de diskuterar för och nackdelar med discourse vs NodeBB.

Trådstartaren skrev 2014 "I saw another discussion "DISCOURSE IS BETTER" but that's not very productive. Instead let's look at what each does better than the other.

I'm posting this under feature requests because that is where I hope this conversation leads."

Så förhoppningsvis har de använt det för utvecklingen och bli bättre, tråden levde senast nov 2021 och 132 inlägg in (jag har inte läst alla).

@Kristine_ Tack! Finns det några planer att infoga dessa identifierare i RDF versionen / datadumpen? Man förväntar ju sig att dumpen ska vara fullständigt och om inte annat hade det varit praktiskt att kunna hålla sig till RDF.

@björn-hagström Bra sammanfattat! Som jag uppfattar pågående arbete så är det en mognadstrappa som vi befinner oss på. Steg ett är att överhuvudtaget möjliggöra att data kan göras sökbar på ett och samma ställe. Steg två är att säkerställa att det som läggs upp håller rätt kvalitet.

@jonor: Dina synpunkter är relevanta och jag funderar på hur vi kan smala ihop dina olika exempel så att det blir lätt att återfinna. (Så att vi senare kan gå tillbaka och se om vi blir bättre). Om du har möjlighet att lägga lite mer tid på detta hör gärna av dig till mig på maria.dalhage@digg.se så kan vi ha en kort avstämning.

@jonor
Hej,
Tack för ditt förslag. Jag slog ihop dem till en och samma, så nu ligger de under taggen öppna data.
Vänliga hälsningar,
Kristine

@tove Hej! Tack för input!

Jag tar med din fundering till våra verksamhetsutvecklare och hoppas kunna svara dig inom kort!

@jonass Jag har inte någon praktisk erfarenhet, men såvitt jag förstått verkar HATEOAS påminna mer om hur webben redan fungerar. I det avseendet borde det ju kännas mer intuitivt eller bekant för en användare, och utvecklingsmässigt mer likna designen för en webbplats eller webbapplikation där klienten är en webbläsare. Att gå från inget API direkt till HATEOAS kanske i så fall kan vara enklare än att bygga om ett befintligt API med statisk specifikation?

Projektet med SL:s nya API verkar visserligen ha drabbats av förseningar, om nu detta kan ha ha att göra med valet av API-design är svårt att veta såvida de inte rapporterar öppet om utvecklingsarbetet.

https://www.trafiklab.se/news/2020/2020-06-26-new-sl-apis/

The API is RESTful and supports HATEOAS implying simpler error handling and navigation of information.

The new SL API ”Public transport information Region Stockholm” replacing today’s 7 SL APIs at Trafiklab

The new SL API has been delayed to Q1 2021. We will update you when we know more.

SL launched its first open APIs in 2014 and today there are 7 APIs with a functionality that has gradually been extended. These services have been used extensively, and SL has received valuable feedback that has been used as part of the basis for the design of the new open SL API.

@salgo60-ej-aktiv Ditt inlägg handlar mer om arbetssätt än om APIer, så jag flyttade det till den här tråden.

@jardenberg
Kul att du hittat hit! Observant reflektion men dessvärre så kan jag inte se att datumformatet går att ändra i inställningarna.

Vi kan se över om det finns läge att i framtiden ändra det i mån av tid.

Vänliga hälsningar,
Kristine

@Magnus-Sälgö Som du vet är vi väl medvetna om att det är svårt för många kommuner att på riktigt komma igång med öppna data och en bättre datahantering i allmänhet. Vi kan inte påverka hur lagen om öppna data ser ut, och har inte heller resurser till att hjälpa alla 290 kommuner, eller medel till att tex samla in data från alla kommuner. Arbetet med öppna data bygger mycket på eget initiativ från kommuner och andra offentliga aktörer. Just nu sker det en översyn hos EU av bl.a. Öppna data direktivet och andra datarelaterade EU-regleringar, så om vi har tur så blir det en ändring i styrningen vilket kan göra det enklare för oss att stödja bl.a. kommuner.
I detta community kan vi inte svara på hur Digg i allmänhet implementerar olika saker, även om vi såklart alltid förespråkar att våra rekommendationer ska implementeras av hela Digg, men i slutändan är det varje enhets beslut och Diggs prioriteringar som styr (alltså inte något vi i gruppen kring dataportalen bestämmer över). Så för dessa typer av önskemål och diskussioner är det bättre om du hör av dig till info(at)digg.se.

@kristine_ Tack. Mail skickat!

@jonor tycker eionet gör det snyggt med identifierare se bathingWaterIdentifier där man är tydlig "Methodology for obtaining data"

Must be a valid bathing water identifier in the "WFDProtectedArea" registry

i mitt hobby Projekt svenska badvatten försöker vi skapa denna i Wikidata tillsammans med Naturkartan, Badkartan IN OCH RÖSTA UPP alla kan vara med och Wiki världen är duktiga på att hantera versioner av data länk exempel, diskussionssidor, enkelt prenumerera/ pinga andra - saker som behövs om löst kopplade system/ personer/ organisationer skall kommunicera vilket TYVÄRR svenska myndigheter, kommuner verkar vara..:

personlig fundering badplatser varför låter man kommuner skicka in koordinater som finns på land och varför finns ingen kvalitetssäkring med Lantmäteriet och varför skickas dålig data till EU. Och varför ställs inte krav på Lantmäteriet att för badplatser ha id = bathingWaterIdentifier

saker vi hittat när man kollar på datat fel loggade med just koordinater vi inte tror på felet är även spårbart på objekt i Wikidata se SPARQL som hittar objekt för badplatser vi satt lägre rang på för att vi som lekmän inser att här vill vi inte bada alla dessa fel skickas sedan utan kvalitetssäkring till EU som inte heller kvalitetssäkrar sakerna känns mer och mer som DN artikeln är allt för sann

1ec972fb-aa54-49d4-8680-4327c601d2f2-image.png

Tack för att ni meddelar! 🐹

@kristine_ bra jag la upp den som issue 4

skapa gärna en projektyta så vi kan se vad som händer länk

@dennis_priskorn

Bra fråga, jag att det krävs ett kontinuerligt arbete för att öka medvetenheten om Sveriges dataportal (inkl community) på en bred front, både hos offentliga aktörer, näringslivet och civilsamhället. Idag arbetar vi framför allt med att bjuda in och informera om communityt i de sammanhang och nätverk vi deltar i, och i den samverkan som bedrivs i olika uppdrag och projekt.

Vi har en del tankar på att vi i framtiden ska kunna utveckla en närmare mer operativ samverkan med offentliga aktörer kring dataportalen, communityt och nyheterna. Det skulle till exempelkunna vara att representanter från andra organisationer kan agera moderatorer för till exempel vissa grupper eller intresseområden inom communityt. Men än så länge är det mer på idéstadie då communityt är så nytt.

Eftersom dataportalen pekar på datakällor som finns "någon annanstans", behöver vi vara lyhörda mot de som tillhandahåller data. Vi vill med communityt främja kunskapsdelning, inspiration och dialog - samtidigt som det inte ska stöka till feedback/frågeloopen till olika organisationers utvecklarportaler eller kundmöten. Så det blir ett lärande hur vi tillsammans (dvs aktörer som tillhandahåller data tillsammans med använder data) vill och kan utveckla samverkan framåt på både teknisk och organisatorisk nivå.