Staffan Malmgrens blogg » metadata

En arkitektur för webutveckling med semantic web-koncept

staffan — Mon, 29 Jun 2009 22:47:46 +0000

Idag checkade jag in en ganska stor ändring i
kodbasen för lagen.nu. Det är lite vanskligt att göra stora ändringar
nu såhär en vecka innan lagkommenteringsprojektet drar igång
på allvar, men just den här ändringen bör kunna göra det enklare att
pussla ihop ny funktionalitet jämfört med hur det ser ut idag.

Vad ändringen handlar om är att använda RDF på en djupare nivå än
vad som gjorts hittils, och med verktyg som är bättre lämpade. Det jag
har nu börjar kännas nära en arkitektur för att bygga
webbtillämpningar på semantic web-koncept istället för den traditionella kombon RDBMS + SQL + dynamiskt språk
(eller den något mindre traditionella dynamiskt språk + MVC-ramverk + O/R-mappning).

För att man ska förstå poängen börjar jag med att beskriva hur det har
sett ut tidigare.

Innehållet på lagen.nu skapas i huvudsak i fyra
steg: Download, Parse, Relate och Generate. De två första stegen handlar
om att hämta innehåll (lagtexter och rättsfall) från andra ställen,
respektive att semantiskt strukturera upp detta (från de text- och
wordfiler som laddats ner). Dessa berörs inte alls av ändringen.

Relate-steget är ganska enkelt: Det går igenom de strukturerade
XHTML2/RDFa-filer som
skapats och plockar ut alla RDF-triples. Dvs från filer som innehåller
både data (lagtext, domslutstext) och metadata (SFS-nummer, titlar,
lagrumshänvisningar…) så plockas metadatat fram. Detta lagras sedan
separat på lämpligt sätt.

Generate-steget tar sedan en strukturerad XHTML2-fil, exempelvis en
lagtext och transformerar den till XHTML 1.0, färdigt att visas i en
webbläsare. Denna transformering lägger till en massa information,
exempelvis sidhuvud och sidfot, innehållsförteckning, och listor av
relevanta rättsfall under varje paragraf.

För att göra det sista måste transformeringssteget på något vis ha
tillgång till en lista över de relevanta rättsfallen. Tidigare har
detta skett genom att Relate-steget konstruerat en (1) gigantisk
RDF/XML-fil med information om samtliga 10 000+ rättsfall som finns i
systemet, och XSLT-transformationen sedan laddat in denna med ett document()-anrop. Det
funkar, men är både långsamt och oflexibelt.

Att skapa kopplingar mellan dokument genom systemets samlade metadata
skulle kunna användas på rätt många olika sätt, men idag görs det bara
på två sätt — dels för listorna på relevanta rättsfall under
lagtextparagraferna, dels för att se till att bara de rättsfall som
faktiskt finns i systemet är länkade i den lista över föregående
rättsfall som finns bredvid varje rättsfall. Det beror dels på att
det är bökigt att implementera nya kopplingar, dels på att det just nu
inte finns så mycket mer information i systemet än just lagtext och
(svenska) rättsfall.

Men med lagkommenteringsprojektet börjar det senare
ändras. Kommentaren för varje enskild paragraf lagras som ett
RDF-påstående, på formen:

 dct:description
"Huvudregeln för känsliga uppgifter är ..."

Och även andra informationskällor ska in. Jag har fyra moduler i
varierande stadier av halvfärdighet (för propositioner och
utredningsbetänkanden, Allmäna
reklamationsnämnens praxis, JO-beslut och EG-domstolens
domslut) och en på planeringensstadiet (EG-lagstiftning).

Med flera informationskällor växer möjligheten för användbara
kopplingar exponentiellt. Under varje paragraf skulle man kunna lista
namnen på den proposition som föranlett lagändringar i denna, eller
namn på EG-direktiv som föranlett propositionerna. För varje sökord
som rättsfall använder kan man skapa en sida som listar andra
rättsfall med samma sökord. Och sen plocka in information från rikstermbanken, svenska Wikipedia och förstås vår egen wiki.

Om man kan skapa en koppling mellan EG-direktiv och svensk lag (på
paragraf/artikelnivå) skulle man tillochmed skapa en koppling mellan
svenska lagparagrafer och förhandsavgöranden från EG-domstolen för
andra länder. Om ni bara kunde se in i huvudet på mig skulle ni
förstå hur vackert allt kommer att bli.

