Designdokumenter for det gennemtænkte ordbogssystem (aka. referart fra designmødet fra i går/nat)

[Peter Makholm <sslug@sslug>]

Den nuværende metode at behandle information ind og ud af
ordbogsprojektet er ikke ret god. Derfor brugte vi i aftes nogle timer
2230-0100 på at finde på noget bedre. Dette vil have minimal
indvirkning på dem der "bare" anvender webinterfacet.

Jeg ville godt have brugt mindst et par timer mere på denne tekst før
jeg offentliggjorde den. Men jeg tror at både Claus og Sune kan finde
nogle guldkorn i den. Alle kommentare modtages med kyshånd, både
designmæssige og forklaringsmæssige.


Mål:
====

Målet er at lave et godt værktøj, der gør det muligt at lave ordbøger
efter open source-princippet. [her skal der stå noget mere]


Overblik:
=========

Systemet er delt op i tre dele, der vil blive behandlet hver for sig:

  * Deltapost

    Information fra normale brugere om korekte, forkerte og manglende
    oplysninger i ordbogen. Disse kan produceres af forskellige
    brugergrænseflader som for eksempel Jacobs webinterface.


  * Statistik over indkomne informationer

    En opgørelse over alt indkomen information i systemet. Hvor mange
    har sagt god for informationen, hvormange mener at informationen
    er forkert og er der nogen autoritative kilder. Denne opgørelse
    erstatter tildels den nuvernde samlet_log.gz.


  * Dataudtræk

    Forskellige typer for udtræk af ovenstående statistik. Det kan
    være at man kun er interesseret i enkelte kategorier eller
    oplysninger der er rigtige med en hvis sikkerhed.


Sidste i artiklen vil vi komme ind på ting som man skal overveje som
administrator for systemet, som ikke direkte er en del af
systemet. Dette inkluderer brugervenlige grænseflader og forskellige
sikkerhedsaspekter.
 


Deltaposten:
============

En deltapost er den måde som bidragsydere til ordbogen kan tilføje og
rette informationer i ordbogen. Ofte vil den normale bidragsydere bare
taste information ind i en eller anden type formular, der derefter
danner en korrekt deltapost og sender den det korrekte sted hen.

En deltapost består af tre typer felter: En angivelse af hvilken post
man ønsker at give oplysninger om (nøglen), en række oplysninger og nogle
metaoplysninger om selve deltaposten. I praksis består deltaposten
bare af en række RFC822-ligende headere uden garanti for rækkefølgen.

Nøglen består at et Word-felt og eventuelt et Id-felt. Id-feltet
bruges kun hvis der er flere forskellige ord, der staves på samme måde
og ska opfattes på præci samme måde, som når en ordbog har flere
indgange for samme bogstavmønster. (hold da kæft hvor er jeg
milijøskadet).

Informationen består af de samme felter som tidligere. Det vil sige
Class, Conjugation, Root, Hypernation, Description, Correction (hvad
vi nu har af felter) samt det nye felt Spelling. Hvis en deltapost
indeholder et af ovenstående felter betyder det altså at afsenderen
enten mener at informationen er rigtig eller at informationen er
forkert. den præcise betydning fremgår af metainformationerne.

Metainformationerne består af felterne: Editor, Date, Authority,
Status og Comment. Meningen med statusfeltet er nu at man kan angive
at informationerne i deltaposten er korekte eller forkerte. det er
ikke muligt at både skrive korrekte og forkerte informationer i samme
deltapost. Ønsker man at ændre på eksisterende information i ordlisten
foregår det ved at må både sender de gamle data i en deltapost med
status minus og de nye data i en deltapost med status plus.

Eksempel: I ordbogen er der oplysninger om at ordet "solsort" er et
udsagnsord. det er tydeligvis forkert, derfor sender jeg følgende to
deltaposter til systemet:

Word: solsort
Class: udsagnsord
Editor: sslug@sslug
Status: -

Word: solsort
Class: navneord
Editor: sslug@sslug
Status: +


Statistik:
==========

Hvergang systemet modtager en deltapost tilføjes oplysningerne til en
statistikfil hvorefter deltaposten arkiveres lodret i en
logfil. Statistikken vil indeholde en post for hvert ord jævnfør
diskussionen om nøgler ovenfor. Derudover indeholder statistikken et
felt for hver information der er blevet lagt ind i systemet samt
hvormange der mener at informationen er rigtig (sendt med status: +),
hvormange der mener at informationen er forkert (sendt med status: -)
samt et felt om der er nogen autoritære informationer.

Det vil sige at der for et ord godt kan være flere modstridende
Class-felter med en angivelse af hvormange der godkender eller
underkender de enkelte felter.

Første gang statistiksystemet støder på en autoritet for en oplysning
vil den markerer automatisk markerer dette i posten. Hvis der senere
kommer modstridende autoriteter, kan autoritetsfeltet kun opdateres
ved at administratorene gør det i hånden.


Dataudtræk:
===========

På baggrund af oplysningerne i statestikken kan der så laves
forskellige former for ordbøger. Oftest vil man bruge en information
hvis der er nok der har sagt ja til den eller den er autoritært
rigtig.

[plapre plapre plapre]


Ting den enkelte adminstrator skal overveje:
============================================

Maskinlæsbarhed. En række af oplysningerne vil være mest værd, hvis de
kan bruges maskinelt. Vores erfaring er at det især drejer sig om
Class, Conjugation samt Category. Det vil være op til den enkelte
administrator for et projekt at definerer hvilke værdier der bør være
i disse felter.


Sikkerhedsaspekter. Der er i det ovenstående intet der sikre at en
eller anden scriptkiddie eller et andet individ på samme
intelligensniveau begynder at floode systemet med forkerte
oplysninger. Det er igen op til administratorene for de enkelte
projekter at definerer en politik om hvorfra vi vil godtage
deltaposter.


Brugergrænseflader. De fleste mulige bidragsyderen vil nok finde det
lidt besværligt at skulle skrive deltaposter i hånden. Vi mener dog at
ovenstående design er det der er lettest at bruge på uforudsete måder,
hvorfor vi ikke har interesseret os for hvordan deltaposter bliver
frembragt. Dette ville næppe være muligt såfremt vi begyndte at
definerer en eller anden form for standardformular.


-- 
Peter