Staffan Malmgrens blogg

För ett tag sedan branchade jag svn-repot i en stable-branch, i vilken koden bakom dagens lagen.nu ligger. I trunk finns nu utvecklingsversionen, vilken syns utåt på ferenda.lagen.nu. Den stora grejen med nästa version kommer vara det som jag strävat efter i flera år, men som jag först nu har en stabil plattform för: Lagtextkommentarer som redigeras med wikiteknik.

Ett första exempel fins, i form av en kommenterad personuppgiftslag. Nästa steg är att skriva en kommentar till brottsbalken, eftersom det är den mest lästa lagtexten på lagen.nu. Genom det arbetet hoppas jag få lite insikter i vad som funkar och inte, både tekniskt och textmässigt. Sen börjar jobbet med att ragga skribenter på allvar, men vill du börja redan nu är det bara att börja genom att klicka på första bästa “redigera”-länk på ferenda.lagen.nu.

Och om du är intresserad av utvecklingen, gå med på epostlistan!

Nu har jag switchat över https://lagen.nu/ från den gamla ruttna koden till den glänsande nya versionen. Jag har även dokumenterat på utvecklingswebben så pass att det finns en möjlighet för någon annan att ladda ner och köra koden. Har ni följt den här bloggen vet ni ju redan vad som är nytt, både framför och bakom kulisserna, men erfarenheterna från utvecklingen skulle räcka till en helt ny serie postningar i stil med de jag gjorde vid den första lanseringen. Det kanske blir av, men nästa punkt på dagordningen är att förbereda den UppLYSning jag håller om en dryg vecka - där kommer tyngdpunkten ligga på RDF, men för att hålla nån sorts verklighetsförankring kommer jag prata mycket om hur lagen.nu funkar också, och framförallt på vilka problem som RDF har löst i utvecklingsarbetet.

Som kanske märkts på några av de senaste postningarna har jag så smått börjat jobba med lagen.nu igen. Mitt mål är att så snart som möjligt få till en “1.5″-version som är funktionellt ekvivalent med dagens tjänst, fast byggd på en kodbas jag inte behöver skämmas för och som använder XHTML2/RDF/ESFR i botten. När den finns på plats börjar racet efter nya features (med ett slutmål att nån gång i fjärran få den 2.0-version klar som jag misslyckades med förra sommaren).

Men jag skulle behöva lite hjälp av just dig (om du använder lagen.nu, dvs) — om du fyller i den här enkäten blir det enklare för mig att veta vad jag ska fokusera på. Tack på förhand!

Imorgon börjar höstterminen med C4:an, vilket markerar slutet på de mängder med ledig tid som jag haft under sommaren. Mitt mål var som sagt att göra en 2.0-version av lagen.nu, och jag hann väl inte ända fram. Men nånting som vi kan kalla en första alfaversion finns nu på:

http://ferenda.lagen.nu/

Den stora synliga skillnaden från 1.0-versionen är en någorlunda annan layout, och det faktum att en wiki är integrerad med det hela. Om man skapar ett konto kan man både editera vanliga sidor samt kommentera lagtext.

Bakom kulisserna är det större skillnader. Koden har omorganiserats så att det i grund och botten är ett mer flexibelt, utökbart ramverk för juridiska texter. Kostnaden för att lägga in stöd för exv förarbeten eller EG-rätt i koden bör vara ganska liten.

Ytterligare en stor skillnad är att jag i och med detta öppnar upp källkoden till lagen.nu. Kod finns att hämta via SVN från http://svn.lagen.nu/svnroot/ och en utvecklingswiki/buggdatabas/källkodsbrowser finns på http://trac.lagen.nu/. Eftersom jag spenderat sommaren med programmering, inte juridik, har jag inte tänkt igenom exakt vilken licens som koden är under, men jag kan åtminstone utfästa att den kommer vara OSI-certifierad (notera dock att en del kod i SVN-repositoryt inte är skriven av mig, och har separata licenser).

En annan licensfråga är den för bidrag till wikin/lagkommentarerna; som en utgångspunkt kan vi säga GFDL och by-sa, dvs dubbellicensiering (GFDL för Wikipedia-kompatibilitet, åtminstone åt ena hållet). Om du är licensexpert och/eller har en åsikt om hur du vill att dina bidrag till lagen.nu ska licensieras, hör av dig!