Men systemet med att spara ner allt i gigantiska XML-blobbar och gräva
igenom dessa med XSLT-funktionen document() skalar inte.

Så, vad dagens ändring gör är att byta ut metadatalagringen – från
stora statiska filer till en RDF-databas. Jag vet att det strider
mot mina tidigare principer, men med strax över en miljon poster
(triples) har jag insett
att det faktiskt behövs.

Enligt den nya ordningen så stoppar Relate-steget in all metadata i
Sesame-databasen istället för att stoppa in det i en gigantisk fil. I
Generate-steget körs sedan ett antal SPARQL-frågor mot denna databas,
och sparar ner steget i en temporär XML-fil, som bara innehåller den
information som är relevant för just det dokument som ska skapas. Den
läses sen in med document() precis som tidigare. Skillnaden är att
denna temporärfil är liten och därmed snabbprocessad, samt att
utvecklingen för att stoppa ner nya datamängder i den är liten – dels
en SPARQL-fråga, dels lite klisterkod för att mappa svaret till en
XML-ig trädstruktur. Vad det gäller det senare hoppas jag kunna
använda SPARQLTree
för att kunna generalisera det helt.

Vad det gäller det förra så är det dock inte hel-enkelt att skriva bra
SPARQL-frågor. Den enda hjälpen som är något att ha är själva specen,
och den innehåller liksom inte så mycket tips av ”for
dummies”-karaktär. Det leder till att mina frågor är ganska yxiga än
så länge. Förhoppningsvis inser jag hur de kan förenklas allt eftersom
jag lär mig krypa på det här området.

Som ett exempel på svårigheterna kan nämnas hur man ska formulera en
fråga som hämtar information alla rättsfall som hänvisar till en viss
lag. Informationen om ett visst rättsfall lagras enligt följande mall
(N3-notation):

@prefix dct:  .
@prefix rinfo:  .

 a rinfo:Rattsfallsreferat ;
     dct:creator  ;
     dct:description "En kvinna med en insulinberoende diabetes, åtalad för misshandel[...]"@sv ;
     dct:identifier "RH 2003:65"@sv ;
     dct:relation ""@sv ;
     dct:subject "Uppsåt"@sv ;
     rinfo:avgorandedatum "2003-11-21"@sv ;
     rinfo:lagrum  
     rinfo:malnummer "B24-03"@sv .

Det intressanta här är rinfo:lagrum-triplen (i fetstil). Det är fråga
om ett rättsfall som hänvisar till brottsbalken, närmare bestämt 1
kap. 2 § 2 st. Brottsbalken har i det här systemet URI:n
.

En inititial SPARQL-fråga för att hämta information om alla rättsfall som hänvisar
till brottsbalken kan se ut såhär:

PREFIX dct:
PREFIX rinfo:

SELECT ?uri ?id ?desc
WHERE {
    ?uri rinfo:lagrum  .
    ?uri dct:identifier ?id .
    ?uri dct:description ?desc
}

(Not: om du inte redan kan grundläggande SPARQL rekommenderar jag att
exempelvis läsa wikipediasidans
introduktion).

Problemet är att den frågan enbart kommer att hitta rättsfall som
hänvisar till brottsbalken i sin helhet, inte rättsfall som hänvisar
till någon enskild paragraf. Detta eftersom URI:er i RDF är
ogenomskinliga — det finns inget inherent samband mellan
och
(som
är URI:n för 1 kap. 2 § 2 st. Brottsbalken).

Det vi vill göra är att ställa en fråga som matchar alla rättsfall som
hänvisar till en viss lag eller något som är en del av samma lag
(enskilda kapitel, paragrafer eller stycken). Ett enkelt, fult,
långsamt och fel sätt är att göra det med ett filter:

PREFIX dct:
PREFIX rinfo:

SELECT ?uri ?id ?desc ?lagrum
WHERE {
    ?uri dct:identifier ?id .
    ?uri dct:description ?desc .
    ?uri rinfo:lagrum ?lagrum .
    FILTER regex(str(?lagrum), "http://rinfo.lagrummet.se/publ/sfs/1962:700")
}

Ganska enkelt, men i praktiken väldigt långsamt, gissningsvis för att
SPARQL-motorn är tvungen att konvertera varenda URI (en datatyp) till
en sträng (en helt annan datatyp), för att sen se om den möjligtvis
börjar på ett visst sätt. Det är också fel, eftersom frågan gör ett
antagande om att

