Staffan Malmgrens blogg

Håkan tipsar om ett par fantastiskt söta triathlonanpassade löparskor. Det känns som det är dags för ett par nya, då mina nuvarande par alla har gått över 100 mil och två år. Även om jag vanligen springer i Saucony kan blommönstret vara det som får mig att byta märke. Om de nu passar mitt supinerande. Eller om det var pronerande. Innan jag kan hålla reda på vilket som är vilket är det definitivt inte läge att börja internethandla skor.

Fast det är mycket prylar som finns på önskelistan just nu. Mårten tipsade om en Ultegrautrustad fullcarbonracer för bara 1200 €, vilket känns fantastiskt prisvärt. Och nödvändigt, om jag ska kunna kapa nån tid att tala om på Kalmar i sommar. Att internethandla cyklar utan att få dem utprovade av någon expert är också förknippat med en viss risk, men med tanke på vad kolfibercyklar kostar över disk i Sverige är det kanske värt att chansa.

I övriga triathlonnyheter provtränade jag med SCT i förrförra veckan, vilket var riktigt kul, och jag är riktigt sugen på att gå med - medlemsavgiften är ungefär jämförbar med kostnaden för det årssimkort som gick ut förra veckan, men ger vansinnigt mycket mer.

Det kostar att hålla sig i form. Så det har blivit en hel del jobb på sistone, och även en hel del studier. Förvaltningsrätten tentades i lördags, vilket markerar inledningen på den så kallade teoretiska terminen, då vi lyfter blicken lite från alla de materiella rättsområden vi pluggat de senaste åren och ställer oss frågan vad det egentligen är vi gör, och hur. Än så länge har vi bara kommit till Herakleitos och Platon (veckans informationstekniska upptäckt: Stefanuspaginering — inte lika universal som URI:er, men å andra sidan över 400 år tidigare), och allt känns väldigt ovant. Och väldigt kul.

Kul är också lagen.nu-arbetet. Jag jobbar så smått med en ny roadmap och kodar på de enstaka stunder jag får över. Arbetet ger också inspiration till ett framtida specialarbete som avslutning på juristutbildningen. Det lutar åt ett tvärvetenskapligt studium av nya metoder för att relevansranka rättsfall med utgångspunkt från andra informationskällor — ett PageRank för juridiska dokument, typ.

Den enkät jag lade ut för några veckor sedan har blivit ifylld av 44 personer i skrivande stund. Tack alla! Jag har lärt mig att ca 40% av er håller på med juridik på fulltid i någon form, att 15% använder lagen.nu dagligen (det är oftare än vad jag gör), att hela 2/3 använder tjänsten helt eller delvis för jobbets räkning och att referat i fulltext är en hett eftertraktad funktion (önskat av 73 % - det är på gång). Ni ställer er relativt positiva till finansiering genom sponsring, bannerannonsering eller donationer, och hälften kan t.o.m. tänka er att slanta upp pengar själva, vilket är jättekul. Men ännu roligare att 25% sagt sig vara villiga att hjälpa till med tekniskt, och 30% med juridiskt kunnande. Och det är sådant, snarare än pengar, jag främst behöver för att gå i land med att utveckla tjänsten åt det håll jag vill (men om nån sitter på ett par hundratusen och vill se hur mycket rättsinformationstjänst man kan få för det, ring mig - telefonnumret finns på bloggen).

Så för att sammanfatta: Jag behöver mer prylar, mer pengar och och mer tid. För några veckor sedan bytte jag (hutlöst mycket) pengar mot en pryl i förhoppningen att den skulle ge mer tid. Då jag har otroligt svårt att komma upp om mornarna och har slösat flera år av mitt liv på snoozemissbruk är jag såhär långt rätt nöjd min Axbo. Grejen är alltså att den ska väcka en när man sover som lättast genom att man sover med en rörelsesensor kring handleden, och det funkar faktiskt ganska bra (även om jag misstänker att en del av effekten kommer av att den saknar snoozeknapp). Som en added bonus blir jag oftast väckt under drömfasen i sömnen , och kommer därför ihåg drömmarna bättre, vilket ger en …intressant inblick i mitt undermedvetna.

