Stämma av "depict" på bilder mot en auktoritet

[salgo60]

• 4184 bilder i Wikicommons som har "samma som" bild hos RAÄ P1260

Tanke: stämma av om det Wikicommons har stämmer med det RAÄ har

• hitta fel "depict", fel kopplingar till RAÄ
• hitta vandaliseringar i Wikicommons
• få en känsla av kvaliten i Wikicommons och SDC
• kanske hitta bilder som borde vara kopplade

Min tro är att för att göra bra Dataroundtripping så skall även RAÄ ha koll på vilka som har deras bilder se vaga tankar

EDIT RAÄ has a tool UGC --> they have connections to Wikicommons --> we can test "forward propgation" see API call for 1000 items

• Example
  • Wikicommons File:Ring_with_rune_carving_(6876085687).jpg same as M83243907 is same as SHM 23481

• M83243907 json is same as SHM 23481

• has P1260 = Swedish Open Cultural Heritage URI = "shm/object/879419"

[salgo60]

Notebook accessing UGC på G

[carwash]

Några tips på hur man kan hitta länkade poster via K-samsöks resp. UGC-Hubbens API:er.

Först bör det påpekas att man kan hämta RDF:n för en post genom att lösa upp dess URI. Obs dock att man ska ange vilket format man vill ha i anropets Accept headers; anger man text/html, som webbläsare gör, kommer man istället att pekas om till postens HTML-representation hos dess resp. ansvarig organisation. K-samsöks förvalt serialiseringsformat för RDF är RDF/XML, men den stödjer även JSON-LD. Så här skulle man kunna hämta, formatera, och visa RDF:n för en post genom att lösa upp dess URI:

RDF/XML:

$ curl -s -L -H 'Accept: application/rdf+xml' 'http://kulturarvsdata.se/uu/srdb/70a83aee-bf96-4564-b98c-8be7f5f5fe2c' | xmlstarlet fo - | less

JSON-LD:

$ curl -s -L -H 'Accept: application/ld+json' 'http://kulturarvsdata.se/uu/srdb/70a83aee-bf96-4564-b98c-8be7f5f5fe2c' | jq '.' - | less

Det kanske finns några länkar till andra poster där i RDF:n, men att lösa upp postens URI räcker inte för att hitta alla länkar med anknytning till den: det kan nämligen finnas länkar hos andra poster som pekar hit, och för att också hitta dessa behöver vi ta hjälp av K-samsöks API, och metoden getRelations. Som med URI:erna kan man välja mellan XML och JSON som svarsformat. Här ska vi hitta samtliga länkar om (dvs både till och från) runstenen Bo KJ61:

XML:

$ curl -s -H 'Accept: text/xml' 'https://kulturarvsdata.se/ksamsok/api?method=getRelations&inferSameAs=yes&relation=all&objectId=uu/srdb/70a83aee-bf96-4564-b98c-8be7f5f5fe2c' | xmlstarlet fo - | less

JSON:

$ curl -s -H 'Accept: application/json' 'https://kulturarvsdata.se/ksamsok/api?method=getRelations&inferSameAs=yes&relation=all&objectId=uu/srdb/70a83aee-bf96-4564-b98c-8be7f5f5fe2c' | jq '.' - | less

Obs. att vi anger parametern inferSameAs=yes – det betyder att K-samsök inte bara ska kolla länkar till/från posten i fråga, utan ska även räkna med relationer till poster som den här posten är owl:sameAs eller dcterms:replaces och betrakta dem som om de även gäller för posten vi angivit i anropet. Vi kan se i svaret att posten om runstenen Bo KJ61 från Samnordisk runtextdatabas är owl:sameAs posten om lämningen runristning L1967:2867 / Tanum 576:1 från Kulturmiljöregistret – dvs posterna beskriver samma sak, fast från två olika system – så anropet slår ihop deras resp. länkar. Man kan utelämna parametern, eller ställa den på no om man bara vill ha länkar som handlar specifikt om den angivna URI:n, och huruvida en relation har härletts eller inte anges med attributet source="deduced" i svaret.

Vi ser också i svaret att posten avbildas av (isVisualizedBy) ett antal bilder. Dessa länkar kan motsvara bilder som har laddats upp på Wikimedia Commons; men det är nog säkrast att slå upp deras URI:er innan man drar hastiga slutsatser: RDF:n skulle kunna innehålla ytterligare identifierare som kan underlätta att matcha mot bilder på Commons, eller kan ha dcterms:replaces URI:er som motsvarar bilder på Commons.

(Obs. att länkar i K-samsök är ömsesidiga, så det går lika bra att göra åt andra håller: slå upp en bild-post för att ta reda på vad den avbildar [visualizes]. Jag utgår dock ifrån att du vill primärt slå upp poster på runinskrifter.)

Länkarna i K-samsök har skapats av de resp. kulturarvsorganisationerna som står för posterna. Att hitta ytterligare länkar som har crowdsourceats från användare via UGC-Hubben funkar på ett likadant sätt, fast då via UGC-Hubbens API:

$ curl -s -H 'Accept: text/xml' 'https://ugc.kulturarvsdata.se/UGC-hub/api?method=retrieve&scope=all&objectUri=http%3A%2F%2Fkulturarvsdata.se%2Fuu%2Fsrdb%2F70a83aee-bf96-4564-b98c-8be7f5f5fe2c' | xmlstarlet fo - | less

Här hittar vi ännu fler bildlänkar som har bidragits av användare. Det kan även finnas länkar till bilder på Wikimedia här. Obs dock att UGC-Hubben är parallell med, men separat från, K-samsök, och den har ingen kännedom om saker som owl:sameAs eller dcterms:replaces relationer som kan gälla för URI:n i fråga; det finns inget som motsvarar K-samsöks inferSameAs, så om vi skulle vilja hitta UGC-länkar om andra poster får vi göra det för hand med ytterligare anrop.

På det här viset kan man hitta länkar mellan runinskrifter och bilder – och mycket mer: egentligen alla sorters länkar mellan alla sorters poster! – via K-samsöks API.

API:erna är ju inte lika smidiga som SPARQL när man vill dra in data från andra källor. SPARQL fanns inte när K-samsök byggdes, men det är något vi vill ha till nästa versionen. För tillfället, om man känner behovet att ställa SPARQL-frågor mot K-samsöks data, får man ta en lokalkopia på posterna man är intresserad av och kör frågorna på sin egen triplestore. Abbe98 har skapat några verktyg som underlättar denna process om man ska lägga in delmängder av K-samskök till Blazegraph:

• SOCH-download-CLI för att ladda ner datan;
• Blazegraph-import-CLI för att importera datan;
• thor och soch-sparql-query-library för att underlätta att ställa SPARQL-frågor genom ett snyggt gränssnitt;