Community på Sveriges dataportal

@josefinlassi Hur har det gått med diskussionerna här?

Jag tänkte mest på hur ofta jag som hypotetisk konsument ska kunna ställa frågor mot APIet.
Ska jag kunna fråga en gång i sekunden? Eller en gång i minuten?
Eller var femte minut?
Hur stora frågor ska jag kunna ställa? Tex rimligtvis inte "all data senaste året" då det lär vara enormt mycket som riskerar att sänka servern eller medföra stora kostnader för kommunen.

Men du har nog rätt i att det skulle innebära en tröskel.

Jag vet inte hur det borde se ut, ville bara väcka diskussionen.
Vill man inte som konsument av data (säg att alla 290 kommuner skulle tillhandahålla enligt specen) kunna veta vad man kan förvänta sig för nivå på leveransen? Om det är ett SLA eller inte och om det är görbart är en annan sak.

Nej men om man ska publicera data så kanske den ska gå att använda.
En global rate limit på en förfrågan per minut kanske duger för nyfikna medborgare men är ju kanske inte en effektiv datakälla att bygga tjänster baserat på.
Jag tänker att en rekommendation för detta skulle kunna vara aktuellt för många datamängder eller?

Det låter toppen!

En tanke som kom upp idag på vårt möte kopplat till detta.
Borde inte specifikationen definiera krav på SLA eller kapacitet på publiceringen för att möjliggöra en bredare användning av data när fler kommuner publicerar?
Så att en utvecklare av en tjänst vet vilken nivå på kapacitet den kan förvänta sig?

Hur tänker ni?

Sen borde specifikationen kanske heta Vägunderhåll istället då den är bredare är enbart Snöröjning.

Hej!

Finns det någon plan på att göra klart denna specifikation för parkeringar eller är den insomnad?

Jag har en fråga kopplat till DCAT-AP

Två exempel på rekommenderade fält enligt DCAT-AP är dcterms:spatial och dcterms:temporal

Hur är dom egentligen tänkta att användas?

• Tar man tex dcterms:temporal så är den ju fullt rimlig om det gäller en serie av data, tex Leverantörsreskontra eller olika mätvärden. Där är jag helt med.
  Men om man publicerar tex Cykelpumpar eller Naturreservat, hur ska den användas där? Det finns ju vare sig ett start- eller slutdatum där.
  Så jag tänker att det inte ska användas i det fallet men trots det kommer ju varningar om att data saknas.
  Vet någon vad tanken är? Eller har jag missförstått något?

• Andra exemplet med dcterms:spatial är också lite oklart för mig.
  Iallafall i vår plattform (Entryscape) kan man välja mellan att antingen ange en rektangel som ritar ut området och det kan ju vara aktuellt ibland, dock är ju tex en kommun sällan helt rektangulär så andra kommuner kommer lätt med.
  Vi har i många fall angett en punkt istället vilket också är valbart men då får man varningar om att man inte följer DCAT-AP.
  Är inte en punkt mer lämpligt tex om man vill ange positionen för en mätpunkt av något slag?
  Borde det inte räcka med bara en punkt?

Oklart om jag lade detta i rätt kategori, hittade ingen som känns riktigt DCAT-AP fokuserad.
Kanske borde finnas en DCAT-AP kategori?

@josefinlassi Jag kom på en sak.

I mitt första inlägg i denna tråd nämner jag några fel som nu är åtgärdade.
Jag felanmälde även dessa till Metasolutions då dom levererar Entryscape åt oss.
Dom såg direkt vad felet var och löste de problemen under samma dag.

Dom gjorde det dock tydligt att felanmälan ska göras till DIGG och att ni sedan felanmäler hos Metasolutions.

Så min gissning är att dom snabbt och enkelt kan lösa även de kvarvarande problemen bara dom får en beställning från er på DIGG.

Säger dom @tomasmonsen: Vi vill ha credd för det hårda kvalitetsjobb vi gör kopplat till vår metadata i det här fallet =D

Trevlig helg på er!

Sen finns det andra som förekommer kombinerat med andra.

