URI:er med fragment

[carwash]

Hej! Jag ifrågasätter "Rekommendation BI-5 Använd inte URL:er med fragment." då detta är ett känt och på flera håll etablerat mönster för att komma runt httpRange-14-frågan. Om man inte vill hela tiden 303 peka om URI:er för icke-digitala resurser till digitala dokument som beskriver dem, en vanlig lösning är att ge saken och metadatat nästan samma URI, men skilja dem bara på fragmentet. Därmed kan man få datat man vill komma åt, både om saken och dokumentet, med ett och samma anrop. T.ex. http://example.com/1234 och dokumentet som beskriver den http://example.com/1234#doc eller tvärtom http://example.com/1234#it och dokumentet som beskriver den http://example.com/1234 Det är t.ex. så KB gör hos Libris, med …#it för själva saken, och utan för metadatat.

Missförstår mig inte – jag fattar att det är problematiskt med fragment i URI:er, och föreslår inte att vi ska på något vis förespråka dem i rekommendationen. (De passar nog bäst för att skilja mellan olika beståndsdelar i en resurs, snarare än att skilja mellan olika resurser.) Jag vill bara påpeka att de är redan idag vanligt förekommande i befintliga beständiga identifierare hos stora aktörer, och att detta bör nog tas hänsyn till i rekommendationen.

[lokal-profil]

@carwash Jag kan se din poäng just i relationen tinget <->beskrivning av tinget som ofta har en benägenhet att blandas ihop.

Undrar om du ser några andra relationer som skulle vara nära nog för att försvara att de bara särskiljs med fragment? Speciellt intressant om du har något exempel med mer än två saker som särskiljs via en sådan mekanism (och det är försvarbart).

[dpriskorn]

Jag ogillar fragment som särskiljning av resurser. Det är inte bra design i mina ögon. Att flera stora svenska offentliga aktörer designer det ena kassa system efter det andra är inget att pejla efter eller på något vis ta hänsyn till.

[carwash]

@lokal-profil @dpriskorn Jag försökte vara tydlig i mitt första inlägg, att jag inte vill förespråka eller ens försvara det som god praxis. Det jag ville påpeka var, att det är trots allt redan vanligt förekommande. Mitt konkreta förslag skulle då kanske vara att (starkt?) deprikera fragment – men jag tror att förbjuda skulle kunna orsaka problem hos befintliga system. Eller kanske inte? Det är kanske lätt att ändra befintliga förekomster?

[matthiaspalmer]

@carwash Jag är medveten om existerande praxis att använda fragment i URI:er i vissa lägen för att undvika 303 redirects. (Cool URIs och httpRange-14 frågan,) Som jag skrivit i texten innan BI-5 så finns det dock nackdelar med användning av fragment, framförallt att man tappar en hel del möjligheter i uppslagningsmekanismen. Det är både en stor nackdel att man inte kan använda link headrar, se UM-8 och UM-9, och att man inte kan livscykelhantera enskilda beständiga identifierare.

Observera också att hela specifikationen är upplagd som rekommendationer, man kan förstås ignorera dem. Det är en öppen fråga om hela specifikationen ska ses som just en rekommendation eller om det ska finnas hårdare krav. Hårdare krav blir naturligtvis svåra att se till att de följs.

Det är också en öppen fråga vilken målgrupp hela specifikationen har. Min tanke, och jag tror också byggblock metadatas position är att man tar fram rekommendationer som är väl genomtänkta och som kan vara en utgångspunkt för offentlig sektor så att man inte behöver tänka igenom saker från början i varje läge.

Jag tror det blir en utmärkt fråga för första mötet att ta upp.

[matthiaspalmer]

@salgo60 Tack för många bra länkar. Dock skulle jag uppskatta lite mer koncis och fokuserad dialog kring de frågor som tas upp. Det blir svårt att följa annars med för många separata frågor som diskuteras i samma ärende.

[matthiaspalmer]

@salgo60 Jag tror jag formulerade mig lite för snällt ovan, I detta projekt håller vi oss till ämnet. Detta ärende handlar om URI:er med fragment. Om du vill prata om något annat får du öppna upp ett nytt ärende.

(Förutsatt förståss att det handlar om förbättringar, förändringar eller korrigeringar kring den terminologi och de tekniska mekanismer som föreslås. Allmänna diskussioner och reflektioner om offentlig sektor och tidigare utredningar får tas någon annanstans.)

Dessutom, kommentar i stil med att ChatGPT kan producera en rekommendation om beständiga identifierare indikerar att du inte läst underlaget.

Härmed kommer jag nu att börja att ta bort / dölja inlägg som inte är tillräckligt "on topic".

[salgo60]

helt ok lycka till...

• chatGPT om vad som saknas
  • chatGPT förslag hur Arkivförordningen 1991:446 påverkas om PID:ar skall hanteras se även min dialog med Lantmäteriet 2020 där deras data är textsträngar

[marma]

Jag tänker att fragment i URI:er för länkad data kan fylla samma funktion som de gör för HTML, dvs att göra det möjligt att länka in i ett dokument / beskrivning utan att behöva skapa URI-routing för all typ av struktur inom dokumentet. Därmed finns det användning som absolut bör undvikas, exempelvis https://example.org/user#12345, men också tillfällen där det kan vara praktiskt, exempelvis https://example.org/item/12345#page-14.

Jag tror också att det beror på vad man exponerar. Affärslogik (användare, organisationer, etc.) har förmodligen mindre behov av fragment än exempelvis ingående metadata för ett objekt. Notera att "typ" ofta inte är en stabil del av en URI när det gäller just annat än enklare affärslogik och att man då får backa till mer generella typer (actor, item, etc.) vilket gör fragment kan behövas när man ska referera strukturen eftersom strukturen skiljer sig åt baserat på typ.

Detta sagt så tycker jag att URI:er utan fragment är en sensible default om man inte är väldigt medveten om vad man håller på med.

[matthiaspalmer]

Det verkar som vi har konsensus här, undvika fragment URI:er är en bra rekommendation, men inte ett hårt krav för de som vet vad de gör.

[matthiaspalmer]

Möte 3 beslöt att BI-5 med BÖR krav är bra med tillhörande förklaring.