Staffan Malmgrens blogg

Ikväll klockan 18:15 håller jag en upplysning om informationsmodellering, RDF och annan semantic web-teknologi, mot bakgrund av hur jag använt dem i lagen.nu. Här är de slides jag tänkt använda, återigen i S5-format. Eftersom jag använder object-taggen för att länka in live-webbsidor funkar det kanske inte i alla webbläsare, men det verkar funka i min Firefox iallafall. Är du i Linköping ikväll, kom gärna förbi!

Den här månaden ska jag prata mycket. Vi kickar igång med ett tvåtimmarsseminarium på kursen Experimentell immaterialrätt, där jag förhoppningsvis ska vara begripligare än förra gången jag försökte förklara “Tekniken på Internet”. Min nuvarande idé är att gå igenom upphovsrättslagen, paragraf för paragraf (åtminstone de viktiga), beskriva relevanta företeelser på Internet och ställa frågor om hur man ska tolka ett halvt sekel gammal lagstiftning i detta ljus.

Sen håller jag ett lunchseminarium på Gärde Wesslau Advokatbyrå på temat “Teknik och juridik”, där jag kommer prata om hur den tekniska utvecklingen förändrar det juridiska arbetet. Vilket kan vara att ta sig vatten över huvudet, eftersom min faktiska erfarenhet av juridiskt arbete är begränsad till kurs-PM och juridikundervisning. Men å andra sidan kan jag den tekniska utvecklingen ganska bra, så det kanske jämnar ut sig.

I slutet av månaden ska jag hålla en UppLYSning nere i Linköping. Den är, till skillnad från de andra, öppen för alla, så kom förbi! Där kommer jag prata om “Informationsmodellering, RDF och den semantiska webben” med utgångspunkt i hur jag använt RDF i den nya versionen av lagen.nu. Förhoppningsvis får jag ihop lite interaktiva peka-och-klicka-demos, kanske med OpenLink RDF Browser, Sesame och Gruff.

På tal om lagen.nu har jag nu inte några blocker eller critical-buggar kvar på 1.5, och är grymt sugen på att släppa den nya versionen, men funderar på om inte #20, #21, #23 och #26 ändå borde fixas innan release. De är nog rätt lättfixade, om någon är sugen på att hoppa in i utvecklingen, och vill ha ett “bite-sized task“. Fast det är klart, innan jag fixar #16 är det inte helt enkelt för en utomstående att veta var man ska börja. Det är kanske den som borde uppgraderas till blocker.

Det blir mycket RDF i lagen.nu 1.5. Och det blir mycket användande av RDFLib. Efter att ha hittat finfina instruktioner om hur man får biblioteket - inklusive SPARQL-parser - att snurra under windows har jag gett mig på min pet peeve i n3-serialiseringskoden, nämligen dess ovana att definera egna anonyma namespaceprefix. Normalt serialiserar den nämligen n3-formatet något i stil med såhär:

@prefix _8: http://lagen.nu/.
@prefix _9: http://lagen.nu/1962:700#.
@prefix dct: http://dublincore.org/documents/dcmi-terms/.
@prefix rinfo: http://rinfo.lagrummet.se/taxo/2007/09/rinfo/pub#.

_8:NJA_2005_s_878 dct:identifier "NJA 2005 s. 878 (NJA 2005:95)";
rinfo:lagrum _9:K29P7;
rinfo:rattsfallshanvisning _8:NJA_1996_s_63,
_8:NJA_2000_s_421;

Men nu blir det det oändligt mycket mer läsbara:

@prefix dct: http://dublincore.org/documents/dcmi-terms/.
@prefix rinfo: http://rinfo.lagrummet.se/taxo/2007/09/rinfo/pub#.

 <http://lagen.nu/NJA_2005_s_878> dct:identifier "NJA 2005 s. 878 (NJA 2005:95)";
     rinfo:lagrum <http://lagen.nu/1962:700#K29P7>;
     rinfo:rattsfallshanvisning <http://lagen.nu/NJA_1996_s_63>,
         <http://lagen.nu/NJA_2000_s_421>;

Här är patchen:

C:\Users\staffan\tmp\rdflib-2.4.0\rdflib>diff -u syntax\NamespaceManager.py~ syntax\NamespaceManager.py
--- syntax\NamespaceManager.py~ 2007-04-04 22:05:32.000000000 +0200
+++ syntax\NamespaceManager.py  2008-06-14 21:36:32.606307200 +0200
@@ -59,8 +59,7 @@
namespace = URIRef(namespace)
prefix = self.store.prefix(namespace)
if prefix is None:
-                prefix = "_%s" % len(list(self.store.namespaces()))
-                self.bind(prefix, namespace)
+                raise Exception("Prefix for %s not bound" % namespace)
self.__cache[uri] = (prefix, namespace, name)
return self.__cache[uri]

Den som förstår RDFLib bättre kan säkert få till samma effekt utan att patcha källkoden genom att subklassa NamespaceManager och trycka in den i kedjan någonstans, men mina försök till det misslyckades.

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.

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.