Community på Sveriges dataportal

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

@jonor mycket relevant fråga men jag tror inte vi är där ännu.... kan vara så illa att man pratat om öppen data sedan 2012 men vi har ingen sjukdomsinsikt eftersom data skapas utan att användas se DN artikeln....

ofta skyller vi på att EU inte sagt vad som skall göras men i detta fall visar dom hur man skall göra det.... ser dock inte att DIGG, grunddata utredningar eller andra tar rygg kollar du på EEA så definierar dom termen i dataelements/99263 och anger tydligt att denna term föds genom att skapas "Methodology for obtaining data" i WFDProtectedArea kollar vi på ett bad ex. Mälarhöjdsbadet SE0110180000001843 så ser man där hur detta concept är definierat dvs. samma borde göras för Stor Stockholm

85e0a461-a110-469b-8d09-a0ea42b1ab62-image.png

Concept-URI euProtectedAreaCode.SE0110180000001843 Accepted Date: 22.11.2019 Status: Valid - stable In country: SE (Sweden) in common/countries Identifier scheme: euProtectedAreaCode (euProtectedAreaCode) in wise/IdentifierScheme Specialised zone type: lakeBathingWater (Lake bathing water) in inspire/SpecialisedZoneTypeCode

För att WIkidata skall fungera i detta ekosystem har vi skapat en egenskap Property:P9616 "Eionet bathingWaterIdentifier"

Min tro

Är vi seriösa med Öppen data måste vi sluta skicka runt textsträngar i csv filer utan stöd för flera språk och tydliga relationer som ovan.... saker måste vara mera datadrivna.... kollar jag på datat ovan så känns det som man laddat upp lite csv filer som nu inte underhålls --> tyder på brist på design och man har fokus på att skapa websidor som är "snygga" men det finns inga informations arkitekter som styr med rak hand ---> dålig data och data som ruttnar Jämför Svenskt Kvinnobiografiskt Lexikon som har en databas KARP Artikel Greta Garbo svenska www.skbl.se/sv/artikel/GretaGarbo engelska www.skbl.se/en/article/GretaGarbo json www.skbl.se/sv/artikel/GretaGarbo.json dom har API som vi kan kolla och stämma av med Wikidata Wikidata har deras unika identifierare i egenskap P4963 som skapades 19 mars 2019

varför ser vi inte det hos kommuner med info om baddata/ gym etc... nu är det ad hoc och egna "snygga web:ar" men skapar en helt oätligt soppa då det gäller

att konsumera data som data exempel på hur bra det kan fungera är EEA som även har ansvarig person och ansvarig person är kompetent och svarar på 66 minuter se email - enormt professionellt för att raljera lite så känns dagens Öppna data lite som att tro att befintlig organisation kan skapa infrastrukturen ovan är som att gå till bilskolelärare och be dom skapa självkörande bilar.... fördelen med självkörande bilar att ingen skulle sätta sig i dessa biler och projektet skulle stoppas, öppen data verkar vara helt kravlöst och utan styrning känns lite som Stockholms skolplattform...

/med hopp om att jag har fel

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

@erik-viklander finns säkert bättre ideer men det känns som ett lågt hängande frukt....

Kan man sedan bygga ett lager som kombinerar Wikidata med GITHUB topic skulle mer avancerade frågor kunna ställas

ge mig alla appar med kategoriserats GITHUB repositories med ett officiellt språk i Sverige... --> Q34#P37 Sverige som graf

ebe8420c-a4de-4340-ae0a-d4deb05b384e-image.png

svenska graf / GITHUB topic samiska graf / GITHUB topic finska graf / GITHUB topic meänkieli graf / GITHUB topic saknas romani graf / GITHUB topic jiddisch graf / GITHUB topic

@datahamstern
Hej! Bra att du lyfter detta perpektiv och intressant att höra om din prenumerationstjänst! Ps berätta gärna mer om den under goda exempel-kategorin så kanske fler hittar till den 🙂

Vi ser gärna att de aktörer som publicerar sin data till Sveriges dataportal först använder sig av sandlådan för att testa sin metadata och hur den visas upp i gränssnittet. Idag ligger informationen om bland annat sandlådan lite "gömd" och tyvärr är det nog så att många inte hittar den. Men vi arbetar med att förbättra dokumentationen för dataportalen (docs.dataportal.se) och vi tar med oss detta perspektiv.

Sandlådan finns för att alla som vill publicera sin data ska kunna testa och se hur olika förändringar i metadatan slår igenom i gränssnittet, vad olika fält visas upp osv, rekommendationer vad gäller tidsserier osv. På så vis vill att när publiceringen går "live" ska den vara bra och bidra till en positiv upplevelse.

Du får gärna starta trådar om hur publikationerna från organisationer till dataportalen kan förbättras, det är bara positivt att få din feedback som användare av dataportalens tjänster.

/Kristine