Balisage Paper: Marking up microrevisions with major implications: Non-linear text in TAG

Embedded markup approaches

As the table in Figure 2 illustrates, there are various embedded markup approaches to expressing complex textual structures. Some are more effective than others, but theoretically text encoders can use any data model to express any kind of text, no matter how complex, as long as they are willing to use some workarounds, do some extra coding, and hand over certain tasks to other data formats (Vitali 2016). But the more additional coding, customized solutions, or handovers are necessary, the more complicated it will be to process, query, interchange, or reuse the encoded files (Haentjens Dekker et al. 2018, Schmidt 2019).

From the outset, the main objective behind the development of TAG has been to both simplify and advance the work of text encoders worldwide. In our ideal scenario, editors can work with a data model that natively supports the modeling of complex text features, with as few handovers or customized technical solutions as possible. The table below therefore represents to what extent markup systems support complex textual features like non-linearity, discontinuity, and overlap in a native way.^[6]

Figure 2: Overview feature-support in embedded markup languages

Overview of complex textual features supported by embedded markup languages. The overview is partly inspired by the map drawn by Wendell Piez (Piez 2008), by the MLCD Overlap Corpus (Marcoux et al. 2012), by the tables of Fabio Vitali (Vitali 2016), and by the inventory of Pierre-Édouard Portier et al. (Portier et al. 2012).

As the table shows, TexMECS is able to natively represent non-linearity. By default, all contents of a TexMECS document are ordered, and it is possible to indicate the start and end of an unordered element. For example, the children of a subst element can be marked as unordered in the following TexMECS notation:

This is a <|subst||<del|useful|del> <add|clear|add>||subst|> example

XCONCUR (Schonefeld 2007), Concurrent XML (Dekhtyar and Iacob 2005), LMNL (Piez 2008), and linear extended Annotation Graphs (LeAG, Barrellon et al. 2017) are designed primarily to deal with overlapping structures and do not natively support non-linear structures.^[7] The case of TEI/XML is slightly more complicated. We mentioned above that the TEI Guidelines identify a number of elements (notably the subst, choice and app) whose children are understood to be unordered. We also noted that this requires the use of a schema language like XML Schema that supports unorderedness, as well as a schema-aware processor. In reality, most generic XML processors will not be aware of these exceptions and process the XML document as a fully ordered tree. In that case, all alternative paths through the text will be considered as being part of one and the same text stream.

Stand-off approaches

Several stand-off approaches to markup also allow for the expression of non-linear structures. The Multi-Version Document (MVD) system developed by Desmond Schmidt et al. (Schmidt 2008, Schmidt and Colomb 2009, Schmidt and Fiormonte 2010) implements a variant graph which is a suitable data structure for representing non-linearity. In the case of a draft manuscript featuring multiple revision stages, the MVD-approach suggests the editor creates separate transcriptions (layers) for each in-text revision stage. The transcription files can be in plain text, HTML, XML or LMNL format.^[8] Creating layers implies interpretative work from the editor who needs to differentiate between revision stages on the manuscript text based on cancelled, added, and transposed (units of) text. Layers are thus artificial constructs that represent a collection of in-text variations. The separate files are merged into one MVD, so that all versions of a text – both the in-text variation and the variation across documents – are stored in one variant graph.

EARMARK (Extremely Annotated RDF Markup; (Peroni and Vitali 2009)) is another standoff system and well-known to the Balisage-community. EARMARK implements a collection of RDF statements about text fragments that describe properties of that fragment. Technically, the underlying RDF data model is flexible enough to express partially-ordered information, but according to the EARMARK specification (Peroni and Vitali 2009), this feature is not supported.

EARMARK does support the option to represent multi-orderedness: via the e-GODDAG extension, RDF statements about the same text node can be repeated in different contexts. This way, users can express multiple text orders (Peroni and Vitali 2009, section 4.1; Di Iorio et al. 2009; Peroni et al. 2014). However, multi-orderedness is not identical to partially-orderedness. To our knowledge, expressing diverging and converging paths through the text stream (our definition of partially-ordered information) is currently not parsable in EARMARK.

