[Home] [Research] [Projects] [Teaching] [Publications] [Curriculum Vitae]

...en doende denkt dan nog.
SGML, TEI en editiewetenschap

Edward Vanhoutte

evanhoutte@kantl.be
edward.vanhoutte@ua.ac.be

Like the publishing industry, the research community
has long realized that its stock in hand is not words on the page,
but information, independent of any particular physical realization.
-Lou Burnard-

1. Elektronische edities

De inhoud van een elektronische editie verschilt in weinig van die van een editie in hard-copy. Commentaar, apparaat en leestekst moeten ook in een elektronische editie te vinden zijn. Maar de inherente kwaliteit van de computer om met grote hoeveelheden data om te gaan zorgt ervoor dat het apparaat niet meer selectief hoeft te zijn, en dat de problemen van de commentaar die meestal voortkomen uit de financiële onmogelijkheid om voor alle groepen lezers een aangepaste papieren editie te publiceren –"bieden we nu een commentaar voor een academisch publiek aan, of voor een leespubliek, of sluiten we een compromis" (wat altijd kwaliteitsverlies betekent)– verleden tijd zijn. Tegelijkertijd vervagen ook de concepten diplomatische editie, leeseditie en historisch-kritische editie. Dit zijn alleen nog maar output-resultaten van een volledige elektronische editie.

Elektronische edities zijn de moeite waard om te hebben. Die moeite bestaat uit het investeren in data zodat de edities die wij maken en over enkele decennia deel zullen uitmaken van een virtuele of digitale bibliotheek, in een formaat zijn aangemaakt dat ze voor een lange tijd en voor een zo breed mogelijk publiek (her)bruikbaar maakt, onafhankelijk van hard- en software, maar zonder verlies van wetenschappelijke kwaliteit. Sperberg-McQueen 1994 spreekt in die zin van de "three fundamental requirements" waaraan een elektronische editie moet voldoen: "accessibility without needless technical barriers to use; longevity; and intellectual integrity." Ook de MLA Committee on Scholarly Editions ondersteunt in hun Guidelines for Electronic Scholarly editions (draft version) die drie requirements, maar zwakt ze (momenteel) een beetje af naar desiderata. [1]

Veruit de belangrijkste en meest cruciale beslissing bij het opzetten van een elektronische editie is de keuze van de encoding standaard: een internationaal geaccepteerd en ondersteunde norm die publiek gedefinieerd moet zijn en soft- en hardware onafhankelijk is. "If the norms are chosen correctly, the edition can be migrated easily to new hardware and software platforms, thus preserving the work that has gone into it." (MLA-CSE: GESE)

Software is dus geen goede basis om een e-editie op te bouwen, omdat het nooit alle gebruikstoepassingen ondersteunt, in het gebruik nooit gelijk gewaardeerd wordt door alle gebruikers en een te korte levenscyclus heeft (tussen de 5 en 10 jaar). Wat voor een problemen zou een op software gebaseerde e-editie van het kaliber van bijvoorbeeld papieren editieprojecten zoals Hans Zellers en Alfred Zächs Conrad Ferdinand Meyer. Sämtliche Werke. [2] waar al bijna veertig jaar aan gewerkt wordt, niet creëren? Het is te verwachten dat heel veel van de huidige softwarepakketten binnen veertig jaar niet meer gemaakt, bruikbaar of ondersteund zullen worden, tenzij in de kelder van één of andere informatica-archeoloog die nog een Pentium met Windows95 als besturingssysteem in zijn collectie heeft staan. Software is echter wel noodzakelijk voor de distributie en de bruikbaarheid van elektronische teksten, maar die teksten zelf, of de edities waar ze deel van uitmaken moeten geconcipieerd worden in abstracte termen met de kenmerken zoals hierboven aangehaald.

2. Markup

