-
I nästa etapp av Riksarkivets API-utveckling kommer vi att exponera metadata om arkivenheterna som länkade data (RDF, i första hand JSON-LD). Därmed måste vi nu fastställa hur resursernas URIer ska se ut. En lätt filosofisk fråga dyker då upp: vilket är snyggast, att path-delarna av URIerna är på svenska eller engelska?
http://data.riksarkivet.se/arkiv/{källa}/{persistent id}eller
http://data.riksarkivet.se/archive/{källa}/{persistent id}http://data.riksarkivet.se/term/{typ, på svenska}/{persistent id}eller
http://data.riksarkivet.se/concept/{typ, på engelska}/{persistent id}osv.
-
-
@Magnus-Sälgö Jag hade två exempel, exakt identifierare är ointressant, det jag funderar på är om det skall vara /arkiv/ eller /archive/, /term/ eller /concept/ osv. Men, om det hjälper att se principen:
Vilken URI är snyggast för https://sok.riksarkivet.se/arkiv/1WBIheq4rX61h03Gjpu0Y3 ?
http://data.riksarkivet.se/arkiv/arkis/1WBIheq4rX61h03Gjpu0Y3
eller
http://data.riksarkivet.se/archive/arkis/1WBIheq4rX61h03Gjpu0Y3
-
@nilsw-ra ok
Lite off topic det jag snurrade in på idag var Brukspatronen E Häggströms, Bygdeå sn, personarkiv där det verkar som NAD anger "depå: Kusthöjden 46" den detaljnivån har vi inte koll på idag i Wikidata - vilket kanske är fel....
Det anges under Arkivinstitution gissar det är lite off topic din fråga men jag blir minst sagt förvirrad vad vi bör ha i Wikidata och vad som finns.... så min undran var mer hur hänger depåer ihop med arkiv och kommer ni att peka på depån... gissar att det kan vara av intresse att hålla koll på det om saker är fysiskt skilda... och hur är förhållandet mellan Arkiv och Arkivinstutition och depå och om det syns i er URI men som sagt det var kanske inte din fråga...
-
@nilsw-ra snyggast är väl inte relevant när det gäller data? Isåfall är det väl viktigare att beskriva de krav som man ställer på sina urlar och vad för datamodell dessa ingår i?
Tänker att json förmodligen utryckts på engelska och då är det väl fördelaktigt om även urlarna (vilka ni förmodligen kommer även skriva ut i JSON) i huvudsakligen är på engelska? Där blir alltså påverkande faktorn istället hur många språk behöver man förstå för att kunna hantera eran data?
Vad behövs för att kunna hantera eran data? Förmodligen kunna förstå er dokumentation, er URL-struktur och era JSON-svar. Vore ju skönt att begränsa det till bara engelska så det blir internationellt gångbart eftersom engelska är ett de facto-språk på internet. Tyvärr måste ni väl förhålla er till språklagen och då kan man väl tänka sig att dokumentation måste finnas på svenska. Jag hoppas ni inte övertolkar den och skriver json-resultaten på svenska också(alltså nycklarna).
Med det sagt tänker jag att @Magnus-Sälgö första svar om slug verkar vara tillämpligt på er concept-endpoint där "typ, på engelska" införs. Jag ställer mig tvekande till sådana typer som inte är dynamiska och lätta att lägga till / ändra och göra alias på. Vad händer om man lägger till en typ som är felstavad? Bryts länkarna eller får man ett alias? Vad händer om felstavningen inte bara är fel utan faktiskt betyder något annat? Undvik sluggar om möjligt säger jag så länge det inte handlar om SEO eller länkar som människor ska läsa ut i löpande text och förstå vad det kan handla om innan man klickar på den.
Senior systemutvecklare i privata sektorn (f.n. Iteam)
-
@Magnus-Sälgö Off topic för min fråga, men jag ska försöka svara. Både arkivinstitutionen (Landsarkivet i Härnösand) och depå (Kusthöjden 46) är auktoritetsposter. Jag ser i databasen att arkivet är kopplat till Landsarkivet i Härnösand, men inte omedelbart var kopplingen till Kusthöjden 46 finns. I RDF-representationen kommer nog bägge att finnas med när den är komplett.
Arkivinstitution med schema:holdingArchive
Depå måste jag reda ut mer om för att veta vad för property -
@Stefan-Wallin "snyggt" är förvisso inte relevant för systemen som ska använda data, men jag tycker det är relevant för människorna som ska läsa och förstå dokumentationen.
Min fundering handlar inte om URLer till API endpoints utan om RDF-URIer, dvs posternas länkade data-identifierare. Dessa kan sedan naturligtvis användas som URL för att hämta data, som JSON-LD eller RDF/XML. Nycklarna i JSON-LD-serialiseringen beror på vilka RDF properties man använder, dessa är normalt på engelska, typ schema:holdingArchive.
Den unika identifieraren, sista ledet i URIerna är normalt en persistent identifierare utan egen betydelse, oftast en Base 62-encodad UUID. Det finns dock befintliga data som hänvisar till begrepp med URIer där även id:t är ett betydelsebärande ord, typ
https://data.riksarkivet.se/tora/namingprinciple/modern
namingprinciple är begreppstyp och modern är ett värde. Dessa är kodvärden som inte ska ändras, inte namn att presentera. Det är för övrigt ett rätt bra exempel på dilemmat, vill vi ha engelska måste vi hitta bra översättningar för de svenska begreppstyperna och värdena.
Jag är kluven till vad som är bäst, det är därför jag frågar. Engelska är som du säger de facto-språk i datasammanhang, men översättningarna kan bli krystade.
-
@nilsw-ra Alla URI:er bör i LD/RDF-sammanhang ses som persistenta i min mening. De är ju en sökväg till det som den persistenta identifieraren pekar ut. Exempelvis är DN's topic-id en slug(tråkigt) men också nästan meningslöst utan sökvägen
https://www.dn.se/om/Ta ämnet
usat.ex:https://www.dn.se/om/usa/. Du kommer inte åt den länkade datan som syftades till på källsajten längre om länken ändras.I ditt exempel med concept/term, är typen av vikt? Vad händer om jag använder samma persistenta identifierare utan typen eller med en annan godkänd typ? Vad tillför typen?
Om jag utan typen eller med annan typ får 404 är rimligtvis typen en del av den persistenta identifieraren i förhållande till hur systemet hanterar entiteten?
Om vi tar istället Wikidata som exempel så har de P-entiteter och Q-entiteter, där är P eller Q en del av identifieraren.
Senior systemutvecklare i privata sektorn (f.n. Iteam)
-
@Stefan-Wallin Alla RDF-URIer är självklart persistenta. Typen och värdet tillsammans ger en unik (persistent) identitet. MEN, det finns också en UUID även för termerna i datalagret, så detta är möjligt:
http://data.riksarkivet.se/term/{persistent id}
eller
http://data.riksarkivet.se/concept/{persistent id}
Då skulle befintliga begreppsresurser, som har /{typ}/{kod} i URIn definitivt behöva en owl:sameAs som pekar ut denna. Det är väl det som tilltalar mig mest, återstår att se om jag kan få med mig övriga intressenter här.
-
@nilsw-ra tackar jag la upp mina OT funderingar på Riksarkivet/dataplattform/issues/5
-
@nilsw-ra I REST-API-Profilen så är frågan om språk inte fullt hanterad. Läs gärna det som finns om språk, https://dev.dataportal.se/rest-api-profil/dokumentation avser att dokumentation bör vara på två språk. Helt sanslöst vad svårt det är att bestämma en så enkel sak som språk (jag deltar i det arbetet). Bra om dokumentation är på engelska, vissa URI:er/namn kommer bli "fåniga" om de översätts till engelska. Sen finns det osäkerhet runt språklagen generellt, är OK att undvika svenska helt för en myndighet. Dina förslag känns förövrigt väldigt bra http://data.riksarkivet.se/concept/{ID} tycker jag! Tänk om flera hade så naturliga URI:er.
-
-
@Magnus-Sälgö Tveklöst så kommer det mesta innehållet i API:er från offentliga organisationer vara på svenska. Sen tror jag inte att det offentliga ska försöka sig på att värdera hur bra språk en individ behöver för att förstå. Mer binärt konstatera vilket språk något är utryckt i. Men just API:er tycker jag är svårt, vacklar själv i denna fråga. Är nog bra att vi resonerar om det här.
-
@jonass ett "problem" vi har i Wikidata där poster mergas enormt mycket som är lite relaterat se SPARQL fråga vad som mergats senaste veckan som är kopplat till Europeana = 63 poster
dvs. 17 aug mergades Q106629593 versionshistorik med Q4767743 - versionshistorik
Problemet här är att om man har en Wikidata identifierare så kan man inte vara säker att det inte är samma objekt som ett annat eftersom den kan ha mergats.... kan enkelt kollas med https://www.wikidata.org/wiki/Special:EntityData/Q106629593.json --> då redirektas till Q4767743
-
@Magnus-Sälgö fast att ta till sig materialet är inte något som t.ex. en utvecklare måste göra, man kan ju bygga tjänster på svenska även om man inte kan ett ord svenska, vilket underlättas när API:er och JSON-svars nycklar är på engelska oftast.
-
@jonass Ja, jag håller med om att språkvalet är klurigt. Det är frestande att säga "engelska", över hela linjen, men det innebär att en mängd verksamhetsbegrepp måste översättas. Min erfarenhet är att dessa översättningar ofta görs fritt av respektive utvecklarteam, vilket leder till svengelska och märkliga svenska "varianter" på översättningar. Ta t.ex. utbildningsområdet, det är inte självklart vad "arbetsplatsförlagt lärande" heter på engelska (som dessutom kan skilja sig mellan brittisk och amerikansk osv).
För många år sen ansåg staten att korrekta översättningar var viktigt och bl.a. utbildningsdepartementet lät ta fram en "Svensk-engelsk ordbok för utbildningsområdet". För att skapa korrekta informationsutbyten och API:er skulle vi behöva normativa ordböcker för resp. domän.
Om vi ser till hur data flödar i en organisation, så färdas begreppen genom ett antal integrationsgränssnitt och mellanprogramvaror. Det finns risker med att ett verksamhetsbegrepp som ursprungligen är på svenska översätts fram och tillbaka ett antal gånger.
-
@mistral och vad händer om ett begrepp delas upp....
tror Wikidatas modell med
- unika egenskapsnummer (uttalande)
- unika objekt id
- möjligt att merga objekt
- hantera alias --> bra för NER
kan hantera viss del av det kaos verkligen utgör....
-
@Magnus-Sälgö Kan nog vara en framkomlig väg. Jag tror på framgång med formella/kontrollerade språk. Varje domän har en specifik, begränsad nomenklatur svenska/engelska, som har en tydlig ägare. "Vem äger den?", kanske någon undrar. Tja...förslagsvis hanterar DIGG en ämnesindelad begreppskatalog, där resp. ansvarig myndighet skapar sin "Master Glossary of Terms".
-
@mistral japp det är en dröm med mogna aktörer som tar ansvar saknar jag kanske Riksarkivet kliver fram... jag gillar det @nilsw-ra gör men saknar att Riksarkivets domänexperter som SBL inte syns se mitt försök med historiska yrken
MEN
Jag tror inte på DIGG det känns som en oldschools myndighet som inte gör skillnad... kan inte ens hantera sin egen länkröta, bygga upp vettiga kategorier ger oss inte helpdesk id, det skapas en nationell Dataverkstad utan publik backlog dom länkar DIGGs länkröta (ingen loggar detta som ett problem eller fixar det).... finns inte en chans att dom kommer att göra skillnad.... känns som alla projekt som körs saknar en metod (fast många lekt i denna sandlådan sedan 2010) blir spännande att se vad som blir av Issue #115
- pengar finns men saker måste styras upp och dessa aktörer måste upp till bevis
Nya aktörer behövs tyvärr Wikidata kan vara en av dom....
Kollar vi på kulturinstitutionerna ser vi samma dysfunktionalitet att Riksarkivet, Kungliga biblioteket är före detta auktoriteter men har svårt att ställa om till ny teknik..... (detta inlägg undantag!!!!)
- min tro man är rädd för att göra Netflix Keepers test
Lyssna på en kille som gör skillnad på Stanford.zoom.us vid 30 min slide 26 han refererar dels min Magnus List men även detta att gamla institutioner/auktoriteter inte platsar i den moderrna digitala världen...
Det finns en anledning att dataportalen.se skapades 2012 och vi sitter 2022 fortfarande på ruta 0 ...
- massa grundläggande saker saknas ge oss Keepers Test.....
I Almedalen fick DIGG frågan om deras verksamhet och svaret blev inte vad dom levererat utan mer att dom blivit så många och vill bli fler och flera myndigheter vill att dom sitter med..... känns även dessa myndigheter borde köra Keepers Test