TAGML Pipeline

Figure 3 presents a schematic representation of the TAGML processing pipeline.

Figure 3: TAGML pipeline

The TAGML processing pipeline. The input is a TAGML document, the output is an Abstract Semantic Graph.

The input of the pipeline is a TAGML document that contains a combination of text and markup. Markup tags indicate whether the text is fully ordered, partially ordered, or unordered.^[9] The TAGML document is first tokenized by the TAGML lexer which produces a stream of TAGML tokens; each token contains information about its position in the TAGML document, its type, and its length. We will discuss the lexer in more detail below. The stream of TAGML tokens is subsequently parsed with an ANTLR-generated parser that uses TAGML grammar, resulting in an AST of the input TAGML document. The most up-to-date version of the TAGML grammar can be found on Github. From the AST, an Abstract Semantic Graph (ASG) can be generated. In the TAG data model, the ASG is implemented either as a Multi-Colored Tree (MCT) or a hypergraph.^[10] In a tree model the markup elements start at the top level and are (almost) all above the text elements, which are at the bottom in leaf nodes. In contrast, the TAG hypergraph model has the text elements at the centre of the model. The relationship between Text nodes and Markup nodes is expressed by hyperedges.

Examples

The examples in this section come from the authorial notebooks of Virginia Woolf's To the Lighthouse, written between 1926 and 1927 (Woolf 1927). Digital facsimiles of the notebook pages are available via the digital archive Woolf Online.^[11] Of each example we show four representations: the manuscript fragment, the TAGML transcription, its AST as produced by the parser, and its hypergraph representation. Again, we'd like to point out that these examples are selected for their simplicity; more complex examples would result in an exceptionally large AST visualisation that won't fit into this paper.

Single deletion

Figure 4: Manuscript fragment with a single deletion

A deleted word on a fragment of Virginia Woolf's manuscript of To the Lighthouse, Fol. 9; SD. p. 4.

If we follow the tag suggestions of the TEI Guidelines for transcription of primary sources and map them to TAGML,^[12] a textual fragment with the deletion can be represented as follows:

[TEI>[s>it seemed [?del>indeed<?del] as if it were now settled<s]<TEI]