är en resurs som är en del av resursen
, utan
någon täckning för det antagandet.

Det korrekta sättet är att modellera just detta
”är-del-av”-förhållande. I RDF-databasen finns en mängd triples av
följande typ:

 a rinfo:Stycke;
     dct:isPartOf .

 a rinfo:Paragraf;
     dct:isPartOf .

 a rinfo:Kapitel;
     dct:isPartOf .

Med det kan vi formulera en fråga som ger oss information om alla
rättsfall för en viss lagtext. Vi vill ha alla rättsfall som antingen
har en rinfo:lagrum-relation med lagtextens URI
eller en rinfo:lagrum-relation med en URI som har
en dct:isPartOf-relation med lagtextens URI eller
en rinfo:lagrum-relation med en URI som har en
dct:isPartOf-relation med en URI som har en
dct:isPartOf-relation med lagtextens URI
eller…

Ok, det blir inte så vackert det här heller, men det blir rätt och
snabbt. Den SPARQL-fråga jag har just nu blir såhär:

PREFIX dct:
PREFIX rinfo:

SELECT ?uri ?id ?desc ?lagrum
WHERE {
   { ?uri rinfo:lagrum  .
     ?uri dct:identifier ?id .
     ?uri dct:description ?desc }
   UNION { ?uri rinfo:lagrum ?lagrum .
           ?lagrum dct:isPartOf  .
           ?uri dct:identifier ?id .
           ?uri dct:description ?desc }
   UNION { ?uri rinfo:lagrum ?lagrum .
           ?lagrum dct:isPartOf ?b .
           ?b dct:isPartOf  .
           ?uri dct:identifier ?id .
           ?uri dct:description ?desc }
   UNION { ?uri rinfo:lagrum ?lagrum .
           ?lagrum dct:isPartOf ?b .
           ?b dct:isPartOf ?c .
           ?c dct:isPartOf  .
           ?uri dct:identifier ?id .
           ?uri dct:description ?desc }
   UNION { ?uri rinfo:lagrum ?lagrum .
           ?lagrum dct:isPartOf ?b .
           ?b dct:isPartOf ?c .
           ?c dct:isPartOf ?d .
           ?d dct:isPartOf  .
           ?uri dct:identifier ?id .
           ?uri dct:description ?desc }
   UNION { ?uri rinfo:lagrum ?lagrum .
           ?lagrum dct:isPartOf ?b .
           ?b dct:isPartOf ?c .
           ?c dct:isPartOf ?d .
           ?d dct:isPartOf ?e .
           ?e dct:isPartOf  .
           ?uri dct:identifier ?id .
           ?uri dct:description ?desc }
}

Förslag på hur man kan förenkla det hela mottages tacksamt…

Det framgår kanske att det här inte är en arkitektur för alla
problem. Men om man har data som kan modelleras med RDF (och när man
jobbat med RDF ett tag så tycker man att i stort sett allt gör det) så
tror jag att åtminstone kombinationen triplestore + SPARQL kan vara
ett intressant alternativ till RDBMS + SQL.

teddybjörnsdebuggning del 2

staffan — Tue, 18 Jul 2006 10:47:24 +0000

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)

Teddybjörnsdebuggning

staffan — Fri, 14 Jul 2006 23:19:57 +0000

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:  
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.

	inbyggt	tillfört
subjekt	smultronfallet stödjer sig på 2 § URL	smultronfallet utvecklar ”hoppande bevisbörda”
objekt	melodimålet refererar smultronfallet	NIR 1994 s 85 kommenterar smultronfallet

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.

Målnummer, personuppgifter och journalistisk verksamhet

staffan — Mon, 24 Oct 2005 21:59:36 +0000

I efterdyningarna från kontakten med domstolsverket började jag forska lite mer i juridiken kring det hela. Det blev frågor som rörde såväl FL som BrB, PUL och YGL. Det mynnade ut i ett PM som kanske dyker upp här snart.

En av sakerna jag lärde mig handlar om personuppgifter: tidigare sa jag tvärsäkert att jag inte behandlade sådana på lagen.nu, eftersom de bara förekom i domslutsreferaten, och jag brydde mig ju bara om data man hittar i detaljvyn, som titel, lagrum, domstol, målnummer… målnummer? Låt oss se hur definitionen på personuppgift lyder:

