Deze digitale editie werd ontwikkeld in overeenstemming met gangbare internationale standaarden voor tekstrepresentatie en -opmaak. Dit biedt de beste garantie op (editie)wetenschappelijke integriteit in alle aspecten van een digitale editie, van representatie (transcriptie en annotaties) tot presentatie. Deze aanpak biedt bovendien mogelijkheden om diverse open-source technologieën in te schakelen voor de uiteindelijke presentatie.
Deze digitale editie vertrekt van dezelfde theoretische uitgangspunten als elke andere brieveneditie. De brieven werden volgens vaste codeerrichtlijnen getranscribeerd en geannoteerd door vrijwilligers, onder inhoudelijke supervisie van het Guido Gezellearchief. De transcripties en annotaties werden aangemaakt in Word bestanden met alle brieven per correspondent, die vervolgens automatisch werden omgezet naar afzonderlijke bestanden per brief. Voor de opmaak van die brondocumenten werden internationale standaarden voor tekstrepresentatie en -opmaak gehanteerd. Wat betreft tekstrepresentatie werd gekozen voor het eXtensible Markup Language (XML) formaat. Dit is een internationale standaard die ontwikkeld werd door het World Wide Web Consortium (W3C), een consortium (met ongeveer 400 ledenorganisaties waaronder grote informaticabedrijven als IBM en Microsoft) dat zich richt op de standaardisering van webtechnologieën. XML documenten bestaan uit platte tekst waarin allerlei meta-informatie kan worden opgenomen. Die meta-informatie bestaat hoofdzakelijk uit elementen en attributen, zoals bijvoorbeeld:
Dit voorbeeld bevat 5 elementen, waarvan het bereik wordt aangegeven door tags. Tags worden gemarkeerd door punthaken (< >) en duiden ofwel het begin (starttag) van een element aan, ofwel het einde (eindtag). In starttags wordt binnen de punthaakjes de naam van het element opgenomen. In eindtags wordt de naam van het element binnen de punthaakjes voorafgegaan door een schuine streep (/). XML elementen kunnen uitgebreid worden met extra informatie, in de vorm van attributen die in de starttag worden toegevoegd. Attributen bestaan uit een attribuutnaam, gevolgd door een gelijkheidsteken (=) en attribuutwaarde tussen enkele (') of dubbele (") aanhalingstekens. In dit voorbeeld wordt de eigenlijke tekst omsloten door een <tekst> element. Daarbinnen worden twee <regel> elementen onderscheiden. Die worden verder getypeerd door verschillende waarden voor het @nummer attribuut. Verder komen er in de tekst (en dus ook binnen de <paragraaf> elementen) nog 2 <titel> elementen voor. Om aan te geven dat het om een XML document gaat, begint het document met een XML declaratie (in het voorbeeld: <?xml version="1.0"?>), met een aanduiding van de versie van de XML standaard waaraan het document beantwoordt. Merk op dat in dit voorbeeld gebruik wordt gemaakt van inzichtelijke elementnamen, maar dat evengoed alle elementen de naam x hadden kunnen dragen. De XML standaard bepaalt enkel de syntactische regels waaraan de opmaak voor documenten moet voldoen. Het biedt de volgende voordelen:
XML voorziet mogelijkheden om de logische structuur van documenten vast te leggen in een schema. Dat bevat een structuurgrammatica (definities van de namen, inhoud en distributie van elementen en attributen) waaraan alle documenten van dat type moeten voldoen. Hiermee kunnen dus formele definities worden vastgelegd voor de opmaak van verschillende teksttypes. De documentstructuur van het vorige voorbeeld zou als volgt kunnen worden beschreven in een schema:
Zonder in detail te treden, [1] biedt dit voorbeeld een illustratie van hoe een documentstructuur kan worden beschreven in een Relax NG schema. In dit geval moet een document bestaan uit een <tekst> element dat een @nummer attribuut kan hebben en één of meer <regel> elementen moet bevatten. Die kunnen op hun beurt platte tekst en <titel> elementen bevatten, en die laatste bestaan uit platte tekst. Een dergelijk schema kan niet enkel descriptief worden gebruikt voor de beschrijving van bestaande documentstructuren, maar ook prescriptief voor de formele controle van nieuwe documenten. Er bestaat immers software die de structuur van XML bestanden kan controleren ten opzichte van wat in een schema als geldige structuur wordt bepaald. Door XML bestanden op een dergelijke manier te valideren ten opzichte van een schema, kan de consistentie van de codering en dus uitwisselbaarheid van de bestanden worden verhoogd.
Om dergelijke uitwisselbaarheid van onderzoeksbestanden te verbeteren, zijn ook op het vlak van inhoudelijke documentdefinities internationale inspanningen tot standaardisering ontstaan. De belangrijkste inspanning op het gebied van tekstopmaak voor humane wetenschappen werd geleverd door het Text Encoding Initiative (TEI), een onderzoeksproject dat werd opgericht in 1987 en sinds 2000 is ondergebracht in een consortium. Het heeft als opzet een interdisciplinair en internationaal opmaakschema te ontwikkelen voor de representatie van allerlei types van teksten voor onderzoek en onderwijs. Sinds 1990 zijn verschillende generaties van TEI codeerschema’s en bijhorende richtlijnen gepubliceerd. In 2005 werd de laatste grote versie, “TEI P5”, uitgebracht, die sinds dan continu wordt bijgewerkt en gedocumenteerd op Guidelines for Electronic Text Encoding and Interchange (TEI P5) . Daarin worden enkele honderden structuurelementen gedefinieerd waarmee tekstfenomenen uit zeer uiteenlopende tekstgenres zoals proza, poëzie, drama,... kunnen worden gecodeerd.
In de volgende secties wordt bondig toegelicht hoe de TEI richtlijnen werden gebruikt voor de codering van de brieven in deze editie. [2]
Elke brief die in deze digitale editie is opgenomen, werd gecodeerd in een apart TEI brondocument, dat beantwoordt aan een specifieke tekststructuur.
In het TEI opmaakmodel worden teksten opgevat als zelfbeschrijvende eenheden, met naast de tekst zelf ook uitgebreide voorzieningen voor meta-informatie over het document. TEI P5 teksten worden opgenomen in een <TEI> element. Daarbinnen moeten minimaal een header-gedeelte met meta-informatie in een <teiHeader> element, en een tekstgedeelte in een <text> element voorkomen:
In de volgende secties wordt eerst beschreven hoe de metadata georganiseerd is (sectie 3), en vervolgens wordt de codering van de eigenlijke tekst gedocumenteerd (sectie 4).
De meta-informatie voor de brieven is afkomstig uit de bibliotheekcatalogus van het Guido Gezellearchief, en werden omgevormd naar corresponderende velden in <teiHeader>. Binnen <teiHeader> worden volgende onderdelen gebruikt:
Voor de Gezellebrieven bestaat de beschrijving van de digitale bestanden in <fileDesc> uit volgende onderdelen:
Een eerste component van de beschrijving van het digitale document in <fileDesc> bestaat uit titelgegevens, in een <titleStmt> gedeelte. Voor elke brief bevat de titelbeschrijving volgende gegevens:
Volgend voorbeeld toont het <titleStmt> element voor de brief van Victor Van Coillie aan Guido Gezelle op 19/03/1861:
Een tweede component binnen <fileDesc> is een gedeelte met informatie over de digitale publicatie in <publicationStmt>, dat volgende informatie bevat:
Volgend voorbeeld toont het <publicationStmt> gedeelte voor bovengenoemde brief:
Een laatste onderdeel binnen <fileDesc> is een bibliografische beschrijving van de brontekst waarop de digitale tekst is gebaseerd, in <sourceDesc>. Omdat het hier over manuscripten gaat, wordt die bronbeschrijving gegeven in een specifiek TEI element <msDesc>, waarbinnen volgende onderverdelingen voorkomen:
Binnen <encodingDesc> wordt gedocumenteerd hoe de digitale tekst zich verhoudt tot de brontekst. Dat gebeurt voor de Gezellebrieven in drie elementen:
Volgend voorbeeld toont het <encodingDesc> gedeelte voor de brief van Emiel Tillieux aan Guido Gezelle op 06/12/1884:
Het header element <profileDesc> wordt gebruikt om gegevens te documenteren over de verschillende talen en handschriften die in een brief voorkomen. In de Gezellebrieven gebeurt dit in volgende elementen:
Volgend voorbeeld toont het <profileDesc> gedeelte voor de brief van Hugo Verriest aan Guido Gezelle tussen 1860 en 09/06/1864:
Voor maximale transparantie, bevat het <xenoData> element in <teiHeader> een kopie van de oorspronkelijke meta-informatie uit de bibliotheekcatalogus van het Guido Gezellearchief. Die metadata werden geëxporteerd in een XML formaat, en worden integraal gekopieerd in <xenoData>.
Volgend voorbeeld toont het <xenoData> gedeelte voor de brief van Pieter Benoit aan Guido Gezelle op 22/04/1855:
Het header element <revisionDesc> bevat een logbestand van alle wijzigingen die aan het digitale document zijn aangebracht. Elke wijziging wordt gedocumenteerd in een <change> element. Het @when attribuut geeft het tijdstip van de wijziging aan.
Volgend voorbeeld toont het <revisionDesc> gedeelte voor de brief van Leonard Lodewijk De Bo aan Guido Gezelle op 27/04/1881:
De meta-informatie in de header wordt gevolgd door de codering van de tekst in het <text> element. Dit element krijgt drie attributen:
Binnen het <text> element wordt de eigenlijke inhoud weergegeven in een <body> element. Als ook de envelop van een brief is getranscribeerd, komt die informatie in een <front> element, vóór <body>. Binnen die grote structuren worden de verschillende “functionele blokken” die in verschillende correspondentietypes kunnen voorkomen onderscheiden in onderliggende structuren. Elk van die blokken wordt gecodeerd in een <div> element, met volgende waarden voor het @type attribuut:
Brieven zullen doorgaans bestaan uit de eigenlijke inhoud, met mogelijk een adresgedeelte in een aparte envelop. Dat kan in volgende structuur worden gerepresenteerd:
Als functionele blokken niet fysiek van elkaar gescheiden zijn, worden ze alle in <body> geplaatst. Zo zal het adres- en mogelijk afbeeldingsgedeelte van een telegram nauwer verweven zijn met de eigenlijke tekst. Om die blokken toch te onderscheiden, worden ze binnen <body> naast elkaar gecodeerd:
De eigenlijke inhoud van de meeste brieven (binnen <body>) bestaat uit een aanhef, paragrafen en een slot. Die worden respectievelijk gecodeerd in <opener>, <p> en <closer>. Voor complexere brieven worden aparte tekstdivisies onderscheiden met <div>, elk met hun eigen aanhef, paragrafen en slot. De aanhef (<opener>) bevat vaak adresinformatie (<address>), een datumregel (<dateline>) en een begroeting (<salute>). Deze informatie kan ook voorkomen in <closer>; dit is ook de plek waar meestal een handtekening (<signed>) voorkomt. Als de tekst een postscriptum bevat, wordt dit in een <postscript> element gecodeerd, naast <closer>. [3]
De brieven kunnen briefhoofden bevatten. Daarvoor wordt het element <fw> (forme work) gebruikt, met "briefhoofd" als waarde voor het @type attribuut. Daarnaast komen ook specifieke formule-achtige “briefzegens” voor. Die worden op dezelfde manier gecodeerd, maar met de waarde "briefzegen". Aan het begin en einde van brieven komt soms ook voorgedrukte tekst voor. Die wordt gemarkeerd met een <seg> element, met "print" als waarde voor het @type attribuut.
De correspondentie van Gezelle bevat veel gedichtfragmenten. Gedichtregels worden in een <l> (line) element gecodeerd; als ze in strofes zijn gegroepeerd, worden ze omsloten in een <lg> (line group) element:
Andere grote structuurelementen die kunnen voorkomen tussen of binnen paragrafen, zijn tabellen en lijsten. Tabellen worden gecodeerd met <table>, waarbinnen de rijen worden aangeduid met <row>. Daarbinnen worden de afzonderlijke cellen als <cell> gecodeerd.
Lijsten worden met <list> aangeduid. Genummerde lijsten worden gemarkeerd met de waarde "ordered" voor het @rend attribuut; ongenummerde lijsten krijgen de waarde "unordered". Binnen <list> worden de afzonderlijke punten als <item> gecodeerd.
Paginagrenzen worden aangeduid met <pb> (page beginning). Het paginanumer dat in de brontekst aanwezig is, wordt getranscribeerd in het @n attribuut. Wanneer de brontekst geen paginanummer bevat, kan de editeur in @n zelf een paginanummer geven. In dat geval krijgt het <pb> element ook een @type attribuut met waarde "editor". Als een woord onderbroken wordt door een paginagrens, wordt het afbrekingsteken gecodeerd in het element <pc> (punctuation character), met een @type attribuut met waarde "pb", en een @force attribuut met waarde "weak". Het daaropvolgende <pb> element krijgt dan een extra attribuut @break met waarde "no". Op die manier kan bij de indexering van de brieven in een XML database het leesteken binnen <pc> worden weggefilterd.
Regeleindes zijn niet expliciet gecodeerd binnen de lopende tekst, behalve als daaruit een editeursingreep kan verklaard worden. Daarvoor wordt dan het element <lb> (line beginning) gebruikt op de plaats waar het regeleinde voorkomt. Als de editeur dit expliciet heeft gemarkeerd in de transcriptie, wordt het @type attribuut gebruikt, met waarde "editor".
Typografisch afwijkende tekst wordt gecodeerd met het <hi> element. In het @rend attribuut wordt de afwijking formeel beschreven. Volegende waarden worden gebruikt:
Die waarden kunnen worden gecombineerd in lijst in het @rend attribuut, gescheiden door witruimte.
Als de brief afbeeldingen bevat die van belang zijn voor de brieftekst, worden die afbeeldingen opgenomen in de transcriptie. Dat gebeurt in een <figure> element. De afbeeldingen worden in het digitale bestand van de brief opgenomen, in de vorm van een Base64 (ASCII) gecodeerde versie van het bestand, in een <binaryObject> element. Met een @mimeType attribuut wordt aangegeven om welk bestandsformaat het gaat: "image/png" voor afbeeldingen die als PNG in de Word-transcripties werden ingevoegd, en "image/jpeg" voor JPEG afbeeldingen. Wanneer de editeur een omschrijving heeft opgenomen voor de afbeelding, wordt die als <figDesc> binnen <figure> opgenomen.
Omdat brieven meestal primaire documenten zijn die niet geredigeerd worden, bevatten ze vaak schrappingen en toevoegingen. Die zijn opgenomen in de transcriptie, maar gemarkeerd met respectievelijk <del> (schrappingen) en <add> (toevoegingen).
Wanneer tekst vervangen wordt, door eerst tekst te schrappen en meteen nieuwe tekst toe te voegen, worden die schrapping en toevoeging gegroepeerd in een <subst> (substitution) element:
Behalve primaire tekstingrepen door de briefschrijver, bevat de correspondentie van Gezelle ook specifieke redactionele ingrepen door de latere lezers (Gezelle en andere lezers die de brieven als redacteus voorbereidden voor taalkundige verwerking). Ook dergelijke ingrepen worden met <del> en <add> aangeduid, maar worden voorzien van een extra @hand attribuut. Daarin wordt verwezen naar de identificatiecode voor het handschrift in het <handNote> element in de header (zie sectie 3.1).
In dit voorbeeld heeft Gezelle (geïdentificeerd als persoon0905-hand) heel wat oorspronkelijke tekst uit de brief geschrapt, en ook enkele kleine woorden toegevoegd. Er is echter ook een grotere tekststructuur toegevoegd: een gedichtfragment (<lg>), dat bestaat uit verschillende regels (<l>). Omdat het TEI model bepaalt dat <add> en <del> slechts tekst en een beperkt aantal kleinere tekststructuren kunnen bevatten, wordt het bereik van deze toevoeging gemarkeerd tussen “lege” elementen, die enkel punten in de tekst markeren, zonder dat ze zelf inhoud bevatten. Het begin van die “grensoverschrijdende” toevoeging is gemarkeerd door het lege element <addSpan> (<delSpan> is het corresponderende element voor de markering van “grensoverschrijdende” schrappingen), dat via het @spanTo attribuut verwijst naar de markering van het einde van die toevoeging in een leeg <anchor> element. Hoewel niet strikt noodzakelijk, worden dergelijke “grensoverschrijdende” toevoegingen en schrappingen ook opgesplitst in verschillende <add> en <del> elementen, die onderling naar elkaars identificatiecodes verwijzen met @next en @prev attributen. Naast deze impliciete linking, wordt in een @corresp attribuut ook verwezen naar een gemeenschappelijke identificatiecode, waardoor de onderbroken groep rechtstreekser kan worden gereconstrueerd.
Een bijzonder type van secundaire toevoeging door Gezelle en andere lezers, zijn taalkundige notities. Die worden apart gemarkeerd in een <note> element, met een @type attribuut, dat de waarde "annotation" krijgt. Die noot bevat dan de toegevoegde tekst in <add>.
Het primaire karakter van brieven levert soms moeilijkheden op bij de transcriptie, die de editeur wil signaleren. Ook kan de editeur beslissen om op andere plaatsen in te grijpen in de tekst, om de leesbaarheid te bevorderen. TEI voorziet een aantal elementen om dat soort editeursingrepen duidelijk te identificeren. In de Gezellebrieven worden volgende editeursingrepen aangeduid:
Dergelijke ingrepen mogen vaak worden verwacht in combinatie met andere auteursingrepen: als een briefschrijver stukken tekst vervangt door andere, kan bijvoorbeeld de geschrapte tekst in <del> niet altijd met zekerheid (<unclear>) of helemaal niet (<gap>) worden getranscribeerd.
In de Gezellebrieven zijn registers aangelegd met meer informatie over verschillende soorten eigennamen. In de brieven wordt verwezen naar die registers, zodat die extra informatie in de editie kan worden getoond, en hun geregulariseerde vorm kan worden gebruikt voor zoekopdrachten in de editie. Voor al deze naamtypes gebeurt die identifcatie door in de brieven het eerste voorkomen van die naam aan te duiden met een <name> element, met een passende waarde voor het @type attribuut:
In een @key attribuut wordt verwezen naar de unieke identificatiecode van de betreffende naam in het register.
Annotaties door de editeur worden gecodeerd in een <note> element.
Binnen annotaties komen vaak verwijzingen voor. Die worden met het <ref> (reference) element aangeduid. In een @target attribuut wordt een formele bestemming voor die verwijzing gegeven. Dat kunnen externe URL’s zijn. In de annotaties van de Gezellebrieven worden voornamelijk twee geformaliseerde linktypes gebruikt:
De prefixen in deze geformaliseerde linktypes worden met behulp van de definities van zulke prefixen in <listPrefixDef> in het header gedeelte opgelost tot volledige URL’s. Zie sectie 3.2 voor een beschrijving van dit mechanisme.