Tidigare frågade jag runt vilket som var det bästa sättet att skapa PDF från nån typ av strukturerad XML-data. De svar jag fick från olika håll pekade på att köra det gen om en CSS3-kapabel layoutmotor vore lämpligt. Så jag har ägnat lite tid åt att trimma in ett stylesheet anpassat för lagtext uttryckt XHTML2 tillsammans med metadata från ESFR-vokabulären.

Som testobjekt använde jag den lagtext som utgör kursfordran för förvaltningsrätt, dvs den kurs jag läser för närvarande. Tidigare har ett förlag tryckt upp en särskild författningssamling för detta ämne, men på introduktionsföreläsningen nämndes att detta inte skulle göras i år, då kostnaden för att ta fram uppdaterade tryckorginal för varje kursstart var för stor (kursen går två gånger om året).

Nu har jag ett automatiserat publiceringsflöde, som utgående från en huvudfil, uttryckt i XHTML2, och en samling lagtexter, också uttryckt i XHTML2, genererar en sammmanslagen fil. Denna innehåller alla författningar (eller delar därav) som huvudfilen hänvisar till genom XInclude/XPointer. Från den sammanslagna filen och ett CSS3-stylesheet skapas sen en PDF. Första steget görs med xmllint –xinclude, andra med Prince. Kostnad för att ta fram uppdaterade tryckoriginal: i princip noll.

Resultat: enkelspaltig (css), dubbelspaltig (css).

Några saker att lägga märke till:

• Innehållsförteckningen har korrekta sidnummerhänvisningar
• Sidhuvudet visar var och i vilken lag man befinner sig på (och växlar utseende beroende på om det är en kapitelindelad lag eller inte)
• Huvudfilen anger vilka förkortningar som ska användas för aktuell lag i sidhuvudet
• Höger- och vänstersidor ser olika ut (precis som i riktiga böcker!)
• Avstavning sker automatiskt efter svenska regler
• PDF-bokmärkena ger en hierarkisk översikt över hela filen
• Det går att inkludera bara enstaka kapitel (eller andra avsnitt) från en lag

Det finns förstås mycket kvar att fixa (kolla exv SekrL 16 kap - inte många rätt i formatteringen där), och även mer att skriva om hur man kan använda CSS3 och Prince XML, men det får bli efter julen.

Det borde inte vara så svårt att modellera lagtext efter ett etablerat schema för textinformation, kan man tycka. Låt gå att HTML4 inte är världens mest sofistikerade modell, men den har rubriker, stycken och listor - det har ju lagtext också. På den nivån borde semantiken stämma överrens, eller?

Nej, naturligtvis inte, för då skulle jag ju inte sitta och skriva det här. Ett exempel är att HTML4 (och därmed XHTML1) inte har någon strukturmekanism som matchar de olika nivåerna som finns i lagtext (avdelningar, kapitel, paragrafer) — det enda som finns är stycken samt och den ganska intetsägande grupperingskonstruktionen <div>.

Ett annat är att i HTML-modellen är en lista (numrerad eller onumrerad) något som befinner sig utanför ett stycke. Det är helt enkelt inte tillåtet att ha en lista i ett stycke. Men enligt modellen/kutymen som används i svensk lagtext så hör en lista till närmast föregående stycke — ska man exempelvis hänvisa till den text i upphovsrättslagen som lyder “skönlitterär eller beskrivande framställning i skrift eller tal” säger man “1 § 1 st 1 p” (observera att man inte säger “1 kap. 1 § 1 st 1 p.” — kapitelhänvisningen utelämnas när paragrafnumreringen räcker för att unikt identifiera en given paragraf, vilket det gör i upphovsrättslagen)

