-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tydlighet med hur datasetet refereras och version, datum publicerat etc.,.. #72
Comments
Först vill jag observera dig på att alla metadata som finns om datamängder på dataportaler är insamlade från andra aktörer, det betyder att det inte alltid går att garantera saker, men så här ser det ut:
För att ta ett exempel: Längst ner finns ett sätt att komma åt dess RDF via följande länk: Det är alltså en entry som har numret 9140 inom kontextet 91 (motsvarande SCB) som kan nås där, notera flaggan recursive=dcat som gör att man även får med datamängdens distributioner, dess publisher, contactPoint osv som egentligen förvaltas som separata entrys. Vilket är en RDF graf där dcterms:modified motsvarar modifieringsdatumet på entryn. I dagsläget har vi inte metadatahistorik påslaget per datamängd i dataportal.se, det är inget som prioriterats hittills och delvis på grund av hur skördning från olika aktörer ibland slutar fungera och då skulle skapa en omfattande metadata historik utifrån rena tekniska skäl. Hoppas detta besvarar iallafall en del av dina frågor. |
Tackar för svar Det jag tror jag är ute efter som steg 1 är mer tydlighet och även använda PID Persistent Identifiers som DOI dvs. precis som ORCID pekar unikt på en person kan vi inte hålla på och skicka runt dataset med olika URL:ar utan det SKALL finns EN unik persistent identifierare för det datasetet annars kan vi aldrig förstå varifrån datat kommit Bra video om ORCID och vad ORCID försöker lösa för problem dvs. ungefär det jag ser med Öppen Data. Vi börjar nu få data i denna portal, i data.europa.eu och organisationer som Naturvårdsverket har sin egen portal... det är väldigt rörigt, DIGG säger sig driva saker men det är i princip omöjliga att följa vad dom gör och de känns inte som en naturlig ledare utan mer tysta administratörer plus att saker skickas runt som textsträngar gör det hela oöversiktligt och mindre professionellt plus att alla "skyller på den som laddar upp" dvs. den kanske med minst kunskap... se svar jag fick från EDP Helpdesk och bristen på bra metadata jag tycker mig se i European data portal länk jmf
finns även knapp Cite Dataset --> tydligt hur man refererar datasetet som källa dock inte enskild data post/Fakta vilket vi vill ha i Wikipedia artiklar Exempel BIBTEX Google approach med dataset
FAIRsFAIR
WikidataVi har nu skapat en egenskap för Öppna data portaler se karta, endast karta Sverige och egenskap P8402 --> att nästa steg blir att med länkad data beskriva enskilda dataset |
@UlrikaDMattsson @matthiaspalmer Exempel hur dumt det blir 2024 Saker är inte persistenta och saknar tombstone pages - Best Practices for Tombstone Pages
Hur är Mathias exempel 2024 "Marktyp per tätort. År 2015"
Styra upp att bra metadata skickas med DCAT-AP till EDP -se issue med dataverkstaden #30 "Styra upp att bra metadata skickas med DCAT-AP till EDP - textsträngar på olika språk - Kunskapsgrafer" Idag skickas svenska textsträngar runt och "fulöversätts"... projekt som dataverkstaden verkar inte ha kompetens att styra upp detta Persistenta identifierare för dataset - ekosystem
Ett dataset skall identifieras med en och samma DOI - DIGG
dvs. den pekar på sig själv men man kan kanske se att den finns på DIGGs dataportal som store-1-resource-15
Kollar vi på Svenska Dataportalen och försöker hitta DIGGS "Digg Leverancier Facturen 2019"
varför skickar DIGG runt sina dataset och konsumenten skall gissa om det är samma data?Finns det en tanke eller klarar DIGG inte ens själva producera vettig data efter att ha varit "digital expertmyndighet" i flera år, jag kan bara instämma med Statskontorets sågning av DIGG... Metadata Svenska portalen - saknas helt DOI som är samma som hos EDP dvs. skräpdata
Kunskapsgraf hos EDP - blir bara trams om saker inte kopplas med länkade dataJag hade fräckheten på ett EDP event 17 nov 2021 att säga att när Google hade presenterat hur dom jobbar med Kunskapsgrafer så
EDP svar var lite mummel vid 54:20 och jag uppfatta att problemet dom såg var kompetensen ute i länderna dvs. för Sverige skulle det vara DIGGs förmåga med KG #70 Googles presentation 22:30 med Knowledge graph reconciliation....
Kunskapsgraf hos NOSADSe #77-18 verkar helt saknas en drivkraft att våga ta steget med bra metadata utan DIGG fokuserar på forum regler... Vaffor då då - varför gör dom på detta vis |
Detta ärende föreslår att det kommer stängas då det redan finns ett tydligt sätt att referera till datamängder via deras URI:er. Det kommer diskuteras på referensgrupp först dock. Att EDP inte följer denna grundprincip inom länkade data är inget vi har rådighet över. Vi försöker påverka dock. |
Ni måste börja sträva efter att ha data kvalitet och jobba ihop med EDP
enklast är att hämta hem EDP referensen och ange schema.org/sameAs som rekommenderas hos Google Blog "Building Google Dataset Search and Fostering an Open Data Ecosystem". Samma borde rekommenderas dom som laddar upp på svenska dataportalen....
Publisher: Myndigheten för digital förvaltning det är ett otyg att Publisher verkar vara textsträngar på svenska när det skickas till en Europeisk dataportal... ex. https://data.europa.eu/data/datasets/https-catalog-digg-se-store-1-resource-15?locale=sk |
Skall vi i Wikidata peka på ett dataset som en källa så bör vissa saker finnas
jag tycker mig sakna detta i https://www.dataportal.se/
jmf . Wikidata Cite This Page Q92961134 som visar hur posten om Sveriges Dataportal Q92961134 skall citeras....
Bäst vore om vi börjar använda DOI eller skapar en egen för dataset/data se hur British Library jobbar aktivt i projekt som FREYA för att de som publicerar vetenskapliga publikationer skall använda DOI och ORCID för författare
The text was updated successfully, but these errors were encountered: