Staffan Malmgrens blogg » webutveckling

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.

Tre antipatterns i webinteraktionsdesign

staffan — Sun, 22 Mar 2009 15:54:01 +0000

Ett antipattern är ett sätt att göra något på, som vid första anblicken verkar vara en vettig approach, men som egentligen gör saker värre. Inom webbutvecklingsvärlden finns det en rik flora av dessa. Här är några exempel:

Pagers som visar ett löjligt litet antal saker åt gången: En pager är alltså den gränssnittskonstruktion som visar ett visst antal saker åt gången – exempelvis sökträffar eller bloggkommentarer. Eftersom det är mycket bökigare att konstruera ett pagingsystem än att helt enkelt visa alla saker på en gång vill folk förstås använda det, och sätter därför gränsen för antal saker som ska visas alldeles för lågt. Bredband är billigt, och moderna webbläsare klarar numera sidor över 15 kb. Minst 100 saker åt gången, tack.
För korta sessionstimeouts: Alla moderna webbprogrammeringsramverk har någon typ av sessionshanteringssystem, så att programeraren ska kunna spara ner en massa information om vad en viss användare gör i steg 1, så att man kan läsa upp det igen i steg 2. Att spara denna information tar förstås lite minne i webbserverprocessen, och har man många användare vill man förstås se till att rensa bort sådant som aldrig kommer användas, eftersom användaren lämnat webbplatsen och inte kommer göra något steg 2-request. Så alla webbprogrammeringsramverk har en sessionstimeout – om inte användaren begär en ny sida på x minuter rensas den data som associerats med användaren. Och eftersom minne var dyrt under förra årtusendet är denna timeout vanligtvis löjligt lågt satt. Vilket får till effekt att den som skickar in ett långt och genomarbetat webbforuminlägg upptäcker att sessionen timat ut, och att de senaste 21 minuternas arbete gått upp i rök. Minne är billigt, men användares tid är det inte. Sätt upp sessionstimeouten till minst 24 timmar, tack.
Reset-knappar på formulär: HTML-standardens avsnitt om hur man gör formulär innehåller ett antal olika typer av formulärelement – textfält, radioknappar, selectmenyer, submit-knappar samt, av någon outgrundlig anledning, en knapp som tar bort allt man mödosamt skrivit in i formuläret, och återställer det till sitt ursprungstillstånd. Risken för att råka klicka på denna knapp är visserligen inte stor, men det lär ändå inträffa mångdubbelt fler gånger än att någon faktiskt har nytta av det. Det första exemplet i standarden använder denna vansinniga funktion, vilket får till effekt att folk som inte tänker efter tror att det är en bra idé att ge användaren tillgång till något som bara kan användas till att skjuta sig i foten. Sluta med det, tack.

Måste det vara så komplicerat?

staffan — Fri, 30 Jan 2009 21:10:05 +0000

Förra helgen samlades ett gäng svenska webbutvecklare för att se om de i små team kunde skapa ett gäng kompletta webbtjänster, från start till mål, på 24 timmar. Det verkar som det gick riktigt bra.

Den här helgen hålls istället Global Game Jam, ett globalt event för spelutvecklare som hålls på massor av fysiska ställen, där enskilda spelutvecklare försöker skapa ett gäng kompletta spel, från start till mål — vilket kan låta mer komplicerat än webbtjänster, men de får å andra sidan 48 timmar på sig.

Ett liknande initiativ, med något längre tidsram är NaNoWriMo — ett årligen återkommande projekt där målsättningen är att skriva en roman (50 000 ord) på en månad.

Jag tror det här är en riktigt bra arbetsform för att förnya sin yrkesroll. Om man är van vid projekt som tar tusentals, kanske hundratusentals, mantimmar, och sen försöker få något gjort på fyrtio timmar måste man ifrågasätta de flesta delar av sitt arbetssätt och rensa bort all onödig komplexitet för att hitta den avskalade, essentiella kärnan i vad det nu är man gör. Jag inbillar mig att det ger mest för den som redan har erfarenhet — om jag satte mig ner och försökte skriva en uppsats om något juridiskt på 24 timmar skulle jag varken jag eller mina läsare bli särskilt mycket klokare.

Global Game Jam inleddes med en sevärd keynote presentation av Kyle Gabler:

Kyle utgör hälften av 2D Boy, som skapade förra årets stora indiespelsucce, World of Goo. Jag är ingen inbiten datorspelare, men efter att ha kört demon var jag tvungen att beställa spelet (som är oförskämt billigt). Sen spelade jag igenom det hela ända till slutet, vilket jag bara gjort med en handfull spel tidigare i mitt liv. Så bra är det.

I keynotepresentationen visas även Crayon Physics, som jag testade en demo av i förra helgen, och som jag just nu funderar på att köpa, eftersom det dels är supergulligt, dels är det första spel jag sett som verkligen är gjort för att spelas på en Tablet PC.

Nostalgia

staffan — Thu, 25 Nov 2004 13:26:00 +0000

By accident, I ended up at the original Netscape
cookie specification. It’s now over eight years since I read that
one for the first time. Notice the 1996-style formatting of the headers:


PERSISTENT
CLIENT
STATE

HTTP COOKIES

Other classic web tech specs: The Common
Gateway Interface, Hypertext Markup Language – 2.0,
Hypertext
Transfer Protocol — HTTP/1.0. I’ve referenced those a lot of times,
back in the day.

Smalltalk and Seaside for web applications

staffan — Tue, 11 May 2004 22:22:00 +0000

So, after debating at length with Göran about pros and cons of Smalltalk as a platform for real world development, I came to the conclusion that Smalltalk was worth looking into in greater detail, and since I’ve been wanting to write my own blog/wiki hybrid, it was suggested that I check out Seaside, a Smalltalk-based framework for web development comparable to ASP.NET or Java Server Faces.

At first look, Seaside doesn’t look much different than ASP.NET. It’s all about modelling your application’s interface in terms of objects and methods (”messages” for you Smalltalkers). Pages are built up of components, inheriting from System.Web.UI.Control (ASP.Net) or WAComponent (Seaside) that can include other components. When the user does things with any component, it results in events being fired (ASP.NET) or messages being sent (Seaside). Both frameworks seem to strive to abstract away the request/response nature of the web, and to allow the programmer to use a more event-driven approach to developement. In addition, seaside uses at it uses continuations to make it possible to, for example, ask the user something (similar to how a modal dialog would do it in a normal GUI enviroment), and then do something with the provided answer — all within the context of a
method.

The main difference is that programming in the Seaside framework results in a lot less housekeeping code. The object is really a ordinary object, except that it’s executed through the web. The difference didn’t really dawn on me before I tried to recreate WACounter as a ASP.Net Server component — it did involve a whole lot of code to handle events, manage viewstate and so on.

From a security perspective, Seaside has problems with the fact that the session id is present in the URL, and it seems harder to make applications RESTful, but apart from those issues, Seaside is definitly a framework worth looking closer at. From my own perspective, I hope that the ASP.NET developers do

Unfortunately, things elsewhere has been chaotic (and not in a good way), so I have not had any further time for experimentation with Seaside. As always, further progress will be reported here.

Update: This is a much better explaination of what continuation-based, or synchronous, web programming is.