Voor een machine is een tekst een consecutieve opeenvolging van karakters (een spatie is ook een karakter) die in een bepaald formaat, afhankelijk van de gebruikte tekstverwerker wordt opgeslagen. Markup (alle additionele informatie die aan een tekst wordt toegevoegd) expliciteert voor de computer wat de menselijke lezer impliciet leest, en is dus noodzakelijk voor de creatie van een machine-readable tekst. Historisch gezien werd het woord markup gebruikt om annotaties of andere tekens binnen een tekst te benoemen die de scriptor, 'komponist' of typist duidelijk maakte hoe de tekst gedrukt, getypt of gelayout moest worden. Met de automatisering van het tekstbedrijf werd het woord overgenomen voor alle specifieke codering die het uitzicht van een tekst bepaalt. Elke tekstverwerker werkt met een markup-formaat dat alleen geldt voor dat bepaalde programma. Die markup (of encoding) is procedureel: het documenteert hoe een bepaalde tekst er op het scherm of op papier moet uitzien (soort en grootte van de font, vet, onderlijnd, cursief, paginagrootte, marges...). Het is dus prescriptief. Wat ik intyp (de tekst) en de informatie over hoe ik zou willen dat de tekst er uitziet (de markup) vormt een eenheid in tekstverwerkers, wat meteen verklaart waarom het soms moeilijk is om teksten tussen tekstverwerkers uit te wisselen zonder verlies aan informatie of zonder conversieproblemen. De laatste jaren hebben de fabrikanten van tekstverwerkingsprogramma's een antwoord op dit probleem gegeven door conversieprogramma's in hun software in te bouwen zodat het nu gemakkelijker is om, vb. Word en WordPerfect files met elkaar uit te wisselen. Maar nog altijd is succes bij het conversieproces niet gegarandeerd.

De vraag is nu of we genoegen nemen met een e-tekst waarin gedocumenteerd is hoe een tekst eruit moet ziet (prescriptief), en of het niet zinvoller en nuttiger is te documenteren wat er in die tekst staat (descriptief). Een voorbeeld:

Als ik de tekstverwerker gebruik om een zin visueel op te maken zodat de lezer een signaal krijgt wanneer het om een boektitel, een benadrukt woord of een woord in een andere taal gaat, schrijf ik bijvoorbeeld de volgende zin:

Die Leiden des jungen Werther is een ontiegelijk mooi boek vol Weltschmerz.

In Microsoft Word's RTF (Rich Text Format) code leest de computer deze zin ongeveer als volgt:

{\i Die Leiden des jungen Werther} is een {\i ontiegelijk} mooi boek vol {\i Weltschmerz}.

