Mediawiki som datalager

lagen.nu använder jag ingen
relationsdatabas. Alla dokument ligger i varsin statisk fil, och den
samling av metadata som behövs för att jag ska kunna exempelvis skapa
index över alla dokument ligger i en gigantisk .n3-fil som jag går
igenom med RDFLib. Anledningen är
förstås min djupt
kända misstro
mot konceptet databasserver i allmänhet och
relationsdatabaser i synnerhet. Jag tycker filsystemet är underskattat
som databas. Det finns alltid där, är snabbt, går att debugga och
manipulera med välbekanta verktyg (ls, find,
grep, xargs, tar, rsync), har ett
begripligt rättighetssystem integrerat med operativsystemet, osv.

Till nästa stora iteration av lagen.nu-koden kommer jag ändå att
börja använda någon sorts server för datalagring. Men det blir
förmodligen inte en traditionell relationsdatabas med
SQL-gränssnitt. Min datamodell är inte särskilt relationell. Med tanke
på hur djupt jag integrerat RDF i systemet blir det förmodligen en
kombination av en triplestore tillsammans med någon form av dokumentdatabas.
För det tidigare blir det förmodligen Sesame, för det senare har jag
tittat nyfiket på CouchDB.

Men i kommentarerna till ett tidigare
inlägg
om en mediaövervakningsbot föreslog Peter Krantz att använda Mediawiki som
datalagring. Jag började kolla på hur man kan automatisera hämtning
och lagring av data från en Mediawikiserver, och det visar sig att det
finns en mycket kompetent pythonmodul, mwclient, för
ändamålet (det finns även ett annat ramverk, pywikipedia,
men det gav inte alls ett lika bra första intryck). Så här enkelt är
det att skapa och ändra en sida:

    import mwclient
    
    site = mwclient.Site('www.example.org','/path/to/mediawiki/')
    site.login('myuser','secret')
    page = site.Pages['Testpage']
    page.save("Hello world", summary="initial version")
    page.save("Goodbye world", summary="updated version")
    print "Page has %d revisions" % len(page.revisions())

Allt det som mediawiki ger — revisionshantering med diffar,
användarhantering, admin- och slutanvändargränssnitt, spamkontroller,
roll- och rättighetssystem, och utökningsmöjligheter
— får man på köpet. Det är kanske inget man vill använda för att
hantera jättemånga updateringar i sekunden, men om man kan se till att
exv cachea de anrop som bara hämtar data kan man nog få det snabbt
nog.

Nästa utvecklingscykel för lagen.nu

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

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

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

Förhandstitt på lagen.nu 2.0

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.

Lagen.nu 2.0 – vägkarta

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?

Wiki as a documentation tool

Recently we’ve been spending a lot of time writing the SDK documentation for the next
release of our product. As none of us is really that into techical documentation,
our first plan was to just write everything plain-text, in notepad (or Emacs in my
case) and hand off the text files to someone else who can do nice formatting, tabelization
(is that a word?), diagrams and such.

However, once the first draft of the actual text was finished, we wanted to see it
with at least a proportional font and proper headings, so we started thinking that
maybe if we used some special marker to signal headings, we could write a script that
would turn it into HTML (we didn’t want to write actual HTML by hand as it’s too much
tags everywhere, particularly <p> tags all over the place).

So, while thinking about what marker to use and how to write the script, it dawned
upon os that whatever we would do would end up very similar to a Wiki formatting engine.
As we use Openwiki for internal documentation
and ”knowledge capture”, I tried downloading it to see if we could make it to work
in a non-IIS context.

OpenWiki actually has an ”embedded” mode, but it’s made for embedding into other ASP
applications, and we wanted it to be used as a command-line vbs script. After some
heavy mangling I got it to work. The resulting WikiTranform.vbs is 274 kb large…
🙂 The end result looks so nice I’m thinking of suggesting that we ship the documentation
in HTML form (as opposed to FrameMaker-generated PDF).

Another option would have been to use Textile,
but since we’re already familiar with the (Open)Wiki style of formatting, this is
probably easiest.

I should pack it up and send to the openwiki guys, unfortunately the required mangling
was pretty rough, so it’s not that easy to fold the changes back into the mainline
source.