Monk - frequently asked questions

NWO/Catch - Scratch
ALICE/University of Groningen,Nationaal Archief/Den Haag

Welkom bij de publieke Monk website voor de transcriptie van probleemwoorden: woorden waarmee de handschriftherkenner van Monk moeite had. Monk is een soort Google, maar dan voor handgeschreven woorden in afbeeldingen (scans) van historische documenten. Monk moet dit kunstje leren en heeft hierbij voorbeelden nodig. Een voorbeeld is een 'ingetikt stukje tekst behorend bij een beelduitsnede'. Om te kunnen lezen moeten er eerst voldoende voorbeelden zijn geleverd. Hierbij kun jij helpen!

Zie ook:

Monk - FAQ - Lijst van email-berichten en vragen


  • Subject: aanmelding
  • Geachte transcribent,
    
    - ik heb de pagina in Monk ondergebracht
    - en tevens toegevoegd aan de publieke 'Monk trainer' (http://tinyurl.com/5w5nqaf)
      Hier komen willekeurige woorden langs, waaronder nu ook uit de
      eerste PV-Astro pagina.
    
    - Verder kunt u als 'expert trainer' inloggen als gebruiker/wachtwoord
      op: http://application02.target.rug.nl/cgi-bin/monkweb?cmd=login
    
    - en daarna regeltranscriptie uitvoeren op
    
    /cgi-bin/monkweb?cmd=editxt&db=19320&ipage=1&edit=11&ntxt=-1
    
      Monk laat standaard in deze collectie bij de in regels opgebroken pagina de kleurenversie 
      van elke regel zien, die is informatiever dan de zwart/wit versie. Deze laatste weergave  
      kan evt. onder de knop [weergave]/[Update rendering style] worden gekozen.
    
    - het trainen van woorden op 'hit list' basis gebeurt onder:
    
    http://application02.target.rug.nl/cgi-bin/monkweb?cmd=TrainedWords&db=19320&trainedwordmethod=Sordex&annot=all&prefix=&sortopt=sorted_hitlistsize
    
      Een woord kan aangeklikt worden en individueel worden 'gelabeld'
      Dit leidt, in tegenstelling tot de publieke woordlabels, voor
      expert-trainers tot een effect in het leerproces. Dit is pas merkbaar
      na gemiddeld een dag.
    
    Ik realiseer me dat het allemaal vrij technisch is maar U kunt niet echt iets heel ernstigs 
    fout doen, dus klik gewoon rond en kijk wat er te beleven valt op Monk.
    
    Vriendelijke groeten,
    Lambert Schomaker 
    


  • Subject: leken-oogst middeleeuwse woorden
  • Geachte transcribent,

    dit een voorbeeld van wat ik zou willen noemen 'leken-oogst': voornamelijk functiewoorden ingetikt door ander gebruikers die het hedendaags Nederlands machtig zijn. Op basis van voorbeelden is een hitlist gemaakt voor de woorden 'en', 'van', 'in' etc.. Bij machineleren wordt door 'aanklontering' met hierop lijkende woorden de zoeklijst (hit list) voller en preciezer.

    Ook het labelen van simpele woorden is al nuttig: complementair aan deze saaie functiewoorden in een regel-strip zijn er natuurlijk de interessantere woorden waarvoor Uw expertise zeker nodig is. Als Monk de saaie woorden kan wegstrepen, wordt gaandeweg duidelijker welke woorden op een regel informatief zijn.

    Mvg Lambert Schomaker

    Subject: Re: leken-oogst middeleeuwse woorden
    
    Beste meneer Schomaker,
    
    Ik zie in de 'leken-oogst' dat afkortingen niet worden opgelost: Bij het
    hedendaagse 'en' staat onder andere 'en (met een streep boven de n)'. In
    het Middelnederlands is dat een afkorting voor 'ende'.
    
    Subject: Re: Re: leken-oogst middeleeuwse woorden

    Beste transcribent,

    de annotatie op woordniveau (dwz, niet de regeltranscriptie) zal voor U nog opvallende bijzonderheden vertonen. Immers, de klassen die worden vastgelegd hebben een uniek 'label'. Indien 'ende' (voluit) en 'en@' (met krul) beide als 'ende' zouden worden gelabeld haalt dit het herkenningspercentage omlaag: immers, twee vormen worden nu in dezelfde bak van woordvormen gegooid. Tabel 1. maakt duidelijk hoe Monk tegen woordbeelden, woordcodes en tekstweergave aankijkt:

    Tabel 1. Monk maakt onderscheid tussen woordbeeld, woordcode en woordtekst

    Beeld (Image) Code Text
    [woordvormklasse] ↔ [uniek Monk woordlabel] ↔ [voorkeursweergave bij gebruikers]
    @ende_en ende

    Hiervoor is een oplossing: bijzondere codes worden voorafgegaan door '@'. Zo zal 2 1/2 als @2_en_een_half kunnen worden geannoteerd, als de vrijwilligers dit met elkaar afspreken of elkaar hierin navolgen. De bijzondere diacritische vorm voor 1/2 (die ik op mijn systeem nog niet zo gemakkelijk kan invoeren) is nog steeds geen standaard. De codes zullen verschillen tussen Apple, Microsoft, Linux, tekstverwerkers en de verschillende internet browsers. Daarom staat Monk toe dat annotatoren een eigen systematiek ontwikkelen, volledig met ASCII codes die zeker nog honderd jaar te ontleden zijn, in tegenstelling tot de huidige coderingen UTF, Unicode etc. die nog steeds in ontwikkeling zijn. Zolang @35_en_een_kwart maar uniek is, is het altijd te herleiden tot interne binaire codering in Unicode, UTF, iso_latin, of TEI (etc. etc.). Voor zeer veel vormen die we in het materiaal tegenkomen is ook gewoonweg nog geen internationaal aanvaardde code. Daarom stelt Monk (dwz. de gemeenschap van Monk transcribenten) zijn eigen standaard.

    Zo zie ik ook dat U al een hedendaagse vertaling doet van de hoofdletters in eigennamen en plaatsnamen. Voor de regeltranscriptie is dit geen probleem (deze is vooral voor menselijk gebruik). Voor de woord-labeling is dit echter een probleem! als de hoofdletter er niet staat, zal het in de toekomst niet mogelijk zijn om woordvorm-modellen met hoofdletters uit de collectie af te scheiden van woord-vorm-modellen (afbeelding) zonder de hoofdletter. Op woordvorm-niveau (en dat is waarin Monk 'denkt'), is er een groot verschil tussen de afbeelding voor [jansen] en [Jansen]. In principe tikt men wat er staat, niet wat men denkt dat er staat of wat men als norm vermoedt. Ook in de Scheepsjournalen blijkt dat de kapiteins, heel onhanding, eigennamen niet met hoofdletters schrijven.

    [dit probleem is later opgelost met het scherm: woordvormcodificatie]

    Een vergelijkbaar probleem is de contractie Derich soin ==> Derichsoin. Ook dit is voor de herkenner op woordniveau een groot probleem. De contractie zal op basis van regels uit het domein moeten gebeuren als naverwerking (post processing). Als er een grote spatie staat is Derich_soin een beter label dan 'Derichsoin', en het is geen probleem om de afzonderlijke Derich en soin te splitsen t.b.v. een nette transcriptie. In de toekomst kan Monk proberen de combinatie te splitsen, in het beeld.

    Wij hebben inmiddels veel ervaring met de verschillende invalshoeken van labeling/annotatie. Bij een bijeenkomst van archivarissen bleek dat men het begreep toen ik zei: al labelen jullie een woordklasse met de code 'XJ765', wanneer je dit maar consistent doet kan Monk de weergave van een woord op scherm of printer altijd weer laten construeren op basis van de weergaveregels voor 'XJ765'. Een dergelijke omvorming van een code naar een specifieke tekstweergave is huis- tuin- en keuken-informatica, dit i.t.t. de patroonherkenning- en beeldbewerkingsmethoden van Monk. De woordvormcodificatie laat toe om de weergave van de code met een andere tekst te realiseren.

    De twee disciplines, patroonherkenning en geschiedkundigen kijken op een verschillende manier naar dit materiaal: voor patroonherkenningsonderzoek zijn de pixels, de krulletjes en de witte ruimtes van belang. Voor geschiedkundigen is het meestal van belang om naar de inhoud te gaan, onvolkomenheden weg te werken en zorgvuldig de diacritica uit te zoeken. Naarmate er meer bekend is over een collectie groeit de systematiek in beide werelden wat naar elkaar toe, hebben gemerkt in de samenwerking met archieven en transcribenten. De belangen van de paleografen liggen op een aantal punten dichter bij de belangen van de patroonherkenners: beide partijen gaat het om de vormdetails.

    Vriendelijke groeten, Lambert Schomaker


  • Subject: labelen
  • Beste Lambert,
    
    Het MONK-systeem begint steeds duidelijker voor me te worden. Het ziet
    er mooi uit, maar ik heb nog wat vragen.
    Begrijp ik het goed dat afgekorte woorden bij het labelen worden
    opgelost en voorafgegaan door een @? Dus 'oviu' labelen als '@ovium',
    'Gijsbt' labelen als '@Gijsbert' etc. En moet de afkorting 'lib' dan
    eigenlijk als '@libre' worden gelabeld? Dit zie ik in de woordenlijst
    (nog) niet terug.
    Ik vroeg me ook af hoe te werken een woord op verschillende manieren is
    afgekort. 'voirscreven' kan bijvoorbeeld als 'voirscreve' zijn afgekort. 
    Beide kunnen als '@voirscreven' worden opgelost, maar er worden dan wel 2 
    vormen in dezelfde bak gegooid.
    
    Vriendelijke groet,
    
    transcribent
    

    Inderdaad is het uitgangspunt om eerst te labelen wat er staat. Als dat lukt, kun je gewoon de letters intikken. Als dat niet lukt, zoals bij afkortingen, gliefen en andere patronen, dan gebruiken we de @... codes. Om nu toch, in 1 en dezelfde code iets te kunnen zeggen over vorm en bedoeling, kan de afspraak @[bedoeld]_[geschreven] worden gehanteerd. Bijvoorbeeld: @voirscreven_voirs. In TEI wordt voor contractie soms gebruik gemaakt van h(ere)n, om de omissie expliciet uit te spellen. Om technische redenen geeft Monk de voorkeur aan @heren_hn. In het scherm voor algemene woordcodificatie voor @heren_hn is genoeg ruimte om de TEI variant van deze vormklasse in te tikken. Bij voldoende interesse zal er naast de LaTeX methode ook een veld voor TEI worden toegevoegd.


  • Subject: doelwoord met andere woorden in hetzelfde vakje
  • Hallo Lambert,
    
    Nog een vraagje over het labelen in MONK:
    
    Het komt regelmatig voor dat in de hitlist blokken staan met meer dan
    een (1) woord.  Onder 'vridages' staan naast 2 groene blokken met
    'vridages' bijvoorbeeld ook 3 rode blokken met 'vridages op' en 'des
    vridages'.  Is het een probleem als deze woordencombinaties als één
    item worden gelabeld? Zodat 'vridages op' een (1) item in de hitlist
    wordt.  Of wordt binnen MONK alleen per woord gelabeld en kunnen
    meerdere woorden niet als een (1) item gelabeld worden?
    
    Hartelijke groet,  
    transcribent
    

    Als er echt meerdere woorden in een vakje staan worden ze samen in het label ingevoerd: te_Amsterdam. Als u een spatie intikt zal deze automatisch in een _ (underscore) worden omgezet. Er is een uitzondering. Als het om een woord met voldoende letters gaat en het is een betekenisrijk woord zoals een achternaam of plaatsnaam, dan mag een enkele foutieve letter links of rechts wel weggelaten worden [e Groningen] ↔ [Groningen]. Evenzo mag [Groninge] als ↔ [Groningen] worden gelabeld.

    Het is daarentegen begrijpelijk dat het labelen van [he] als [het] onwenselijk is: er is geen overtuigend bewijs in de eerste twee letters aanwezig om -als mens of computer- af te kunnen leiden om welk geheel woord het zou kunnen gaan.


  • Subject: blauwe in plaats van groene vakjes
  • Beste Lambert,
    
    Ik heb een aantal woorden proberen te labelen. Zo heb ik '11' veranderd
    in @Romeinse_xi_11. Na het saven werd het rose vakje met 
    het herkenningsresultaat blauw (Human labeled,
    does not fit in current hit list) in plaats van groen. 
    
    Subject: Re: blauwe in plaats van groene vakjes

    Beste transcribent,

    blauw is even goed als groen. Het woord wordt niet groen gemarkeerd omdat het label verschilt van de naam van de zoeklijst. wanneer deze zoeklijst opnieuw gesorteerd is (Sordex), zal deze hit list zelf ook "@Romeinse_xi_11" heten. Dit label is dan identiek aan jouw nieuwe 'human label' zodat de kleur groen wordt. Deze herberekening en verbetering van de zoeklijsten gebeurt periodiek, voornamelijk 's nachts.

    Mvg Lambert


  • Subject: Romeinse getallen
  • Beste Lambert,
    
    Ik heb een aantal woorden proberen te labelen. Zo heb ik '11' veranderd
    in @Romeinse_xi_11  (...)
    
    Subject: Re: Romeinse getallen en blauwe in plaats van groene vakjes

    Beste transcribent,

    De labeling is gevoelig voor boven- en onderkast: de romeinse cijfers die door andere transcribenten waren gelabels hadden meestal de vorm: @ROMEINSE_...! Dit kun je ook zien bij het intikken: een al bestaande prefix wordt in de suggestielijst getoond. Het is dus beter om in dit geval consistent 'ROMEINSE_XI_11' in te voeren. De extra labeling met de arabische '11' is wenselijk omdat de codering dan redundant is, en snel te controleren door andere evt. jonge gebruikers met minder ervaring in het ontcijferen (dat woord is er niet voor niets) van romeinse getallen.

    Mvg, Lambert


  • Subject: Tandwiel /Sordex herberekening
  • Beste transcribent, je kunt nu ook zelf met de 'tandwielknop' een aanvraag indienen voor herberekening van een zoeklijst. Die wordt periodiek opgepikt door de rekenserver en er wordt een nieuwe 'Sordex hit list' gemaakt, voor dat woord.
    Subject: Re: Tandwiel
    
    Beste Lambert,
    
    Bedankt voor deze service!
    
    Ik heb het tandwiel inmiddels aangezwengeld. Hij is nu al een tijdje
    bezig met het aanmaken van een nieuwe Sordex. Hoe lang duurt dat proces
    gemiddeld?
    
    Vriendelijke groet,
    
    transcribent
    
    Subject: Re: Re: Tandwiel

    Beste transcribent,

    hoelang een Sordex herberekening duurt is jammer genoeg niet goed te voorspellen. Het hangt van veel factoren af: hoe groot is de woordenlijst?, hoe lang geleden is de grote index ververst? Hoeveel rekencapaciteit kan Monk krijgen? Bij een nieuwe collectie waarvan nog maar een paar zoektermen bekend zijn zal het in het algemeen veel sneller gaan dan bij een grote bestaande collectie of een dik boek.


    Naar de woordtranscriptie-pagina

    Of probeer de Monk zoekmachine


    Copyright 2008,2009,2010 Lambert Schomaker