XHTML2 löser de här problemen. Man kan ange att delar av texten logiskt sett är delar av ett större sammanhang genom <section>-taggen (som dessutom ger effekt på rubriker, så att man kan använda <h>-taggen genomgående utan att behöva fippla med h1, h2, h3 osv.

Den tillåter även att en lista (numrerad eller onumrerad) är en del av ett stycke.

Men det finns fortfarande ytterligare minst ett förekommande mönster i svensk lagtext som XHTML2 inte kan efterlikna, nämligen ovanan att stoppa in nya element i en numrerad lista. Ta exempelvis Mervärdesskattelagen, 5 kap. 9 § och den lista som finns där - nånstans under lagens levnad bestämde lagstiftaren att stoppa något nytt mellan punkt 4 och 5 – resultatet blev punkt 4 a. Visst känns det lite som att lagstiftaren programmerat BASIC på 1980-talets hemdatorer? Man får vara glad att det inte finns någon juridisk RENUM.

Det här kan XHTML2 inte efterlikna, eftersom dess modell kräver att alla element i en numrerad lista ska ha ett nummer som faktiskt är ett nummer och inte en friformsetikett.

För att överkomma den här modellimpedansmismatchen får jag helt enkelt modellera numrerade listor i lagtexter som onumrerade listor, och låta numreringen utgöra en del av varje punkts PCDATA-text (samt uttrycka samma information som del av ett xml:id-attribut).

Samma mönster att stoppa in nya element förekommer för övrigt på andra ställen i lagstiftningen, såsom paragraf- och kapitelnivå — se exv 11 a § och 2 a kap. i upphovsrättslagen. Det här är dock inget egentligt problem för XHTML2-modellering, eftersom det här inte finns något alternativ till att låta dessa elements numrering uttryckas på annat sätt än som en del av dess PCDATA. Det är bara det att just för listor så finns potentialen att göra Rätt, men på grund av en restriktiv XHTML2-modell, alternativt en slarvig lagstiftare, är det ändå inte möjligt.

Värst är det när nya stycken stoppas in — eftersom dessa inte numreras explicit blir en hänvisning till “4 § 3 st” trasig när lagstiftaren bestämmer sig för att stoppa in ett nytt stycke mellan första och andra stycket i den paragrafen.

Sedan någon månad tillbaka använder jag min Tablet PC som studiehjälpmedel i kursen förvaltningsrätt. Mitt huvudsakliga verktyg för antecknande är Evernote, som håller reda på en samling anteckningar i både och maskin- och handskrivet format, och organiserar dem med taggar (tyvärr dock ingen svensk handstilsigenkänning). På föreläsningar där jag är en student bland hundra använder jag datorn som en vanlig laptop och skriver på tangentbordet, men på mindre seminarier och lektioner där interaktivitet och diskussion förekommer använder jag den i tabletläge och skriver på skärmen, för att inte gömma mig bakom en uppfälld skärm.

Istället för en lagbok använder jag en PDF-fil som jag skapat med betalversionen av Adobe Acrobat, som vi har på jobbet. Den antecknar jag sedan i med PDF Annotator, både i tablet- och laptopläge, och har numera en någorlunda genomklottrad fil. Tyvärr får jag inte ta med mig datorn på tentan, så dagarna innan har jag tänkt överföra de understrykningar (men inga anteckningar)

Jag tycker det här sättet att jobba på funkar riktigt bra. Om kurslitteraturen fanns att köpa elektroniskt skulle datorn vara det enda jag behövde släpa på till och från skolan. Men det finns några problem utöver att jag måste övergå till amishteknik inför tentan, varav det största är att lagtext-PDF:en är undermålig. Det vore ju mycket bättre om lagen.nu hade nån sorts “generera författningssamling i PDF-form”-funktion. Jag ser fyra sätt att bygga en sådan, givet källmaterial är i XHTML2 och RDFa och följande krav:

• Automatisk avstavning som följer svenska regler
• Kontroll över sidfötter och huvuden som automatiskt reflekterar vilken lag och vilka paragrafer som finns på varje sida (tänk sidhuvuden i typisk telefonkatalog eller lexikon)
• Automatisk generering av innehållsförteckning och index
• Fungerande interna och externa hyperlänkar i resultatet
• Kontroll över generering av PDF-bookmarks
• Andra saker som blir uppenbara när en lösning som saknar dem står färdig.

Jag kan se fyra sätt:

1. Old school: Transformera XHTML2-koden till (La)TeX och låt pdftex bygga en snygg PDF
   + Snygg typografi, riktigt bra svensk avstavning
   - Jag och (La)TeX har, trots upprepade försök, inte bondat riktigt
2. New school: Transformera XML-koden till XSL-FO och låt fop eller någon annan processor göra PDF av det hela
   + Standardiserat och fint
   - Jag kan inte XSL-FO. Finns det nån gratis XSL-FO -> PDF-processor som är bra?
3. Bleeding edge: Skriv ett superavancerat CSS3-stylesheet, koppla direkt mot XHTML2-datat och koppla in en CSS3-kapabel PDF-genererare
   + Ingen mellantransformering
   - Jag kan inte CSS3 (och är djupt misstänksam mot tidigare CSS-varianter). Prince XML är svindyrt.
4. NIH-syndromet: Använd iText eller annat lib för att generera PDF direkt.
   + Jag slipper bli expert på ett sidbeskrivningsspråk
   - Jag måste bli expert på ett API

Dear lazyweb: vad skulle ni välja (givet att ni inte är experter på LaTeX, XSL-FO eller CSS3)?

I mitt jobb som forskningsamanuens på IRI ingår bland annat att hjälpa till med konferenser, seminarier och andra evenemang. Jag har varit dålig på att tipsa om dem på bloggen, men gör bot och bättring nu genom att uppmärksamma heldagskonferensen “Vad är gällande rätt?” där ett gäng riktigt kunniga jurister och andra rättsinformationsspecialister går igenom frågor om rättsinformation (dvs lagar, rättsfall, förarbeten och liknande) och säkerhet — är informationen fullständig, korrekt, oförändrad och vems är ansvaret?

Obligatorisk närvaro för jurister med informationsintresse eller informationsspecialister med juridikintresse. Sa jag att det var gratis? Mer information och anmälan via IRI:s nyhetssida. Vi ses där!

Det Vervaprojekt jag varit lite inblandad i har nu publicerat en uppdaterad version av sin metadatamodell för rättsinformation. Det handlar alltså om hur man ska representera dokument som lagar, förarbeten, rättsfallsreferat m.m. elektroniskt. Dvs sådana frågor som jag bollat med ända sen jag startade lagen.nu - men med skillnaden att den här specifikationen görs by the book av folk som verkligen kan datamodellering. Tydligast märks det i att all metadata uttrycks i form av RDF, och det som nu publicerats är en vokabulär, dvs en lång lista på egenskaper som dokument (och andra resurser) kan ha.

Arbetet hittills är främst inriktat på att identifiera egenskaper på dokumentnivå, och har mycket gått ut på att diskutera saker som “den här texten här överst i dokumentet, vad är den?” och resonera kring titel vs rubrik vs beskrivning vs … Men det som jag tycker känns bäst är ansatsen att alla resurser (både kompletta dokument och resurser inuti dokument, exv en paragraf i en lag) ska ha permanenta URI:er. Det där med att man både inom och utom systemet ska kunna hänvisa till resurser på ett otvetydigt och maskinläsbart sätt är, hur trivialt det än kan låta, ett stort steg framåt.

Liten uppdatering om vad jag håller på med:

Träning: Har börjat komma igång så smått efter kalmar, målsättningen är fyra lättare pass i veckan (ett simpass, två löppass och ett långpass på cykeln) med mycket fokus på bra teknik.

För löpningen innebär det att öka stegfrekvensen till ca 180 steg i minuten (Jag har några podrunner-mixar med lämplig BPM i lurarna för att hålla takten vilket hjälper mycket - synd bara att musiken är så trist) och se till att landa på fotsulan (inte hälen) med foten under kroppen (inte framför). 180 steg i minuten är vansinnigt mycket fortare än de kanske 150-160 jag brukar springa med, men jag kan redan känna att det här är mindre slitigt för lederna och mer slitigt för flåset.

För simningen innebär det att lära mig växelvis andning, dvs andas var tredje simtag på omväxlande höger och vänster sida. Tidigare har jag andats varannat simtag, alltid på höger sida, och det är lite svårt att få in så mycket luft i lungorna den korta sekund munnen är ovan vattenlinjen att det räcker för tre simtag. Idag skedde dock någon form av litet genombrott och jag kunde köra 400 m oavbrutet i en lugn rytm utan att syret tog slut. Försöken att lära mig voltvändning är dock än så länge fruktlösa.

För cyklingen innebär det att få till ett bra rundtramp, dvs att utnyttja benens alla muskler till att inte bara trycka ner pedalen (mellan klockan 2-5 om man tänker sig vevpartiet som en urtavla) utan även dra den bakåt (5-7), uppåt (7-11) och slutligen trycka framåt (11-2). Det övar jag främst genom att klicka ur ena skon ur pedalen och dra runt cykeln enbart med andra foten under några minuter (det är sjukt tungt!). Det svåra är att få jämnt tryck och hastighet så att inga “döda punkter” finns på hela varvet. Jag försöker även öka kadensen - det rekommenderas att man trampar 90 varv / minut. Jag har ingen kadensmätare så jag har ingen aning om vad jag ligger på, men förmodligen alldeles för lågt.

Jobb: På måndag slutar min semester från min huvudsyssla som amanuens på IRI (vars webbplats för övrigt numera är uppfräshad, XHTML-validerad, allmänt semantisk och mikroformatbeströsslad). Hösten lär bjuda på en hel del löpande administrationsarbete, men också arrangemang av konferenser och liknande evenemang. Boka den 29 november för konferensen “Den rättsliga informationsförsörjningen: Säkerhetskrav?” redan nu!

Men jag har ett gäng sidouppdrag av varierande omfattning. Under sommaren har jag jobbat lite med det offentliga rättsinformationssystemet (som jag även var aktiv inom under förra hösten) med att skriva lite skön pythonkod som genererar RDF och XHTML2-versioner av de (konsoliderade) författningar som ingår i SFS. Lite samma som gamla lagen.nu-koden, men den här gången med en kodkvalité som jag faktiskt inte behöver skämmas över. Bland annat har jag därigenom lärt mig att använda Genshi för XML-generering medelst templates - inte alls dumt. Koden kommer förhoppningsvis snart göras tillgänglig under någon lämpligt öppen licens, tillsammans med resten av rättsinfoprojektets kodbas.

Det finns några ytterligare saker i pipen, bland annat medförfattande av en lite mer akademisk artikel om ett spännande ämne, en permanent post som krönikör i en större branschtidning, och en föreläsning på en av juridiska programmets specialkurser. Mer detaljer kommer när det börjar närma sig slutförandet. I övrigt försöker jag hålla nere på extraknäcken så att jag kan fokusera på…

Studier: Har tyvärr varit lite eftersatta under våren. Nu är det bot och bättring som gäller. Skatterätt (som jag inte direkt sett fram emot, men däremot alla mina kompisar som vill göra smarta avdrag) och förvaltningsrätt (vilket ska bli märkligt kul) är det som gäller under året. Jag ska även tenta av de två kurser jag har släpande (fastighetsrätt och processrätt). Banne mig.

Sen är det bara teoretiska terminen (med ffa rättshistoria och allmän rättslära), specialkursterminen (där jag ska försöka begränsa mig till två kurser från ett betydligt större smörgåsbord) och examensarbetet (där jag kommer på ett nytt ämne i veckan som jag vill skriva om) kvar innan jag blir jur kand. Nu är det bara hemvägen (mindre än hälften) kvar, två år. Det är ju ING-EN-TING!

Jag har funderat på sista tiden om hur den perfekta IT-miljön för en praktiserande jurist borde se ut. Det synes mig som om det mesta arbetet på det här området fokuserar på rättsinformationstjänster – företrädelsevis webbtjänster, med mycket rättsinformation (lagar, rättsfall, förarbeten…) och smarta sätt att hitta i informationsmängden.

Men när man väl hittat information, vad gör man med den? På samma sätt som en programmerares vanligaste deliverable är en kompilerad binär, är en jurists vanligaste deliverable ett dokument av något slag — en rättsutrednings-PM, ett domskäl, en doktorsavhandling… För att kunna skapa dessa dokument konsumerar vi stora mängder rättsinformation. Men kan kopplingen mellan rättsinformationstjänsten och dokumentproduktionen bli bättre än ett ständigt alt-tabbande mellan webläsarfönstret och Word?

Min idé är en ny kategori av program — låt oss kalla dem Integrated Legal Lab Environment for Research (ILLER) som knyter ihop informationssökandet och -producerandet. Min ide om hur en ILLER skulle kunna se ut är grundat i min erfarenhet av olika IDE:er från mina glada programmerardagar, parat med det lilla jag lärt mig om rättsutredningar genom mina studier och jobbet på IRI.

Det finns tre aspekter på en rättsutredning:

• Relevant information ska sökas fram
• De källor man använder sig av ska redovisas
• Själva skrivandet

En ILLER skulle ha “rättsutredning” som grundkoncept. I en rättsutredning finns ett eller flera deliverabledokument (säg, 2 Word-dokument och en powerpoint). Men framförallt finns en lång lista på källor (Upphovsrättslagen, infosoc, sanktionsdirektivet, rättsfall, artiklar, böcker…). En ILLER skulle ha sökfunktionalitet för att hitta sådana källor, antingen i fulltext (lagtext, rättsfall, vissa artiklar) eller åtminstone bibliografiinformation (monografier, andra artiklar). Hur ett sådant gränssnitt ser ut är klassisk rättsinfosökning — men en grundidé är att en ILLER kan konfigureras att söka i olika databaser. På det viset kan man tänka sig att man får tillgång till KarnovPlus kommenterade lagtext, eller NIRs artikelarkiv, om man prenumererar på deras tjänster (och de har ett sökgränssnitt som är kompatibelt med ILLERn). När en relevant källa är hittad lägger man till den till utredningens källförteckning med ett klick.

Självklart ska man kunna lägga upp en ny källa från scratch, och koppla den till en URL eller ett dokument på hårddisken. Det är kanske bäst att tänka på källförteckningen i en ILLER som en bokmärkeslista, fast med all info som behövs för att skapa en bibliografiförteckning.

När man sen skriver själva PM:et eller vad det nu är frågan om embeddas Word eller Powerpoint in i ILLERn. Denna har en massa magi för att känna igen källreferenser (ffa lagtext och liknande) i löpande text. Säg att man skriver “Enligt 54 § URL så gäller […]” — när markören är i närheten av den texten visas texten till 54 § URL i en sidopanel. Genom magisk dokumentrelevansranking presenteras också listor på andra dokument som kanske är relevanta men som inte är med i källförteckningen.

För att hänvisa till en källa är det enkel drag&drop från källförteckningen in i dokumentet. Källförteckningen i slutet av dokumentet genereras naturligtvis automatiskt.

Fler saker kan tänkas. Men det viktiga är att koppla ihop skrivandet med informationssökandet — automatisk referenshantering är en uppenbar feature, men fler dyker upp ju mer jag tänker på det hela. Integration med olika KM-system är en. Juridikanpassad grammatik/språkkontroll är en annan. Autocomplete för referenser är en tredje.

Jag tror det finns en stor marknad för ett sådant här verktyg — men det hela hänger på hur bra rättsinformationstjänst som ligger i botten för sökningarna. Två affärsidéer kan skönjas — antingen bygger man en ILLER och lanserar den under eget namn, och träffar dealar med rättsinformationsförädlningsföretagen (Infotorg, Thomson, WoltersKluwer, Westlaw…) om att de ska erbjuda ett ILLER-kompatibelt gränssnitt — eller så bygger man en anpassningsbar ILLER och säljer den till rättsinfoföretagen, som brandar den och kopplar den tight till sina egna databaser, och säljer den genom existerande kanaler.

Den första varianten är svårast men kan ge bäst utdelning (och även om det bara går halvbra kan man nog bli uppköpt av någon rättsinfoleverantör som vill få en edge för sina tjänster). För att nå marknader utanför Sverige måste naturligtvis kopplingar med nationella rättsinfortjänster göras. Den andra varianten är enklare, inte minst för att man slipper arbetet med att arbeta upp egna kanaler för försäljning och lokalisering.

Men det är inget jag kan göra den närmsta tiden. Ni som jobbar inom rättsinformations/verktygsbranschen - ta idén och spring! Ni får tre års försprång

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.