-
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
-
Forked by
Maria_Dalhage
-
@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)
-
@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 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.