Tex Umeå kommun, Umeå Energi och Vatten- och avfallskompetens i norr AB tex.
Det är tre olika organisationer som dock verkar dela på samma öppna data-plattform. (https://opendata.umea.se/explore/)
Borde inte dom presenteras separerade på https://admin.dataportal.se/status/overview där dom idag slås samman till "Umeå kommun"?

@josefinlassi sa i Frågor om metadatakvalitet och ev bugg?:

@Andreas-Sundberg Jag måste kolla upp det här, så jag spelar in mina kollegor och återkommer.

Toppen, stort tack!

Nu är dct:accessRights, mediaetyp och ordlista åtkomstbegränsningar åtgärdade.

Däremot finns det fler oklarheter:

• Varför har vi noll poäng på dcat:downloadURL trots att enbart 1% av alla våra url:er är döda?
  (Dom är för övrigt inte döda utan det kan ta några sekunder att ladda flera månaders IoT-data så den tolkas nog som död)

• Vad är det som gör att vi får noll poäng på DCAT-AP-överensstämmelse? Vi följer DCAT-AP till punkt och pricka.

• Vad ska man ange på Rättigheter/Rättighetsförklaring (dct:rights) för att det ska vara korrekt? Vi har ju redan CC0-licens på 100% av våra distributioner.
  Vad gör att vi får noll poäng här?
  Borde väl rimligtvis räcka med licens eller Rättighetsförklaring?

Med vänlig hälsning,

Södertälje kommun

Hej!

Jag kikar på vår Metadatakvalitet på dataportal.se
(https://www.dataportal.se/metadatakvalitet/katalog/_quality/75)

Där står tex under Återanvändbarhet och Användningsbegränsningar (dct:accessRights) 100% Nej för Södertälje.
Jag kan dock inte hitta en enda datamängd som har något annat än Publik satt som dct:accessRights

Och hur tusan anger man "Ordlista för åtkomstbegränsningar" som vi också har noll % på?

Och hur hittar jag Medietyp på Distributioner som vi också har noll% på?
dcat:mediaType

För kännedom: Vi använder Entryscape

@josefinlassi sa i Sökfunktionen behöver trimmas:

@Andreas-Sundberg Nu är det fixat, så du kan söka bara på "snö".

Toppen!

Det hänger ju på om bilens bladläge är kopplat till deras system eller inte.
Ofta är det ju bara så att föraren väljer plogning i sin app och sedan manuellt fäller ner bladet.
Då är det ju ingen koppling.

Jag håller med. Skriver man snö under specifikationer så dyker inte snöröjning upp.
Borde inte behövas wildcard characters (*) för att söka.

Hej!

Vi jobbar i Södertälje på att publicera snöröjning enligt specifikationen.
Vi har ett par frågor:

Det finns en motsägelse. I specifikationen i punkt två "Datamodell" står det att "Tidpunkt anges enligt ISO 8601 med TZD."
I exemplet (längst ner i specifikationen) står det dock bara som en radda siffror vilket alltså inte är vad som står i punkt två Datamodell.
Vilken ska vi följa?

Det vore bra om vi även kunde uppdatera exemplet (längst ner i specifikatonen) till ett med minst två poster så det syns hur vi ska kapsla in det. Utifrån mallen på Github skulle vi tro att det blir typ följande men vi vet inte säkert:

[
{
"source": "5561234567",
"supplier_key": "LeverantörA",
"timestamp": "2024-02-10T08:30:00Z",
"longitude": 18.0686,
"latitude": 59.3293,"measure_type":"SW",
"material": "",
"dosage": "",
"spread_width": ""
},

{
"source": "5569876543",
"supplier_key": "LeverantörA",
"timestamp": "2024-02-10T09:00:00Z",
"longitude": 17.8419,
"latitude": 59.3760,
"measure_type": "PL",
"material": "",
"dosage": "",
"spread_width": ""
},

{
"source": "5563456789",
"supplier_key": "LeverantörC",
"timestamp": "2024-02-10T09:45:00Z",
"longitude": 18.0456,
"latitude": 59.3322,
"measure_type": "GC",
"material": "",
"dosage": "",
"spread_width": ""
}
]

Hej!

Vi i Södertälje kikar på at publicera öppen data för offentlig konst. Kikade på specifikationen (https://lankadedata.se/spec/skr/) och blir förvånad över att inte koordinater finns med i den.

Vore inte det en rimlig sak att ha med?

Vad säger @mattias mfl?

Jag tror också på att skala ner det till en betydligt mindre nivå av data. Mycket för att sänka tröskeln.