Det är värt att återigen påpeka att det här är en alfarelease. Det är mycket som inte funkar (bland annat kan man inte lista alla lagar, så man måste veta SFS-numret och mata in det i adressraden) och utseendet lämnar mycket att önska. Jag är dock tacksam för buggrapporter och förbättringsförslag, gärna direkt i buggdatabasen.

Det där med teddybjörnsdebuggning funkade ganska bra. Jag fortsätter med nästa designfråga. Eftersom det här i första hand är anteckningar för mig själv är jag inte alltid övertydlig med förklaringar, men fråga gärna om du undrar något!

Frågan att lösa är hanteringen av rättskälledokument som vi inte har tillgång till (placeholders). Ett typiskt exempel är NJA 1977 s. 756 (det s.k. lingonpulpfallet, som utvecklar principer om bevisbördans placering för leveransköp där köparen står risken under transport). Detta finns inte hos domstolsverket, men det vore bra att ha med i databasen, åtminstone ett metadataskelett bestående av titel och NJA-nummer (och kanske referade rättsfall/lagrum etc), så att andra rättsfall, diskussioner, litteraturhänvisningar etc kan länka till det.

För rättsfall (om vi börjar med det) som vi har tillgång till ser arbetsgången ut såhär:

• Rättsfallet laddas ned (Download)
• XML utvinns ur HTML-koden (Parse)
• Rättsfallet indexeras i databasen (Index), detta steg innebär att en rad i LegalDocument-tabellen skapas med URN[1], displayid, xmlpath och htmlpath
• HTML genereras från XML och ett rättskällespecifikt XSLT-stylesheet (Generate)

När allt detta är på plats kan vi visa rättsfallet. All central metadata (målnummer/referatnummer, rubrik, lagrum etc) ligger i XML-filen.

Jag ser två skilda tillvägagångssätt: Antingen låter vi våra placeholders efterlikna de vanliga rättskälledokumenten så mycket som möjligt, med målet att senare delar i kedjan (de som katalogiserar, visar och gör dokument kommenterbara) inte ska behöva veta om det är en placeholder eller inte.

Eller så låter vi placeholders vara väsensskilda from vanliga rättskälledokument, just för att göra det tydligt att det här inte är originalinformation (vad är exempelvis skillnaden mellan inbyggd och tillförd metadata för en placeholder?)

