geneticTEI.xml
<?xml version="1.0" encoding="UTF-8"?>
<TEI xmlns="http://www.tei-c.org/ns/1.0" xmlns:rng="http://relaxng.org/ns/structure/1.0"
xmlns:ge="http://www.tei-c.org/ns/geneticEditions">
<teiHeader>
<fileDesc>
<titleStmt>
<title type="main">An Encoding Model for Genetic Editions</title>
<author>Lou Burnard, Fotis Jannidis, Elena Pierazzo, Malte Rehbein</author>
</titleStmt>
<editionStmt>
<edition n="3">Revised Draft</edition>
</editionStmt>
<publicationStmt>
<authority>TEI MS SIG, Genetic Edition Workgroup</authority>
</publicationStmt>
<sourceDesc>
<p>Born Digital</p>
</sourceDesc>
</fileDesc>
<revisionDesc>
<change when="2010-10-03">
<name>Syd Bauman</name>
<desc>Typos</desc>
</change>
<change when="2010-04-05">
<name>Gregor Middell</name>
<date>5 April 2010</date>
<desc>Extended theoretical part; writing acts vs. textual stages</desc>
</change>
<change when="2010-04-03">
<name>Gregor Middell</name>
<date>3 April 2010</date>
<desc>Reworked chapter "The dossier level"; added graph-based encoding of genetic
aspects</desc>
</change>
<change when="2010-04-03">
<name>Gregor Middell</name>
<date>3 April 2010</date>
<desc>Chapter "Revision campaigns" revamped; added examples/ updated schema</desc>
</change>
<change when="2010-04-02">
<name>Moritz Wissenbach</name>
<date>2 April 2010</date>
<desc>Chapter "Revision campaigns" extended</desc>
</change>
<change when="2010-04-01">
<name>Gregor Middell</name>
<date>1 April 2010</date>
<desc>updated schema</desc>
</change>
<change when="2010-04-01">
<name>Gregor Middell</name>
<date>1 April 2010</date>
<desc>Extracted examples into separate files, added test suite</desc>
</change>
<change when="2010-04-01">
<name>Malte Rehbein</name>
<date>1 April 2010</date>
<desc>Chapter Undoing alterations extended</desc>
</change>
<change when="2010-03-11">
<name>Elena Pierazzo</name>
<date>11-03-2010</date>
<desc>Implementation of the decisions made 25/26 of February</desc>
</change>
<change when="2009-09-10">
<name>Lou Burnard</name>
<date>28-30 Oct 09</date>
<desc>Further revision campaign</desc>
</change>
<change when="2009-09-10">
<name>Lou Burnard</name>
<date>9-11 Sept 09</date>
<desc>Further revision campaign</desc>
</change>
<change when="2009-08-28">
<name>Lou Burnard</name>
<date>27-28 Aug 09</date>
<desc>Major revisions after discussion with Elena</desc>
</change>
<change>
<name>Elena Pierazzo</name>
<date>08 May 2009</date>
<desc>Conversion from MS Word</desc>
</change>
<change>
<name>Elena Pierazzo</name>
<date>01 August 2009</date>
<desc>Major update following Paris' Workshop</desc>
</change>
</revisionDesc>
</teiHeader>
<text>
<front>
<divGen type="toc"/>
<pb/>
<div>
<head>About this Document</head>
<p>This document describes a <hi rend="bold">draft</hi> encoding model for Genetic
Editions and Genetic Editing. The document is the product of a Workgroup on Genetic
Editions (chair: Fotis Jannidis), which is part of the TEI MS SIG (chairs: Elena
Pierazzo, Malte Rehbein, Amanda Galley). </p>
<p>The workgroup's goal was to develop an Application Profile for the encoding of
genetic editions and, in general, genetic phenomena. It is expressed as a TEI P5
conformant customization, integrating material from the existing TEI Guidelines,
chiefly Chapter 11. <title>Representation of Primary Sources</title> and Chapter 12.
<title>Critical Apparatus</title>, together with additional new material. It may
eventually, at the end of the process described in the following section, constitute
a free-standing new chapter of the <title>Guidelines</title> or remain a set of
recommendations for how to customize the Guidelines, but that is a decision for the
TEI Council.</p>
<p>The document reflects discussions held at a number of different meetings:</p>
<list>
<item>MS SIG meeting held in London during the annual members’ TEI meeting (November
2008); the minutes of the meeting can be found here: <ptr
target="http://wiki.tei-c.org/index.php/Minutes_London_2008"/>.</item>
<item>Genetic Edition workgroup held in London (March 2009); minutes can be found
here: <ptr target="http://wiki.tei-c.org/index.php/Minutes_London_03-2009"/>. </item>
<item>Workshop "Genetic Editions in a Digital Framework", held in Paris, 14/15 May
2009, and following discussion; programme of the workshop can be found here: <ptr
target="http://wiki.tei-c.org/index.php/GeneticEditionsWorkshopParis"/></item>
<item>Genetic Edition workgroup held in Würzburg (September 2009)</item>
</list>
<p>The document was subsequently extensively revised by Elena Pierazzo and Lou Burnard, for
presentation at a panel held at the Annual TEI Members Meeting in November
2009; at a
Genetic Edition workgroup held in Oxford (February
2010); at a Genetic Edition workgroup held in Würzburg
(March 2010); and finally in Oxford in April of the
same year for
presentation to the TEI Council meeting in Dublin.</p>
<p>The work group was initially inspired by HMNL, the
<soCalled>HyperNietzsche Markup
Language</soCalled> and following versions (<title>GML Genetic Markup
Language</title>) produced by Paolo D'Iorio and colleagues from the HyperNietzsche
project. We would like to thank Paolo D'Iorio for his invaluable contribution in the
early stages of the work. </p>
<p>Major contributors to this document, in addition to those already
cited, include Gregor Middel and Moritz Wissenbach, from the
Faustprojekt at the University of Wuerzburg. </p>
<div>
<head>Work Plan</head>
<p>The planned evolution of this document and the encoding model it describes may be
summarized as follows:</p>
<list>
<item>Initially, we worked on a pseudo-encoding model, expressed using our own
terminology. This stage was completed by July 2009. <!-- reference ? --></item>
<item>This pseudo-encoding model was re-expressed using the TEI P5 encoding
framework and revised extensively. </item>
<item>The same step-by-step approach will be taken for the standardisation
process: <list>
<item>First we develop an application profile, that is, a well-documented
TEI customisation.</item>
<item>This will be presented to the TEI Council as a proposed modification
of the TEI</item>
<item>If the TEI Council approves it, the Council will decide how it should
be integrated into the current <title>Guidelines</title>.</item>
</list></item>
</list>
<p>This draft document is publicly available for discussion and feedback from the
community. The document source is maintained in the TEI subversion repository at
<ptr target="http://tei.svn.sourceforge.net/viewvc/tei/trunk/genetic/"/>;
background information about the development of the proposals and associated
materials, is hosted on the TEI Wiki at <ptr
target="http://wiki.tei-c.org/index.php/Category:Genetic_Editions"/>. </p>
</div>
<div>
<head>Conventions used</head>
<p>Although the entire document is a draft and therefore susceptible of changes, some
sections are less stable than others. In particular, when a section or a
particular element requires further discussion or is considered an open problem,
such a section or element is marked by a * mark.</p>
<p>As required for TEI conformance, non-TEI elements are defined in a distinct
non-TEI namespace. In the usage examples and throughout this document that
namespace is mapped to the prefix <hi rend="bold">ge:</hi>, while TEI elements are
not marked by any namespace prefix.</p>
</div>
</div>
</front>
<body>
<div>
<head>Theoretical Framework</head>
<p>The genetic approach differs from other approaches to the study of texts because it
aims not only to identify <q>what is on the page</q>, but also to reconstruct the
<emph rend="bold">process</emph> necessary to produce <q>what is on the
page</q>.</p>
<p>The encoding model for Genetic Editing must therefore handle:- <list>
<item>Genetic <term>transcription</term> of a single document in such a way as to
trace its evolution; </item>
<item>Genetic <term>reconstruction</term>: that is, creation of a <term>Genetic
Dossier</term> assembling multiple related documents, and description of the
genetic relations amongst them;</item>
<item>Genetic <term>editing</term>, the goal of which is preparation of a
<term>Genetic Edition</term> whether derived from a single or multiple
witnesses.</item>
</list> A Genetic Edition may be prepared by producing a full transcription of all
extant witnesses, or by combining a full transcription of only one document (a
<term>base-text</term>) with information derived from other witnesses by means of
automatic collation.</p>
<p>Because our model aims to be independent of presuppositions associated with any
particular theoretical framework, we begin by reviewing some typical dichotomies in
editorial theory.</p>
<div xml:id="deutung">
<head>Fact vs. Interpretation</head>
<p>In German editorial theory there is a well known opposition between what is there
in the source document, the <term>record</term> (<foreign xml:lang="deu" rend="it"
>Befund</foreign>), and the interpretation of this phenomenon (<foreign
xml:lang="deu" rend="it">Deutung</foreign>). This opposition implies that there
is a way to talk about the record without any interpretation. Yet at some possibly
simplistic level, everything we say about a text is based on interpretation,
particularly in the realm of genetic criticism.<note place="foot">See also the
TEI’s (implicit) position on this point: <q>we define markup, or (synonymously)
encoding, as any means of making explicit an <hi rend="italic"
>interpretation</hi> of a text</q> (TEI Guidelines: <ref
target="http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SG.html">v. A
Gentle Introduction to XML</ref>). See also reference to Robinson and
Solopova 1993/1997: 21: <q>Any primary textual source… has its own semiotic
system within it.[…] The two semiotic system are materially distinct, in
that text written by hand is not the same as the text on the computer
screen</q>.</note> At the same time, there is an obvious difference between
the interpretation that some trace of ink is indeed a specific letter and the
assumption that a change in one line of a manuscript must have been made at the
same time as a change in another line because their effects are textually related
(for example, the first change was to a rhyming word, which necessitated the
second change). Therefore we propose to talk about differing <term>levels</term>
of interpretation, thus differentiating between <soCalled>what’s there</soCalled>
(document/fact) and <soCalled>how does it relate</soCalled>
(text/interpretation).</p>
</div>
<div>
<head>Status vs. Process</head>
<p>When a scholar examines a written text, especially a manuscript, the object of the
investigation is usually to discover the final result of that writing and
rewriting process. The examination can take various forms: it can be approached
from a codicological or documentary point of view, <soCalled>photographing</soCalled> the resulting
product, from a textual point of view, or from a genetic point of view, by trying
to describe the flow of authoring.</p>
<p>The present proposal addresses both approaches: sections <ptr target="#document"/>
and <ptr target="#alterations"/> are presented from
the codicological or documentary point of view,
while the other sections investigate the process of writing and re-writing of the
text, thus constituting the purely genetic parts of the present proposal.</p>
</div>
<div>
<head>Document vs. Text</head>
<p>In Manuscript Studies (Editing, Codicology, Palaeography, Art History, History)
the first level of enquiry is always the document, the physical support that lies
in front of the scholar’s eyes. </p>
<p>To understand the text that is contained in the manuscript, a deep study of the
manuscript itself is fundamental: the layout, the type of script, the type of
support, the binding, and many other aspects are able to tell us about
when, where, and why this particular text was composed. The text however
represents a different level of enquiry: it is a construct, derived from the
reading of the documents.</p>
<p>In the case of modern draft manuscripts scholars must give detailed consideration
to the layout, the different stratifications of writing and the disposition of
these in the physical space; all of these, together with an understanding of the
text, are required to gain insight about the composition, time of revisions, and
flow (<foreign xml:lang="fr">flux</foreign>) of the text. Furthermore, in some
cases, we know that the kind of physical support used to record it not only
influences but may also actually determine the text itself. For instance, the
content and the length of letters are often determined by the size and quantity of
the paper available to the writer; even more so for items such as postcards. </p>
<p>The TEI has traditionally prioritised the text level. Of the two possible views
available to someone transcribing a primary source (text and document), the TEI
privileges the text (hence <hi rend="italic">Text</hi> Encoding Initiative). Such
physical or topographical information as a typical TEI encoding provides is
subordinate to the main structural encoding, whether because it is represented by
empty elements (<gi>pb/</gi>, <gi>lb/</gi>, <gi>cb/</gi>) or attributes (<gi>add
place=""</gi>, <gi>note place=""</gi>, or <att>rend</att>). The TEI thus
reflects the not uncommon view that, while relevant, documents are somehow less
relevant than the texts they embody; to use a bibliographical metaphor, texts are
<soCalled>substantial</soCalled> while documents are
<soCalled>accidental</soCalled>. </p>
<p>However, for genetic editions, a focus on the document is crucial. In
many cases, the only way to reconstruct the process of writing and re-writing
which leads to a new text is to examine a specific document. We therefore propose
to complement the existing text-focussed approach with a new encoding scheme
focussed instead on the document.</p>
<p>We should then clarify the way we will use the following words:</p>
<list>
<item><label>Document</label> the physical object, the manuscript or other primary
source, comprising one or more written surfaces</item>
<item><label>Text</label> the intellectual content of the document, the words
written in their logical (non physical) sequence</item>
<item><label>Facsimile</label> a surrogate representation (not necessarily
digital) of the document (a photograph, a microfilm, a digital image)</item>
<item><label>Document level</label> transcription of the content of a document
according to its physical layout</item>
<item><label>Text level</label> transcription of the content of a document
according to its logical, semantic meaning </item>
</list>
</div>
<div xml:id="act_vs_state">
<head>Writing Acts vs. Text Stages</head>
<p>As noted in the previous section, the focus on purely
documentary aspects in a genetic edition often serves to reconstruct the writing
process, which in turn enables allow the editor to justify a genetic analysis,
for example to identify which text passage has been altered first or which textual variant predates
another. The encoding of the writing process, it
must be observed, is not simply a different point of
view about the text in hand, but rather regards as a
relevant a set of
information fundamentally different from that
captured by a purely textual encoding.</p>
<p>When talking about alterations on a textual level,
it is
the <emph>stages</emph> of the text which vare of major
interest. These stages are the results of various alterations
applied to the draft; each addition, deletion, substitution etc. is viewed from the perspective
of the possibly new text state it yields. For example the following substitution is
well-defined from this perspective:</p>
<egXML xmlns="http://www.tei-c.org/ns/Examples">
<subst>
<del>landscape</del>
<add>scenery</add>
</subst>
</egXML>
<p>When considering the writing process however, a
number of different possible writing acts can
be imagined leading to the same change of state. For
example: <egXML
xmlns="http://www.tei-c.org/ns/Examples">
<p>
<del rend="strikethrough">landsca</del>pe <handShift new="#new_material"
/>scenery </p>
</egXML>
</p>
<p>This example stresses the writing process and
provides two additional pieces of information: firstly
the fact that the author did not strike through the
whole of the first word and secondly that
a change in writing material happened just before
the word <mentioned>scenery</mentioned> was written.
In current encoding practice, which tends to favour the textual view, the two
perspectives are often integrated, subordinating aspects of the writing process to
their textual outcome or regularizing them so they do not interfere with
a text-driven evaluation of the encoding.</p>
<egXML xmlns="http://www.tei-c.org/ns/Examples">
<subst>
<del><hi rend="strikethrough">landsca</hi>pe</del>
<add hand="#new_material">scenery</add>
</subst>
</egXML>
<p>As the example shows, this integrative approach can be a viable one in many cases,
but taking this pragmatic shortcut blurs a specific editorial
distinction, maybe exactly the distinction one wants to emphasize (e.g. to
separate <foreign>Befund</foreign> from
<foreign>Deutung</foreign>). Furthermore, it makes it particularly hard to be as precise about the
<emph>documentation</emph> of <soCalled>what’s
there</soCalled> as one is about the
<emph>interpretation</emph> of <soCalled>what’s the possible outcome</soCalled>. Ideally in a
genetic edition the editor would prefer to encode the two perspectives
separately and align them later on instead of trying to integrate them right away,
and thereby potentially neglect information of
importance in their genetic analysis.</p>
</div>
</div>
<div>
<head>Aspects of Genetic Editions</head>
<p>Modern genetic editions describe the genetic process within one manuscript and over
the course of two or more manuscripts, which are said to form part of a
<term>dossier</term>, that is, the set of documents which a genetic editor
considers as having contributed to the evolution of a particular text, including
associated diaries, letters, etc. Usually a view of a manuscript as a single
self-contained object is also offered. This is because the manuscript view provides
the material basis for the relationships established by the inter-manuscript
relationship. Therefore we propose to differentiate between the following aspects of
a genetic edition:</p>
<list type="gloss">
<label>Document level</label>
<item>
<list type="gloss">
<label>topological description</label> <item>
description of the layout of the
text and the basis for a rendition of a text as a diplomatic
transcription.</item>
<label>Textual Alterations</label> <item>
like additions, deletions,
substitutions.</item>
<label>Grouping Modifications</label> <item>
groups of changes at different
locations of one document, used to create sets which express the editorial
assumption that these changes have been undertaken in one stage.</item>
</list>
</item>
<label>Dossier level</label>
<item> <list type="gloss">
<label>Genetic Grouping</label> <item>groups phenomena in more than one document,
in order to describe editorial assumption that these phenomena are related
in some way.</item>
<label>Genetic Relation</label> <item>
describes the genetic relation between
different parts of a text,<note place="foot">As in the case where a document
describes the ordering of parts of a text contained in another document.
It is the case, for instance of Beckett's <title>That Time</title> where
the speeches of A, B and C are obsessively first subdivided and
subsequently shuffled and reshuffled by the means of sequences of letters
and numbers contained in a number of documents.</note> or across
several documents, as a series of steps on a path.</item>
<label>Comparison or Collation</label> <item>
expresses the differences between
texts as the result of a comparison between documents.</item>
<!-- will need revision -->
</list>
</item>
<label>Document and Dossier levels</label>
<item>
<list type="gloss">
<label>Chronology, Date and Time</label> <item>the encoding of the chronology of
the text or parts of it in absolute or relative time.</item>
<label>Documenting Editorial Decisions</label> <item>documents the arguments which
are the basis for editorial decisions to encode the text in a specific way
including ways to express uncertainty and alternatives.</item>
<label>Text Stage</label> <item>a reconstructable stage in the evolution of a
text, represented by a document or by a revision campaign within one or more
documents, possibly assigned to a specific point in time. </item>
</list>
</item>
</list>
</div>
<div>
<head>The document level</head>
<div xml:id="document">
<head>Transcription of a document </head>
<p>A document-based transcription is hierarchically organised in the following way: <list>
<item>document<list>
<item>Writing Surface (page, double page, folium, etc.) <list>
<item>zone <list>
<item>Text, lines or tables</item>
</list></item>
</list></item>
</list></item>
</list></p>
<p>We propose to introduce a new element, <gi>ge:document</gi> to encode a
document-based transcription, at the same level as the existing TEI <gi>text</gi>
element. A full TEI document may thus comprise: <list>
<item>a TEI Header, containing metadata</item>
<item>a TEI <gi>facsimile</gi> element, containing and describing visual
representations of a document</item>
<item>a <gi>ge:document</gi> element, containing a genetic transcription of a
document</item>
<item>a TEI <gi>text</gi> element, containing an encoded version of the text
constructed from the document.</item>
</list>The header and at least one of the other three components must be present.
We do not discuss <gi>facsimile</gi> or <gi>text</gi> elements here; for these
refer to the published TEI Guidelines. </p>
<p>In the simplest case, a document contains one or more written surfaces, of various
types (pages, for example). Each surface may contain one or more distinct written
zones of writing, each comprising one or more identifiable topographic lines. The
following elements are used to represent these basic components: <specList>
<specDesc key="document"/>
<specDesc key="surface" atts="type"/>
<specDesc key="zone" atts="rotate stage"/>
<specDesc key="line" atts="type"/>
<specDesc key="table"/>
</specList></p>
<!-- remove @rotate? add something to describe writing orientation,
using SVG description of baseline; added to any zone, line
simple case writing orientation on zone, or line;
or link to something in SVG for complex case
distinguish writing direction; svg for shape and for baseline
moritz will write on wiki soon
-->
<p>Like a <gi>facsimile</gi>, a <gi>ge:document</gi> contains information about the
written surfaces constituting a document. Because of this similarity, we would
like to use the same elements (<gi>surface</gi> and <gi>zone</gi>) as proposed in
the existing TEI scheme, although these place limits on what can be described.
Specifically, the <gi>zone</gi> element as currently defined can represent only a
rectangular area; it also lacks any way of stating the baseline applicable to any
writing contained within it </p>
<p>The size of the writing surface is defined by a set of cartesian coordinates
measured from the top left corner. The co-ordinates of all zones identified within
the writing surface are given in terms of the same co-ordinates, as further
discussed in the TEI proposals for <gi>facsimile</gi>. It will often be the case
that explicit dimensions for a manuscript page (expressed in mm for example) are
also supplied in a <gi>msDesc</gi> element in the TEI Header, but this is not a
requirement; in particular there is no assumption that the co-ordinate system
defined by a <gi>surface</gi> maps to any particular external dimensions, nor that
the co-ordinate systems of different documents necessarily correspond. </p>
<p>A <gi>surface</gi> element may contain any number of <gi>zone</gi>,
<gi>graphic</gi>, <gi>ge:line</gi> or <gi>table</gi>elements. The
<gi>graphic</gi> element is used to point to any graphic (non textual)
component forming part of the page, in the usual TEI manner. The <gi>zone</gi>
element is used to delimit any contiguous section of writing which the encoder
wishes to identify for some purpose. </p>
<p>Zones can be nested and grouped, and can also overlap. Their positioning with
respect to the <gi>surface</gi> element is defined by coordinate values taken from
the same co-ordinate system as the surface itself, measured from the top left
corner. The element carries a <att>rotate</att> attribute which describes (in
degrees) the orientation of the surface with respect to the content (writing,
images) in that <gi>zone</gi>, with respect to its normal orientation. Note that
the mechanism aims to describes the process by which the content of a specific
<gi>zone</gi> has been supplied (i.e. the author has physically rotated the
writing surface) rather than the orientation of the writing.</p>
<!-- fotis wants to generalise rotation to things other than zones
actually he wants to kill it... -->
<p>Zones are arbitrarily defined by the encoder according to the layout of the
writing surface and can make use of a standardised vocabulary (e.g. the top
margin). <!-- means what? --></p>
<p>To overcome the inherent limitations of the existing <gi>zone</gi> and
<gi>surface</gi> elements, we need to extend their capability to include the
definition of arbitrary polygons, using an attribute
such as <att>svg:points</att>, from the Standard
Vector Graphics (SVG) XML namespace. This would
also provide a way of defining a baseline for the writing. This work is not
yet fully elaborated. </p>
<p>The attribute <att>stage</att> is used to indicate the <term>stage</term> in a
writing campaign to which this zone has been assigned by the encoder, as further
discussed in <ptr target="#stages"/> below. </p>
<p>Within a zone, individual lines of writing are usually, but not necessarily,
distinguished using the <gi>ge:line</gi>. Zones can
also include <gi>table</gi>
elements, as lines and tables represent the principal ways of organising
texts on a surface.<!--note>Can we have <gi>cell</gi> restricted to contain only what
is allowed within <gi>ge:line</gi>? Namely: <specList>
<specDesc key="model.pPart.transcriptional"/>
<specDesc key="model.pPart.editorial"/>
<specDesc key="model.hiLike"/>
<specDesc key="model.gLike"/>
<specDesc key="model.global"/>
</specList>
</note--> In the case of an interlineated text, interlinear writing can be treated as a
line on its own (perhaps characterised by a <att>type</att> attribute) or as
textual addition, encoded with an <gi>add</gi> (see below <ptr
target="#alterations"/>).<!-- more discussion
needed --></p>
<p>In the following imaginary example, there are two main areas of writing, the diary
entry (black ink) and another (supposedly later) annotation in blue ink. <figure>
<graphic url="examples/D1.png" width="400px"/>
</figure> Note that the diary entry forms a zone which itself contains two zones:
one containing the date, and the other containing three lines about birds. The
five lines of annotation in blue ink form another zone, to record which the diary
page has been rotated 90° clockwise by the author. Using the elements discussed so
far, the page might be transcribed as follows:</p>
<!-- D1_1.xml -->
<egXML xmlns="http://www.tei-c.org/ns/Examples">
<ge:document>
<surface ulx="0" uly="0" lrx="200" lry="300">
<zone ulx="10" uly="43" lrx="185" lry="84" rotate="0">
<zone>
<ge:line rend="right"> 1 April 2009 </ge:line>
</zone>
<ge:line>Fed Birds in the park today.</ge:line>
<ge:line>Might write an article about </ge:line>
<ge:line>the Thick-billed Warbler. </ge:line>
</zone>
<zone ulx="9" uly="20" lrx="70" lry="60" rotate="90">
<ge:line>Samaria is a Greek </ge:line>
<ge:line>brand of water that</ge:line>
<ge:line>comes from the natural</ge:line>
<ge:line>springs of Stilos, in </ge:line>
<ge:line>Crete </ge:line>
</zone>
</surface>
</ge:document>
</egXML>
<p>On the other hand, if the encoder considers it inconvenient to mark the text
within <gi>ge:line</gi> elements, one could encode the same text as follows:
<!-- D1_2.xml --><egXML xmlns="http://www.tei-c.org/ns/Examples">
<ge:document>
<surface ulx="0" uly="0" lrx="200" lry="300">
<zone ulx="10" uly="43" lrx="185" lry="84" rotate="0">
<zone>1 April 2009 </zone>
<lb/>Fed Birds in the park today.<lb/> Might write an article about
<lb/> the Thick-billed Warbler. </zone>
<zone ulx="9" uly="20" lrx="70" lry="60" rotate="90">
<lb/>Samaria is a Greek <lb/> brand of water that <lb/> comes from the
natural <lb/> springs of Stilos, in <lb/> Crete </zone>
</surface>
</ge:document>
</egXML>
</p>
<p>For comparison, here is a typical TEI transcription of the same page, focussing on
its textual structure <!-- D1_3.xml --><egXML
xmlns="http://www.tei-c.org/ns/Examples">
<div type="diary-entry">
<dateline>
<date value="2009-04-01"> 1 April 2009 </date>
</dateline>
<p><lb/>Fed Birds in the park today.<lb/> Might write an article about <lb/>
the Thick-billed Warbler. </p>
</div>
<div type="note" rend="rotated">
<p><lb/>Samaria is a Greek <lb/> brand of water that <lb/> comes from the
natural <lb/> springs of Stilos, in <lb/> Crete</p>
</div>
</egXML>
</p>
<!--<p>[We need here an example discussing problem of interlinear markup
]</p>-->
<p>Is it possible to combine both perspectives (documentary and textual views) within
a single encoding? In general a document-based transcription, which is done
page-by-page and possibly line-by-line, is almost certain to overlap with some
part of a the text-based structure. The cleanest solution may be to encode both
structures separately, providing both a <gi>ge:document</gi> and a distinct
<gi>text</gi> solution, perhaps using some form of external pointing to link
the two, and minimizing redundancy of encoding by using XInclude. This option is
further discussed below and also in the TEI Guidelines. </p>
<p>A further, and possibly simpler, approach is to apply to the textual elements such
as <gi>p</gi> exactly the same kind of <soCalled>flattening</soCalled> approach as
has been applied to the <gi>ge:line</gi> elements in the preceding example.
Instead of marking the textual paragraphs as full elements, we mark only their
frontiers, using the standard TEI <gi>milestone</gi> element, with the addition of
a spanning attribute, as follows: <!-- D1_4.xml --><egXML
xmlns="http://www.tei-c.org/ns/Examples">
<surface ulx="0" uly="0" lrx="200" lry="300">
<zone stage="#stage1" seq="0" ulx="10" uly="43" lrx="185" lry="84">
<zone>
<milestone unit="date" spanTo="#endDate"/>1 April 2009 <anchor
xml:id="endDate"/>
</zone>
<milestone unit="p" spanTo="#p2"/>
<ge:line>Fed Birds in the park today.</ge:line>
<ge:line> Might write an article about </ge:line>
<ge:line>the Thick-billed Warbler.</ge:line>
</zone>
<zone stage="#stage2" ulx="9" uly="20" lrx="70" lry="60" rotate="90">
<milestone unit="p" xml:id="p2" spanTo="#end"/>
<ge:line>Samaria is a Greek</ge:line>
<ge:line>brand of water that</ge:line>
<ge:line>comes from the natural</ge:line>
<ge:line>springs of Stilos, in</ge:line>
<ge:line>Crete</ge:line>
<anchor xml:id="end"/>
</zone>
</surface>
</egXML>
</p>
<p>Elements <gi>zone</gi>, <gi>ge:line</gi>, and
<gi>cell</gi> may all contain a selection of the phrase
level elements which have been considered essential to a document based
transcription. These elements are all drawn from the
following existing TEI classes: <specList>
<specDesc key="model.pPart.transcriptional"/>
<specDesc key="model.pPart.editorial"/>
<specDesc key="model.hiLike"/>
<specDesc key="model.gLike"/>
<specDesc key="model.global"/>
</specList> A subset of the elements provided by
these classes needs to be defined. In addition, a
mechanism is needed to constrain the content of the
selected elements such that they contain only
elements which are allowed within <gi>ge:line</gi>.
<!-- TODO: refer to model.zonePart/linePart as an extension point for the content model -->
<!-- <note place="foot">Can we limit the content of seg within this specific context?
Or do we need another element with such a content? This is point is left open
for the Council to evaluate.</note--> The generic
<gi>seg</gi> element can also be used to
encode any semantic aspect of the transcribed document (e.g. dates or names), though
it is recommended that such an approach is kept to a minimum. In case extensive
semantic markup is to be applied, the textual perspective should be preferred or
included alongside, as suggested above. </p>
<p>The written surfaces of which a document is composed are not always homogenous. In
the following example, taken from the Walt Whitman archive, two pieces of
newsprint have been glued to a piece of blue paper on which a poem is being
drafted: <figure>
<graphic url="examples/whitman01.jpg" width="400px"/>
<head rend="it">Image from
http://www.whitmanarchive.org/resources/sleepers/duk.00258.001.jpg</head>
</figure> The two pieces of newsprint might perhaps be regarded as special kinds
of zone, but they are effectively new surfaces, since they might contain
additional written zones themselves (such as the numbers in this case). We
therefore propose a distinct element, <gi>ge:patch</gi>, which can appear within a
<gi>surface</gi>, and behaves effectively like one, except that it contains
specialized attributes to provide additional information. <specList>
<specDesc key="patch" atts="binder type height width"/>
</specList> Using this element, the Whitman draft above might be encoded as
follows: <!-- whitman01.xml --><egXML xmlns="http://www.tei-c.org/ns/Examples">
<surface>
<zone>
<ge:line>Poem</ge:line>
<ge:line>As in Visions of — at</ge:line>
<ge:line>night —</ge:line>
<ge:line>All sorts of fancies running through</ge:line>
<ge:line>the head</ge:line>
</zone>
<ge:patch type="newsprint" binder="glue" height="40" width="90"> Spring has
just set in here, and the weather.... a steamer <zone>
<ge:metaMark function="sequence">2</ge:metaMark>
</zone>
</ge:patch>
<ge:patch type="newsprint" binder="glue" height="35" width="90"> "The shores
on either side of the Sound are... The In- <zone>
<ge:metaMark function="sequence">3</ge:metaMark>
</zone>
</ge:patch>
</surface>
</egXML> The <gi>ge:metaMark</gi> element used in this example is further
discussed below (<ptr target="#mm"/>)</p>
<p>Surfaces can also be damaged, perforated, and cut. In such cases a combination of
<gi>damageSpan</gi> and <gi>gap</gi> elements may be used. <specList>
<specDesc key="damageSpan" atts="group"/>
<specDesc key="gap"/>
</specList> Suppose that a piece of paper has been cut from the page
encoded by a <gi>surface</gi> element, and that we can infer the dimensions of the
missing piece. This could be encoded as follows: <!-- damageSpan_1.xml --><egXML
xmlns="http://www.tei-c.org/ns/Examples">
<surface ulx="0" uly="0" lrx="200" lry="300">
<zone>...</zone>
<damageSpan hand="#author" spanTo="#zoneEnd" agent="knife_or_scissors"
group="1" extent="3x5" unit="cm"/>
<zone ulx="9" uly="20" lrx="70" lry="60"/>
<anchor xml:id="zoneEnd"/>
</surface>
</egXML> In the example an empty <gi>zone</gi> element has been provided in order
to give the coordinates of the missing piece of <gi>surface</gi>, assuming that
those are reconstructible. If a full page is missing, <gi>damageSpan</gi> can be
used within <gi>ge:document</gi>, perhaps in conjunction with a <gi>gap</gi>
element. <!-- damageSpan_2.xml --><egXML xmlns="http://www.tei-c.org/ns/Examples">
<ge:document>
<surface ulx="0" uly="0" lrx="200" lry="300">
<zone>...</zone>
</surface>
<damageSpan spanTo="#p3"/>
<gap extent="1" unit="folio">
<desc>Stub of a missing folio</desc>
</gap>
<surface ulx="0" uly="0" lrx="200" lry="300" xml:id="p3">
<zone>...</zone>
</surface>
</ge:document>
</egXML> Now suppose that the missing folio is by chance found somewhere; in this
case it is likely that the editor might want to encode the two statuses of the
document, before and after the damage, tracing the genesis of the document as well
as the genesis of the text. In this case, the same mechanism used to
describe the genetic history of the text can be used to describe the genesis of
the document (see below <ptr target="#stages"/>): a
<att>stage</att> attribute linked to a
<gi>ge:stageNote</gi> element can identify the different
states in the history of the document.
<!-- damageSpan_3.xml --><egXML xmlns="http://www.tei-c.org/ns/Examples">
<ge:document>
<surface ulx="0" uly="0" lrx="200" lry="300">
<zone>...</zone>
</surface>
<damageSpan spanTo="#P3" stage="#stage2"/>
<gap extent="1" unit="folio" stage="#stage2">
<desc>Stub of a missing folio</desc>
</gap>
<surface corresp="folio.xml#p1" stage="#stage1"/>
<surface corresp="folio.xml#p2" stage="#stage1"/>
<surface ulx="0" uly="0" lrx="200" lry="300" xml:id="P3">
<zone>...</zone>
</surface>
</ge:document>
</egXML> In this example, we assume that the two
recovered pages (i.e. both sides of the missing
folio) have been encoded in some separate XML
document which can be obtained from the URL
<code>folio.xml</code>. This could be referenced via
the <att>corresp</att> attribute, transcluded by means
of a <gi>ptr</gi> or included by XInclude. The
content could also simply be encoded
within the same document as content for the
otherwise empty <gi>surface</gi>s). Note that the
<gi>damageSpan</gi> and <gi>gap</gi> belong to a second stage in the life of
the document; the descriptions of <val>#stage1</val> and <val>#stage2</val> can be
found in the header, within the <gi>ge:stageNote</gi> section.</p>
<!-- <note><hi rend="bold">EP:</hi> I cannot include Lebrave example because, even if I
asked a couple of times, he did not answer to my requests of using his material,
so I don't know if the images are protected by copyright or not.</note>-->
<!-- need to add Lebrave's scarey example of virtual reconstructed document -->
</div>
<div xml:id="alterations">
<head>Textual Alterations</head>
<p>Traces of authorial alteration (correction, addition, deletion, etc.) are
frequently found within a single document, and may also be inferred when different
documents are compared. It is however an open question as to whether
inter-document discrepancies at the dossier level should be regarded in the same
way as intra-document alterations. If two witnesses are collated, we may observe
that a word present in one is missing from the other: does it necessarily follow
that this is an addition or a deletion, which we would not hesitate to mark with
an <gi>add</gi> or <gi>del</gi> tag if we are transcribing a single manuscript? We
return to this question <ref target="#collation">below</ref>.
<!-- Or do we need a completely new
set of elements to do it? In a genetic process, at any point the
author can decide to stop revising the text within a given document
and decide to move to a new document (i.e. copy it anew), so the two
phenomena (alterations at document level and alterations at dossier
level) are indeed closely related. On the other hand we need to
differentiate them because the one within a single document is
explicitly marked by the author, while the one detected by comparison
is only implicit. It may also happen that implicit alterations were
perhaps marked in a lost intermediate version. This remains an open
problem (see .</p> <p>The following discussion-->
</p>
<p>In this section we discuss elements introduced for the markup of alterations at
the document level, within a single document, complementary to the elements
already provided for this purpose by the TEI scheme. We discuss specifically: <list>
<item><soCalled>meta-marks</soCalled>, that is a kind of authorial markup
present in the source and indicating how it should be read; </item>
<item>additions, where a passage has been rewritten to fix or clarify it; </item>
<item>deletions, where a passage had been struck through to indicate that it
has been removed, or where a deletion has itself been cancelled</item>
<item>transpositions, where passages have been reorganized or resequenced.
</item>
</list>
</p>
<p>The TEI already provides the following basic elements for transcription, which
constitute the <ident>model.pPart.transcriptional</ident> class: <specList>
<specDesc key="add"/>
<specDesc key="app"/>
<specDesc key="corr"/>
<specDesc key="damage"/>
<specDesc key="del"/>
<specDesc key="orig"/>
<specDesc key="reg"/>
<specDesc key="restore"/>
<specDesc key="sic"/>
<specDesc key="subst"/>
<specDesc key="supplied"/>
<specDesc key="unclear"/>
</specList> The present proposals extend this list by adding the following
elements to the same class: <specList>
<specDesc key="mod" atts="rend type"/>
<specDesc key="modSpan" atts="spanTo"/>
<specDesc key="metaMark" atts="function targets"/>
<specDesc key="used" atts="spanTo"/>
<specDesc key="undo" atts="spanTo"/>
<specDesc key="redo" atts="spanTo"/>
<specDesc key="rewrite" atts="cause"/>
<specDesc key="transposeGrp"/>
<specDesc key="transpose"/>
</specList> .</p>
<p>Most of these elements imply a certain level of semantic
interpretation; for instance the usage of the <gi>add</gi> element to encode, say,
interlinear insertions involves a decision that the
interlinear text has been deliberately inserted rather
than simply misplaced. As discussed
above (see <ptr target="#act_vs_state"/>), the use of these elements
when transcribing from a documentary perspective is
a pragmatic shortcut. In cases where it is felt
desirable to keep the recording of
<soCalled>what is on the page</soCalled> entirely separate from
<soCalled>what is the editor’s
interpretation</soCalled> (see <ptr
target="#deutung"/>), we provide two generic elements, <gi>ge:mod</gi> and
<gi>ge:modSpan</gi>, which can be used to
record any kind of modification identified in
the document. These elements can be
categorised by means of their <att>type</att>
attribute, and visual aspects of their appearance
can be described by means of the <att>rend</att>
attribute, but they provide no further
interpretation of the function or intention of
the passage so marked up.</p>
<p> Whether such a modification, for instance a struck-out passage, is
to be interpreted as a deletion or as some other
phenomenon (e.g. as being already used) should be
be expressed using the other, more semantically motivated, elements,
which function at a different level of description.</p>
<div>
<head>Additions, fixations and clarifications</head>
<p>A writer may sometimes rewrite material a second time without significant
change and in the same place. We consider this a distinct activity from
addition as usually defined because no new textual material results but the
status of existing material changes. We distinguish two variants of this:
<term>fixation</term> where the first version was a tentative draft which is
subsequently fixed, for example by inking it over; and
<term>clarification</term>, where the first version was badly written and
has been rewritten for clarity. The element <gi>ge:rewrite</gi> is provided to
cover both cases. </p>
<p>In this simple example, taken from the papers of Henrik Ibsen, the writer wrote
the word <mentioned>skuldren</mentioned> hastily, and then returned to it to
make the letter <mentioned>l</mentioned> larger and clearer: <figure>
<graphic url="examples/skuldren.jpg" width="400px"/>
<head rend="it">Image from a ms of Peer Gynt, Collin 2869, 4°, I.1.1, the
Royal Library of Copenhagen</head>
</figure> We might transcribe this word as follows: <!-- skuldren.xml --><egXML
xmlns="http://www.tei-c.org/ns/Examples">
<ge:line>... Sku<ge:rewrite cause="unclear">l</ge:rewrite>dren </ge:line>
</egXML>
</p>
<p>The following example, taken from a manuscript of Jane Austen's
<title>Sanditon</title>, shows a rewriting where a pencilled passage has
been fixed with ink, with some modification: <figure>
<graphic url="examples/AusSand70.png" width="400px"/>
<head rend="it">Image from page 70 of the Sanditon manuscript</head>
</figure> In this example, Austen sees in the fixation an opportunity to
manipulate the text previously written, and thus changes the pencilled
<mentioned> could but get a young</mentioned> to the inked <mentioned>could
get a young</mentioned>, writing the inky <mentioned>get</mentioned> on top
of pencilled <mentioned>but</mentioned> and striking over with black ink the
pencilled <mentioned>but</mentioned>. A simple way of encoding this might be as
follows: <!-- AusSand70.xml --><egXML xmlns="http://www.tei-c.org/ns/Examples">
<ge:rewrite cause="fix" hand="#ja2" stage="#s1">Now, if we could <subst
stage="#s1">
<add>get</add>
<del>but</del>
</subst>
<del stage="#s1" rend="overstrike">get</del> a young Heiress</ge:rewrite>
</egXML> where the <att>stage</att> attribute groups the operations that belong
to the rewriting stage, assuming an implied previous stage (the first layer of
writing). If the first layer need to be addressed independently, another
pointer can be added to the <att>stage</att> attribute:
<!-- AusSand70.xml --><egXML xmlns="http://www.tei-c.org/ns/Examples">
<ge:line stage="#s0"> <ge:rewrite cause="fix" hand="#ja2" stage="#s1">Now...</ge:rewrite></ge:line>
</egXML>
where <val>#s0</val> and <val>#s1</val> both point to the declaration
of such stages in the header, the first one conventionally representing the
first layer of writing and the second the rewriting stage. </p>
<!-- note that the hand specified for the rewrite is the second one -->
<p>A single rewrite may not be sufficient, and it may be that the document becomes
almost unreadable as a result of repeated clarification. In the following
example, we can distinguish at least two attempts to write the letters
<mentioned>er</mentioned> in the word <mentioned>bægerklang</mentioned>: <figure>
<graphic url="examples/munch01.jpg" width="400px"/>
<head rend="it">Image from http://www.emunch.no/tei-mm-2008/ms.html </head>
</figure> We might encode this by nesting the <gi>rewrite</gi> element as
follows: <!-- munch01.jpg --><egXML xmlns="http://www.tei-c.org/ns/Examples">
<ge:line>ved Bæg<ge:rewrite cause="unclear" stage="#stage2">
<ge:rewrite cause="unclear" stage="#stage1">er</ge:rewrite>
</ge:rewrite> ...</ge:line>
</egXML> The <att>stage</att> attribute used here is discussed further below
(<ptr target="#stages"/>). </p>
<p>Metamarks and other markup-like strokes can also
be inked over with the same purpose as the fixation
or clarification of text passages. For
instance, in a draft version of Goethe’s Faust, a passage was struck through
once in pencil during one revision and then again
with ink during a later revision, supposedly to fixate the deletion.</p>
<figure>
<graphic url="examples/faust_redo.jpg"/>
<head rend="it">Fixation of a deletion in Goethe’s Faust</head>
</figure>
<p>We propose an element <gi>redo</gi> (the opposite
of <gi>undo</gi>, see
<ptr target="#undo"/>), which can be used to encode this process as follows:</p>
<egXML xmlns="http://www.tei-c.org/ns/Examples">
<ge:line><ge:redo xml:id="redo_3" hand="#g_t" target="#mod_1" cause="fix"
/><ge:modSpan xml:id="mod_1" rend="strikethrough" spanTo="#anchor_1"
hand="#g_bl"/>Ihr hagren, triſten, krummgezog<ge:mod rend="strikethrough"
>nen</ge:mod>ener Nacken</ge:line>
<ge:line>Wenn ihr nur piepſet iſt die Welt ſchon matt.<anchor xml:id="anchor_1"
/></ge:line>
</egXML>
</div>
<div>
<head>Deletions and marked as used</head>
<p>In general, deletion in a source is marked using the <gi>del</gi> or
<gi>delSpan</gi> element. However, it is useful to distinguish cases where a
passage has been <q>indicated as superfluous or spurious in the copy text by an
author, scribe, annotator, or corrector</q> (TEI P5, s.v. <gi>del</gi>) from
cases where a passage has been struck through or otherwise marked as having
been used or copied to another location. In this latter case, the author does
not intend to suppress the content, but only to mark that it has been
transferred or reused. The element <gi>ge:used</gi> is provided to mark this
kind of <soCalled>deletion</soCalled>.</p>
<p>The following page from the Walt Whitman archive has been crossed through to
indicate used material: <figure>
<graphic url="examples/whitman02.jpg" width="400px"/>
<head>Page from
http://www.whitmanarchive.org/resources/sleepers/20051105_0650.jpg</head>
</figure> This page contains many internal deletions, but these should be
distinguished from the <soCalled>deletion</soCalled> signalled by the large
cross, which actually shows that the page has been transferred or re-used, not
deleted. </p>
<p>Material marked as re-used in this way often spans more than one zone or line.
For that reason, the <gi>ge:used</gi> element is a spanning element, indicating
the end of the used area by means of a <att>spanTo</att> attribute. We might
encode the above page as follows: <!-- whitman02.xml --><egXML
xmlns="http://www.tei-c.org/ns/Examples">
<surface>
<ge:used rend="cross" spanTo="#X2"/>
<zone>
<ge:line rend="underline">The Poet</ge:line>
<ge:line><del rend="strikethrough">I think</del> His sight is
the</ge:line>
<ge:line> sight of the ? and</ge:line>
<ge:line>has sent the instinct of the</ge:line>
<ge:line>? dog</ge:line>
</zone>
<zone>
<ge:line>I think <ge:rewrite>ten</ge:rewrite> million</ge:line>
<!-- ... -->
<ge:line>well; those <subst>
<del rend="strikethrough">supple-fingered gods</del>
<add>journeymen divine.</add>
</subst></ge:line>
<anchor xml:id="X2"/>
</zone>
</surface>
</egXML>
</p>
</div>
<div xml:id="mm">
<head>Metamarks</head>
<p>By <term>metamark</term> we mean marks such as numbers, arrows, crosses, or
other symbols introduced by the writer into a document expressly for the
purpose of indicating how the text is to be read. Such marks thus constitute a
kind of markup of the document, rather than forming part of the text. </p>
<p>Unlike marginal notes or other additions to the text, meta-marks indicate a
deliberate alteration of the writing (e.g. <q>move this passage over
there</q>). We also consider as metamarks dates introduced to mark the
beginning of a manuscript or a revision, but not forming part of it.</p>
<p>The <gi>ge:metaMark</gi> element carries a <att>function</att> attribute which
specifies the function of the meta-mark and a <att>target</att> attribute which
points to the element or elements concerned. </p>
<p>The following example is taken from <title>Kundige bok 2</title>, a 15th
century legal book from the city of Göttingen, containing regulations of
everyday life issued by the city council <figure>
<graphic url="examples/ka04_1v-dtl.jpg" width="400px"/>
<head>Malte's example</head>
</figure>
</p>
<p>In the second paragraph, the sentence beginning <q>Ock en schullen de
bruwere...</q> was first written along with the word <mentioned
xml:lang="lat">lege</mentioned> ("read") in the left hand margin,
functioning as a metamark to indicate that this sentence forms part of the
regulations. A further sentence was then added, while at some later stage or
stages the text and also the metamark were deleted. We might encode this as
follows: <!-- ka04_1v-dtl.xml --><egXML
xmlns="http://www.tei-c.org/ns/Examples">
<del>
<ge:metaMark function="flag" target="#s1">lege</ge:metaMark>
<s xml:id="s1">Ock en schullen de bruwere des hilgen dages nicht over
<lb/>setten noch uppe den stillen fridach bruwen.</s>
<add>
<s>Noch nymande <lb/>over setten, se en sehin denne erst, dat uppe den
bonen <lb/>neyn stro noch, huw noch flaß ligghe, by pine eyner
halven <lb/>roden, deme bruwere so wol alse dem bruwheren to
murende.</s>
</add>
</del>
</egXML>
</p>
<p>Here are some further examples showing the use of this element, taken from the
manuscript drafts of Thomas Moore's <title>Lalla Rookh</title>
(1817)<!--, provided by Justin Tonra, NUIG-->. The first shows a simple use of
a metamark used to take stock of the progress of composition: <figure>
<graphic url="examples/moore02.jpg" width="400px"/>
<head>Lalla Rookh</head>
</figure>
</p>
<p>At regular points throughout the various drafts of the work, a number occurs,
usually in the right margin (in this instance, "100"). These numbers result
from the author counting the number of verse lines he has composed to the given
point, and are not part of the text, but represent a stage at which Moore is
taking stock of the progress of his composition. </p>
<p>
<!-- moore02.xml -->
<egXML xmlns="http://www.tei-c.org/ns/Examples">
<surface>
<zone>
<!-- main zone -->
<ge:line>Be this she cried & wing’d her flight</ge:line>
<ge:line>My offering at the Gates of Bliss</ge:line>
<ge:line>
<del>Fully to know the odours <gap extent="1" unit="word"
reason="illegible"/></del>
</ge:line>
<ge:line>
<del>Tho foul to heaven the vapour went</del>
</ge:line>
<ge:line>
<del>From vulgar</del>
<add>common</add>
<del>victors</del>, blood like this</ge:line>
<ge:line> Shed out for freedom, flows so bright. <ge:metaMark
function="count">100</ge:metaMark></ge:line>
<ge:line> It would not stain the purest <subst>
<del>fount</del>
<add>rill</add>
</subst> .</ge:line>
<ge:line>“That sparkles thro the fields of light. <del>
<ge:metaMark function="count">100</ge:metaMark>
</del></ge:line>
<ge:line> Behold her in the skies again —</ge:line>
<ge:line>
<subst>
<del>But</del>
<add>And</add>
</subst>, tho so fleet her pinions bore</ge:line>
<ge:line> The spirit of the Warriors slain,</ge:line>
<ge:line>Now reach’d & pass’d the gates before her</ge:line>
</zone>
<zone>
<!-- left zone -->
<ge:line> Tho foul too oft the</ge:line>
<ge:line>tears that still</ge:line>
<ge:line>Tho foul the droppings <add>weepings</add></ge:line>
<ge:line>that distil</ge:line>
<ge:line>Tho foul the tears that</ge:line>
<ge:line>oft distil</ge:line>
<ge:line>From glory’s faulchion’</ge:line>
</zone>
</surface>
</egXML>
</p>
<p><figure>
<graphic url="examples/moore03.png" width="400px"/>
<head>Lalla Rookh 2</head>
</figure> This example demonstrates the use of a common proof-correction mark:
in the left margin of the page, adjacent to a group of three cancelled lines of
verse, the word "stet" is written. "Stet", a Latin word meaning "let it stand"
is commonly used by authors, editors, and proofreaders where a previous action
should be disregarded. In this instance, Moore is indicating that the three
deleted verse lines should be let stand, as evidenced by their appearance in
the first printed edition of <title>Lalla Rookh</title>. The word, "stet" does
not form part of the text, but rather declares that a certain function be
performed upon the text. <!-- moore03.xml --><egXML
xmlns="http://www.tei-c.org/ns/Examples">
<surface>
<zone>
<ge:line><gap extent="1" unit="word" reason="illegible"/>
<del>in his light</del>
<add>within</add> eyelids, within the spray</ge:line>
<ge:line>From Eden’s fountain, when it lies</ge:line>
<ge:line><hi rend="underline">On that blue</hi>
<del>before that</del> flower, which, Brahmins say</ge:line>
<ge:line> Can only <add>blooms nowhere but</add> bloom in
Paradise,</ge:line>
<ge:line>
<del xml:id="del1">“Nymph of a bright, fair but erring line!</del>
</ge:line>
<ge:line>
<ge:metaMark function="undo" target="#del1 #del2 #del3"
>stet</ge:metaMark>
<del xml:id="del2">(He gently <add>gently</add> he said) one hope
is thine</del>
</ge:line>
<ge:line>
<del xml:id="del3">One hope (he gently said) is thine</del>
</ge:line>
</zone>
</surface>
</egXML>
</p>
<p>Other examples of <gi>ge:metaMark</gi> can be seen in marked-up proofs such as
the following, taken from the Walt Whitman archive: <!-- wrong example -->
<figure>
<graphic url="examples/moore04.png" width="400px"/>
<head>http://www.whitmanarchive.org/resources/sleepers/loc.00295.jpg</head>
</figure></p>
</div>
<div>
<head>Alternative Readings</head>
<p><figure>
<graphic url="examples/moore04.png" width="400px"/>
<head>Lalla Rookh 3</head>
</figure> In this example two alternative readings are provided, without either
one being prioritised or subordinated. While the author apparently first
composed the line "Alone before his native river -", at some later point, he
entertained the possibility of using the word "beside" instead of "before." In
the context of this manuscript, there is no indication of which word the Moore
favours, so the status of these words as possible alternative readings needs to
be encoded. The evidence of the first edition of <title>Lalla Rookh</title>
shows that the word "beside" was chosen, but for the purposes of encoding this
manuscript, the facility to encode two equally-possible alternative readings
needs to be available. </p>
<!-- moore04.xml -->
<egXML xmlns="http://www.tei-c.org/ns/Examples">
<zone>
<ge:line>Alone <seg type="alternative" xml:id="alt1">before</seg>
<add place="above" type="alternative" xml:id="alt2">beside</add> his
native river —</ge:line>
<alt targets="#alt1 #alt2" mode="excl" weights="0 1"/>
</zone>
</egXML>
<!--<p>As a further example, consider the manuscript of a poem by Emily Dickinson discussed by Vetter and McDonald
2003 <note place="foot">
<bibl>
<author>Lara Vetter and Jarom McDonald</author>
<title level="a">Witnessing Dickinson's Witnesses</title>
<title level="j">Literary Linguistic Computing</title>
<biblScope type="vol">18</biblScope>
<biblScope type="issue">2</biblScope>
<biblScope type="pp">151-165</biblScope>
<date>2003</date>
<ptr
target="http://llc.oxfordjournals.org/cgi/reprint/18/2/151?maxtoshow=&HITS=10&hits=10&RESULTFORMAT=&fulltext=vetter&searchid=1&FIRSTINDEX=0&resourcetype=HWCIT"
/>
</bibl>
</note>. In this case, a plus sign is used to indicate that there are two
possible alternatives for the word following it, concerning which the
writer remains undecided. We can mark this up as follows: <egXML
xmlns="http://www.tei-c.org/ns/Examples">
<ge:line> <ge:metaMark function="alternative" targets="#alt01">+<alt
targets="#alt01 #alt02 #alt03" mode="excl" weights="1 0 0"
/></ge:metaMark>
<hi rend="underlined" xml:id="alt01">estranged</hi> -
<ge:metaMark function="alternative" targets="#alt2"
>+</ge:metaMark>
<add type="alternative" xml:id="alt02" place="inline"
>alarmed</add>
</ge:line>
<ge:line>
<ge:metaMark function="alternative" targets="#alt03">+</ge:metaMark>
<add type="alternative" xml:id="alt03">submerged</add> - </ge:line>
</egXML>
Note here the use of the existing TEI element <gi>alt</gi> to indicate
that the three elements indicated are mutually exclusive alternates: the word
<mentioned>estranged</mentioned> can be alternated with
<mentioned>alarmed</mentioned> (written in-line, aster
<mentioned>estranged</mentioned>) and <mentioned>submerged</mentioned>
written at the bottom of the page. Since <mentioned>estranged</mentioned> is
underlined, the editors argue (loc cit pp. 155-162)
that this possibility is to be preferred to the others and hence give it a
weight of 1.</p>
-->
</div>
<div>
<head>Transpositions</head>
<p>Metamarks are commonly used in the context of <term>transposition</term>, that
is, the moving of words or blocks by the author to a different position using
arrows, asterisks or numbers, or other metamarks. One possible approach (used,
for instance in HNML) would be to regard such transpositions as a special kind
of substitution, and actually to represent the result of the transposition
indicated by the metamarks in the encoding, for example by considering the
segment previous to the transposition as deleted, and substituted by the one
after the transposition. </p>
<p>Our recommendation is to record the actual state of the witness, but in such a
way as to facilitate its reorganization as a distinct processing step. We
propose to represent the re-alignment of transposed blocks or segments by means
of a stand-off mechanism. The elements <gi>ge:transposeGrp</gi> and
<gi>ge:transpose</gi> are provided for this purpose. For example, in the
following extract from an Ibsen manuscript <figure>
<graphic url="examples/ibsen01.jpg" width="400px"/>
<head>Extracted from
<ref>http://www.emunch.no/tei-mm-2008/ms.html</ref></head>
</figure>, the underlined numbers 1 and 2 indicate that, although the word
<mentioned>bör</mentioned> precedes the word <mentioned>hör</mentioned> in
the text, the order of the two words should be reversed. We may encode this as
follows: <!-- ibsen01.xml --><egXML xmlns="http://www.tei-c.org/ns/Examples">
<ge:line><seg xml:id="ib01">bör</seg><ge:metaMark rend="underline"
function="transposition" target="#ib1" place="above">2.</ge:metaMark>
og <seg xml:id="ib02">hör</seg><ge:metaMark rend="underline"
function="transposition" target="#ib02" place="above"
>1.</ge:metaMark></ge:line>
<ge:transposeGrp>
<ge:transpose>
<ptr target="#ib02"/>
<ptr target="#ib01"/>
</ge:transpose>
</ge:transposeGrp>
</egXML>
</p>
<p>Note the use of the generic <gi>seg</gi> element to identify the sections of
text being transposed. When (as in the following example) the whole of line is
to be transposed, there is no need to delimit the sections concerned: <figure>
<graphic url="examples/ibsen04.jpg" width="400px"/>
<head>Extracted from
<ref>http://www.emunch.no/tei-mm-2008/ms3.html</ref></head>
</figure>
<!-- ibsen04.xml --><egXML xmlns="http://www.tei-c.org/ns/Examples">
<ge:line xml:id="ib3"><ge:metaMark function="transposition"
place="margin-left">2.)</ge:metaMark> thi da er du med Himmelen i
Pagt; — </ge:line>
<ge:line xml:id="ib4">
<ge:metaMark function="transposition" place="margin-left"
>1.)</ge:metaMark> da kan du Folkets Jøkelhjerter tine;</ge:line>
<ge:transposeGrp>
<ge:transpose>
<ptr target="#ib4"/>
<ptr target="#ib3"/>
</ge:transpose>
</ge:transposeGrp>
</egXML> When transposition is made, the whole element indicated is understood
to be moved, not just its contents. In the above example, the metamarks are
thus understood to be moved along with the lines to which they apply. </p>
<p>In case the area to be transposed is overlapping with some other kind of
markup, the generic <gi>milestone</gi> can be used instead of <gi>seg</gi> or
any other existing elements.</p>
<p>One or more <gi>transposeGrp</gi> elements may be supplied either embedded
within the text or in the <gi>profileDesc</gi> of the header, depending on
local preference. Each <gi>transposeGrp</gi> can contain one or more
<gi>transpose</gi> elements, each of which defines a single
transposition.</p>
</div>
<div>
<head>Substitution</head>
<p>In the current model for the TEI <gi>subst</gi> element, one or more additions
and deletions may be combined if they are considered as representing a single
editorial act, a substitution. Without extension, this model could not
therefore include cases such as the following example taken from Thomas Moore's
<title>Lalla Rooke</title>
<figure>
<graphic url="examples/moore01.png" width="400px"/>
</figure> Here the word <mentioned>pondering</mentioned> is deleted, and the
phrase <mentioned>she mus'd</mentioned> are added, while the word
<mentioned>thus</mentioned> remains unchanged. It seems appropriate to treat
all of this as a single substitution. This would require a modification to the
content model of <gi>subst</gi> so as to permit text along with other members
of <ident type="class">model.pPart.transcriptional</ident>, so that this
example could be encoded as follows: <!-- moore01.xml --><egXML
xmlns="http://www.tei-c.org/ns/Examples">
<ge:line>While <subst><del>pondering</del> thus <add>she
mus'd</add></subst>, her pinions fann'd</ge:line>
</egXML></p>
</div>
<div xml:id="undo">
<head>Undoing alterations</head>
<p>In some cases an author indicates that an alteration is itself to be altered:
for example, a struck through passage may be restored via a dotted underlining,
or the underlining of a passage may be deleted by a wavy line. </p>
<!-- need a simpler example first, need to discuss relation with restore -->
<p>The TEI provides an element <gi>restore</gi> for one specific kind of
alteration to an alteration, namely the undoing of a deletion. We propose a
more general element, <gi>ge:undo</gi>. The element <gi>ge:undo</gi> usually
encloses the element (e.g. the <gi>add</gi>, <gi>del</gi> etc.) to be undone.
If it appears within such an element, the implication is that only this part of
the parent element has been cancelled. For example, in this passage taken from
Giacomo Leopardi's <title>Zibaldone</title> (p. 3595), the phrase <mentioned>si
rechi á</mentioned> was underlined word by word, and then the underlining of
the word <mentioned>si</mentioned> was cancelled. <figure>
<graphic url="examples/leop01.png" width="400px"/>
</figure>This could be encoded as follows: <!-- leop01.xml --><egXML
xmlns="http://www.tei-c.org/ns/Examples">
<ge:line> che e’ <hi rend="underline"><ge:undo spanTo="#x2"/>si <anchor
xml:id="x2"/> rechi a’</hi>
<del rend="overstrike">dotti</del>
<hi rend="underline">denti</hi> l’un d’essi cibi</ge:line>
</egXML></p>
<!-- not sure I remember what we said but it seems to me we decided to
point from the undo to the element to be undone-->
<p>To make explicit the relation between the undoing act and the initial act, we
propose an alternative way of encoding these scribal acts, namely an empty
<gi>ge:undo</gi> element, which points to the
element the effect of which is being cancelled. If
more than one (not coherent) part of the deletion
is undone, more than one <gi>undo</gi> element
will be needed, and each part undone must be
given an identifier.</p>
<p>In the following example, three text stages can be identified: <list>
<item>s1 (initial): This is just some sample text, we need a real example. <figure>
<graphic url="examples/undoing1.jpg" width="400px"/>
</figure></item>
<item>s2: This is not a real example.</item>
<item>s3: This is just some text, not a real example.</item>
</list></p>
<p>This can be encoded using empty <gi>ge:undo</gi> elements as follows:
<!-- undoing1.xml --><egXML xmlns="http://www.tei-c.org/ns/Examples">
<ge:line>This is <del stage="#s2" xml:id="del_1" rend="overstrike"><ge:undo
target="#del_1" spanTo="#X02" rend="dotted" stage="#s3"/>just some
<anchor xml:id="X02"/>sample <ge:undo target="#del_1" spanTo="#x4"
rend="dotted" stage="#s3"/>text,<anchor xml:id="x4"/> we need
</del><add stage="#s2">not </add>a real example.</ge:line>
</egXML> The <att>target</att> attributes on <gi>undo</gi> point to
the elements representing the initial acts (the
deletions) which are undone. The <att>rend</att>
attribute indicates the way this reversion is
indicated. The <att>spanTo</att> attributes
points to the <gi>anchor</gi> which marks the
point in the text where this reversion
finishes. Since two non-contiguous parts
of the deletion are undone, there are two
<gi>ge:undo</gi> elements, each with the
appropriate attribute values. If
<att>spanTo</att> is not supplied, the
<gi>ge:undo</gi> is understood to refer to the
whole of the text contained by the element indicated
by its <att>target</att> attribute. </p>
</div>
<!-- my version in talk is different -->
<div>
<head>Instant corrections</head>
<p>The use of tags such as <gi>del</gi> and <gi>add</gi> necessarily implies that
the modification concerned was made at some time after the original writing. An
exception to this is where a false start or <soCalled>instant</soCalled>
correction has been identified: the author starts to write, and then
immediately corrects what has been written. A special mechanism is provided for
this case: an <att>instant</att> attribute has been introduced to
<ident>att.editLike</ident>, whose datatype is
<ident>data.xTruthValue</ident> and <code>false</code> is the default value.
When the value of <att>instant</att> is <code>true</code> this indicates that
the addition or deletion is considered to belong to the same writing stage as
the rest of the unmodified document, while <code>false</code> means some stage
later than the current stage.</p>
<p> An example of false start can be seen in the following line: <figure>
<graphic url="examples/whitman03a.jpg" width="400px"/>
<head>http://www.whitmanarchive.org/resources/sleepers/uva.00256.001.jpg</head>
</figure> in which we can detect the following sequence of events: <list
type="ordered">
<item>The letter T is written and then immediately deleted</item>
<item>The word The is written, deleted, and replaced by the word His</item>
<item>The added word His is then deleted</item>
<item>The initial letter i of the words iron necklace is overwritten with a
capital I</item>
</list> To indicate that the first of these acts must have taken place before
the others, we might encode this revision campaign as follows:
<!-- whitman03a.xml --><egXML xmlns="http://www.tei-c.org/ns/Examples">
<ge:line><del instant="true">T</del>
<subst>
<del>The</del>
<add place="above">
<del rend="overstrike">His</del>
</add>
</subst>
<subst>
<del rend="overwritten">i</del>
<add place="superimposed">I</add>
</subst>ron necklace</ge:line>
</egXML>
</p>
</div>
</div>
</div>
<div>
<head>The dossier level</head>
<p>The term <term>dossier</term> is used to refer to the set of documents which a
genetic editor considers as having contributed to the evolution of a particular text.
These may include drafts, revisions, or documents related in other ways.</p>
<div>
<head>Assembling a dossier</head>
<p>Since a dossier needs to be assembled from many documents, which will most
probably be encoded in distinct TEI documents, one way to assemble a dossier’s
contents for further processing would be to use the existing
<gi>teiCorpus</gi> element in combination with <ref
target="http://www.w3.org/TR/xinclude/">XML
Inclusions (XInclude)</ref>. The
<gi>teiCorpus</gi> construct provides for a
common place to record metadata
regarding the organization of the dossier itself, independently of
the metadata regarding each particular document contained within it, which would
be held in a discrete TEI Header attached to that particular encoded document. The
XInclude mechanism provides a convenient means of managing the
many separate resources which are likely to be needed to constitute a complete
dossier. For example, supposing we have a dossier comprising three documents, each
of which has been encoded in its own document:</p>
<!-- dossier_1.xml -->
<egXML xmlns="http://www.tei-c.org/ns/Examples">
<teiCorpus xmlns="http://www.tei-c.org/ns/1.0"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:ge="http://www.tei-c.org/ns/geneticEditions">
<![CDATA[<teiHeader>
<!-- information about the dossier -->
</teiHeader>
<xi:include href="document1.xml"/>
<xi:include href="document2.xml"/>
<xi:include href="document3.xml"/>
]]>
</teiCorpus>
</egXML>
<p>(Note that each of the documents referenced (<ident>document1.xml</ident> etc)
should contain a complete <gi>TEI</gi> element.)</p>
</div>
<div>
<head>Genetic Graphs</head>
<p>Looking at the documents which constitute a given dossier, there are many types of
relationships which can be identified, both amongst complete documents, and
amongst parts of those documents, including alterations, revisions, stages and
other compositional phenomena. A further complexity arises if for example an
author chooses to correct two different versions at the same time,<note
place="foot">Manzoni, for instance, used to modify an old draft to see how a
new variant fitted with the context before copying it into a new draft.</note>.
We may thus need to express that two or more documents are related in different
ways; for instance, one document may be the sequel of another, one may have been
drafted at the same time as another, one may contain material or treat topics
related to those of another, for example a newspaper article may inspire or be
quoted by a given work.</p>
<p>We propose to model the <soCalled>genetic relations</soCalled> one can deduce from
such penomena by means of a <term>graph</term>. <note place="foot">Graph-like data
structures have many applications. An early proposal to use such a formalism
for handling textual variation is <bibl><author>Sperberg-McQueen, C.M.</author>
(1989). <title>A directed-graph data structure for text
manipulation</title>. In: <title>ICCH/ALLC Conference. The Dynamic Text at
the University of Toronto.</title>
<ref type="URL"
>http://www.w3.org/People/cmsmcq/1989/rhine-delta-abstract.html</ref></bibl>.
For a recent one, see <bibl><author>Desmond Schmidt</author>
<author>Robert Colomb</author> (2009): <title>A data structure for
representing multi-version texts online</title> (in <title level="s"
>International Journal of Human-Computer Studies</title>,
<biblScope>Volume 67 , Issue 6 (June 2009)</biblScope>
<biblScope type="pp">497-514 </biblScope>
</bibl>
</note> A graph is a mathematical representation composed of <term>node</term>s
and <term>arcs</term>. Nodes represent objects, which are related: Typical objects
in our case are documents, document components, text stages (as defined in <ptr
target="#stages"/> below) or even single phenomena (acts of writing or a
textual alterations). Each arc between two nodes then represents a relation,
in our case a genetic relation, between the two
objects it links. Arcs may be typed and directed to further specify the kind of
relationship they represent. For our purposes one can assume that a typical
genetic graph is directed and acyclic, because we generally expect the
<term>paths</term> through a genetic graph (formally defined as an ordered set
of nodes traversed by following its arcs) to represent genetic processes with an
implied chronological order. In this respect a genetic graph resembles a family tree,
in that there is a single terminal node,
representing the final or published version
of a text with many preceding nodes linking to it, either directly or via other
nodes, each of which represents draft versions of various parts. Alternatively,
there may be more than one final state, e. g. in the case of multiple published
texts or unpublished fragments.</p>
<p>A visual representation of an exemplary genetic graph might look as follows:<figure>
<graphic url="examples/geneticRel.png" width="400px"/>
</figure></p>
<p>What can be seen here is on a very abstract level: The nodes (drawn as rectangular
shapes with letters) represent parts of the dossier, the directed arcs (drawn as
lines with arrows) represent relationships between the parts (probably of an
evolutionary type). Thus the graph can be read as A and B being precursors of C, C
in turn leading to F, F to G, G to H, and H leading to the final state Z, which
additionally draws influences from E and D.</p>
<p>All this abstract information can be encoded using the following elements (see
also the Guidelines chapter 19. Graphs, Networks, and Trees): <specList>
<specDesc key="graph" atts="type"/>
<specDesc key="node" atts="value"/>
<specDesc key="arc" atts="from to value"/>
</specList>
</p>
<!--geneticRel.xml -->
<egXML xmlns="http://www.tei-c.org/ns/Examples">
<graph type="directed">
<node xml:id="A" value="http://edition.net/witness/A">
<label>A</label>
</node>
<node xml:id="B" value="http://edition.net/witness/B">
<label>B</label>
</node>
<node xml:id="C" value="http://edition.net/witness/C">
<label>C</label>
</node>
<node xml:id="D" value="http://edition.net/witness/X#part1">
<label>D</label>
</node>
<node xml:id="E" value="http://edition.net/witness/X#part2">
<label>E</label>
</node>
<node xml:id="F" value="http://edition.net/witness/F">
<label>F</label>
</node>
<node xml:id="G" value="http://edition.net/witness/G">
<label>G</label>
</node>
<node xml:id="H" value="http://edition.net/witness/H">
<label>H</label>
</node>
<node xml:id="Z" value="http://edition.net/text/">
<label>Z</label>
</node>
<arc xml:id="AC" from="#A" to="#C"
value="http://edition.net/genetic/analysis#ac"/>
<arc xml:id="BC" from="#B" to="#C"
value="http://edition.net/genetic/analysis#bc"/>
<arc xml:id="CF" from="#C" to="#F"
value="http://edition.net/genetic/analysis#cf"/>
<arc xml:id="FG" from="#F" to="#G"
value="http://edition.net/genetic/analysis#fg"/>
<arc xml:id="GH" from="#G" to="#H"
value="http://edition.net/genetic/analysis#gh"/>
<arc xml:id="DZ" from="#D" to="#Z"
value="http://edition.net/genetic/analysis#dz"/>
<arc xml:id="EZ" from="#E" to="#Z"
value="http://edition.net/genetic/analysis#ez"/>
<arc xml:id="HZ" from="#H" to="#Z"
value="http://edition.net/genetic/analysis#hz"/>
</graph>
</egXML>
<p>Such an abstract graph structure can be easily imported into or exported from a
graph database, transformed into other XML-based representations of graph-based
data models like <ref target="http://www.w3.org/TR/REC-rdf-syntax/">RDF/XML</ref>,
or it can be serialized to <ref target="http://www.w3.org/TR/SVG11/">SVG</ref> for
interactive visualization.</p>
<!-- <p>The number of possible paths that might be drawn for a given dossier is not of
course limited in any way: the encoder may derive as many as they wish. They may
also wish to represent other forms of syntagmatic structure, for narratalogical or
other purposes, using essentially the same mechanism. </p> -->
<!-- TODO: show transformation of a path to a timeline -->
</div>
<div>
<head>Genetic analysis</head>
<p>With the graph’s abstract structure defined, one can now go on and specify what
the nodes and arcs actually represent. This is done by assigning properties to
them via the <att>value</att> attribute. In the example the nodes A-H point to
individual witnesses, D and E being an exception as they point to different parts
of the same witness. The node Z (the final state in our example) supposedly points
to the edited text and each arc’s value points to a resource, whose contents
comprise the <term>genetic analysis</term>, which underlies the assumed genetic
relations expressed in the graph.</p>
<p>[...]</p>
<!-- TODO: example for the contents of a genetic analysis with commentary, discussion of certainty etc. -->
</div>
<div>
<head>Constructing genetic graphs</head>
<p>It is highly unlikely, that editors will construct and encoded genetic graphs by
hand, unless the dossier is as simply structured as the given example. Rather a
typical workflow might be:</p>
<list type="ordered">
<item>The editor transcribes each witness in a separate TEI document.</item>
<item>During the transcription process phenomena of genetic relevance are
annotated with identifiers, that classify these phenoma as belonging to a
certain genetic process or that simply relates these phenomena in a
well-defined way.</item>
<item>By automatically collecting and evaluating all those annotations from all
transcribed documents, a preliminary graph is constructed, that can be
visualized and navigated.</item>
<item>Steps 1-3 are repeated up to the point, where the graph cannot be further
refined via this procedure.</item>
<item>Optionally, the automatically constructed graph can be annotated
manually.</item>
</list>
<p>For example in the genetic edition of Goethe’s Faust, the final text is known and
can therefore serve as a canonical reference system for constructing genetic
relations. Each verse has a unique number:</p>
<egXML xmlns="http://www.tei-c.org/ns/Examples">
<speaker>Faust.</speaker>
<lg>
<l n="354">Habe nun, ach! Philosophie,</l>
<l n="355">Juristerei und Medicin,</l>
<l n="356">Und leider auch Theologie!</l>
<l n="357">Durchaus studirt, mit heißem Bemühn.</l>
<l n="358">Da steh' ich nun, ich armer Thor!</l>
<l n="359">Und bin so klug als wie zuvor;</l>
</lg>
</egXML>
<p>This makes it possible to express genetic relations
by using these same verse numbers to index
corresponding verses or ranges of verse-numbers throughout their various
witnesses, stages or variants. Although a genetic graph generated from
the coindexed verses will not be of a very fine
granularity, it can be a useful preliminary base
for subsequent refinement. By incorporating metadata for the witnesses (especially
dating information) and results of collation eith other relevant information, the
graph can be enriched in an iterative manner and periodically checked for
consistency. Finally, together with the transcriptions, collation results, and a
critical apparatus it can be archived as an integral part of the genetic
edition.</p>
</div>
</div>
<div xml:id="collation">
<head>*Collation and Critical Apparatus</head>
<p>As noted <ref target="#alteration">above</ref>, not all kinds of variation within and
between documents are equivalent. For example, most people would regard authorial
modifications within a single draft or between subsequent drafts as having a
different significance from modifications assigned to scribal variation within a long
textual tradition, despite their formal similarities.</p>
<p>When a passage has been visibly deleted in one version of a text we will generally
mark it explicitly; if however a passage present in one version (A) is omitted in
another (B), it may be a matter of uncertainty as to whether it has been deleted from
B, or added to A. Even if this is certain (perhaps because the order of the two
versions is known), the omission from B of material in A is not entirely the same
phenomenon as an explicit deletion.</p>
<p>The addition (or deletion) of a segment from a version is normally a deliberate act
of the author and we would like to be able to record that in positive way; whether we
need another set of editorial elements or we should use the same set that are used
for transcription remains an open question. </p>
<p>Identifying additions or deletions on the basis of a comparison of different versions
of a text is possible, using existing TEI elements for critical editing such as
<gi>app</gi> and its child <gi>rdg</gi> elements. This method uses the argument
<foreign xml:lang="lat">e silentio</foreign>: for example, to identify that
something is missing from a witness, all available readings must be compared, and
there is no way of explicitly marking an absent (or additional) reading. For
instance, the 1856 edition of <title>Leaves of Grass</title>of the 1856 omits the
words <soCalled>all, all</soCalled> which are included in the 1881-82 version. We may
record this as an apparatus: <!-- app.xml --><egXML
xmlns="http://www.tei-c.org/ns/Examples">
<l n="22">And the enraged and treacherous dispositions <app>
<rdg wit="#Leaves81-82">, all, all</rdg>
<rdg wit="#Leaves56"/>
</app> sleep</l>
</egXML> but this does not indicate whether the words were deleted consciously from
the 1856 dedition, or added in the 1881 version. Furthermore, if we decided to use
the existing <gi>add</gi> or <gi>del</gi> elements within the <gi>rdg</gi>, for
example: <!-- app.xml --><egXML xmlns="http://www.tei-c.org/ns/Examples">
<l n="22">And the enraged and treacherous dispositions <app>
<rdg wit="#Leaves81-82">
<add>, all, all</add>
</rdg>
<rdg wit="#Leaves56"/>
</app>...</l>
</egXML> the result would be ambiguous: it might indicate that there is an explicit
addition (for example, by interlinear or marginal interpolation) within the 1881
text, or it might indicate that this addition appears as a result of collating the
1881 and 1856 texts. </p>
<!--
attach difference information to arcs; examples needed
need to invent a null-reading element for app
qualifications
standoff for readings
transposition can also be included in apparatus
-->
<!--
<list >
<item>Only one document has been entirely transcribed (perhaps the first or
the last version), while the others are only reconstructable via
collation, which can be stored within the same document or in a separate
one.</item>
<item>All documents composing a dossier have been transcribed and the
collation is stored in a separate document</item>
</list></p>
<div>
<head>One document is transcribed</head>
<p>If, beside the base-text which is fully transcribed, all extant witnesses
have to be reconstructed via collation, it is essential to be able to
distinguish alterations that happen within them and between witnesses. For
instance, using the existing tag set we could possibly encode as follows:
<egXML xmlns="http://www.tei-c.org/ns/Examples">
<l n="22">And the enraged and treacherous dispositions<app>
<lem wit="#Leaves81-82">
<add>, all, all</add>
</lem>
<rdg wit="#Leaves56"/>
</app> sleep</l>
</egXML></p>
<p>Nevertheless, this might force the intended usage of <gi>add</gi> as it
might imply that there is an addition (interlinear, marginal or wherever) on
the edition 1881-82 (a problem which will certainly be magnified with
manuscripts) which is not the case. -->
<p>One solution might be to use a different element (say <gi>ge:interAdd</gi>) for
addition implied by collation, reserving <gi>add</gi> for deletions that happen at
the document level. Another, if all the documents have been fully transcribed, might
be to use stand off techniques to represent the collation. This is a more promising
possibility which the workgroup has not yet fully explored. If all the alterations
occurring at document level are already encoded within each transcription, the
dossier-level collation will only need to point to passages within the separate files
and classify the types of readings resulting from the collation:
<!-- app.xml --><egXML xmlns="http://www.tei-c.org/ns/Examples">
<app xmlns="http://www.tei-c.org/ns/1.0">
<rdg wit="#Leaves81-82">
<span from="#v22-5" to="#v22-8" type="add"/>
</rdg>
<rdg wit="#Leaves56">
<span from="#v22-5" type="del"/>
</rdg>
</app>
</egXML>
</p>
</div>
<div>
<head>Manuscript and Dossier Levels</head>
<div xml:id="stages">
<head>Stages/ Revision campaigns</head>
<p>A major purpose of genetic editing is the identification of <soCalled>revision
campaigns</soCalled> or, more generally, <term>stages</term>. A genetic editor
needs to be able to assign a set of alterations (deletions, additions,
substitutions, transpositions, etc.) and/or an act of writing to a particular
stage, to indicate both that one or more of such phenomena preceded or followed
another and also to indicate that they are related in some way, for example that
one is a consequence of the other. To document this we need: <list>
<item>a system to assign phenomena to a particular stage</item>
<item>a way to characterize a stage, in itself and in relation to other
stages.</item>
</list></p>
<p>The existing element <gi>creation</gi> (within the TEI Header profile description)
is defined as the appropriate location for all information relating to the genesis
or production of a text. We modify it slightly to permit a new
<gi>stageNotes</gi> element which contains a number of <gi>stageNote</gi>
elements, one for each identified stage:
<listSpec>
<specDesc key="stageNotes" atts="ordered"/>
<specDesc key="stageNote"/>
</listSpec>
</p>
<p>In the following example taken from the genetic edition of Goethe’s
Faust, the editor has identified four distinct stages:</p>
<!-- faust_1.xml -->
<egXML xmlns="http://www.tei-c.org/ns/Examples">
<profileDesc>
<creation>
<ge:stageNotes ordered="true">
<ge:stageNote xml:id="ST-1">First stage, written in ink by a
writer</ge:stageNote>
<ge:stageNote xml:id="ST-2">Second stage, written in Goethe's hand using
pencil</ge:stageNote>
<ge:stageNote xml:id="ST-3">Fixation of the revised passages and
further revisions by Goethe using ink</ge:stageNote>
<ge:stageNote xml:id="ST-4">Addition of
another stanza in a different hand, probably
at a later stage</ge:stageNote>
</ge:stageNotes>
</creation>
</profileDesc>
</egXML>
<p>The <gi>stageNotes</gi> elements
carries an attribute <att>ordered</att>, which can take the values
<code>true</code> or <code>false</code> (the default). The attribute specifies
whether the order of child elements signifies a temporal order for the
revision campaigns which they document. In the Faust example above, the
editor has asserted that the four stages distinguished are ordered chronologically
according to the order of the <gi>stageNote</gi> elements. Note that asserting a
specific order early on, though probably one of the hardest tasks in a genetic
analysis, can considerably reduce the encoding effort in assigning textual alterations to
stages during the transcription, as we will see below. For instance
deletions can only be assigned to a stage that follows the one in which the
passage being deleted was written down. Hence, having a certain order of stages put in
place before transcription begins, will allow the encoder to reduce verbose
tagging, where default assumptions based on the natural order of actions can be
made.</p>
<p>If necessary, <gi>stageNotes</gi> elements can be nested hierarchically. This may
be helpful in two cases. Firstly one can build up hypotheses about related
revisions step-by-step, starting with stages of smaller coverage, whose members
are certainly related, and then in a subsequent pass grouping these stages in
turn, thereby extending their reach.</p>
<!-- stages.xml -->
<egXML xmlns="http://www.tei-c.org/ns/Examples">
<profileDesc>
<creation>
<ge:stageNotes>
<ge:stageNote xml:id="o">An unrelated stage note</ge:stageNote>
<ge:stageNotes xml:id="m" cert="low">
<ge:stageNote xml:id="m1">Alterations on one manuscript page, certainly
related</ge:stageNote>
<ge:stageNote xml:id="m2">Alterations on another manuscript page,
certainly related</ge:stageNote>
<ge:stageNote xml:id="p">Another unrelated stage note</ge:stageNote>
</ge:stageNotes>
</ge:stageNotes>
</creation>
</profileDesc>
</egXML>
<p>Another use case for nested <gi>stageNote</gi> elements would be the need to
express a <emph>partial</emph> ordering of revision campaigns.</p>
<!-- stages.xml -->
<egXML xmlns="http://www.tei-c.org/ns/Examples">
<ge:stageNotes ordered="true">
<ge:stageNote xml:id="ST1">The first stage</ge:stageNote>
<ge:stageNotes xml:id="STlast">
<!-- We have no indication, which of the following revision
campaigns took place first, but we know they followed ST1 -->.
<ge:stageNote xml:id="ST-rev1">A revision of the first stage</ge:stageNote>
<ge:stageNote xml:id="ST-rev2">Another revision of the first
stage</ge:stageNote>
</ge:stageNotes>
</ge:stageNotes>
</egXML>
<p>In addition to the possibility of ordering text stages in relation to each other,
<gi>stageNote</gi> elements may carry a number of attributes from the
<ident>att.datable</ident> class (<att>period</att>, <att>when</att>,
<att>notBefore</att>, <att>notAfter</att>, <att>from</att>, and <att>to</att>)
which allow each stage to be dated as exactly or inexactly as necessary, in the
same way as is currently possible for the TEI <gi>date</gi> element.</p>
<!-- Maybe note that absolute dates and relative order can conflict -->
<!-- stages.xml -->
<egXML xmlns="http://www.tei-c.org/ns/Examples">
<profileDesc>
<creation>
<date notAfter="1816-07-18"/>
<ge:stageNotes ordered="true">
<ge:stageNote xml:id="mod1" when="1816-07-16">The first draft of
<title>Persuasion</title> is completed by the <date>July 16
1816</date> written after the word <q>Finis</q> at <ref
target="#pers-30">page 30</ref>.</ge:stageNote>
<ge:stageNote xml:id="mod2" notBefore="1816-07-16">After the <date>16th
of July</date> Austen starts revision of the two final chapters, by
rewriting the end and adding a new block (<ref target="#transp-1"
>pages 32-35</ref>) to be inserted at <ref target="#insertion-p1"
>page 19</ref>. This stage is documented by the deletion of the
date (<date>July 16 1816</date>) at <ref target="#pers-30">page
30</ref>, and the addition of more text and of a new date
(<date>July 18. 1816</date>) at <ref target="#pers-31">page
31</ref></ge:stageNote>
<ge:stageNote notBefore="1816-07-18">Before publication, after <date>July
18th, 1816</date> chapters 10-11 were broken into three chapters,
10, 11, 12, as witnessed by the print.</ge:stageNote>
</ge:stageNotes>
</creation>
</profileDesc>
</egXML>
<p>Each <gi>stageNote</gi> element, apart from
declaring a text stage, may also contain references to other
annotations contained within the <gi>teiHeader</gi> or in the document (as shown
in the previous example). Such references, along with the textual content are
purely documentary and do not affect the textual
stage associated with any element thus referred
to. The association of a textual component with a
writing stage is always made explicitly, either by
pointing from the <gi>stageNote</gi> attribute
<att>target</att> to one or more elements, or
(for preference) by pointing from the element
concerned to the
<gi>stageNote</gi> element by means of its <att>stage</att> attribute:</p>
<!-- stages.xml -->
<egXML xmlns="http://www.tei-c.org/ns/Examples">
<ge:line stage="#firstStage">This is a <subst stage="#secondStage">
<del>house</del>
<add>mouse</add>
</subst>.</ge:line>
</egXML>
<p>This simple example shows the latter of the two options: The relevant stages are
declared in the header; then textual alterations and acts of writing are assigned
to them. So the whole sentence was realized in the first stage, while the
substitution of “house” with “mouse” happened at the second stage. <!--Here the
assumed ordering of the stages and default assumptions about the natural ordering
of the textual alterations allows to reduce the tagging considerably, as only the
addition has to be annotated, whereas the substitution and consequently the
deletion are assumed to happen at the same stage.--></p>
<p>A more complex and complete example:</p>
<!-- faust_1.xml -->
<egXML xmlns="http://www.tei-c.org/ns/Examples">
<profileDesc>
<creation>
<ge:stageNotes type="ordered">
<ge:stageNote xml:id="firstStage">First stage, written in ink by a
writer</ge:stageNote>
<ge:stageNote xml:id="secondStage">Revised by Goethe using
pencil</ge:stageNote>
<ge:stageNote xml:id="thirdStage">Fixation of the revised passages and
further revisions by Goethe using ink</ge:stageNote>
<ge:stageNote xml:id="fourthStage">Addition of another stanza, probably
at a later stage</ge:stageNote>
</ge:stageNotes>
</creation>
</profileDesc> [...] <div stage="#firstStage">
<l n="11656">
<subst>
<del>Ihr</del>
<add>
<ge:rewrite stage="#thirdStage">
<seg stage="#secondStage">Nun</seg>
</ge:rewrite>
</add>
</subst> wanſtige Schuften mit den Feuerbacken</l>
<l n="11657">Ihr glüht ſo recht vom Höllen Schwefel <subst
stage="#secondStage
#thirdStage">
<del>ſatt</del>
<add>feiſt</add>
</subst>.</l>
<l n="11658">
<delSpan spanTo="#anchor_delSpan_1" stage="#thirdStage"/>Ihr hagren,
triſten, krummgezog<subst>
<del>nen</del>
<add>ener</add>
</subst> Nacken</l>
<l>Wenn ihr nur piepſet iſt die Welt ſchon matt.<anchor
xml:id="anchor_delSpan_1"/></l>
</div>
</egXML>
<p>Note first, that a stage, once assigned to an element, is inherited by all
descendents of that element, unless overridden by a subsequent assignment. So in
the example above the three verses are assigned to the first stage initially. The
writing of <mentioned>Nun</mentioned> (as part of the substitution in the first verse) takes place in
the second stage and is repeated or fixated in the third. Also the
substitution in the second verse is done repeatedly: initially it takes place in
the second stage, but is fixated as a whole in the third.</p>
<p>As one can see, the interpretation of what the stage assignments mean for a
particular text passage and the actions upon it can be based on a number of
implicit assumptions and constraints which have the
effect of minimizing the amount of tagging necessary. If
it is desired to make these presuppositions more explicit, one can differentiate between
acts of writing and textual alterations and accordingly between their assignment
to stages as follows:</p>
<!-- faust_2.xml -->
<egXML xmlns="http://www.tei-c.org/ns/Examples">
<profileDesc>
<creation>
<ge:stageNotes type="ordered">
<ge:stageNote target="#zone_1 #subst_3">First stage, written in ink by a
writer</ge:stageNote>
<ge:stageNote
target="#zone_2 #mod_1 #line_1 #line_2 #subst_1 #subst_2
#subst_4 #delSpan_1"
>Revised by Goethe using pencil</ge:stageNote>
<ge:stageNote
target="#redo_1 #redo_2 #redo_3 #subst_1 #subst_2
#delSpan_1 #add_1"
>Fixation of the revised passages and further revisions by Goethe
using ink</ge:stageNote>
</ge:stageNotes>
</creation>
</profileDesc> [...] <ge:document>
<surface>
<zone xml:id="zone_1">
<ge:line xml:id="line_1">
<handShift new="#g_bl"/>
<ge:rewrite hand="#g_t" xml:id="redo_1">Nun</ge:rewrite>
</ge:line>
<ge:line><handShift new="#jo_t"/>Ihr wanſtige Schuften mit den
Feuerbacken</ge:line>
<ge:line xml:id="line_2">
<handShift new="#g_bl"/>
<ge:rewrite hand="#g_t" xml:id="redo_2">feiſt</ge:rewrite>
</ge:line>
<ge:line>Ihr glüht ſo recht vom Höllen Schwefel ſatt.</ge:line> [...]
</zone>
</surface>
</ge:document>
<text>
<body>
<l n="11656">
<subst xml:id="subst_1">
<del>Ihr</del>
<add>Nun</add>
</subst> wanſtige Schuften mit den Feuerbacken</l>
<l n="11657">Ihr glüht ſo recht vom Höllen Schwefel <subst xml:id="subst_2">
<del>ſatt</del>
<add>feiſt</add>
</subst>.</l>
</body>
</text>
</egXML>
<p>Here two transcriptions of the same passage are given, one from a documentary
perspective stressing the writing process, and one from the textual perspective
emphasizing textual alterations. The assignment to stages is also done
differently here, pointing from the stage notes to the text passages and
alterations in question. From the documentary perspective, the stage
assignments describe the writing process, in that they specify, which segment has
been written when and how often. From the textual
perspective, the markup
concentrates on the order of textual alterations and
makes no assumptions about
the order of writing.</p>
</div>
</div>
</body>
<back>
<div>
<head>ODD</head>
<p>TEI Extension for Genetic Editions -- preliminary version</p>
<schemaSpec ident="geneticTEI" docLang="en" xml:lang="en" targetLang="en">
<!-- =============== Modules =============== -->
<moduleRef key="core"/>
<moduleRef key="tei"/>
<moduleRef key="header"/>
<moduleRef key="textstructure"/>
<moduleRef key="certainty"/>
<moduleRef key="analysis"/>
<moduleRef key="drama"/>
<moduleRef key="linking"/>
<moduleRef key="msdescription"/>
<moduleRef key="nets"/>
<moduleRef key="figures"/>
<moduleRef key="textcrit"/>
<moduleRef key="transcr"/>
<moduleRef key="gaiji"/>
<moduleRef key="namesdates"/>
<elementSpec module="core" ident="analytic" mode="delete"/>
<elementSpec module="core" ident="biblItem" mode="delete"/>
<elementSpec module="core" ident="biblStruct" mode="delete"/>
<elementSpec module="core" ident="binaryObject" mode="delete"/>
<elementSpec module="header" ident="broadcast" mode="delete"/>
<elementSpec module="analysis" ident="cl" mode="delete"/>
<elementSpec module="analysis" ident="c" mode="delete"/>
<elementSpec module="textstructure" mode="delete" ident="div1"/>
<elementSpec module="textstructure" mode="delete" ident="div2"/>
<elementSpec module="textstructure" mode="delete" ident="div3"/>
<elementSpec module="textstructure" mode="delete" ident="div4"/>
<elementSpec module="textstructure" mode="delete" ident="div5"/>
<elementSpec module="textstructure" mode="delete" ident="div6"/>
<elementSpec module="textstructure" mode="delete" ident="div7"/>
<elementSpec module="header" ident="equipment" mode="delete"/>
<elementSpec module="core" ident="equiv" mode="delete"/>
<elementSpec module="header" ident="fsdDecl" mode="delete"/>
<elementSpec module="core" ident="headItem" mode="delete"/>
<elementSpec module="core" ident="headLabel" mode="delete"/>
<elementSpec module="core" ident="meeting" mode="delete"/>
<!-- <elementSpec module="figures" ident="table" mode="delete"/>-->
<elementSpec module="header" ident="metDecl" mode="delete"/>
<elementSpec module="header" ident="metSym" mode="delete"/>
<elementSpec module="core" ident="monogr" mode="delete"/>
<elementSpec module="core" ident="postBox" mode="delete"/>
<elementSpec module="core" ident="postCode" mode="delete"/>
<elementSpec module="header" ident="recording" mode="delete"/>
<elementSpec module="header" ident="recordingStmt" mode="delete"/>
<elementSpec module="header" ident="state" mode="delete"/>
<elementSpec module="header" ident="stdVals" mode="delete"/>
<elementSpec module="core" ident="street" mode="delete"/>
<!--elementSpec module="header" ident="tagsDecl" mode="delete"/-->
<elementSpec module="analysis" ident="w" mode="delete"/>
<!--elementSpec module="header" ident="tagUsage" mode="delete"/-->
<elementSpec module="core" ident="imprint" mode="delete"/>
<elementSpec module="header" ident="rendition" mode="delete"/>
<!--elementSpec module="header" ident="namespace" mode="delete"/-->
<elementSpec module="namesdates" ident="addName" mode="delete"/>
<elementSpec module="namesdates" ident="age" mode="delete"/>
<elementSpec module="namesdates" ident="birth" mode="delete"/>
<elementSpec module="namesdates" ident="bloc" mode="delete"/>
<elementSpec module="namesdates" ident="death" mode="delete"/>
<elementSpec module="namesdates" ident="district" mode="delete"/>
<elementSpec module="namesdates" ident="education" mode="delete"/>
<elementSpec module="namesdates" ident="event" mode="delete"/>
<elementSpec module="namesdates" ident="faith" mode="delete"/>
<elementSpec module="namesdates" ident="floruit" mode="delete"/>
<elementSpec module="namesdates" ident="forename" mode="delete"/>
<elementSpec module="namesdates" ident="genName" mode="delete"/>
<elementSpec module="namesdates" ident="geo" mode="delete"/>
<elementSpec module="namesdates" ident="geogFeat" mode="delete"/>
<elementSpec module="namesdates" ident="geogName" mode="delete"/>
<elementSpec module="namesdates" ident="langKnowledge" mode="delete"/>
<elementSpec module="namesdates" ident="langKnown" mode="delete"/>
<elementSpec module="namesdates" ident="lisEvent" mode="delete"/>
<elementSpec module="namesdates" ident="lystNym" mode="delete"/>
<elementSpec module="namesdates" ident="listOrg" mode="delete"/>
<elementSpec module="namesdates" ident="listPerson" mode="delete"/>
<elementSpec module="namesdates" ident="listPlace" mode="delete"/>
<elementSpec module="namesdates" ident="location" mode="delete"/>
<elementSpec module="namesdates" ident="nameLink" mode="delete"/>
<elementSpec module="namesdates" ident="nationality" mode="delete"/>
<elementSpec module="namesdates" ident="nym" mode="delete"/>
<elementSpec module="namesdates" ident="occupation" mode="delete"/>
<elementSpec module="namesdates" ident="offset" mode="delete"/>
<elementSpec module="namesdates" ident="org" mode="delete"/>
<elementSpec module="namesdates" ident="orgName" mode="delete"/>
<elementSpec module="namesdates" ident="person" mode="delete"/>
<elementSpec module="namesdates" ident="personGrp" mode="delete"/>
<elementSpec module="namesdates" ident="place" mode="delete"/>
<elementSpec module="namesdates" ident="population" mode="delete"/>
<elementSpec module="namesdates" ident="region" mode="delete"/>
<elementSpec module="namesdates" ident="residence" mode="delete"/>
<elementSpec module="namesdates" ident="roleName" mode="delete"/>
<elementSpec module="namesdates" ident="sex" mode="delete"/>
<elementSpec module="namesdates" ident="socecStatus" mode="delete"/>
<elementSpec module="namesdates" ident="surname" mode="delete"/>
<elementSpec module="namesdates" ident="terrain" mode="delete"/>
<elementSpec module="namesdates" ident="trait" mode="delete"/>
<!-- =============== Content models for the documentary view =============== -->
<classSpec ident="model.zonePart" type="model" mode="add">
<desc>elements which can form part of a zone</desc>
</classSpec>
<classSpec ident="model.linePart" type="model" mode="add">
<desc>elements which can form part of a line</desc>
</classSpec>
<!-- =============== Topographical document structure =============== -->
<elementSpec ident="document" ns="http://www.tei-c.org/ns/geneticEditions" mode="add">
<desc>contains a document-centric transcription of a primary source, providing
topographical information as well as transcription</desc>
<classes>
<memberOf key="model.resourceLike"/>
<memberOf key="att.global"/>
</classes>
<content>
<rng:oneOrMore>
<rng:ref name="surface"/>
<rng:zeroOrMore>
<rng:ref name="model.global.edit"/>
</rng:zeroOrMore>
</rng:oneOrMore>
</content>
</elementSpec>
<elementSpec ident="surface" module="physdesc" mode="change">
<classes mode="change">
<memberOf key="att.typed" mode="add"/>
</classes>
<content>
<rng:zeroOrMore>
<rng:choice>
<rng:ref name="model.global"/>
<rng:ref name="model.glossLike"/>
<rng:ref name="model.graphicLike"/>
<rng:ref name="zone"/>
<rng:ref name="patch"/>
</rng:choice>
</rng:zeroOrMore>
</content>
</elementSpec>
<elementSpec ident="patch" ns="http://www.tei-c.org/ns/geneticEditions" mode="add">
<desc>contains a part of a written surface which was originally physically
distinct but became attached to it at the time that one or more written zones
were created.</desc>
<classes>
<memberOf key="att.coordinated"/>
<memberOf key="att.global"/>
<memberOf key="att.typed"/>
</classes>
<content>
<rng:zeroOrMore>
<rng:choice>
<rng:text/>
<rng:ref name="model.global"/>
<rng:ref name="zone"/>
</rng:choice>
</rng:zeroOrMore>
</content>
<attList>
<attDef ident="binder" mode="add">
<desc>Describe the method by which a patch is or was connected to the main
surface</desc>
<datatype>
<ref xmlns="http://relaxng.org/ns/structure/1.0" name="data.enumerated"/>
</datatype>
<valList type="open">
<valItem ident="glued">
<desc>patch is glued in place</desc>
</valItem>
<valItem ident="pinned">
<desc>patch is pinned or stapled in place</desc>
</valItem>
<valItem ident="sewn">
<desc>patch is sewn in place</desc>
</valItem>
</valList>
</attDef>
<attDef ident="flipping" mode="add">
<desc>indicates whether the patch is attached and folded in such a way as to
provide two writing surfaces</desc>
<datatype>
<ref xmlns="http://relaxng.org/ns/structure/1.0" name="data.truthValue"/>
</datatype>
</attDef>
<attDef ident="height">
<desc>height of the patch</desc>
<datatype>
<ref xmlns="http://relaxng.org/ns/structure/1.0" name="data.outputMeasurement"/>
</datatype>
</attDef>
<attDef ident="width">
<desc>width of the patch</desc>
<datatype>
<ref xmlns="http://relaxng.org/ns/structure/1.0" name="data.outputMeasurement"/>
</datatype>
</attDef>
</attList>
</elementSpec>
<elementSpec ident="zone" module="physdesc" mode="change">
<classes mode="change">
<memberOf key="att.coordinated" mode="add"/>
<memberOf key="model.zonePart" mode="add"/>
</classes>
<content>
<rng:zeroOrMore>
<rng:choice>
<rng:text/>
<rng:ref name="model.zonePart"/>
<rng:ref name="model.global"/>
</rng:choice>
</rng:zeroOrMore>
</content>
<attList>
<attDef ident="rotate" mode="add">
<desc>indicates the amount by which this zone has been rotated clockwise,
with respect to the normal orientation of the parent <gi>surface</gi>
element as implied by the dimensions given in the <gi>msDesc</gi> section
or by the coordinates of the <gi>surface</gi> itself. The orientation is
expressed in arc degrees.</desc>
<datatype minOccurs="1" maxOccurs="1">
<rng:ref name="data.count"/>
</datatype>
<defaultVal>0</defaultVal>
</attDef>
</attList>
</elementSpec>
<elementSpec ident="line" ns="http://www.tei-c.org/ns/geneticEditions" mode="add">
<desc>contains the transcription of a topographic line in the source
document</desc>
<classes>
<memberOf key="model.zonePart"/>
<memberOf key="att.typed"/>
<memberOf key="att.global"/>
</classes>
<content>
<rng:zeroOrMore>
<rng:choice>
<rng:text/>
<rng:ref name="model.global"/>
<rng:ref name="model.linePart"/>
</rng:choice>
</rng:zeroOrMore>
</content>
</elementSpec>
<!-- =============== Text stages =============== -->
<classSpec ident="att.staged" type="atts" mode="add" module="tei">
<desc>groups elements which can be assigned to a specific text stage by means of
the attributes it provides.</desc>
<attList>
<attDef ident="stage" mode="add">
<desc>points to one or more <gi>stageNote</gi> elements which contain a
description of a text-stage to which the editors think the alteration/
text passage marked by the element bearing this attribute (and its
children) belongs.</desc>
<datatype minOccurs="1" maxOccurs="unbounded">
<rng:ref name="data.pointer"/>
</datatype>
</attDef>
</attList>
</classSpec>
<classSpec type="atts" ident="att.global" mode="change" module="tei">
<classes>
<memberOf key="att.global.linking"/>
<memberOf key="att.global.analytic"/>
<memberOf key="att.global.facs"/>
<memberOf key="att.staged" mode="add"/>
</classes>
</classSpec>
<elementSpec ident="creation" mode="change">
<content>
<rng:ref name="macro.phraseSeq.limited"/>
<rng:optional>
<rng:ref name="stageNotes"/>
</rng:optional>
</content>
</elementSpec>
<elementSpec ident="stageNotes" ns="http://www.tei-c.org/ns/geneticEditions"
mode="add">
<desc>contains one or more descriptions of the stages which have been identified
in the genesis of a text.</desc>
<classes>
<memberOf key="att.global"/>
<memberOf key="att.typed"/>
</classes>
<content>
<rng:oneOrMore>
<rng:choice>
<rng:ref name="stageNotes"/>
<rng:ref name="stageNote"/>
</rng:choice>
</rng:oneOrMore>
</content>
<attList>
<attDef ident="ordered" mode="add">
<desc>indicates whether or not the order in which
the children of this element are presented is significant</desc>
<datatype>
<ref xmlns="http://relaxng.org/ns/structure/1.0" name="data.truthValue"/>
</datatype>
<defaultVal>true</defaultVal>
</attDef>
</attList>
</elementSpec>
<elementSpec ident="stageNote" ns="http://www.tei-c.org/ns/geneticEditions"
mode="add">
<desc>documents a particular stage in the genesis of a text.</desc>
<classes>
<memberOf key="att.datable"/>
<memberOf key="att.editLike"/>
<memberOf key="att.global"/>
<memberOf key="att.typed"/>
</classes>
<content>
<rng:zeroOrMore>
<rng:choice>
<rng:ref name="macro.specialPara"/>
<rng:ref name="stageNote"/>
</rng:choice>
</rng:zeroOrMore>
</content>
<attList>
<attDef ident="target" mode="add">
<desc>points to one or more elements that belong to this stage.</desc>
<datatype minOccurs="1" maxOccurs="unbounded">
<rng:ref name="data.pointer"/>
</datatype>
</attDef>
</attList>
</elementSpec>
<!-- =============== Textual alterations =============== -->
<elementSpec ident="mod" ns="http://www.tei-c.org/ns/geneticEditions" mode="add">
<desc>represents any kind of modification identified within a text at a documentary level.</desc>
<classes>
<memberOf key="model.pPart.transcriptional"/>
<memberOf key="att.global"/>
<memberOf key="att.transcriptional"/>
<memberOf key="att.typed"/>
</classes>
<content>
<rng:ref name="macro.paraContent"/>
</content>
</elementSpec>
<elementSpec ident="modSpan" ns="http://www.tei-c.org/ns/geneticEditions" mode="add">
<desc>represents any kind of modification identified
within a text at a documentary level, where this
extends over other XML markup constructs in the document.</desc>
<classes>
<memberOf key="model.global.edit"/>
<memberOf key="att.spanning"/>
<memberOf key="att.global"/>
<memberOf key="att.transcriptional"/>
<memberOf key="att.typed"/>
</classes>
<content>
<rng:empty/>
</content>
</elementSpec>
<elementSpec ident="subst" module="transcr" mode="change">
<!-- should be in different namespace -->
<content>
<rng:group>
<rng:group>
<rng:ref name="model.pPart.transcriptional"/>
</rng:group>
<rng:oneOrMore>
<rng:choice>
<rng:text/>
<rng:ref name="model.pPart.transcriptional"/>
</rng:choice>
</rng:oneOrMore>
</rng:group>
</content>
<attList>
<attDef ident="type" mode="add">
<desc>The type of substitution.</desc>
<datatype minOccurs="1" maxOccurs="1">
<rng:ref name="data.name"/>
</datatype>
</attDef>
</attList>
</elementSpec>
<elementSpec ident="transposeGrp" ns="http://www.tei-c.org/ns/geneticEditions"
mode="add">
<desc>supplies a list of transpositions indicated at some point in the text,
typically by means of metamarks.</desc>
<classes>
<memberOf key="model.profileDescPart"/>
<memberOf key="model.global.meta"/>
<memberOf key="att.global"/>
</classes>
<content>
<rng:oneOrMore>
<rng:ref name="transpose"/>
</rng:oneOrMore>
</content>
</elementSpec>
<elementSpec ident="transpose" ns="http://www.tei-c.org/ns/geneticEditions"
mode="add">
<desc> describes a single textual transposition as an ordered list of at least two
pointers specifying the order in which the elements indicated should be
re-combined. </desc>
<classes>
<memberOf key="att.global"/>
</classes>
<content>
<rng:group>
<rng:ref name="ptr"/>
<rng:oneOrMore>
<rng:ref name="ptr"/>
</rng:oneOrMore>
</rng:group>
</content>
</elementSpec>
<!-- =============== Undo/Redo/Rewrite =============== -->
<elementSpec ident="undo" ns="http://www.tei-c.org/ns/geneticEditions" mode="add">
<desc>points to any marked-up intervention in a
text which has subsequently been
marked as to be cancelled or undone.</desc>
<classes>
<memberOf key="model.pPart.transcriptional"/>
<memberOf key="att.global"/>
<memberOf key="att.spanning"/>
<memberOf key="att.transcriptional"/>
</classes>
<content>
<rng:empty/>
</content>
<attList>
<attDef ident="target" mode="add">
<desc>points to the element representing the intervention to be undone.</desc>
<datatype minOccurs="1" maxOccurs="1">
<rng:ref name="data.pointer"/>
</datatype>
</attDef>
</attList>
</elementSpec>
<classSpec type="atts" ident="att.repeatable">
<attList>
<attDef ident="cause">
<desc>documents the presumed cause of the repeated act of writing.</desc>
<datatype>
<rng:ref name="data.enumerated"/>
</datatype>
<valList type="closed">
<valItem ident="fix">
<desc>repeated for the purpose of fixation</desc>
</valItem>
<valItem ident="unclear">
<desc>repeated to clarify a previously illegible or badly written text
or mark</desc>
</valItem>
</valList>
</attDef>
</attList>
</classSpec>
<elementSpec ident="redo" ns="http://www.tei-c.org/ns/geneticEditions" mode="add">
<desc>points to a marked-up intervention in a
text which has subsequently been
marked for a second time in a different way. </desc>
<classes>
<memberOf key="model.pPart.transcriptional"/>
<memberOf key="att.global"/>
<memberOf key="att.repeatable"/>
<memberOf key="att.spanning"/>
<memberOf key="att.transcriptional"/>
</classes>
<content>
<rng:empty/>
</content>
<attList>
<attDef ident="target" mode="add">
<desc>points to the element representing
the intervention which is to be repeated.</desc>
<datatype minOccurs="1" maxOccurs="1">
<rng:ref name="data.pointer"/>
</datatype>
</attDef>
</attList>
</elementSpec>
<elementSpec ident="rewrite" ns="http://www.tei-c.org/ns/geneticEditions" mode="add">
<desc>contains a sequence of text which has been rewritten by the author, for
example by over-inking, to clarify or fix it.</desc>
<classes>
<memberOf key="model.pPart.transcriptional"/>
<memberOf key="model.global"/>
<memberOf key="att.global"/>
<memberOf key="att.repeatable"/>
<memberOf key="att.spanning"/>
<memberOf key="att.transcriptional"/>
</classes>
<content>
<rng:ref name="macro.paraContent"/>
</content>
<remarks>
<p>Multiple rewritings are indicated by nesting one <gi>rewrite</gi> within
another. In principle, a rewriting differs from a substitution in that
second and subsequent rewrites do not materially alter the content of an
element. Where there are minor changes made during the rewriting however
these may be marked up using <gi>del</gi>, <gi>add</gi>, etc. with an
appropriate value for the <att>stage</att> attribute.</p>
</remarks>
</elementSpec>
<!-- =============== Authorial changes =============== -->
<elementSpec ident="metaMark" ns="http://www.tei-c.org/ns/geneticEditions" mode="add">
<desc>contains any textual or graphical mark in
a written text intended to signal how the text
should be read and not forming part of the text itself.</desc>
<classes>
<memberOf key="model.pPart.transcriptional"/>
<memberOf key="att.spanning"/>
<memberOf key="att.placement"/>
<memberOf key="att.global"/>
</classes>
<!--, for example some which
functional but not part of the text. Could transform the text, like a
strikethrough, or provide meta-information, like a date-->
<content>
<rng:ref name="macro.specialPara"/>
</content>
<attList>
<attDef ident="function" mode="add">
<desc>describes the function (e.g. add, delete, alternate) of the
mark.</desc>
<datatype minOccurs="1">
<rng:ref name="data.word"/>
</datatype>
</attDef>
<attDef ident="target">
<desc>indicates the element(s) to which the function of the meta-mark
refers. Pointers are separated by a white space</desc>
<datatype minOccurs="1" maxOccurs="unbounded">
<rng:ref name="data.pointer"/>
</datatype>
</attDef>
</attList>
</elementSpec>
<elementSpec ident="used" ns="http://www.tei-c.org/ns/geneticEditions" mode="add">
<desc>a passage of text which has been marked as used, usually
meaning that it has been transcribed to a fair copy.</desc>
<classes>
<memberOf key="model.pPart.transcriptional"/>
<memberOf key="model.global"/>
<memberOf key="att.spanning"/>
<memberOf key="att.global"/>
</classes>
<content>
<rng:empty/>
</content>
<remarks><p>The mark is often a
strikethrough, but can be any author-specific mark.</p></remarks>
</elementSpec>
<!-- =============== Genetic Groups =============== -->
<elementSpec ident="geneticGrp" mode="add"
ns="http://www.tei-c.org/ns/geneticEditions">
<desc>Group texts and document which are somehow related in a genetic
process</desc>
<classes>
<memberOf key="model.profileDescPart"/>
<memberOf key="att.global"/>
</classes>
<content>
<rng:oneOrMore>
<rng:ref name="geneticNote"/>
</rng:oneOrMore>
</content>
</elementSpec>
<elementSpec ident="geneticNote" mode="add"
ns="http://www.tei-c.org/ns/geneticEditions">
<desc>describes a particular set of documents or document fragments which are
considered to be mutually associated in some way.</desc>
<classes>
<memberOf key="att.typed"/>
<memberOf key="att.editLike"/>
<memberOf key="att.global"/>
</classes>
<content>
<rng:oneOrMore>
<rng:ref name="linkGrp"/>
</rng:oneOrMore>
<rng:oneOrMore>
<rng:ref name="model.pLike"/>
</rng:oneOrMore>
</content>
</elementSpec>
<!-- =============== Adjust existing classes to new schema =============== -->
<elementSpec ident="arc" module="nets" mode="change">
<attList>
<attDef ident="value" usage="opt" mode="add">
<equiv/>
<desc>provides the value of an arc, which is a feature structure or other
analytic element.</desc>
<datatype>
<rng:ref name="data.pointer"/>
</datatype>
<valDesc>A valid identifier.</valDesc>
<remarks>
<p>Copied from the node element to support full-featured property graphs,
where also arcs may be annotated.</p>
</remarks>
</attDef>
</attList>
</elementSpec>
<classSpec type="atts" ident="att.editLike" mode="change">
<attList>
<attDef ident="instant" mode="add">
<desc>Is this an instant revision?</desc>
<datatype>
<rng:ref name="data.xTruthValue"/>
</datatype>
<defaultVal>false</defaultVal>
</attDef>
</attList>
</classSpec>
<!-- TODO: We are note sure, whether it is wise to add so much to the documentary markup -->
<classSpec type="model" ident="model.gLike" mode="change">
<classes mode="change">
<memberOf key="model.zonePart" mode="add"/>
<memberOf key="model.linePart" mode="add"/>
</classes>
</classSpec>
<classSpec type="model" ident="model.segLike" mode="change">
<classes mode="change">
<memberOf key="model.zonePart" mode="add"/>
<memberOf key="model.linePart" mode="add"/>
</classes>
</classSpec>
<classSpec type="model" ident="model.hiLike" mode="change">
<classes mode="change">
<memberOf key="model.zonePart" mode="add"/>
<memberOf key="model.linePart" mode="add"/>
</classes>
</classSpec>
<classSpec type="model" ident="model.pPart.editorial" mode="change">
<classes mode="change">
<memberOf key="model.zonePart" mode="add"/>
<memberOf key="model.linePart" mode="add"/>
</classes>
</classSpec>
<classSpec type="model" ident="model.pPart.transcriptional" mode="change">
<classes mode="change">
<memberOf key="model.zonePart" mode="add"/>
<memberOf key="model.linePart" mode="add"/>
</classes>
</classSpec>
<classSpec type="model" ident="model.pPart.msdesc" mode="change">
<classes mode="change">
<memberOf key="model.zonePart" mode="add"/>
<memberOf key="model.linePart" mode="add"/>
</classes>
</classSpec>
<elementSpec ident="unclear" module="core" mode="change">
<classes mode="change">
<memberOf key="att.editLike" mode="add"/>
<memberOf key="att.typed" mode="add"/>
</classes>
</elementSpec>
<elementSpec ident="table" mode="change">
<classes mode="change">
<memberOf key="model.zonePart" mode="add"/>
</classes>
</elementSpec>
<!-- add milestone to att.spanning (this should be done for all
model.milestoneLike elements actually -->
<elementSpec ident="milestone" module="core" mode="change">
<classes>
<memberOf key="att.spanning"/>
<memberOf key="model.milestoneLike"/>
<memberOf key="att.typed"/>
<memberOf key="att.sourced"/>
</classes>
</elementSpec>
<!-- =============== XInclude support =============== -->
<elementSpec ident="include" ns="http://www.w3.org/2001/XInclude" mode="add">
<desc>The W3C XInclude element</desc>
<classes>
<memberOf key="model.common"/>
<memberOf key="model.headerPart"/>
</classes>
<content>
<rng:optional>
<rng:ref name="fallback"/>
</rng:optional>
</content>
<attList>
<attDef ident="href">
<desc>pointer to the resource being included</desc>
<datatype>
<rng:ref name="data.pointer"/>
</datatype>
</attDef>
<attDef ident="parse" usage="opt">
<defaultVal>xml</defaultVal>
<valList type="closed">
<valItem ident="xml"/>
<valItem ident="text"/>
</valList>
</attDef>
<attDef ident="xpointer" usage="opt">
<datatype>
<rng:text/>
</datatype>
</attDef>
<attDef ident="encoding" usage="opt">
<datatype>
<rng:text/>
</datatype>
</attDef>
<attDef ident="accept" usage="opt">
<datatype>
<rng:text/>
</datatype>
</attDef>
<attDef ident="accept-charset" usage="opt">
<datatype>
<rng:text/>
</datatype>
</attDef>
<attDef ident="accept-language" usage="opt">
<datatype>
<rng:text/>
</datatype>
</attDef>
</attList>
</elementSpec>
<elementSpec ident="fallback" ns="http://www.w3.org/2001/XInclude" mode="add">
<desc>Wrapper for fallback elements if an XInclude fails</desc>
<content>
<rng:ref name="AnyThing"/>
</content>
</elementSpec>
<macroSpec type="pe" ident="AnyThing" mode="add">
<desc>Matches any element</desc>
<content>
<zeroOrMore xmlns="http://relaxng.org/ns/structure/1.0">
<choice>
<element>
<anyName/>
<zeroOrMore>
<attribute>
<anyName>
<except>
<name>xml:id</name>
<name>xml:lang</name>
</except>
</anyName>
</attribute>
</zeroOrMore>
<ref name="AnyThing"/>
</element>
<text/>
</choice>
</zeroOrMore>
</content>
</macroSpec>
</schemaSpec>
</div>
</back>
</text>
</TEI>
