Validation Information:

[table border="1" colwidth="115"]

Contained by:,<add>|<choice>|<date>|<del>|<head>|<metamark>|<note>|<num>|<p>|<restore>|<seg>|<sic>|<stamp>|<unclear>

May contain:,<add>|<anchor/>|<choice>|<date>|<del>|<delSpan/>|<floatingText>|<lb/>|<lg>|<metamark>|<note>|<num>|<pb/>|<restore>|<seg>|<stamp>|<unclear>

What is it?

The <seg> tag contains a sentence in the manuscript. To make the edition's collation and Synoptic Sentence View tools work, we give each sentence a sentence number. These numbers are derived from the module's 'base text' – usually its first edition.


The value of the @n attribute starts with the manuscript's catalogue number, followed by a comma, and ends with the sentence number itself in between square brackets. For example:

[xml] <seg n="MS-UoR-2934,[0127]">[/xml]

In the case of a sentence that eventually did not make it into the base text, take the number of the preceding sentence that did make it into the base text, add a vertical bar (|) and continue numbering:

[xml] <seg n="MS-UoR-2934,[0127|001]">[/xml]

The first number should always consist of 4 digits: (0001 and so on), the second number (after the vertical bar) should always consist of 3 digits: (001 and so on).

In manuscripts (not typescripts!), because we follow a more document-oriented hierarchy, we have to close all <seg> tags before moving on to the next facsimile. Whenever a sentence continues on another facsimile (e.g. from "01r" to "02r"), we link these two parts of the sentence together by using the @rend attribute, adding the values "part1" and "part2" (and, in the case of extremely long sentences, "part3", "part4", etc.). For example:

[xml] <div type="page" rend="recto" n="01r">
<pb n="01r">
<seg rend="part1">…</seg>
<div type="page" rend="verso" n="01v"></div>
<div type="page" rend="recto" n="02r">
<pb n="02r">
<seg rend="part2">…</seg>

We distinguish four types of <seg>s:

  1. regular sentences (without a @type attribute),
  2. paralipomena (type="paralipomena"),
  3. open variants (type="alternative"),
  4. transpositions (type="transposition").

This type of <seg> contains a loose jotting (e.g. on the left hand page). Most loose jottings do not clearly correspond to any particular sentence in the text, and therefore do not need further attributes, except if they can be linked to a certain sentence. In that case, they receive the @n attribute of that sentence:

[xml] <seg type="paralipomena" n="MS-UoR-2934,[0034]">[/xml]

These <seg>s will be included in the Synoptic Sentence View, not declared as "version" of the sentence, but as "loose jotting" pertaining to the sentence:



When you find a <seg type="paralipomena"> that contains such a draft version of another sentence, please also add a note at the end of the sentence that explains the relation between the two sentences:

[xml] <note resp="#DVH">Draft version of sentence
<ref type="sentencelink" target="#[0210]">0210</ref>.</note>[/xml]

In this example, the note will say 'Draft version of sentence 0210.', in which the sentence number will link to sentence 0210 thanks to the <ref> element.

Open variants

In case of an open variant or alternative reading, the inline variant is encoded as a <seg> with a @type attribute "alternative". The other variant is encoded as an addition with a @type attribute. Both the <seg type="alternative"> and the <add type="alternative"> need an xml:id. For example:

[xml] That is <seg type="alternative" xml:id="alt1">an easy thing to say</seg>
<add place="supralinear" xml:id="alt2" type="alternative">soon said</add>.[/xml]


A transposition takes place when the author indicates that the order of two scraps of text have to switch places. In this case, each 'scrap' will need a @type="transposition" attribute, and a unique @xml:id. For example:

[xml] <seg type="transposition" xml:id="trans1">It is</seg>
<seg type="transposition" xml:id="trans2">perhaps</seg> something breaking,[/xml]

Don't be alarmed if the transposition is not immediately visualized: this visualization will only occur when we have declared the @xml:ids for transposition in the header. For example:

[xml] <listTranspose>
<ptr target="#trans2"/>
<ptr target="#trans1"/>

If a document contains more than one occurrence of a sentence (e.g. there are two occurrences of sentence [0127]), these will be ordered in the Synoptic Sentence View following their documentary order. A version of sentence [0127] on page 49v will be placed before a version on page 50r. If this order in your opinion does not match the order in which they were chronologically written, you can add a @version attribute, making this correct chronological order explicit. The <seg> on page 50r would have <seg version="1"> and the <seg> on page 49v would have <seg version="2">:


<pb n="49v"/>
<seg n="0127" version="02">A newer version.</seg>

<pb n="50r"/>
<seg n="0127" version="01">An older version</seg>



To make all the of the edition's tools and functionalities work properly, we have to follow these rules for spacing within <seg> tags:

1. Please put the spaces in between sentences in between the <seg> tags:


<seg>First Sentence.</seg> <seg>Second Sentence.</seg>


2. It's OK to take a new line for every <seg>, but please leave a space after every closed <seg>:

[xml] <seg>First sentence.</seg> (<= one space)
<seg>Second sentence.</seg>[/xml]

3. When a sentence runs over two pages, this is encoded as such:

[xml] <div n="79r">
<seg rend="part1">First part of sentence, </seg>
<div n="80r">
<seg rend="part2">Second part of sentence.</seg>

These two <seg>'s will later be turned into one for the Synoptic Sentence View.

Please remember to put an extra space after the last word of "part1" (here: 'sentence,'). If you don't, there will be no space between those words in the Synoptic Sentence View.