Förslag (som mest går på den första vägen): LegalDocument-tabellen utökas med en isPlaceholder-boolean, eller kanske en source-URL (skulle då vara http://www.rattsinfosok.dom.se/-nånting för originaldokument och http://lagen.nu/nånting för placeholders).

Wikin utökas med en möjlighet att mata in skelettet till ett rättskälledokument (i första steget XML-rakt-upp-och-ned, i andra steget med hjälpsam formulärfrontend). Vi skulle kunna använda Mediawiki-style-namespaces: default namespace för vanliga artiklar, ett annat för kommentarer/annoteringar (”Annotering:1960:729″, ett tredje för placeholders (”Källdokument:NJA_1977_s._756″) osv. För just placeholder-namespacet gör wikins save-funktion motsvarande Index och Generate (se ovan).

Den stora fördelen är att wikiinfrastrukturen för användarhantering och historyhantering kan återanvändas (och jag gillar idén med att wikienabla så mycket som möjligt av det användargenererade innehållet). Även framtida wikiidéer, som att använda trust metrics, skulle då komma placeholderhanteringen till godo.

[1] URN ger ett speciellt problem just för rättsfall. Som jag sade tididgare är det att föredra att använda målnummer framför sidnummer i NJA när URN:en konstrueras, men för gamla rättsfall har vi inte alltid tillgång till denna. Då blir vi så illa tvugna att utgå från (säg) NJA-sidnumret (urn:x-nja:1977#s756). Det kan leda till en situation där vi för ett visst fall har både en placeholder och ett “riktigt” rättskälledokument i databasen, men med olika URNs. Det är inte så mycket att göra åt (men man kan naturligtvis skriva ett script som letar efter och upptäcker sådant)

Jag funderar på hur jag borde strukturera upp datamodellen för lagen.nu med avseende på användargenererat innehåll. Ett bra sätt att lösa programmering är sk teddybjörnsdebuggning, även känt som Rubber Ducking eller att använda en Cardboard Programmer. Idéen är alltså att förklara sitt problem för något föremål som representerar en åhörare; genom att man tvingar sig att formulera problemet på ett sådant sätt att det blir begripligt för denna tänkta åhörare reder man ofta ut det och hittar lösningen av sig själv. Genom att använda en teddybjörn, anka eller liknande slipper man störa någon annan. Och eftersom ingen ändå läser den här bloggen får den agera teddybjörn idag.

Det jag vill uppnå är att man ska kunna koppla metadata till godtyckliga rättskällor, på ett sådant sätt att det blir lätt att sammankoppla liknande källor. För teknikerna i publiken kanske det är värt att beskriva vad en rättskälla är; det är något som innehåller rättsregler och alltså kan användas som bas för ett juridiskt resonemang. Den typiska rättskällan är lagtext, men även förarbeten, domslut, juridisk litteratur och oskrivna rättsgrundsatser kan räknas som rättskällor. Avgränsning mellan rättskällor är inte alltid helt knivskarp; exempelvis kan man fråga sig om lagar (bestäms av riksdagen), förordningar (bestäms av regeringen enligt delegeringsregler från av riksdagen) och föreskrifter (bestäms av myndigheter enligt delegeringsregler från regeringen) är en och samma rättskälla eller tre olika.

Det är heller inte helt klart vad den minsta odelbara enheten i en rättskälla är; är det enskilda lagar som sådana, enskilda paragrafer, stycken, meningar, punkter eller ord?

Med detta sagt, vad vill jag uppnå med att “koppla metadata till godtyckliga rättskällor”? Jag vill förbättra sök- och sammankopplingsmöjligheterna. Ett exempel: NJA 1994 s 74 kallas allmänt “smultronfallet” bland jurister. Det behandlar frågor om verkshöjd för brukskonst, det s.k. dubbelskapandekriteriet och utvecklar en bevisbörderegel för att avgöra om intrång i upphovsrätt enligt 2 § URL har skett, som sedermera blivit känt som hoppande bevisbörda. Det ingår i kursfordran i C3:an på Stockholms universitet, kommenteras av Karnell i i NIR 1994 s 85 och omnämns av Olsson i Copyright, sjunde upplagan, s 72 Vi har här åtminstone åtta olika metadata (metadatum?). Några av dem hör till rättsfallet, några kopplar ihop rättsfallet med andra rättskällor. Några av dem är uttryckta direkt i rättsfallet såsom det är publicerat hos domstolsverket (explicit metadata), några kan deduceras från andra rättskällor (implicit metadata) och en del känner jag bara till efter att ha gått C3an (extern metadata) (sade jag föressten att jag fick Ab även där? Fyra kurser i rad, yay me!). Det finns ytterligare metadata som en erfaren immaterialrättsjurist skulle kunna plocka fram.

Vad ska man kunna uppnå med all denna metadata? Några exempel: Jag vill att man ska kunna, på google suggest-maner, mata in “smultr” och få upp “smultronfallet (NJA 1994 s 74)” i förslagslistan. På wikisidan för Dubbelskapandekriteriet ska det finnas en automatisk länk till rättsfallet, och även under eller bredvid texten i 2 § URL. När man tittar på NJA 2002 s 178 (”melodimålet”, som använder sig samma intrångsbedömning) ska det finnas en länk till rättsfallet, med “(hoppande bevisbörda)” som kommentar. Och naturligtvis ska det finnas ett omnämnande av Karnell och Levins artiklar på sidan som beskriver rättsfallet.

Hur ska det här representeras? Och hur ska vi dra skillnaden mellan explicit, implicit och extern metadata?

Det hjälper att kunna adressera saker; kanske i en URN-baserad syntax. Något i stil med följande:

• urn:x-dv:hd:T1138-92 motsvarar NJA 1994 s 74 (varför inte något i stil med urn:x-nja:1994#74? jo, även om alla jurister refererar till fallet genom dess sidnummer i det årets NJA-utgåva så är den bästa identifieraren för fallet faktiskt målnumret — dels för att den är officiell på ett sätt som den privat utgivna NJA inte är, dels för att den finns tillgänglig direkt — vilket sidnummer en dom hamnar på i NJA vet man inte förrän det årets utgåva är tryckt och klar)
• urn:x-dv:hd:T828-01 motsvarar NJA 2002 s 178 på samma sätt.
• urn:x-sfs:1960:729#P2 motsvarar 2 § upphovsrättslagen
• urn:x-su:jur:c3#kursfordran motsvarar kursfordran på c3:an
• urn:issn:0027-6723:1994#s85 motsvarar Karnells artikel i NIR
• urn:isbn:91-39-01172-0#s72 motsvarar Olssons omnämnande i Copyright.

Man kan observera att alla ovanstående uppgifter kan uttryckas på formen objekt - relation - subjekt — dvs den modell som används i RDF/semantic web. Vi kan uttrycka ovanstående metadata i N3-syntax. Några relationer tar vi från Dublin Core, andra hittar vi på själva.

@prefix dct:  <http ://purl.org/dc/terms/1.1/>
urn:x-dv:hd:T1138-92 "behandlar" "verkshöjd"
urn:x-dv:hd:T1138-92 dct:references urn:x-sfs:1960:729#P2

urn:x-dv:hd:T828-01 dct:references urn:x-dv:hd:T1138-92

urn:x-dv:hd:T1138-92 dct:alternative "Smultronfallet"
urn:x-dv:hd:T1138-92 "behandlar" "dubbelskapandekriteriet"
urn:x-dv:hd:T1138-92 "utvecklar" "hoppande bevisbörda"
urn:x-dv:hd:T828-01 "behandlar" "hoppande bevisbörda"
urn:x-su:jur:c3#kursfordran dct:requires  urn:x-dv:hd:T1138-92
urn:issn:0027-6723:1994#s85 "kommenterar" urn:x-dv:hd:T1138-92
urn:isbn:91-39-01172-0#s72  "kommenterar" urn:x-dv:hd:T1138-92

Listan över möjliga relationstyper måste förstås fastställas på något lämpligt sätt, ovanstående är bara ett snabbt utkast.

I ovanstående är de två första relationerna explicita; när man tittar på rättsfallsreferatet står det klart och tydligt “Lagrum: 2 § Upphovsrättslagen” och “Sökord: Verkshöjd”. Den tredje relationen är implicit — den framgår inte direkt av smultronfallet, men däremot från melodimålet (det är dock explicit metadata sett från melodimålets perspektiv). De avslutande relationerna är explicita — vi känner bara till dem om nån har manuellt matat in dem i systemet. Notera dock att om jag på något sätt skulle komma över en digitaliserad komplett lista över vilka rättsfall som behandlats i juridisk litteratur, och lagt in den som en (del av en) rättskälla, skulle de sista två (Karnells och Olssons kommentarer) övergå från extern till implicit metadata.

Egentligen kan man se det som en 2×2 matris, där ett metadatum sorteras in olika beroende på dels om det är automatiskt utvunnet (”inbyggt metadata”) eller manuellt inmatat (”tillfört metadata”), dels om det har den aktuella rättskällan som objekt eller subjekt. Om man ser det på det här viset blir termerna explicit och implicit metadata lite meningslösa.

Det här skulle vara ganska enkelt att överföra till en datamodell. Men för att skilja på inbyggt och tillfört metadata gör vi detta till två separata modeller (djangosyntax):

class IntrinsicRelation(models.Model):
    object = Models.charFields(maxlength=100)
    relation = Models.charFields(maxlength=100)
    subject = Models.charFields(maxlength=100)

class AddedRelation(models.Model):
    object = Models.charFields(maxlength=100)
    relation = Models.charFields(maxlength=100)
    subject = Models.charFields(maxlength=100)

IntrisicRelation-tabellen byggs om vid varje uppdatering, medans AddedRelation-tabellen editeras wiki-style. Den senare borde därför ha nån sorts history-funktionalitet. Jag tänker något i stil med bugzillas history, där man kan se vilka egenskaper (motsvarande våra relationer) som ändrats av vem och när. Kanske att det räcker med en loggtabell eller -fil?

Tja, ungefär så. Ett närliggande problem som jag inte har löst än är hur vi ska hantera rättsfall för vilka domstolsverket (där jag hämtat data ifrån) inte har någon information — det gäller exv alla rättsfall innan 1980. Många av dessa är intressanta, och man kan tänka sig att personer för hand matar in åtminstone några centrala metadata som enligt ovanstående modell är inbyggt (referat-id, rubrik, lagrum) så att man sedan har något att hänga upp tillfört metadata på (nyckelord). Men det blir en fråga för nästa teddybjörnsdebuggningssession.

Det här ämnar jag göra med lagen.nu 2.0:

• Rättskällor: Flera rättskällor (förutom SFS även förarbeten, rättsfall, vissa nämnd/myndighetsbeslut (ARN, JO), EG-direktiv, EG-domstolsdomar)
• Annotering: Göra rättskällorna kommenterbara och även bygga en generell jurist-wiki
• Koppling: Koppla ihop rättskällor och wikiartiklar med varandra semi-automatiskt (en generaliserad version av dagens länkar till rättsfall och lagändringar under kommentarerna)

Det här skulle vara nice-to-haves:

• Inkorporering av doktrin
• Rättsfall i litteraturen

Det finns också några saker jag inte kommer göra:

• Allt som kräver manuell interaktion med myndigheter eller andra — lagen.nu måste kunna köra och uppdateras i princip obevakat, som det gjort det senaste året.

Använder du lagen.nu? Vad skulle du vilja ha ut av en rättsinformationstjänst?

För att bygga lagen.nu 2.0 kommer det krävas ett rätt stort lass med teknologier. Jag har väl ungefär samlat ihop alla pusselbitar och känner mig ungefär som när man storhandlat inför en riktigt ambitiös middagsbjudning — alla råvaror och alla verktyg finns på plats, nu gäller det bara att hantera dem. Lite om vad som ingår:

XML: Lagen.nu 1.0 använde XML en hel del bakom kulisserna, men XML-formaten var odokumenterade, ad-hoc’iga och i största allmänhet inte så väldigt XMLiga (inga namespaces, data som borde varit i noder lagrades i attribut och vice versa, inget utnyttjande av befintliga standarder som RDF och XLink). Det här ska på något sätt bli bättre i 2.0 — det finns en hel del internationella projekt kring hur juridisk information ska representeras i XML, men de flesta känns som kommittéprodukter med mycket snack och lite spec — det känns som XML inbjuder till sånt, i högre grad än andra komponenter i stacken nedan. Metalex verkar dock lovande.

XSLT: För att få ut de semantiskt korrekta XML-dokumenten på webben måste de transformeras till nån sorts HTML. För 1.0 gjorde jag en del riktigt knepiga transformationer då mantrat där var “vem behöver databaser när vi kan slänga in allt i ett gigantiskt XML-dokument och XPath()a oss fram” — för 2.0 kommer en vanlig old-school relationsdatabas att användas, så förhoppningsvis blir det bara en fråga om att ta befintliga stylesheets och trimma lite.

SOAP: Det här är väl mera på nice-to-have-listan snarare än release-blocker-listan, men det vore kul att åtminstone doppa tårna i hela webservicesträsket. Två problem är dock att jag aldrig har jobbat mot någon skarp web service från klientsidan, så jag vet inte riktigt hur ett WS-API ska kännas för att vara bra, samt att jag egentligen inte har en bra känsla för vilka rättskälleinformationsfunktioner som skulle vara vettiga att göra åtkomliga som webservices.

HTML: Allt ska ju bli HTML till slut, så viss koll på läget måste jag ju ha även här. Det blir förmodligen XHTML 1.0 Strict, en viss grad av divitis (den lösning jag skissade på här visade sig vara ohållbar när man kör den på exempelvis inkomstskattelagen och många kommentarer), och förmodligen tyvärr sämre semantisk meningsfullhet än i 1.0 (det största problemet är numrerade listor — för att sätta en kommentar bredvid en punkt i en punktlista kan jag inte representera själva punkten som en LI-tag — det går inte att placera en P-tag med kommentaren vid sidan av när man är i ett UL-kontext). Dock så ska ett flertal tabeller bort och ersättas med DL-listor, efter tipsen här.

CSS: Ärligt talat är inte 1.0 särskilt visuellt upphetsande. Det kanske inte kommer bli pastellfärger och rundade hörn, men en något mer genomtänkt visuell känsla hoppas jag kunna åstadkomma. Jag har med min nya op-center-setup möjlighet att testa på Firefox, IE, Konqueror, Opera och Safari, och ser med skräckblandad förtjusning fram emot utmaningen att få det hela att se bra ut utan att degenerera till tabellsoppa.

DHTML/AJAX: Inte bara för att det är en nödvändig beståndsdel om man vill vara web 2.0, mycket av wikifunktionaliten skulle vinna på att med lite AJAX göra det möjligt att redigera kommentarer rakt på sidan, a la flickr’s fotobeskrivningsmagi. Och vore det inte coolt om sökrutan föreslog lagtexter a la google suggest? Jag har kollat runt på vad för hjälpramverk som finns på javascriptutvecklingsscenen (jag har läst DHTML Utopia och såg inte alls fram enmot att göra all crossbrowserkompatibilitetssörja för hand) och fastnade tillslut för MochiKit (efter att ha kollat på Dojo, Prototype/script.aculo.us, YUI och den här artikeln) — att det beskrevs som kraftigt pythoninfluerat var ett tungt vägande skäl.

EBNF: En av de bästa sakerna med lagen.nu 1.0 var den EBNF-baserade tolkningen av lagtextreferenser i löpande text. Den är, i ärlighetens namn, mest ihophackad utan någon djupare förståelse för textparsning i den högre skolan, och det känns som att jag borde ägna lite tid åt SimpleParse-dokumentationen för att hantera andra typer av referenser, nu när jag ska hantera flera typer av rättskällor.

Python: Jag hamnar ofta i fällan att när jag, när jag lärt mig ett verktyg tillräckligt bra för att få riktigt jobb gjort med det, slutar lära mig mera. Under våren har jag dock gått tillbaks till grunderna för python och försökt utnyttja mer än de få procent av språket som 1.0 använder. Det blir vettig objektorientering, bättre utnyttjande av standardbiblioteket och kanske lite riktigt funktionell programmerings-tänk (första kapitlet i TPiP är en riktig ögonöppnare här). De tre viktigaste bitarna kommer nog bli Django för allt dynamiskt, BeautifulSoup för allt HTML-tröskande (tillsammans med SimpleParse enligt ovan), och ElementTree för allt XML-byggande.

MySQL: Och så ska ju saker lagras i en databas också. Jag är som tidigare nämnts skeptisk mot RDBMS-användande, men med tanke på hur fint django abstraherar bort det hela känns det motiverat att faktiskt plocka in en databasserver i mixen. Det blir förmodligen MySQL även om alla de coola kidsen använder Postgresql, men då jag redan har en MySQL-server körandes för Wordpress, MediaWiki och lite annat, har jag än så länge inte sett nån verklig anledning att byta.

Ungefär så — det blir en ganska diger lista när man kollar på den. Vilket anknyter till den här bloggpostningens titel, det kan inte bli några djupa kunskaper inom varje enskild del (särskilt som en stor komponent inte är med här, nämligen domänkunskapen om just rättsinformation) men förhoppningsvis tillräckligt för att ro det hela i land.

Idag blev jag uppringd av en person från domstolsverket, som hade sett lagen.nu. Personen i fråga var dock kritisk till att jag länkar direkt till rättsfallen på deras site; genom mina länkar hade nämligen Google hittat till rättsfallen och indexerat dessa. Det ansåg man var dåligt, då vissa referat kan innhålla personuppgifter, och om dessa indexeras kan dessas personliga integritet kränkas. Detta är grundproblemet, vilket jag har viss förståelse för.

Domstolsverket hade ursprungligen tänkt att Google och andra sökmotorer inte skulle kunna indexera rättsfallen genom att man valt en relativt komplicerad weblösning för att göra dessa tillgängliga, men då jag lade in direktlänkar på lagen.nu brast den förutsättningen.

Fråga uppstod om huruvida jag inte borde ha kontaktat domstolsverket innan, och även om min hantering kunde tänkas bryta mot personuppgiftslagen. Vad gäller att be om tillstånd innan man länkar har jag alltid tyckt att det är fullständigt fel. Välkommen till webben, det är så här den funkar, liksom. Vad gäller PUL så är jag relativt säker på att min behandling, som enbart befattar sig med den data som finns i varje domsluts detaljvy, inte faller under dess bestämmelser, då personuppgifter enbart kan förekomma i referaten.

Jag har, från tid till annan, funderat på att även behandla/lägga upp referaten, men valt att inte göra det just på grund av hänsyn till personuppgiftslagen. En lösning på problemet skulle vara att skaffa ett utgivningsbevis för lagen.nu så att YGL blir tillämplig; då gäller (enkelt uttryckt) inte PUL. Av flera olika anledningar är dock inte det aktuellt i dagsläget. Men det är ett ämne för ett inlägg någon annan dag.

Sedan i eftermiddag har domstolsverket valt att lösa problemet genom att stoppa in en restriktiv robots.txt på sin tjänst. Detta gör att jag inte, enligt den sedvänja som gäller på internet, får screenscrape:a tjänsten. Vilket jag naturligtvis tycker är dumt, inte minst med avseende på offentlighetsprincipen, och vilket leder till att listorna med rättsfall under paragraferna på lagen.nu gradvis kommer bli mer och mer irrelevanta. Jag har mailat en förfrågan om huruvida domstolsverket kan göra ett undantag i denna policy för mig, men inte fått något slutgiltigt besked.

Trots att slutresultatet, åtminstone som det ser ut nu, går lagen.nu emot, så tycker jag ändå att domstolsverket har handlat ganska rätt. Visst borde de haft en robots.txt uppe sen dag ett, och visst borde de göra undantag för min webrobot, och kanske borde man fråga sig vad personuppgifterna har att göra i domslutsreferat som ska vara anonymiserade, men nu har de iaf löst ett tekniskt problem med en teknisk, snarare än en juridisk, åtgärd. Alla tjänar på att sådana här riktlinjer uttrycks med kod, inte författningar.

Taggningsmöjligheterna på lagen.nu är första steget i en process genom vilken det ska bli möjligt att koppla information (som etiketter, kommentarer eller bara understrykningar) till lagtext. Ett problem har varit hur man ska fixa det rent layoutmässigt.

Det övergripande resultatet jag är ute efter är följande:

De turkosa områdena är alltså lagtext, medans de gula är redaktionella kommentarer.

Det klassiska sättet att göra detta hade varit med en enkel tabellayout.De röda linjerna är tabellceller:

Men sånt är ju fel och fult. Det är inte semantiskt meningfullt, utan ett missbruk av dokumentstruktur för att åstadkomma en layouteffekt. Det är inte table-free design.

Det nya sättet att göra det med är CSS. För att få ett block att ligga bredvid ett annat block använder man float="left|right" och märker upp blocken med div-taggar. För att inte kommentarerna till stycke 1 ska flyta ihop med kommentarerna till stycke 2, utan ligga i linje med det stycke de kommenterar, måste varje lagtext-kommentarspar kapslas in i ytterligare en div (de röda linjerna är yttre div:ar, de gröna inre):

… och exakt hur skulle detta vara bättre, egentligen?

Vad vi har gjort är att återuppfinna tables för layout, fast med ett annat ord. Det semantiskt rätta vore att en stycke lagtext följs, på samma nivå i dokumentträdet, av kommentaren till denna text. Men det ska alltså presenteras sida-vid-sida. Hur göra detta?

Såhär!

Här är HTML-koden enkel, utan nästlade div:ar. Magin består i att kommentarsboxarna till en början är dolda (display=none i CSS-instruktionerna). När sidan är laddad och vi vet vilken position som varje lagtextbox har hamnat på, så kan vi använda absolute positioning och flytta kommentarsboxarna till sin rätta plats bredvid lagtexten:

             pe = FindPreviousBox(ps[i].previousSibling)
             ps[i].style.top = pe.offsetTop + "px"
             ps[i].style.display = "block";

(FindPreviousBox är en enkel rekursiv funktion som hittar rätt lagtextelement.) Vi hade inte kunnat göra det här statiskt, eftersom vi inte hade någon aning om var varje lagtextbox skulle komma att hamna på sidan i absoluta termer, eftersom detta beror på ffa läsarens fontstorlek. Men när sidan väl är laddad och layoutad är det en enkel operation att hitta rätt information i DOM:en.

Är det här en perfekt lösning? Nej, jag är inte ens säker på att den är bra. Framförallt funkar den riktigt dåligt om användaren har CSS men inte javascript, eftersom kommentarsboxarna då är gömda. Däremot funkar det bra med google och lynx.

Det kanske finns något semantiskt meningsfullt sätt att organisera informationen som låter mig uttrycka källtext med kommentarer på ett sånt sätt att det dessutom går att layouta fint. Men om inte annat är det kanske ett uppslag till hur man kan augumentera sin layout med lite javascript.

Imorgon ska jag prata om vikten av vettig lagstiftningsteknik ur ett demokratiskt perspektiv. Det blir mindre högtravande än det låter.