Personuppgifter: All slags information som direkt eller indirekt kan hänföras till en fysisk person som är i livet.

Jepp. Ett målnummer passar jättebra in på den här definitionen, då den indirekt kan hänföras till parterna i ett civilmål, eller den tilltalade i ett brottmål. Jag kände mig hyfsat dum när det här påpekades för mig. Och på tal om brottmål blir det ännu bättre om vi kollar 21 §:

Det är förbjudet för andra än myndigheter att behandla personuppgifter om lagöverträdelser som innefattar brott, domar i brottmål, straffprocessuella tvångsmedel eller administrativa frihetsberövanden.

Oops. Jag, som inte vill begå några brott mot PUL, tog raskt bort all rättsfallsinformation från lagen.nu medans jag utredde situationen.

Men, var det inte den här paragrafen som APB nyss fick dispens ifrån? De kanske kan göra ett undantag för mig också, tänkte jag och ringde datainspektionens callcenterjurister. Efter att ha redogjort för min situation förklarade den vänliga juristen på andra sidan att min användning rymdes under rubriken ”journalistisk verksamhet”. Jag tyckte det lät mycket konstigt, och underströk att jag inte gör något sorts redaktionellt urval eller överhuvudtaget nånting som liknar det som journalister håller på med, men tydligen ska uttrycket tolkas så pass extensivt.

Poängen med att behandlingen anses ske uteslutande för journalistiskt ändamål är att stora delar av PUL då inte blir tillgänglig, bland annat 10 § och 21 § — fantastiskt smidigt. Nästan som att skaffa ett utgivningsbevis för att falla under YGL, men utan alla nackdelar. Som jag ska skriva om i detalj nån annan gång.

Uppdatering: Bara för att min användning tydligen faller under journalistisk verksamhet, är det inte säkert att din gör det. Det här är inte juridisk rådgivning. Om du är osäker, ring eller maila datainspektionen, de är pigga på att svara på frågor.

Back again!

staffan — Tue, 17 Aug 2004 09:12:00 +0000

After a two month hiatus from writing, and one month of actual
downtime, this blog is back. The reasons for downtime are mainly
various technical problems, most of them having to do with
me wanting to host the blog on the big windows machine under my desk,
instead of some decent hosting provider, and also a two-week holiday in
Guatemala, during which I neither had the opportunity or felt the need
to get the site running remotely.

As for the writing hiatus, that had to do with some fairly substantial
changes that are going on in my life. At that time, it was to early to
say anything in any place that google indexes, but now things can be
told.

But that will be for a later post. Right now I want to divert your
attention to the brand new, sleek, unmodified-right-out-of-the-box
design of the blog (well, most of you probably read this in a RSS
reader and those that don’t, should consider, but…). I’ve moved from
dasBlog on WinXP to Blosxom on FreeBSD, mainly for the
reason that my FreeBSD box has only had one hard drive crash in five
years, while my Windows box has had two in just over six months. This
also reduces the number of boxes that I have to have running
permanently under my desk.

I could have tried to install Mono on FreeBSD and kept on running
dasBlog that way, but since this machine is a 166 Mhz Pentium I, it
might not have proven to be such a snappy experience. Blosxom (which,
by the way, should be spelled ‘bloxsom’, according to my fingers) can
be configured to generate static pages, which is much more suitable
for that kind of horsepower, and it’s also nicer from a security
perspective.

The drawback is of course that I have to import all old entries (and
comments) from the old blog somehow. Since all the stuff is there in
good ol’ XML, it should be no more trouble than a 15-minute hack. FLW.

Bloxsom wasn’t the only blog software I looked at, but it won on
virtue of having no database dependency. I really like to avoid using
RDBMS’es whenever I can, and the need for MySQL/Postgres to power this
blog is really really not that big.

Having said that, I’m not 100% happy with blosxom either, in
particular the way that the base install has very few features,
instead relying on a extensive catalog of plug-ins to add
functionality. I would think that this leads to features being poorly
integrated, even conflicting, with each other. But I’ll probably have
a more informed opinion once I try it out more extensively. Also, I
don’t like that the posting date is the same as the file
timestamp. Over time, I’ve managed to reset timestamps on a large
amount of files in a number of circumstances, and it would be a pity
if this metadata for my blog postings were to just disappear.