Inaktiva PID / avpublicerat material #13
Comments
|
Håller med RAÄ håller på med httpkoder och gissar varför saker försvunnit det känns inte 2023 Exempel med RAÄs bebyggelseregistet där vi hittade flera 1000 döda länkar och RAÄ själva började gissa att det är copyright osv sv... RAÄ är en myndighet som lekt med detta i > 10 år och har ingen vettig helpdesk där man får ett helpdesknummer och en sida man kan följa ärendet --> gör datat blir mer eller mindre oanvändbart för andra än Wiki entusiaster... jag skulle vilja säga ha en kunskapsgraf där man kan följa livscykeln, tycker det även skall vara tydligt hur en PID föds där kan man titta på EEA hur dom beskriver kriteriet och vem man kontaktar om man vill ha en ny data element bathingWaterIdentifier 99263 Methodology for obtaining data Exempel udda ändring som RAÄ gjorde för att vara "tydligare"
|
|
UM-10 säger bara att man ska svara med status koden 410. |
|
Eventuellt kan man också använda link rel=sunset då den: Den definieras här: https://www.rfc-editor.org/rfc/rfc8594.html |
Men som Niklas på KB sa i den video intervju Mathias gjorde med honom för 9 år sedan "städa vid källan inte ha ett reningsverk vid varje handfat" det bör vara tydligt att för konsumenten av en PID varför, blir det bara en rekommendation att förklara så blir det samma antipattern vi ser hela tiden med öppna data att det levereras massa textsträngar som jag som konsument skall städa upp och tolka... varje sten vi lyfter på visar ett kaos och avsaknad av informationsdesign... DIGG använder ordet främja allt för ofta istället för att ställa krav och säga skall eran organisation leverera data på högsta nivå så uppfyll följande krav #10 Skall vi gå från dagens data silos till där kommuner har sina beslut, kommentarer utredningar med Persistenta Identifierare så behövs saker som ovan vara enormt tydliga att det förväntar vi oss av data leverantören. 
Bilden ovan ett beslut om nytt Naturreservat som 2023 Naturvårdsverket vet om och verkar inte kunna leta fram själva utan ber mig prata med Tyresö kommun.... Här borde Tyresö kommun fått en PID av Naturvårdsverket och Naturvårdsverket peka tillbaka på beslutet i sina register... att inte vara tydlig vad som förväntas av olika aktörer blir inte bra... idag verkar det mesta vara ett kaos...
Mitt RAÄ exempel ovan så la vi ned 10 tals timmar att förstå problemet som efter 1 år kommenterades av RAÄ att nu var det fixat dvs. det var nog en bugg hos RAÄ.... Mer tydlighet hur man uppträder för att vara bäst i klassen Tack |
Maintenance hell - utan tombstone pages #383775 fel wikidata -> RAÄ - enorma kostnader att underhålla ett dåligt ekosystem för persistenta identifierareMin Issue #4 "att skapa Best practices" känns mer än viktigt om detta skall bli något... plus att vi får inte ramla in i den vanliga DIGG fällan att det bara blir en pdf spec utan att ett ekosystem byggs kring detta med att hantera livscykeln med persistenta identifierare från att
Jag testade 2023-09-08 att köra igenom 173 000 länkar Wikidata -> RAÄ där RAÄ inte har följt Best Practices for Tombstone Pages som rekommenderas ovan utan endast ger dig http-koden plus en statisk text --> att städaktiviteten att förstå vad som sker blir konsumentens problem = "ett reningsverk vid varje handfat" --> Maintenance hell
Rekommenderat utseende på tombstone page
This page conforms to best practices for tombstone pages.
RAÄs ekosystem med httpkoder och en statisk text på svenska - Problem 1: följer inte rekommendationen på tombstone pagesExempel fel från RAÄ
Status samma test 2021-03-25 med samma dataset fel funna 4605På Wikipedia diskuterades detta fel från 27 september 2020
Problem 2: RAÄ saknar bra mönster för att hitta länkröta i sina system - jmf Humlab Riksdagen CorpusRAÄ saknar publika backlogs och enkelhet att logga fel med helpdeskid --> maintenance hell för konsumenten Att kontinuerligt kolla av sina PID:ar och datakällor dom kopplar till som Wikidata gör Humlab Riksdagens Corpus något som alla måste göra...Jag sliter en del med Svenska Riksdagsmän och Wikidata där ett forskningsprojekt Riksdagens corpus valt att ange samma som Wikidata eftersom Wikipedia är den organisation som har bäst kunskap över svenska Riksdagsmän över tid i Sverige (borde vara Riksarkivet och Sveriges Riksdag eller Kungliga Biblioteket...)
Problem 3: RAÄ saknar bra mönster när organisationer lämnar dom - dom verkar bara ta bort posten och skicka 404I körningen ovan finns ett bra mönster att man i PID:en kan se agenten exempel
Flera fel gjorda lesson learned är att skapa detta kaos är inte bara att ett fel görs man brukar prata om "a trail of shit"...
Observer patternEn snygg implementering av Observer pattern vore att även i löst kopplade system kan saker som citation graphs skapas....
dvs. att en SFS som Riksdagen har skulle kunna ha koll på vilka myndighetsförfattningar som refererar den, att utredningar som refereras kan am med ett klick kunna se vilka som refererar till den se #100 #85 status idag är att ex. Esamverkan publicerar dokument som refererar myndigheter som upphört och ligger i en kartong hos Riksarkivet dvs. det saknas helt vettig dokumenthantering vilket jag ser som en brist i vår demokrati och att Sveriges Riksdag inte har 5-star data Fixat av RAÄ 6 september 2021 - tid 1 år
Behovet av best practices #4 är stort för att styra icke digitala organisationer att fungera i ett ekosystem med persistenta identfierare |
|
Problem 4: Hur skall problem med Persistenta identifierare kommuniceras/felanmälas när flera organisationer är inblandade... idag saknas en infrastruktur för att jobba ihop
UPDATE 2023-10-03:
|
|
Problem5: Skall vara enkelt att på landningssidan av en Persistent identifierare se
Pratade nyss med Linnea (som snabbt svarat på twitter) och det verkar vara helt fel i RAÄs del - allt skall levereras dit och det ligger i Linneas backlog att ladda upp fler objekt dvs. min killgissning ovan att Wikidata inte skall peka på kulturnav är nog fel
@carwash vad är RAÄs take på detta?
|
|
Vet inte om ni är mogna för detta men PID livscykeln borde styras upp så att det skalar även mellan olika länders PID:ar och då tänker jag på mer avancerat än http:koder jag tror det skall till bra API:er, SPARQL federation "The Magnus list" det jag ser ovan av RAÄs httpkod baserade "lösning" är att det lätt blir en datasilo med dålig data... men det kanske är en början.... blir ofta lite ghosting då man pekar på problem och vill ha dialog ( se skuggbackloggar)... Wikidata ser behovet att olika intressenter pratar ihop sig så dom har skapat ett event nu 2023 och jag försöker få med forskare på Riksdagen corpus som nu bygger stora delar av sitt ekosystem på Wikidata på gott och ont se länk där jag tycker dom borde jobba med egna kunskapsgrafer och jobba mer internationellt som ParlaMINT WIkidatas utmaning idag är löst kopplade system med olika mogenhetsgrad och en community som bygger på frivillighet... se lista med externa Wikidata egenskaper som idag > 8200 / enbart svenska > 100 tyvärr så skapas inte så många svenska egenskaper lite pga av att initiativ som detta om att standardisera PID hanteringen inte landat och det kaos vi har med massa datasilos utan publika backlogs... 
Hur snyggt Nobelprize.org och Wikidata jobbar ihop med 5-star open dataExempel hur Persistenta identifierare kopplar ihop två löst kopplade system... |
|
Bra exempel som jag tweetade om att RAÄ måste följa "The Magnus List" om man skall kunna hantera livscykeln med persistena identifierare och samspel med dom som "konsumerar" deras datat
|
|
SND har funderat på ett grundläggande informationspaket som hör samman med en tombstonesida för avpublicerat material. Vi har baserat det på Schema.org även om det finns många andra tänkbara lösningar. Vi har inte kunnat hitta kontrollerade termer som exakt mappar mot svensk förvaltning av handlingar, men EU:s OP Core har en lämplig status baserad på ADMS (https://www.w3.org/TR/vocab-adms/) där Completed/Deprecated/UnderDevelopment/Withdrawn finns tillgängliga och Withdrawn mappar mot avpublicerade handlingar. På detta sätt går det att garantera information om hur en handling har hanterats. Syftet är också att underlätta myndighetsutövningen och efterlevnaden av t.ex. kraven i RA-FS 2009:1 och annan relevant lagstiftning som berör hanteringen av allmänna handlingar i elektronisk form. Obligatoriska
Valfria (ett urval av många möjliga)
Motsvarande hantering med HTTP 300?
Noterar också att @salgo60 har uppmärksammat den vikt som EOSC lägger på utförlig maskinläsbar tombstoneinformation. Detta kommer sannolikt bli standard för statlig datadistribution i EU, så det är en god idé att få med en grundläggande implementation redan nu även om den inte är perfekt. |
|
@andre-jernung tack för att du lyfter betydelsen/möjligheter med persistenta identifierares och som jag ser det den enda vägen framåt idag ser jag datasilos och massa länkröta... tror saker skall kopplas mer till Fair data och saker som FAIR Data Maturity Model DOI: 10.15497/rda00045 pdf och The FAIR Cookbook for FAIR doers Jag jobbade med internationella banktransaktioner som konsult på SEB och för att hantera hur 2 banker kommunicerar avvikelser och problem definierades Swift jag tror för att detta med persistenta identifierare skall bli bra så behövs något liknande... och att anledningen skall vara maskinläsbar.... Wikidata har > 7000 olika externa identifierare som ofta inte ens ger oss ett helpdesk id eller har en publik öppen backlog dvs. det blir kaos... jag skapade 2020 en lista med det som behövs av en extern identifierare för att det skall bli bra med Wikidata se "The Magnus list" skall PIDar leva så kan det inte vara ad hoc varje gång fel uppstår... utan mycket bättre styrning behövs... tycker att 2023 är det status quo vi ser galet med länkröta och inga ekosystem som skapas #112 / #76... det positiva jag ser är ett projekt som skapar TEI av Riksdagstrycket med @MansMeg som projektledare där han driver på och har en öppen publik backlog där snygga mönster som att en PR gör tester att deras data är konsistent men även att Wikidata som dom pekar på "sköter sig"....
Exempel på fel
skall detta bli något måste vi prata metadataroundtrippingJag har testat att klassificera fel hos Riksarkivet och andra källor vilket fungerar perfekt med Wikidata som kan hantera motstridiga fakta och även ange vilket fakta som är trovärdigt och varför... tror en liknande maskinläsbar tanke är den enda vägen framåt att sitta och manuellt jaga fel skalar inte och sedan bör detta ske mellan trovärdiga källor där Wikidata enbart skall lyssna och konsumera... vi har idag 2023 skapat enormt bra koppling med Nobelpriset.org som hade massa länkröta och teststrängar och har idag
Annat snyggt mönster är detta med ange olika trovärdighet hos påståenden how to handle differencies compare Wikidata see #35
Vad menar vi då vi säger att vi jobbar ihopIntressant modell "what we mean when we refer to collaboration" Fact sheets: your guide to building collaborative capacity där jag ser att börja knyta ihop myndighets Sverige med pid.ar och samma som är det som är Digitalisering
För mig är det självklart att skattefinansierad verksamhet skall finnas i kolumnen med "high reward" jag ser tyvärr mest ordet främja som jag tolkar som vänstra kolumnen = low reward 
Hör gärna av dig 0735152802 |
|
@andre-jernung jobbar ni med PROV provenance? jag skulle gärna se att Riksarkivet, RAÄ, forskningsprojekt som Riksdagens Corpus och Umeå Universitet Familia hade bättre data och jobbade lika, tycker mig se att i Riksdagens Corpus bygger man mycket av sin kunskap idag på en bok "Tvåkammar-riksdagen 1867–1970" som när vi även skannat in porträttböcker från tidigt 1900 kan se att denna bok klassificerar politiska vildar med en annan terminologi, att inte ha provenance tappar vi en stor del av spårbarheten och trovärdigheten det Wikipedia världen utan källor ofta med all rätt beskylls för men som jag nu ser 2023 års forskningsdata drabbas av.... Känns som en bra tombstone sida skall ha metadata som beskriver proveniens/PROV (Provenance) och PROV är en bra modell för detta....
Exempel bilder och metadata Wikicommons SPA
|
|
@andre-jernung diskussion om PROV hos Riksdagens Corpus https:// github.com/welfare-state-analytics/riksdagen-corpus/issues/421 Exempel hur struligt det är att skapa samma som med Gbg Karp |
|
Möte 4 beslöt att rekommendation 4 är tillräckligt konkret för att detta ärende kan stängas. |
@matthiaspalmer vilka volymer pratar ni om att DIGG/myndigheter/kommuner skall skapa PID:ar - ni borde ha en vision som följs upp och gärna att ni skapar en nyttoberäkning enligt DIGGS mall
Geggan med SCB och skolenhetskoder
UpdateHittar nu av "misstag" detta hos SCB som pekar på att saker finns hos Skolverket... så då måste vi föröka fatta hur dom gör det... kostnaden är enorm för gegga utan persistenta identifierare 
|
|
@andre-jernung interesting how other countries works with research data and knowledge graphs was shown today on CLARIN Café - ParlaMint I feel Sweden needs to step up we see all the time that projects deliver bad data example one project combined seats with Swedish politicians but didn't understand what a persistent identifier is and "invented" something new see issue #450 were another projects cant just consume the data bit needs to clean the data... seems also that there is a culture being afraid explaining for another project that they needs to step up.... result waste of time and money example another example 
Another example Parlamint: LREC-COLING 2024 Workshop: Stay up to date with the cafés: |
Contact Details
[email protected]
What benefits does the suggestion solve?
I specifikationens Rekommendation UM-10 framgår att (inaktiv) PID som pekar på avpublicerat material enbart skall hanteras med HTTP 410-respons utan ytterligare kontextuell information.
Detta bryter i vår mening med de best practices som utformats internationellt men också med förväntningar på transparens och ansvarsutkrävande hos svensk statlig verksamhet.
Feature suggestion description
För PID som pekar på avpublicerat material existerar en praxis med s.k. tombstone pages som kan innehålla information om varför materialet avpublicerats, vad det eventuellt har ersatts av och vem som är ansvarig för beslut och förvaltning.
Ett exempel på denna praxis kan t.ex. ses hos DataCite:s rekommendationer: https://support.datacite.org/docs/tombstone-pages
Alternative solutions
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: