Guidelines Hantera persistenta identifierare för dataset som laddas upp på flera ställen

[salgo60]

IA

Contact Details

[email protected]

What benefits does the suggestion solve?

Idag laddas ett dataset upp ofta på massa olika ställen, samma dataset bör ha EN persistent identifierare så att konsumenten ser att det är samma data på alla olika ställena se hur svenska dataportalen och edp inte verkar utbyta persistenta identifierare och inte heller den enskilda kommunen /myndigheten #82 Persistenta identifierare för dataset - ekosystem --> att jag som konsument omöjligen kan avgöra om det är "samma" data

Se "Building Google Dataset Search and Fostering an Open Data Ecosystem"

Connecting Replicas of Datasets
"It is very common for a dataset, in particular a popular one, to be present in more than one repository.
We use a variety of signals to determine when two datasets are replicas of each other. For example,
schema.org has a way to specify the connection explicitly, through schema.org/sameAs,
which is the best way to link different replicas together and to point to the canonical source of a dataset.
Other signals include two datasets descriptions pointing to the same canonical page, having the same Digital Object Identifier (DOI),
sharing links for downloading the dataset, or having a large overlap in other metadata fields.
None of these signals are perfect in isolation, therefore we combine them to get the strongest possible indication of when two datasets are the same."

Feature suggestion description

En tydlighet i specifikationen om vikten av att ett datatset inte har olika persistenta identfierare på olika ställen eller som i fallet #82 att det enbart hos EDP verkar som de sätter en persistent identifierare och anger hur detta data skall citeras men detta sätt att citera datasetet delas inte av svenska dataportalen utan vi får 2 datasilos

Alternative solutions

schema.org/sameAs

Additional information

No response

[salgo60]

Exempel hur konstigt dataverkstaden refererar till dataset/specifikation och länkröta skapas
www.dataportal.se/sv/specifications/matsvinn...q=Matsvinn...spec_standard%24spec_profile...

• korrekt att länka dataportalens spec är dataportal.se/specifications/matsvinn/1.0 om denna spec flyttas till EDP borde EDP ha samma Adress för specifikation alternativt schema.org/sameAs

Korrekt borde vara att dataverkstaden jobbar med persistenta identifierare och inte massa sköra websökningar, inget datum finns på dataportalens sida om Matsvinn men dagens hantering av att länka verkar bli fel redan efter några månader enl. troligen den spec matsvinn dom försöker länka så skapades den för 9 månader sedan = 28 mars 2023

• annat antipattern hos dataverkstaden är att dom inte verkar kolla sina egna länkar... utan det är vi som konsument som gör jobbet åt dom...
• etiketten "Adress för specifikation" borde tydligare ange att denna spec citeras enligt xxx och att det är en persistent identifierare och ännu bättre om man har en DOI och inte börjar hitta på nya instabila saker...
  • om dataverkstaden som säljs in som att dom kan öppna data inte gör det har vi enorma problem blir "en blind som leder en blind" se VINNOVA som verkar ha köpt grisen i säcken "Verkstaden har en ansvarig ledare, projektledaren i denna ansökan, och olika former av kompetensgrupper för dataverkstadens löpande genomförande. Utöver det finns från start förmågor inom öppna data, informatik, arkitektur, och juridik." .... mig veterligen är det väldigt spretigt med dataverkstaden och det saknas EN publik backlog för mig en early warning precis som ovanstående klantighet med websidor med länkröta...
    • är det så att VINNNOVA har dålig koll vart våra skattepengar spenderas?

[salgo60]

liknande problem med dataportalen att identifiera organisation där organisationsnumret troligen är unikt men man geggar till det med en konstig url som pekar på en sida som inte finns hos KB...

organisationer identifieras med org nummer som pekar på en sida utan landningssida exempel sökning

• organisationsnummer 2021000837 anges som http://id.kb.se/organisations/SE2021000837

fel hos dataportalen eller kb?

• problem med dataportalen/DIGG och KB att dom saknar publik backlog så vi vet inte om dom jobbar på detta eller om detta inte är ett problem...

[salgo60]

"Strings not things" dvs. här saknas persistenta identfierare eller peka med schema.org/sameAs och vi får gegga 3.0 för nyckelord

• DIGG har skapat Concepts docs.dataportal.se/concepts
• Dataportalen enl. denna sökning jobbar med text strängar och lägger översättningar för troligen samma ord som 2 text strängar hur skall detta skala till EUs alla språk kan vi bara spekulera i... och om jag inte kan språken som visas hur skall jag då gissa mig till om det är samma ord... saknas alltså
  • ett fungerande ekosystem
  • 5 stardata
  • att DIGG lever som dom "lär"... och använder på sin egen portal den funktion som finns där för concepts
  • och som alltid saknas en publik backlog om detta jobbas med och tydlighet vilka projekt som jobbar med vad och vem är ansvarig för gegga 3.0

[salgo60]

Verkar nu som svar skickas in i Google docs ;-) och saker stängs med motivering vi jobbar med det redan... jag vill se

• issues skapas i backloggar hos respektive projekt läs om flummet Statskontoret beskriver hur DIGG jobbar idag

En reality check är att

• hela dataportalen lider av detta antipattern #82
• dataverkstaden fattar inte PID:ar och hur man skall referera se #40 - projekt där @matthiaspalmer och hans företag konsultat i över ett år kostnad > 5 miljoner skattekronor ...

Är det mer ryggen fri än styra upp?

[salgo60]

• var/hur sker det och kan ni påvisa att det blir bättre? DCAT pratas det om 2016 varför tar det 7 år?