Rome Wasn't Digitized in a Day - Council on Library and Information ...

47
Additionally, Schmidt and Colomb postulated that the lack of an “accurate model of textual variation”
and the ability to implement such a model <strong>in</strong> a digital world have cont<strong>in</strong>ued to frustrate many
humanists.
A related problem identified by Schmidt and Colomb is that of overlapp<strong>in</strong>g hierarchies, or when
different markup structures (e.g., generic structural markup, l<strong>in</strong>guistic markup, literary markup)
overlap <strong>in</strong> a text. Markup is said to overlap <strong>in</strong> that “the tags <strong>in</strong> one perspective are not always well
formed with respect to tags <strong>in</strong> another” (e.g., as <strong>in</strong> well-formed XML). Schmidt and Colomb proposed
that the term “overlapp<strong>in</strong>g hierarchies” is essentially <strong>in</strong>correct: “Firstly, not all overlap is between
compet<strong>in</strong>g hierarchies, and secondly what is meant by the term ‘hierarchy’ is actually ‘trees’, that is a
specific k<strong>in</strong>d of hierarchy <strong>in</strong> which each node, except for the root, has only one parent.” They put
forward that although there have been over 50 papers deal<strong>in</strong>g with this topic, one fundamental and
common weakness <strong>in</strong> the proposed approaches was that they offered solutions to problematic markup
by us<strong>in</strong>g markup itself. The authors further and asserted that all cases of overlapp<strong>in</strong>g hierarchies are
also cases of textual variation, even if the reverse is not always true. “The overlapp<strong>in</strong>g hierarchies
problem, then, boils down to variation <strong>in</strong> the metadata,” Schmidt and Colomb declared, add<strong>in</strong>g that “it
is entirely subsumed by the textual variation problem because textual variation is variation <strong>in</strong> the entire
text, not only <strong>in</strong> the markup” (Schmidt and Colomb 2009). They thus concluded that textual variation
was the problem that needed solv<strong>in</strong>g.
Ma<strong>in</strong>ta<strong>in</strong><strong>in</strong>g that neither version control systems nor multiple sequence alignment (<strong>in</strong>spired by
bio<strong>in</strong>formatics) can adequately address the problem of text variants, Schmidt and Colomb propose
model<strong>in</strong>g text variation as either a “m<strong>in</strong>imally redundant directed graph” or as an “ordered list of
pairs” where each pair conta<strong>in</strong>s a “set of versions and a fragment of text or data.” The greatest
challenge with variant graphs, they expla<strong>in</strong>ed, is how to process them efficiently. The m<strong>in</strong>imum
number of functions that users would need were read<strong>in</strong>g a s<strong>in</strong>gle version of a text, search<strong>in</strong>g a
multiversion text, compar<strong>in</strong>g two versions of a text, determ<strong>in</strong><strong>in</strong>g what was a variant of what else,
creat<strong>in</strong>g and edit<strong>in</strong>g a variant graph, and separat<strong>in</strong>g content and variation. The solution proposed by
Schmidt (2010) is the multiversion document format (MVD):
The Multi-Version Document or MVD model represents all the versions of a work, whether
they arise from corrections to a text or from the copy<strong>in</strong>g of one orig<strong>in</strong>al text <strong>in</strong>to several variant
versions, or some comb<strong>in</strong>ation of the two, as four atomic operations: <strong>in</strong>sertion, deletion,
substitution, and transposition. … An MVD can be represented as a directed graph, with one
start node and one end-node. … Alternatively it can be serialized as a list of paired values, each
consist<strong>in</strong>g of a fragment of text and a set of versions to which that fragment belongs. As the
number of versions <strong>in</strong>creases, the number of fragments <strong>in</strong>creases, their size decreases, and the
size of their version-sets <strong>in</strong>creases. This provides a good scalability as it trades off complexity
for size, someth<strong>in</strong>g that modern computers are very good at handl<strong>in</strong>g. By follow<strong>in</strong>g a path from
the start-node to the end-node any version can be recovered. When read<strong>in</strong>g the list form of the
graph, fragments not belong<strong>in</strong>g to the desired version are merely skipped over (Schmidt 2010).
Schmidt listed a number of benefits of the MVD format for humanists, <strong>in</strong>clud<strong>in</strong>g the follow<strong>in</strong>g: (1) it
supports the automatic computation of <strong>in</strong>sertions, deletions, variants, and transpositions between a set
of versions; (2) MVDs are content format-agnostic about <strong>in</strong>dividual versions so they can be used with
any generalized markup or pla<strong>in</strong> text; (3) an MVD is “not a collection of files” and <strong>in</strong>stead stores “only
the differences between all the versions of a work as one digital entity and <strong>in</strong>terrelates them” (Schmidt
2010); (4) s<strong>in</strong>ce the MVD stores the overlapp<strong>in</strong>g structures of a set of versions, the markup of