The question mark prefix in the [?del> tag indicates that the element and its textual content are optional, thus two ways of reading the text. When processed by the TAGML parser, the following AST is produced:

Figure 5: AST of a single deletion

Visualisation of the AST of a single deletion.

The TAGML grammar is context-sensitive,^[13] and a TAGML document consists of one or more chunks. Each chunk can contain either a start tag, an end tag, text, or text variation. In this diagram, the TAGML tokens are visualized in the blue leaf nodes. The fact that the lexer has different modes enables us to reuse a (sequence of) character(s). Based on their position in the TAGML document, the same characters may get a different function. For example, if the lexer is in the 'Default'-mode, a left square bracket [ is identified as the start of a markup opener, so the lexer switches to the 'Inside Markup Opener'-modus. The lexer remains in this modus until it encounters a token that prompts it to switch to another modus, in this case that could be the > token, which triggers the lexer to switch back to the 'Default'-modus ('pop mode // back to default'). The diagram shows how a TAGML token can trigger the shift to a different modus: the modes of the lexer are visualized in red and connected to the tokens that trigger them.

From the resulting AST a Multi-Colored Tree or a hypergraph can be generated. Because hypergraphs are more suitable to represent non-linear information, we will show the hypergraph for each TAGML document. Note that the AST only expresses the syntactic structure of the TAGML document, which means the start tags and end tags are not linked. Going from an AST to a hypergraph, then, means that the start and end tags will need to be reconnected in order to form Markup nodes in the hypergraph.

Figure 6: Hypergraph visualisation of a single deletion

A visualisation of the hypergraph of the single deletion, with the markup information in labeled hyperedges. Here, the Text nodes form a directed graph and the text can be read from left to right, following the arrows. The visualisation shows the two paths through the text that imply that the text can be read in two different ways: one version of the text includes the deleted word indeed, and one version excludes it. The Markup nodes connected to the Text nodes are visualized as coloured spheres. For example, the Markup node labeled del is connected to the Text node indeed.

Immediate deletion

Figure 7: Manuscript fragment of an immediate deletion

An immediate deletion (currente calamo) on a fragment of Virginia Woolf's manuscript of To the Lighthouse, Fol. 9; SD. p. 4.

In TAGML, the immediate deletion is expressed as follows:

[TEI>[s>The [del>im<del] picture of stark & compromising severity.<s]<TEI]

Note that the [del> does not have an optional prefix ? because we interpret an immediate revision as part of the same writing stage as the rest of the text. This means there is just one reading of the text and that reading includes two deleted text characters im.

Figure 8: AST of an immediate deletion

An AST of the immediate deletion encoded in TAGML. The different modes of the lexer are visualized in red. Note, for instance, how the lexer interprets text characters either as Text or as a markupName depending on its current modus (respectively 'Default'-modus or 'InsideMarkupOpener'-modus).

Figure 9: Hypergraph of an immediate deletion

Visualisation of the hypergraph as generated from the AST above. Because the immediate deletion is taken as part of the running text, the text in the hypergraph has no branches: there is only one way of reading the text. The fact that the text characters im are deleted is represented by associating the Text node with a Markup node labeled del.

Grouped revision

Figure 10: Manuscript fragment of a grouped revision

A grouped revision on a fragment of Virginia Woolf's manuscript of To the Lighthouse, Fol. 15; SD p. 7.

A grouped revision is a clear example of non-linear, partially ordered information: alternative readings for the same point in the text. In the TAGML syntax, the branching of the text stream is indicated with <|, the individual branches are separated with a vertical bar | and the converging of the branches is indicated with a |>. Individual branches contain markup and text. The present example can thus be encoded like this:

[TEI>[s> something <|[del>trustful<del]|[add>trusting<add]|>, something childlike<s]<TEI]

As we will see in the visualization of the AST below, the TAGML parser will recognize and interpret the divergence and convergence signs, so that the content of the branches is considered variant text ('ITV_text').

Figure 11: AST of a grouped revision

This visualization of the AST of the grouped revision example shows how the lexer switches constantly between modes. This ensures that the parser has the right information and can interpret non-linear, partially ordered information as it was intended by the human encoder: as an indication of two readings of the same point in the text.

Figure 12: Hypergraph of a grouped revision

This hypergraph visualization demonstrates the concept of branches by showing how the text diverges into two branches after the word something. Each branch contains both text and markup. The information in the branches is mutually exclusive: when read from left to right, the text in the hypergraph either reads something trustful, something childlike or something trusting, something childlike. The branches converge again after the text variation ends.

Taken together, the different visualizations of in-text revisions illustrate how TAG and TAGML allow for a natural and idiomatic digital representation of in-text variation, one that we think comes as close as possible to how a human encoder understands it. The next section will look at ways to transfer this understanding to a collation tool.

Creating additional witnesses for each in-text revision

Section 3.1.2 (Stand-off approaches) described how users of the MVD technology can create separate layers for each occurrence of in-text variation. These layers can subsequently be used as temporary witnesses for the plain text collation. Using the MVD collation functionality 'Compare', the temporary witnesses and the base texts are compared to one another. Both the official text versions and their temporary layers are merged into one MVD, which stores the text shared by each version and layer only once, similar to a variant graph. 'Compare' does not recognize markup elements and consequently does not differentiate between text and markup. In fact, it is not quite correct to say that the collation program ignores the markup information about non-linearity: the markup was never there in the first place.^[14] The result of the collation is an MVD variant graph containing in-text revisions as well as between-document variation. In the variant graph, in-text non-linear structures (i.e., within one witness) are distinguished from external variation (i.e., between witnesses) by sigla.

Passing along markup

Some collation tools allow for markup elements to be passed on through their pipeline. The markup elements are ignored during the alignment process, but they are present in the output and can then be used for further analysis or visualisation purposes.

Juxta Commons accepts TEI/XML encoded files for collation. The tool offers an interface that lists all TEI/XML elements contained by the input witness; the user can select which elements should be part of the collation and which can be filtered out. The TEI/XML elements are not part of the alignment process proper: they are saved as stand-off annotations to the text tokens and passed-on through the collation pipeline. The elements can be visualized in the heat map representation of the collation result, which shows deletions in red and additions in green. In other output formats of Juxta, the <add> and <del> tags are no longer there.

Another method to pass along markup through the collation pipeline requires coding on the side of the editor who interacts with the underlying code of the collation tool. We illustrate this approach by looking at the software CollateX.^[15] The JSON input format for CollateX allows for extra properties to be added to words. In a preprocessing step, the text is tokenized and transformed into JSON word tokens. Editors can make a selection of markup elements that they wish to attach to the JSON token as a t property (the t standing for token). The collation is executed using the value of the token's n property (n for normalized), but the selected markup is included in the JSON alignment table output via the t property, and can be processed in the visualisation of the alignment table. This approach does approximate the goal of having in-text revisions marked as non-linear text in both in- and output, but at the point of alignment, the collation algorithm is unaware of any non-linearity in the witness' text and treats the partially ordered information as a linear structure.

Comparing data-centric XML

Finally, there are several approaches to comparing XML trees (Barabucci et al. 2016, Ciancarini et al. 2016). Some XML editors, like oXygen, have a built-in XML comparison function. In theory, this approach would allow for the comparison of TEI/XML transcriptions containing non-linear information encoded with subst or app elements. The comparison functionality is primarily developed for structured, record-based XML documents – e.g., XML documents containing address information such as person name, address, age – and the documents are compared on the level of the XML elements.

Comparing two record-based XML documents results in an overview of the difference in markup. For example, an add element in witness A would be aligned with an add element that is on the same relative location in witness B. Note that these matches are made on the element level and not on level of the textual content. Textual scholars studying the revisions in literary texts, however, would typically give preference to the textual content.

The DeltaXML software does detect and display changes between two XML documents, either on the level of the XML elements or on the level of the text content. (Delta XML) Their Document comparator tool compares two XML documents and merges them into a new XML document that contains additional attributes representing the variation. What is more, DeltaXML provides the option to identify orderless containers: XML elements whose children can be arranged in an order that is not considered significant. Orderless containers are marked by placing the deltaxml:ordered="false" attribute on the element so that all its children will be considered to occur in any order. It's a description that seems to apply to our interpretation of the subst, the app and the choice elements. Comparing XML documents that contain a combination of ordered and orderless data (i.e., the children of some XML elements are ordered, but others are orderless) remains, according to the DeltaXML developers, a challenge. They propose to solve it by preprocessing the input XML documents.^[16]

That data-centric XML comparison methods usually do not work for text-centric encoded documents has already been pointed out by Di Iorio et al., who wrote that although XML is used to encode both literary documents and database dumps, there is something different from diff-ing an XML-encoded literary document and an XML-encoded database (Di Iorio et al. 2009, emphasis in original). In the case of comparing an encoded literary document, the authors state, the output of a diff should be evaluated on its naturalness, that is: for an algorithm to identify the changes that would be identified by a manual, human approach. To this end, Di Iorio et al. developed the implementation JNDiff.^[17] Di Iorio et al. were right to point out that the comparison of encoded literary documents is quite unique. In the majority of cases, the collation of such documents needs to take place on the level of the text. Rather than being compared, the markup indicating in-text revision needs to be interpreted as it was indented by the encoder: identifying the start and end of textual variation.

HyperCollate's approach

HyperCollate takes as input two TAG hypergraphs of the individual witnesses. Note that each hypergraph may contain a combination of ordered, partially ordered and unordered information. The partially ordered information is represented as two or more branches in the hypergraph, with the text nodes in these branches having the same position in the text vis-à-vis the document root node (see the hypergraph visualisations in section 3.2.2 Examples).

The computational pipeline of HyperCollate can be visualized as follows:

Figure 13: The HyperCollate pipeline

A visualisation of HyperCollate's approach, to be read from the upper left to the upper right corner; then from the lower left to the lower right corner.

The output of that alignment is a set of matching tokens. Again, the tokens in this set contain information about their depth, and there may be more than one text token on the same position. Based on the information from this set of matches, the two witness hypergraphs are merged into a new collation hypergraph that contains all information about the Text nodes and the Markup nodes of the input witnesses. All the nodes that are not aligned are unique to one of the two witnesses; all the nodes that are aligned can be reduced from two to one node, with labels on the edges indicating which node is part of which witness.

For every witness, then, there is always a fully connected path of Text nodes through the collation hypergraph: from the start node to the end node, following the sigla on the edges. Labeled hyperedges are used to associate the Markup node(s) with the Text nodes. The collation hypergraph can be visualized as an ASCII table or a collation graph (in .dot, SVG or PNG format). In the case of >2 witnesses, the collation output could also be used as the basis for a new collation following the progressive alignment-method (Spencer and Howe 2004).

Examples

In the paragraphs below, we return to the examples from section 3.2.2 Examples. Each example text fragment is collated with HyperCollate against another version of the same text that can be found in the print proofs of To the Lighthouse Woolf 1927.^[18] The HyperCollate output, a collation hypergraph, can be visualized in multiple ways, from an ASCII alignment table to an SVG graph. Each format has its own level of information density. Here, we provide an alignment table visualisation and an SVG collation graph visualisation to illustrate what differences this density makes: a simpler visualization may be clearer, but it may lack relevant information about the textual variance and/or the markup.

Single deletion

Input witness 1:

[TEI>[s>it seemed [?del>indeed<?del] as if it were now settled<s]<TEI]

Input witness 2:

[TEI>[s>as if it were settled<s]<TEI]

Figure 14: Alignment table visualisation of the collation output

The [-] in front of the text token 'indeed' is how HyperCollate visualizes that this token is marked as a deletion in the input. However, this simple alignment table visualisation does not show that there are two different paths through the text of witness 1.

Figure 15: Collation graph visualisation of the collation output

A collation hypergraph visualisation of the output of HyperCollate. As with a standard variant graph, the matching Text tokens are merged; only the variant Text tokens are made explicit. The witness sigla, represented on the edges as well as in the vertices of the collation hypergraph, indicate which tokens belong to which witness. Furthermore, vertices include a path to the markup associated with each Text node. In this visualisation, the two paths through the text of witness 1 are visible.

Immediate deletion

Input witness 1:

[TEI>[s>he appeared the [del>im<del] picture of stark & compromising severity.<s]<TEI]

Input witness 2:

[TEI>[s>he appeared the image of stark & compromising severity.<s]<TEI]

Figure 16: Alignment table visualisation of the collation output

This alignment table visualisation shows that the text characters 'im' (an immediate deletion in witness 1) align with the word 'image' in witness 2. Note that aligned is not the same as match: two tokens may be placed above each other because they are at the same relative position between two matches, even though they do not constitute a match. Still, by including the deletion in the collation we see that Woolf deleted the word 'image' and opted for 'picture' in her draft manuscript, but that based on the print proofs she went with 'image' after all.

Figure 17: Collation graph visualisation of the collation output

Visualisation of the collation hypergraph. The variant graph visualisation can include more information than an alignment table, which makes it a useful visualisation to analyse the collation outcome in more detail. Note, for instance, that this visualisation shows that the Text tokens 'im' (witness 1) and 'image' (witness 2) are indeed not considered matches by HyperCollate.

Grouped revision

Input witness 1:

[TEI>[s>something <|[del>trustful<del]|[add>trusting<add]|>, something childlike <s]<TEI]

Input witness 2:

[TEI>[s>something trustful, something childlike <s]<TEI]

Figure 18: Alignment table visualisation of the collation output

The alignment table visualisation of HyperCollate presents grouped revisions in a single cell, to indicate that there are two optional readings for the same position in the text.

Figure 19: Collation graph visualisation of the collation output

Looking at the markup information in the vertices of this collation hypergraph, we see that the Text token 'trustful' has different markup in witness 1 compared to witness 2. Still, because HyperCollate takes the text as leading, the Text tokens are merged into one vertex.