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.

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!

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.

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.

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.

UnicodeDecodeError: ‘ascii’ codec can’t decode byte 0×84 in position 1: ordinal not in range(128)

Om du programmerat python känner du säkert igen ovanstående felmeddelande. Roten av problemet är att python har två strängtyper; den ursprungliga str som innehåller en singlebytesträng utan någon vidare information om vilken teckenkodning som använts, och unicode, som är en fullständig unicodesträngtyp.

Det faktum att båda dessa typer finns, fungerar och ser nästan likadana ut gör att en pythonprogrammerare måste vara på tårna hela tiden för att vara säker på vad för sorts data han bollar med — något som tar bort mycket av fördelarna med dynamismen i språket. Annars blir det lätt så att kod som verkar fungerande helt plötsligt krashar om någon stoppar in ett åttabitarstecken nånstans där ingen hade tänkt på att kunde göra det. Och om man inte är disciplinerad är det lätt att man snärjer in sig i en röra av unicode(…) och foo.encode(’iso-8859-1′). [1]

För lagen.nu 2.0-koden försöker jag använda unicode rakt igenom, så mycket som möjligt, och behandla str som om det vore en bytearray. Det går …sådär. ElementTree ger alltid ifrån sig unicode och man mår bäst om man bara stoppar in unicode i den (även om det går att stoppa in str, men det är inte att rekommendera att använda något med höga bitten satt). BeautifulSoup är unicode-only från och med version 3, vilket är ett stort steg framåt.

Django är dock ett sorgebarn i sammanhanget. Gränssnitten både utåt, mot webbläsaren och innåt, mot databasen, är str, dessutom utf-8-kodat (om man inte ändrat DEFAULT_CHARSET, vilket dock inte är en egentlig lösning), något som är det sämsta av bägge världar. Jag menar, len av en sträng som innehåller ‘räksmörgås’ ska vara 10, aldrig 13, men kolla vad len(u’räksmörgås’.encode(’utf-8′)) är.

Vad värre är, det går inte att stoppa in unicode överallt heller. De modeller man skapar behöver få sina strängvärden som utf-8-kodade str, annars får man ‘Warning: Data truncated for column ’subject’ at row 1′ och frågetecken i databasen. Åtminstone mot min MySQL-databas, som internt lagrar i utf-8 (tror jag). Är det likadant vad gäller Postgres och SQLite? Vem vet?

Det går väl att lära sig leva med. Sätt upp en barriär mellan django-land och min egen kod, och se till att all str-data kodas om till unicode, och vice versa. Det kanske ordnas innan 1.0, men det är mycket att göra.

Django är dessvärre inte ensam i detta — igår tillbringade jag alldeles för lång tid på att försöka använda email-modulen med unicodesträngar, men den modulen är inte unicodesäker. Simpleparse klarar inte heller unicodeindata. Det finns säkert fler exempel.

Just unicodehantering[2] är ett av de få områdena där jag saknar COM/CLR/Java-världen. Jag menar, multibytetecken funkade smärtfritt i VB6 för typ en miljon år sedan.

På temat unicode saknade jag igår några bra teststrängar för att testa unicodedata med lite exotiskare tecken (allt över U+0255, typ) — utländska motsvarigheter till Räksmörgås, typ. Jag hittade inget direkt, men klistrade ihop något baserat på wikipedias förstasida:

Unicode/UTF-8-test

Som en added bonus innehåller den en hel del BiDi-tester med vad jag tror är korrekt rendering. Jag hade ingen aning om att det var ett så komplicerat ämne, men nu har jag lärt mig en ny HTML-tag. Det är inte varje dag!

[1] Så ser lagen.nu 1.0-koden ut. Ibland blir jag påmind om en kompis som förklarade hur han programmerar C: “klagar kompilatorn så sätter jag dit en ‘*’, om inte det hjälper byter jag ut den mot ett ‘&’”

[2] Och till en mindre del debugging, även om det har ändrats sedan jag upptäckte Wing IDE

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?