(De codes van WordPerfect kunnen zelfs niet in druk weergegeven worden omdat ze ge bruik maken van speciale computer controle codes die geen equivalente letters of symbolen hebben. Die codes worden gebruikt omdat ze zeker niet als inhoud van de zin verkeerd geïnterpreteerd zouden worden door de computer.

In het lay-outen van mijn tekst heb ik voor drie verschillende soorten informatie hetzelfde 'signaal' gebruikt: nl. cursief. De computer interpreteert het hierboven aangehaalde voorbeeld als volgt: '{\i' is een instructie om de modus 'cursief' aan te zetten en '}' zet het cursief af. Erg bruikbaar voor onderzoek is zo'n tekst niet. Als ik nu met een markup-systeem kan aangeven wat die informatie is en niet hoe ik die informatie gerepresenteerd wil zien, zou dat veel nuttiger zijn. Een computer kan dan gemakkelijk in een tekst op zoek gaan naar plaatsen waar titels van boeken voorkomen, een woord retorisch wordt benadrukt, of waar een vreemde taal wordt gebruikt, en daar operaties en berekeningen mee uitvoeren. Dat kan in het onderzoek veel tijd en fouten sparen. Zo'n markup kan er ongeveer zo uitzien:

<title>Die Leiden des jungen Werther</title> is een
<emph>ontiegelijk</emph> mooi boek vol <lang="duits">Weltschmerz</lang>

3. SGML

Een goede en betrouwbare encoding standaard is SGML: Standard Generalized Markup Language, in 1986 gepubliceerd als een ISO standaard (ISO 8879). [3] Als dusdanig is ze publiek gedefinieerd, exact en consistent gedocumenteerd, wordt ze door de ISO gecontroleerd, en wordt ze internationaal geaccepteerd en ondersteund onder de vorm van gesofistikeerde implementaties. SGML zelf is geen markup-taal of encoding scheme, maar een meta-taal die het mogelijk maakt om markup-talen te definiëren. Een markup-taal moet specifiëren welke markup toegestaan is, welke markup vereist is, hoe de markup onder scheiden wordt van de tekst en wat de markup betekent. SGML voorziet in middelen om de eerste drie te doen. De documentatie van de specifieke markup talen met SGML gecreëerd is nodig voor de laatste vereiste, zoals bijvoorbeeld in de TEI P3 Guidelines (zie infra). Omdat SGML bestaat uit een plain ASCII file, is het volledig onafhankelijk van soft- of hardware en kan het over alle netwerken verspreid worden. De kracht en de flexibiliteit van het mechanisme zorgt er o.a. voor dat dezelfde elektronische tekst voor verschillende doeleinden gebruikt kan worden.

SGML-beginners of mensen die toevallig het ISO 8879 document inkijken, worden dikwijls geïntimideerd door de schijnbare complexiteit van de standaard. Een volledige behandeling van SGML valt buiten het bestek van dit artikel [4], maar ik wil hier toch de 3 principes beschrijven waarop SGML gebouwd is.

3.1. SGML beschrijft de structuur van teksten

SGML is een standaard om teksten te beschrijven. Het werkt op het niveau van de menselijke kennis en niet op het niveau van computer processing. Een tekst met een SGML markup wordt gezien als een collectie objecten binnen een algemene structuur. Het hangt af van de ontwerper van een SGML document welke objecten z/hij wil coderen of taggen. Dat kan bijvoorbeeld titel, hoofdstuk, paragraaf, bladzijde, vers, strofe, lijn, act, scene, naam, citaat, lijst, datum... zijn maar dat kunnen ook analytische kenmerken zijn zoals woordklasse, of vormen van linguistische, historische of literaire interpretatie. Metadata of beschrijvende informatie over een tekst, zoals de fysieke conditie van een manuscript, de plaats van een annotatie op het manuscript of de kleur en vorm van een initiaal kunnen evengoed als SGML objecten gecodeerd worden. De titel van dit hoofdstuk kan er in SGML dus als volgt uitzien:

<div type="chapter">
<head>SGML beschrijft de structuur van teksten</head>

De sequentie <div type="chapter"> duidt aan dat een structurele eenheid hier begint en dat het type van deze eenheid 'chapter' is. De hele tekst van dit hoofdstuk volgt dan binnen dit 'div' element beginnend met de 'head'. De titel van dit hoofdstuk blijft 'head', in welke layout het ook wordt gepresenteerd. Zo laat SGML de preciese beschrijving toe van de intrinsieke structuur van teksten. Doordat de ontwerper van een SGML document zelf beslist over wat getagged wordt, is markup altijd de expressie van een interpretatie die discutabel is, maar het is alleen discutabel omdat het zo expliciet is. Niemand kan nog zeggen: Dat bedoelde ik niet.

3.2. SGML verklaart wat de structuur van een tekst moet zijn

SGML doet meer dan de structuur van teksten beschrijven. Door middel van een Document Type Definition (DTD) kan het de structuur van een tekst voorschrijven. Een tekst behoort volgens SGML tot een bepaald type. Dit type wordt bepaald door de samenstellende delen en hun structuur. De technische term voor een tekstuele eenheid die deel uitmaakt van die structuur is element. De betekenis van een element komt voort uit haar plaats in die structuur, i.e. uit de relatie met de andere elementen. In een formal element declaration in de DTD wordt de naam of Generic Identifier (GI) van een element vastgelegd, geven de mimimization rules aan of het element al dan niet afgebakend moet worden door een start- en een end-tag, en beschrijft een content model in welke context een element kan voorkomen. De minimization rule bestaat uit twee karakters (gescheiden door een witruimte), waarvan de eerste betrekking heeft op de start-tag en de tweede op de end-tag. Ofwel is dat karakter een liggend streepje '-' of een 'O'. Het liggend streepje betekent dat de tag vereist is, en de O betekent dat de tag kan weggelaten worden (O van 'optional' of 'ommissible'). We maken dit duidelijk met de beschrijving van een mogelijke DTD voor een arbitraire verzameling gedichten:

De DTD voor onze verzameling gedichten ziet er dus als volgt uit:

<!ELEMENT anthology	- -      (poem+)>
<!ELEMENT poem          - -      (title?, stanza+)>
<!ELEMENT title         - o      (#pcdata)>
<!ELEMENT stanza        - o      (line+)>
<!ELEMENT line          - o      (#pcdata)>

Het volgende is dus een voorbeeld van een geldige 'anhology' [6]:

<anthology>
	<poem>
		<title>Bewegen 6
		<stanza>
			<line>koel is de wereld
			<line>de kevers van het ongeluk
			<line>wandelen in mijn gezicht
		<stanza>
			<line>mijn oog is helderwit
			<line>de koekoek legt een angstei
			<line>in mijn armen
		<stanza>
			<line>het werkwoord dromen
		<stanza>
			<line>en ik die slaap noch waak
			<line>die weef noch maai
		<stanza>
			<line>ik ben een gezwollen zang
			<line>en gebarsten is mijn waterkeel
	</poem>
		<!-- meer gedichten	-->
</anthology>

Een attribute bij een element kan verdere informatie aan dat element geven en wordt in een ATTLIST in de DTD verklaard. Een eenvoudig voorbeeld is:

<stanza n="2">...tekst van de strofe...

Waarbij aangegeven wordt dat dit de tweede strofe van een gedicht is. Attributes kunnen ook gebruikt worden om indexen te controleren:

<name type=personal normal="ClausH">Hugo Claus

De naam Hugo Claus kan dan onder ClausH in een index van persoonsnamen terechtkomen.

In SGML moet elk document met een DTD verbonden zijn. Door een DTD te definiëren wordt voor een deel tegemoet gekomen aan het nadeel van de verbositeit die eigen is aan een SGML markup-taal (in het voorbeeld hierboven kunnen de end-tags van <title>, <stanza> en <line> weggelaten worden omdat de DTD expliciteert waar die eindigen). De DTD wordt door een SGML parser gebruikt om de aangebrachte markup van de bijhorende e-tekst te valideren, en SGML-gevoelige software kan gebruik maken van de structurele informatie die in de DTD beschreven wordt om zich intelligent te gedragen. Een intelligente SGML editor zal op basis van de DTD bijvoorbeeld de gebruiker die markup aanbrengt op een tekst alleen die tags voorstellen die op dat punt in de tekst geldig zijn.

3.3. SGML laat geen informatie verloren gaan

De platform- en software-onafhankelijkheid van SGML werd in de twee vorige hoofdstukjes op een abstract vlak verzekerd. Dit derde principe past die vereiste toe op het niveau van de reeks bytes (karakters) waaruit een tekst bestaat en heet het entity reference scheme: elk karakter of reeks karakters kan een naam krijgen (entity) en waar je wil kan je dit karakter of deze reeks in het document voegen door die naam in te voegen (entity reference) of: een bepaalde reeks karakters kan door een andere reeks karakters gesubstitueerd worden wanneer het gewenst is. Dit principe is bijvoorbeeld van groot nut bij het transcriberen van primaire bronnen waarin karakters staan die afwijken van de standaard karakter sets. Een auteur kan bijvoorbeeld de gewoonte hebben om het woord 'niet' te schrijven als 'nt' met een superscript krulletje boven de letters. Als editeur wil ik dit weergeven in de transcriptie op het scherm of in druk, maar mijn computer-systeem heeft die mogelijkheid niet. Ik kan het gebruik van het krulletje in het bijvoorbeeld als volgt opnemen:

n&sup-krul;t

De reeks '&sup-krul;' is de entity reference, De '&' duidt het begin van de entity aan, en de kommapunt ';' sluit die af. Ergens anders in het SGML systeem kan ik exact definiëren wat de entity 'sup-krul' is waaraan hier gerefereerd wordt. Ik kan als volgt aanduiden dat de entity een afkorting is voor 'ie':

<!ENTITY sup-krul 'ie'>

In dit geval kan de processor de entity reference &sup-krul; vervangen door 'ie' als:

niet

Of ik kan het bijvoorbeeld laten vervangen door een langere reeks die een SGML tag bevat, bijvoorbeeld de tag voor 'expansie van een afkorting' waarmee ik ook meteen expliciteer wat het is:

<!ENTITY sup-krul '<expan>ie</expan>'>
Wat resulteert in: 
n<expan>ie</expan>t

De processor kan dan bijvoorbeeld geïnstrueerd worden om alle expansies van afkortingen in cursief weer te geven:

niet

Als ik de file naar een systeem overbreng dat dat superscript krulletje bijvoorbeeld wel kan weergeven, kan ik de entity reference laten vervangen door een welbepaalde bitmap karakter uit een eigen fontlijst.

Maar neem nu het (weinig waarschijnlijke) geval waarin uit later onderzoek blijkt dat die bepaalde auteur dat krulletje niet gebruikt als afkorting voor 'ie' maar voor 'ooi', zodat er niet 'niet' moet gelezen worden, maar 'nooit', dan kan de hele editie snel bijgewerkt worden door één simpele ingreep:

<!ENTITY sup-krul <expan>ie</expan>'>

wordt vervangen door:

<!ENTITY sup-krul '<expan>ooi
</expan>'>

Er staat daarenboven geen limiet op de omvang van de reeks karakters die door een entity reference worden weergegeven -en dus is ze heel bruikbaar voor het weergeven van boiler-plate tekst [7]-: het kan een hele file zijn, een image file of in sommige gevallen zelfs een collectie files.

4. SGML in de industriële en de academische wereld

De industrie heeft de economische en operationele voordelen van een structurele en beschrijvende markup van documenten al ingezien en maakt intensief gebruik van SGML voor data-transmissie en procedurele operaties. De grootste uitgeverijen van de wereld, waaronder IBM, Kluwer en Elsevier maken gebruik van SGML, en ook andere industrieën zoals bijvoorbeeld de farmaceutische, de software-, de luchtvaart- (vb. Boeing), de automobiel- en de defensie-industrie. Het is dan tegenwoordig ook niet uitzonderlijk meer om 'kennis van SGML vereist' in de vacaturebijlage van de krant te zien staan.

In de academische wereld zijn er m.b.t. SGML twee belangrijke dingen gebeurd: ten eerste de doorbraak en uitbouw van het World Wide Web (WWW) en ten tweede het werk van het Text Encoding Initiative (TEI).

4.1. WWW, HTML, XML

Het WWW is gebaseerd op een serie protocollen en technieken waaronder HTML (Hyper Text Markup Language). HTML is de markup-taal die gebruikt wordt om websites te bouwen die door een browser zoals Mosaic, Internet Explorer of Netscape Navigator gelezen kunnen worden, en is specifiek layout-gericht. HTML is gedeclareerd als een SGML DTD, en is de meest gebruikte applicatie van SGML. Nieuwere versies van HTML tonen meer en meer pure SGML kenmerken, en XML (eXtensible Markup Language) die over enkele jaren dé norm op het WWW zal zijn, is nog meer op de SGML-norm gebaseerd en is dan ook een veel krachtiger taal dan HTML.

4.2. TEI en P3

Het TEI publiceerde in 1994 (in druk en elektronisch) de P3 Guidelines for Electronic Text Encoding and Interchange: twee volumes van samen 1290 bladzijden waarin het gebruik van SGML wordt aanbevolen en waarin een hele reeks aan DTD-fragmenten worden beschreven die gecombineerd kunnen worden om elektronische teksten aan te maken en te analyseren. Met dit werk komt het TEI tegemoet aan de vierde vereiste (zie hfst. 3) die aan een markup-taal wordt gesteld: ze documenteert wat de markup-talen betekenen.

Het TEI werd in 1987 gesticht met de specifieke opdracht om een standaardformaat te ontwikkelen voor de uitwisseling van machine-readable teksten en om specifieke aanbeve lingen te doen voor de aanmaak en markup van elektronische teksten. [8] Het werk van verschillende werkgroepen bestaande uit experten uit bepaalde domeinen resulteerde in 1990 in de eerste versie van de Guidelines (P1 voor 'proposal one'): 280 A4-bladzijden. De P3 betekent de definitieve Guidelines en is, mede door een uitbreiding van de werkgroepen (waaronder 'textual criticism', hypertekst en hypermedia, transcriptie van manuscripten, drama, poëzie en literair proza), de eerste poging sinds de uitvinding van de computer om een alle-doelen-dienend schema op te stellen voor de representatie van elektronische teksten voor onderzoek, dat ten eerste poogt een registratie te zijn van een consensus van de hele gemeenschap van geïnteresseerde researchers, ten tweede alle types van teksten in alle talen en schriften en uit alle periodes in de aanbevelingen wil betrekken, ten derde alle types van onderzoek wil ondersteunen en dat ten vierde tot een goed einde werd gebracht zonder voortijdig afgebroken te worden (Sperberg-McQueen 1994). Heel vroeg in het werkproces van het TEI werd er besloten dat SGML de basis van het nieuwe encoding schema zou worden. Dat impliceert dat TEI markup gebruikt kan worden met alle SGML-gevoelige software. De DTD's voorgesteld door het TEI zijn vrij verkrijgbaar op het WWW, alsook de Guidelines. TEI-conforme documenten kunnen met SGML-editors (zowel public-domain software als commerciële pakketten) gemaakt en aangepast worden. SGML-processing tools, SGML-layout tools, SGML-delivery tools en -browsers (weerom zowel public domain als commerciële pakketten) kunnen gebruikt worden om TEI documenten respectievelijk te verwerken, te verspreiden op papier en in elektronische vorm.

5. Het TEI schema

5.1. De pizza

Omdat TEI een SGML applicatie is, heeft een TEI conform document een DTD nodig. Het TEI stelt niet één DTD voor, maar voorziet in een beschrijving van DTD-fragmenten die als bouwstenen kunnen fungeren maar met bepaalde restricties die de uitwisselbaarheid van documenten garandeert. Er werd voor deze doe-het-zelf opzet gekozen vanuit de filosofie dat de structuur van het document eerder de DTD voorschrijft dan andersom. Het TEI schema wordt door Burnard 1995 het "Chicago Pizza model" genoemd: "All pizza's have some ingredients in common (cheese and tomato sauce); in Chicago, at least, they may have entirely different forms of pastry base, with which (universally) the consumer is expected to make his or her own selection of toppings." De ingrediënten van de TEI pizza noemen we tag sets en zijn een collectie van definities voor SGML elementen en hun attributes. De TEI DTD bestaat altijd uit een core tag set (de cheese and tomato sauce) een base tag set (de bodem) en additional en auxiliary tag sets (de toppings).

  1. De core tag sets definiëren elementen die in alle documenten nodig zijn, en is dus per default voorhanden.
  2. De base tag sets definiëren de structurele basiscomponenten van een document. Er is maar één keuze toegelaten, en momenteel heeft het TEI sets voor proza, poëzie, drama, getranscribeerde spraak, woordenboeken en terminologische databases.
  3. Additional tag sets mogen in alle klassen van documenten voorkomen, maar definiëren elementensets die voor gespecialiseerde toepassingen, zoals: physical transcription, textual criticism, names and dates, graphs and trees, figures and tables, language corpora... Ze kunnen naar believen gecombineerd worden.
  4. Auxiliary tag sets bevatten elementen met erg gespecialiseerde functies en concipiëren een eigen DTD onafhankelijk van de hoofd-DTD.

5.2. de TEI-header

Een TEI-conform document onderscheidt zich van een gewoon SGML document door de aanwezigheid van een header die door de core tag sets wordt opgelegd. The TEI-header is de eerste poging om documentatie over een elektronische tekst in-file vast te leggen zodat het door dezelfde software behandeld kan worden die ook de tekst behandelt. De header moet metadata bevatten die van belang zijn voor bibliothecarissen die de elektronische tekst willen catalogiseren en voor wetenschappers die met het document willen werken. De header bestaat uit vier delen waarvan de eerste in elke header moet voorkomen en de drie andere delen optioneel zijn.

  1. De file description <filedesc> bevat volledige bibliografische informatie over het document, waaronder informatie over de bronnen waarvan het elektronische document is afgeleid, en kan gemakkelijk vertaald worden naar een conventionele catalogus record. [9]
  2. De encoding description <encdesc> documenteert de principes die gebruikt werden bij de transcriptie van de tekst.
  3. De profile description <profiledesc> bevat een gedetailleerde beschrijving van alle niet-bibliografische aspecten van een tekst, in het bijzonder de gebruikte talen en sub-talen, de situatie waarin de tekst van het document geproduceerd werd, de deelnemers (van belang bij transcriptie van spraak), topics of classificatie van het document, demografische of sociale karakteristieken van de auteurs... "No-one is likeley to need all of these categories of information, but all of them are likely to be essential to some users." (Burnard 1995)
  4. In de revision description <revisiondesc> wordt bijgehouden wie een verandering op de tekst aanbracht en wanneer.

Een geldige TEI-header voor de transcriptie van de eerste druk van Een huis dat tussen nacht en morgen staat van Hugo Claus ziet er zo uit:

<!doctype tei.2 public "-//TEI//DTD TEI Lite 1.0//EN" "TEILITE.DTD">
<tei.2>
<teiheader>
	<filedesc>
		<titlestmt>
			<title>The foundations of the house: A machine-
			readable transcription of Een huis dat tussen
			nacht en morgen staat, first draft 1953</title>
			<author>Hugo Claus</author>
			<principal>Edward Vanhoutte</principal>
		</titlestmt>
		<publicationstmt>
			<availability status="RESTRICTED">
				<p>Not to be distributed outside the project</p>
			</availability>
			<authority>
				<name>Edward Vanhoutte</name>
			</authority>
		</publicationstmt>
		<sourcedesc>
			<bibl>Hugo Claus, Een huis dat tussen nacht en morgen
			staat. Gedichten. Antwerpen/'s-Gravenhage: De
			Sikkel/Daamen N.V., 1953</bibl>
		</sourcedesc>
	</filedesc>
</teiheader>

5.3. de tekst

De tekst in een TEI-conform document bestaat uit een optioneel front <front> deel, gevolgd door de body <body> en een optioneel back <back> deel. Het TEI past het scheermes van Ockham toe in de behandeling van de onderverdelingen van de tekst. In plaats van voor elke onderverdeling een aparte tag te voorzien, werkt TEI met het <div> element dat een attribute bij zich heeft waarin het type van onderverdeling gespecifieerd wordt (een <div> kan genummerd worden waar dat nodig is). In een prozatekst zal een <div> één of meerdere paragrafen <p>bevatten, in een poëzie-tekst één of meerdere lijnen <l> al dan niet gegroepeerd in lijngroepen <lg>, en in drama paragrafen of lijnen, afhankelijk van de aard van de tekst.

6. TEI en teksteditie[10]

In zijn essay Text-editing and the computer: Facts and Values doorprikt Ian Small de illusie als zou de computer objectieve edities kunnen voortbrengen. De waarde-oordelen en de selecties van de editeur blijven ook in een elektonisch editie een rol spelen "So the reader accessing the computer is in no sense being presented with a value-neutral or 'objective' body of information." Vooralsnog kan de computer dit menselijk oordelen, dat menselijk toekennen van waarden niet overnemen. En Small concludeert dan ook dat "the computer clearly cannot operate as a substitute for the text-editor." Ik spreek dat geenszins tegen, maar waar de computer in Smalls visie het menselijk interpretatieve component verduistert, expliciteert het TEI encoding scheme die beslissingen. Het TEI voorziet immers in een serie tags voor een hele reeks aan tekstkritische problemen: o.a. de encoding van een kritisch apparaat, de registratie van varianten en fysieke schade aan de getuigen, de indicatie van onzekere lezingen, de mogelijkheid om elk deel van een tekst te associëren met een al dan niet complexe annotatie...[11]

In de TEI voorstellen voor editiewetenschap kunnen vier soorten tags onderscheiden worden: tags voor apparatus entries, tags voor editeurscommentaar bij de transcriptie van primaire bronnen, tags voor annotatie en tags voor het linken van het apparaat met de tekst.

6.1. apparatus entries

De <app> tag groepeert alle variante lezingen die in het apparaat worden weergegeven. Editeurs die met een basistekst werken, kunnen hun lemma afbakenen met de <lem> tag. Wie geen basistekst wil voorstellen gebruikt alleen <rdg> tags (voor readings). De attributes orthographic en substantive bij <rdg> typeren de variant. De autorisatie van de tekst kan gedocumenteerd worden met de <hand> tag en de verantwoordelijkheid voor een bepaalde transcriptie of editeursopmerking kan met de <resp> tag vastgelegd worden. De sigla van de getuigen worden met behulp van een <wit> tag geëxpliciteerd.

	<app>
	    <lem wit="d1">paradedegen</lem>
	    <rdg wit="m1" type="orthographic">paraden-degen</rdg>
	    <rdg wit="m2" type="orthographic">parade degen</rdg>
	</app>
	<app>
	    <lem wit="d1">het bovenkleed</lem>
	    <rdg wit="m1" type="substantive">den rok</rdg>
	    <rdg wit="m2" type="substantive">het kleedsel</rdg>
	</app>

In een <witlist> worden alle getuigen <wit> opgenomen eventueel met een beschrijving van een enkele bron of van meerdere bronnen die door één sigle worden genoemd.

	<witlist>
	   <witness sigle="m1">AMVC S725, 4825</witness>
           <witness sigle="m2">AMVC S725, 4825</witness>
	   <witness sigle="d1">exemplaar uit de Centrale Bibliotheek KuLeuven,
	   5A60030 <bibl><author>August Snieders</author><title>Anne
	   Dieu-le- Veut. Een verhaal uit de XVIIe eeuw.</title> Antwerpen, J.P. Van
	   Dieren, 1877.</bib></witness>
	</witlist>

Verdere gegevens omtrent een bepaalde lezing kunnen met de <witdetail> tag en een identifier die de leesplaats aanduidt waar ook in de tekst worden opgenomen. Er zijn ook tags voor de beschrijving van fragmentaire bronnen enz.

6.2. editeurscommentaar bij transcriptie van primaire bronnen

Alle mogelijke commentaar over het fysieke voorkomen van de primaire bronnen kan in de transcriptie gedocumenteerd worden met een reeks tags. Ik geef een paar voorbeelden:

6.3. annotatie

De P3 stelt verschillende methodes voor om een tekst te annoteren met gestructureerde of free-form annotaties (<note>). De <span> tag kan gebruikt worden om een deel van de tekst te associëren met een bepaalde interpretatie...

6.4. linken van het apparaat met de tekst

Welk systeem er gebruikt wordt (er zijn er drie in de P3) hangt af van de beslissingen die de editeur genomen heeft over de inrichting van de editie. De location-referenced method kan zowel met een extern als met een in-line apparaat gebruikt worden en wordt in de basistekst vastgelegd. De double end-point-attached method kan ook met zowel een in-line als een extern apparaat gebruik worden, maar wordt op een aparte plaats (binnen of buiten het document met de basistekst) vastgelegd. De parallel segmentation method tenslotte kan alleen gebruikt worden wanneer er geen basistekst-concept is en alleen met een in-line apparaat. Voor de verdere documentatie van de linking-systemen verwijs ik naar hfst. 19.2 van de P3.

7. De moeite waard?

Aan het begin van dit artikel heb ik betoogd dat elektronische edities de moeite waard zijn om te hebben en dat die moeite bestaat uit het investeren in data. Een elektronische editie maakt men niet op één dag, zoals men ook een papieren editie niet op één dag maakt. Is het dan niet de verantwoordelijkheid van de editiewetenschap om, in een wetenschappelijk terrein dat het met beduidend minder centen moet doen dan haar zusterwetenschappen, edities in een zodanige vorm aan te maken dat ze ook nog als wetenschappelijk voer kunnen dienen voor de toekomst. Een editie is altijd -volgens de betrokken editeur dan toch- de beste editie op het ogenblik van het verschijnen. Een elektronische tekst kan nu eenmaal eindeloos verrijkt worden met lagen van interpretaties en annotaties, een proces dat jaren kan voortgaan. Het resultaat is een tekst die op elk moment van haar bestaan compleet is, maar die eindeloos kan uitgebreid worden, een principe waarop ook de beste wetenschappelijke bibliotheken gebouwd zijn. Het functionele zit hem ook hierin dat aan de elektronische versie de opdracht kan gegeven worden om elke laag te tonen of te verbergen "so that the visual representation of the text can mirror our changing focus of interest as we study it." (Burnard 1995)

Als we de principes van software- en hardware onafhankelijkheid door het gebruik van een formaat wat gedocumenteerd is, publiek gedefinieerd en gedeclareerd is naast ons neerleggen, zullen we edities maken die niet in de toekomst gebruikt kunnen worden. Als we die principes echter huldigen door het gebruik van SGML TEI, creëren we niet alleen edities die langer zullen dienen dan de computers op ons bureau (eigenlijk zolang er computers bestaan), maar verzekeren we ook de uitwisselbaarheid en verspreiding van ons wetenschappelijk werk bij zowel een lees- als een academisch publiek door gebruik te maken van methodes om verschillende visies op hetzelfde materiaal te documenteren en te demonstreren.

Edities blijven maken in een formaat dat elke overdrachts- of preservatieve functie, eigen aan de teksteditie, in de weg staat betekent intellectuele oneerlijkheid op wetenschappelijk niveau.

Literatuur

Noten

© Edward Vanhoutte, 3 december 1997.
A previous version of this text is also published in: Edward Vanhoutte & Dirk Van Hulle (red.), Editiewetenschap <!--in de praktijk-->. Antwerpen: Genese, 1998, p. 107-133.

XHTML auteur: Edward Vanhoutte
Last revision: 26/03/2001

[Home] [Research] [Projects] [Teaching] [Publications] [Curriculum Vitae]