On Not Writing a Review about Mirador : Mirador , IIIF , and the Epistemological Gains of Distributed Digital Scholarly Resources

This piece mushroomed from a simple enough looking suggestion to write a review about Mirador, a viewer component for web based image resources. While playing around and testing Mirador however, a lot of questions started to emerge–questions that in a scholarly sense were more significant than just the functional requirements of textual scholars and researchers of medieval sources for an image viewer. These questions are forced upon us because of the way Mirador is built, and by the assumptions it thereby makes–or that its developers make–about its role and about the larger infrastructure for scholarly resources that it is supposed to be a part of. This again led to a number of epistemological issues in the realm of digital textual scholarship. And so, what was intended as a simple review resulted in a long read about Mirador, about its technological context, and about digital scholarly editions as distributed resources. The first part of my story gives a straightforward review-like overview of Mirador. I then delve into the reasons that I think exist for the architectural nature of the majority of current digital scholarly editions, which are still mostly monolithic data silos. This in turn leads to some epistemological questions about digital scholarly editions. Subsequently I return to Mirador to investigate whether its architectural assumptions provide an answer to these epistemological issues. To estimate whether the epistemological “promise” that Mirador’s architecture holds may be easily attained, I gauge what (technical) effort is associated with building a digital edition that actually utilizes Mirador. Integrating Mirador also implies adopting the emerging standard IIIF (international image interoperability framework); a discussion of this “standard-to-be” is therefore in order. Finally the article considers the prospects of aligning the IIIF and TEI “standards” to further the creation of distributed digital scholarly editions.

For the purposes of showing Mirador's capabilities I have opted to use a few folios from a digitized medieval Dutch manuscript, the so called Comburg Manuscript (Comburger Handschrift,Württembergische Landesbibliothek Stuttgart,shelfmark Cod.poet.et phil.fol.22).It contains a collection of some well-known Middle Dutch works.The folios shown contain the first columns of the Middle Dutch fable Van den Vos Reynaerde (transl.Of Reynaert the Fox), of which a full translation is also open access available in English (Bouwman and Besamusca 2009).
If a collection of images is being viewed, controls to leaf through the collection are also provided: left and right pagers, and a thumbnail bar.The latter can be collapsed to save screen estate for viewing the actual image (cf.Figures 3 and 4).In the case that a collection has properly added metadata, Mirador will also instantly display an index/contents, if so configured (Figure 5).
Mirador's technical designers and developers ought to be commended for not suffering from the "not invented here" syndrome.Instead of developing a completely new code base, they have maximally reused existing software components.This is a sensible development strategy as it lessens the development burden and prevents    images.Given that comparing codices and manuscripts is the bread and butter of textual scholarship, there is utility in being able to put two, three, or more codices next to each other on one's screen.So, if a Mirador viewer instance is set up for a particular collection of manuscripts, additional "slots" can be added for viewing other folios in the collection (Figure 6).
Of course, adding more and more views of manuscripts will soon turn a workbench into an impressively cluttered graphical interface, even if the user happens to have a 5120 by 2880 pixel monitor with 27″ screen diagonal-which is unlikely as roughly half of that (1322 by 768 pixels on a 15″ screen) is much more middle of the road currently.As Mirador is highly configurable the user may want to remove all that clutter of index buttons, paging buttons, thumbnails, and image property controls in order to attain, as the documentation has it (http://projectmirador.org/docs/docs/ getting-started.html),"Zen mode" (Figure 7).
From a scholarly point of view, all that viewing "power" at one's finger tips is a dream.But I am a pretty spoiled scholar/developer, and therefore I still miss a locked scroll or parallel pan feature which would scroll or pan both (or more) images that I am looking at simultaneously.This would be a feature that makes comparing lines a far less tedious task.(It should be noted that although this feature is not available out of the box there is a plugin that exactly provides this behavior.) Another arguably indispensable feature of Mirador is the ability to annotate images, for which a convenient tool ships with Mirador by default.A scholar can draw a border around any arbitrary area and add annotation text for that area (Figure 8).In all, then, Mirador delivers an impressively well-functioning and rich viewer and annotation tool.Panning and zooming is all rather nicely instant and seamless, which makes for a comfortable viewing experience.

How not to write a review for Mirador
Of course, I could have called it a day right there.This review was to be handed in by January 2017.Theoretically I could have made that deadline, I think.But the text above still felt improperly incomplete as a review of Mirador.Nothing in there is really factually wrong-but it is also a far cry from the larger story of which Mirador is a chapter.Also, that larger story needs to be told.But "How hard can it be?" is a dangerous thought, and I never saw the end of it.Let me tell you about it… Given the wrapping and encapsulation of ready-made components that Mirador does, one could critique it for being "just" a thin graphical user interface over a set of pre-baked code libraries, adding little of essence that could not have been achieved by several other means.However, first of all such a judgment would not be fair to the effort it must have taken to integrate all these libraries and functionalities.But more importantly: it would not acknowledge the pivotal role Mirador plays in what may be no less than a paradigmatic shift in how we understand, approach and interact with cultural heritage resources.Clarifying this will take a bit of explanation.There is also a graveyard somewhere for scholarly transcription environments.

The Persistence of Silos
Failed projects almost never get proper epitaphs or eulogies-the one for Project Bamboo by Quinn Dombrowski (2014) being the notable exception-which is a pity because such eulogies would be highly informative.In the case of transcription tools, a defining trope would be that the tool was built as an "integrated transcription environment."Integrated is a more formal term for "does it all."Their developers often want these tools to be the start and end all of digital textual scholarship work.
This most often means that these tools expect all resources to reside in one placespecifically, on the computer or server where the tool is deployed.The reasons for this are not technical, born instead of institutional necessity and development convenience.The institutional makeup of academia and its (grant) funding schemes favour local institution-level digitization and development (Prescott 2016).
Collaborative development between institutions is often frustrated by funding limitations, and moreover requires significantly more coordination effort than local development.Lastly, from the point of view of the developer, it is simply convenient to have all data in the same form and format and at an arm's length.Just as it is convenient for a scholar to have all sources and secondary literature on her desk, this saves a lot of tedious logistics needed to gather and process information.The effect of convenience for institution and for developer however is that these tools turn into so-called "data silos" (https://en.wikipedia.org/wiki/Information_silo):all images, texts, annotations, and so forth need to reside on the same server to be used by the tool.
This has been a long-standing problem in digital scholarship technology.
As far back as 2007, when a group of colleagues and I began a project called Interedition (http://www.interedition.eu/), the situation was almost perfectly the same: almost every institution, in some cases even each individual professor in textual scholarship was somehow involved in creating a large integrated all-purpose research environment.This caused (and causes) a lot of reinvention of wheels and duplication of effort, in a field that is notoriously understaffed with digitally and computationally skilled scholars and developers.At the time, it seemed to us-a mixed group of digital humanities developers, researchers, and any hybrid form in between-a good idea to reuse tools and resources rather than having local copies of text files and annotations, local tools, and the local burden of integration and graphical user interface development.This was not just a developer's concern, to keep development loads small; it also seemed to us that keeping tools and data locked in one place behind a one-size-fits-all interface would be in stark contrast to the heterogeneous demands and requirements scholars had for document resources that were spread, quite literally, across the planet.What use would it be to have an alignment tool locally in Würzburg if one of the documents it needed to align was in the Bibliothèque Nationale in Paris?Our buzzword of the day became "interoperability."The ideal was that no matter where you were, the tool at your disposal would work just as easily on a digital manuscript facsimile in, for instance, Florence as on a print edition in New York.We reasoned along the lines of serviceoriented architecture.That is, distributed resources would be reachable via the same technical protocol language, which would guarantee that any local interface speaking that access language would be able to approach and use them.In that way it would not matter if I were using T-PEN and my colleague in Berlin were using EVT (https://visualizationtechnology.wordpress.com/),we would still both be able to hook into the same resource in Stanford.In 2011 my colleague Peter Boot and I also argued for such services-based digital scholarly editions in a more academic fashion (Boot and van Zundert 2011).It turned out, however, that between dream and reality stand institutional politics and practical considerations.

Iron Manning the Digital Scholarly Edition
If the two contentions above hold water, they go a long way to explain why digital scholarly editions are all still based on a model of a unique, undivided, and complete product, and why Robinson's (2004) dream that "all readers may become editors too" by reusing the various parts of digital editions, and creating their own transcriptions and annotations, has not taken off.The second contention stands as a model for a great number of practical and pragmatic choices and limitations that influence the process of digital scholarly editing and the result of that process.
Here however, I am not interested in these practical considerations.Nobody denies that it is highly convenient to have a text available anywhere, anytime.Nobody denies that it is practical to avoid travelling to the national library of another country to check particular artefacts on a specific folio.No one has denied the facilitative nature of a full text search.And every editor is aware of the limitations that funding, institutional policies, and capacity put on any edition.Yet still the obvious practical, pragmatic, and (possibly) financial benefits of publishing scholarly editions digitally have not convinced the majority of scholarly editors that digital editions are worthwhile.
I wonder how far this may be due to the particular stance that we, digital scholarly editors and computational humanists, have taken in arguing the digital scholarly edition.Advocates like myself have been hammering away at the practical advantages and revolutionary paradigm-shifting nature of electronic editions for more than a decade.Julianne Nyhan and Andrew Flinn (2016) argue that there is a distinct and overused revolutionary motif in digital humanities publications.Arguably this motif has worked as a shibboleth for the community, but it also may have worked rather counterproductively against the acceptance of digital methods in the humanities "proper", where the need for and advantages of a revolution were greeted with justifiable skepticism.Peter Robinson's "The Digital Revolution in Scholarly Editing" ( 2016) is an interesting publication in this respect.Clad in revolutionary terminology, it is highly critical of the aspects of digital scholarly editing usually depicted as The second pillar is that only qualified scholars have the authority to make a text the rest of us may read.Both pillars are now fallen.We are moving to a world where every manuscript and every book from the past is online, free for anyone to look at.You no longer need to be tenured and well-connected to see a manuscript: increasingly, all you need is an internet connection.
As for academic authority: peer-review and tenure committees are fine things but no-one is going to assert that only approved scholars can read manuscripts.(Robinson 2016, 198) Robinson takes my second contention above (the perpetual lack of capacity, funding, and skilled personnel) as a major argument in favour of shared open digital editions.
The facsimile materials should be put on the Web publicly under the freest license possible, open to all to transcribe, annotate, interpret, copy, perform, and so forthan admirable altruistic and democratic argument, further underpinned by the fact that our work is usually financed through tax money.
The issue here is not whether I agree with Robinson, but his proclamation that this "revolution" is a fact, that the future course of (digital) textual scholarship cannot be but this one, and that it is already happening.Much academic literature about digital textual scholarship seems to subscribe to a similar premise.Franz Fischer's excellent contribution in Speculum (2017) postulates: the (albeit slowly) growing number of digital critical editions increases the demand for assembling and providing critical texts that are in the form of a textual corpus, because only collections or corpora of texts that are otherwise dispersed on various websites allow for a systematic analysis and for efficient research across the works of a specific author, genre, subject, period, or language as a whole.(S266) Again, it is not whether Fischer is wrong or right here-in practice, I actually agree with his contention.What I find interesting is that Fischer postulates a world of existing digital editions (or data) and then suggests several solutions for how to reconcile the heterogeneity and specificity of critical editing with the homogeneity of digital corpora.These solutions are primarily methodological in conception, but with elements of IT architecture mixed in.
I want to cast Robinson's and Fischer's premises here as "iron manning", which is an inverse form of making a straw man argument (Casey 2012).This is unfair because their argument is well-intended and not necessarily wrong, but for the Commedia, but works more akin to some obscure and opaque 12th century book of prayers-would be happily surprised to receive one.The potential public reach of these works does not justify the development of heavyweight digital infrastructure or applications on the off chance that there may be an interested individual out there who actually knows more about an edition than the editor learned in the fifteen odd years spent studying it.
Calling it a revolution does not make a strong epistemological case.So, what could the epistemological case be?Why do we not discuss this widely in our field?Again, as a possible opening for a debate: two contentions.The first is that distributed open digital editions improve quality, and higher quality information advances knowledge.What constitutes quality of information is another conundrum that I will not detail here; suffice to say that it is also a highly situated concept (cf. Borgman 2015; Gitelman 2013).But the epistemological argument for distributed information lets itself be construed rather easily.It is connected to skill.Suppose I am a scholar in need of high-quality digital facsimiles of some folios of some medieval manuscript.I could try to obtain high-quality photographs and digitize them myself.But soon I would be facing questions like "How many DPI and what colour depth should these images be?", "How and where should they be stored?","What is a feasible standard for the technical description of these photographs?".
Chances are, a textual scholar is less equipped to answer these questions than a library-based digitization expert.The quality of the production of such digital facsimiles is related to the skill and knowledge of the producer.In contrast, if I want to be assured of the best possible transcription I am going to take my chances with the textual scholar specializing in 12th century European paleography, rather than with the librarian.This difference in assured quality of information does not evaporate post production.The curation and maintenance of digital information is yet another field of expertise, best left in the skilled hands of people maintaining some digital repository.Thus, digital scholarly editions may be sites of intersecting knowledge that affirm and support specific and highly-skilled expertise.This does not mean they cannot be altruistic and democratic at the same time, opening up editions to the public, but the primary epistemological scholarly gain seems to be in better, more specific support for quality knowledge and expertise.
My second contention in support of distributed information is related to distributed knowledge, also known as group knowledge or, indeed, "wisdom of the crowd" (https://en.wikipedia.org/wiki/Wisdom_of_the_crowd).As pointed out above, arguing some epistemological advantage based on the "wisdom of the crowd" seems a dodgy fad at best, but it is a well-known fact that distributed knowledge adds up to more than local or individual knowledge (Fagin, Halpern, Moses, and Vardi 1995) and it can be explained relatively easily.Suppose some person X knows that fact A is related to fact B, but she does not know that fact B is related to some other fact C.
Suppose also that another person Y knows that fact B is indeed related to C, but he in contrast does not know that B is related to A. The distributed knowledge that neither person has is that all three facts are related.They could gain this knowledge if the local information were somehow exposed and eventually shared (e.g. through wordof-mouth or publication).This kind of transformation of distributed knowledge into added knowledge is actually what textual scholars do all the time.What is, quite inexactly (Timpanaro 2005), called Lachmann's method is an excellent example of this.A scholar may find two copies of a text sharing the same copying error-in other words, information distributed over two sources.Combined, this information adds the knowledge that these copies are in all likelihood more closely genealogically related than copies that do not have that error.
The salient point here is that, although connecting distributed information might be done computationally, it must currently be done by hand, because the information that digital scholarly editions hold is represented almost exclusively through visual interfaces.This means that the epistemological benefit they can have depends on human agents connecting the dots.These human agents are part of a social epistemology (Goldman and Blanchard 2016), and distributed knowledge may certainly be uncovered in such a system of networked knowledge.However,

Silos and Epistemological Gains
The majority of current digital scholarly editions bring neither of the potential epistemological benefits described above.Most are based on a process of copying, creating or even re-creating all resources in a single digital location (i.e. on one server), forming silos that gather many kinds of different information with different curation and maintenance needs.This situation will not change in light of the promise of networking knowledge via non-human agents that have yet to be designed-the latter of my epistemological arguments above-especially since we have very little inkling of the value of the knowledge that would emerge in this way from distributed information.
The argument about quality of information, and delegation of tasks according to expertise, may actually be convincing for textual scholars.But the incentive for textual scholars to build distributed systems is at best altruistic: creating webservice-based distributed digital scholarly editions is harder and requires more technical expertise than creating complete and finite websites.As iterated above, the data silo is a cheaper, technically less complicated solution that is less dependent on many external stakeholders, quicker to realize, more adaptable to local needs, and usually has better predictability for deliverables and turnaround.
Does this mean that technically networked information is inevitably, both epistemologically and pragmatically, a non-starter for textual scholarship?That the idea serves no purpose?This remains to be seen.As with so many semantic technologies, the value of distributed information for textual scholarship is more promise than reality, impossible to determine as there are so few real implementations to test-drive.Given the complexities and unclear payoff, it is also not a development that scholars can be expected to lead all by themselves.This is another conundrum: it is on the one hand up to technologists and digital humanists who believe deeply in its promise to demonstrate the value of distributed information resources, but on the other hand the epistemological affordances such networks might create can hardly be left to the technologists to evaluate, as they are usually not textual scholarship experts.

Mirador as an Argument for Distributed Scholarly Resources
So why then would I still maintain, as I said above, that Mirador potentially plays a pivotal role in what may be nothing less than a paradigmatic shift in how we understand, approach and interact with cultural heritage resources?Mirador's strength is in its architectural composition, which a truly lazy reviewer might attack as a mere patchwork of existing code pieces without much added value.
But from a networked knowledge perspective, its architecture is precisely the strongest statement it can make, enabling it to be part of a distributed model that would leverage the epistemological benefits of resource quality I argued above.Mirador was built explicitly to do one job and do it very well: viewing digital images.The developers and designers stayed far away from every other temptation.On the functional (or user facing) side of things they provided no image retouching functions, no dedicated transcription possibilities (although the annotation function has been used for simpler transcription tasks), no metadata editing capabilities, no annotation tools, no print-on-demand-service… no nothing.They just delivered a bare-bones viewing, zooming, panning tool.This is an explicit design choice and by that an explicit assertion on how (scholarly) resources should be networked, namely not by integrating all software and data in one single (server) location, but through lightweight protocols that inform very specialized tools where they can find data and what they should do with it.
This strategy allows tools such as Mirador to be completely agnostic as to where some resource is located or how it is produced, served, and maintained, so long as its image data can be requested as input and depicted.In this regard Mirador's architectural makeup can be read as an argument, just as editions (Cerquiglini 1999), interfaces (Andrews and van Zundert 2016), and software code (van Zundert 2016) can be seen as arguments in a wider debate on textual scholarship.
Mirador's argument favours distributed digital scholarly resources because it positions itself as a component that fits as a cog in just such a distributed ecosystem.Thus the epistemic argument of Mirador about the digital edition is that a digital edition ought to be a composition of various distributed resources.
Had the developers of Mirador chosen any other strategy, then with every function they added there would have been a tighter integration with other software and stronger demands concerning the form (and possibly location) of data resourcesand with every function Mirador would thus have become more an argument in favour of digital scholarly editions as monolithic data silos.In contrast, and quite on purpose, Mirador does not care whether one resource is in Madrid and another is in San Francisco-as the developers themselves explain: Users, such as scholars, researchers, students, and the general public, need to compare images hosted in multiple repositories across different institutions.(Jansen, Luijten, and Bakker 2009) testifies to this.In the case of facsimiles, an editor often has to make do with a lower quality photograph of a folio as an illustration (e.g. Figure 9).Higher quality can arguably be offered and maintained by an expert in an institution that takes the care for digital images and its sources to be one of its core tasks.Chances are this will not be the scholar that made the transcriptions and edition.In the case of the edition of the

Mirador as Part of an Ecosystem of Digital Scholarly Resources
Even though it may be reasonable to expect an epistemological benefit from distributed digital scholarly editions, it remains to be seen whether that benefit would actually be realized.The other essential component of an image repository is a server that will stream requested images to the application ("client") that wants to use them.Not any image server will do, however.Again, IIIF compliance is a prerequisite for the server to be part of a distributed network of resources that Mirador asserts.Several of such servers exist "off the shelf" though (cf.http://iiif.io/apps-demos/#image-servers),such as IIPImage (http://iipimage.sourceforge.net/).
Any Mirador viewer can be pointed to a particular manifest by clicking the "Replace Object" option (Figure 10).This will let the user choose from a list of preselected repositories (Figure 11), but a manifest URL can also be keyed in manually Suppose a scholar would want to create a digital scholarly edition from such distributed resources.What would it take?To make this more than just a theoretical wish or a thought experiment, I have implemented my own demo of a distributed edition with a tiny sample of images and text (cf.Appendix 1).I mainly wanted to know how hard it would be, because the simpler the work, the likelier that scholars will take to developing digital editions from distributed resources.My experience, however, suggests that one needs to be quite an experienced (web) developer to be able to create the needed web services and the integrating application, i.e. the edition.
On a somewhat higher level of overview, what follows describes the implementation of the demo edition.together properly, the front page of the image server can be admired (Figure 14).
The fuel for the Apache-IIPImage engine is images.These images need to be prepared as so-called pyramidal TIFFs that allow efficient and fast streaming of image information to a client (such as Mirador).Effectively, each image is stored in several sizes in one file to support zooming.Each size is associated with a layer, and each layer is broken up into many small tiles that travel the Internet quickly and easily.To create pyramidal TIFFs, one needs to be comfortable with a tool such as ImageMagick (https://www.imagemagick.org)and commands such as convert original_0001.tif-define tiff: tile-geometry = 256 × 256 -compress jpeg 'ptif:pyramidal_0001.tif'.Once the pyramidal images have been created, the image server is able to show us facsimiles (Figure 15).
Finally, the manifest file needs to be created.This would usually require a developer to generate it from some database of image information, or by creating a script to query the image files directly (e.g. using exiftool, https://www.sno.phy.queensu.ca/ ~phil/exiftool/).For this demo, given the very few images it would describe, the manifest file was put together by hand.The hardest part of this was understanding the IIIF specification, which is to say, the formal language used to describe the structure and metadata of image collections.The specification is not really complicated, but getting to know it still involves somewhat of a learning curve.There is a tool that is tremendously helpful when building manifests by hand or when trying to familiarize oneself with the IIIF manifest specification, which is the Oxford Manifest Editor (http://iiif.bodleian.ox.ac.uk/manifest-editor). Whether generated or written by hand, the result is a manifest file (Figure 16) that can be consulted by any computer running an IIIF client.At this point there is an image repository that contains, presumably, the facsimiles of the codex that the scholar wants to turn into a digital edition (e.g.something like Figure 15).Arguably this part of the work would be delegated to some specialized service or institution.Of course, if no institution already hosts the images one needs, the editor faces the task of convincing some institution to host them, and possibly to fund the related work and maintenance.Alternatively, the editor could create a self-maintained repository as explained here.
Now an actual Web application is needed that uses Mirador to look at the image repository.These days Web application development requires more and more knowledge beyond "plain old HTML and JavaScript."Mirador is no exception, and reusing Mirador's source code while at the same time adhering to more formal and current software development principles requires substantial Web development experience and knowledge.Mirador is developed using the Node.jsruntime environment (https://nodejs.org/en/).This means it can actually be run out of the box on Node.js as a server, which is a solution one might opt for.The main reason for choosing Node.js however, seems to be the NPM package manager (https:// www.npmjs.com/)that comes along with the environment and which protects developers from the proverbial "version hell"-that is, the conflicts that arise when two components one needs require two different versions of a third component.A 19th century cart wheel will not fit your 21st century Tesla, even though they are just "wheels" and "vehicles".Mirador uses a lot of third-party JavaScript components, and so it needs to carefully check the versions of those components that it combines.NPM is a very convenient way to deal with this problem.However, the consequence is that if you want to use the Mirador source code from its official repository (https://github.com/ProjectMirador/mirador) in the "proper" way, you will first need to download and compile all components and sources that Mirador uses into one mirador.jsfile using Grunt (https://gruntjs.com/),which is another tool in the Node.jsdomain.
Once this is done, the Mirador demo application provided by the original authors can be deployed by moving Mirador's whole directory into the folder designated by the Apache web server as the source of the files it serves.Of course, there is also a less formal but more convenient and speedier way to start using Mirador.If one does not require substantial changes and adaptations, it is possible to "drop in" a single van Zundert: On Not Writing a Review about Mirador Art. 5, page 30 of 48 pre-compiled mirador.jsfile, and to refer to this inside a web page's HTML source.
At this point we can reach our Mirador instance via any web browser, and we can add the URL of our manifest, which Mirador should use to show us the contents of our image repository (Figure 17).
We need a source for our transcriptions too.This involves setting up another server that will provide on request the transcription of a particular page of the codex Mirador is displaying.One could adapt one of the transcription and visualization environments named in the beginning of this article.For my demo I created my own basic transcription server (https://github.com/jorisvanzundert/mirador_review_demo).It uses a Sinatra Web server in the Ruby language (http://sinatrarb.com/;https://www.ruby-lang.org/en/) and serves a TEI-XML file that transcribes a tiny portion of the first facsimile (Figure 18; see Appendix 1 for the full source of the textual data).Using the Nokogiri HTML/XML parser in the background (http://www.nokogiri.org/),the same server will use an XSLT stylesheet on request to transform the TEI-XML into HTML, visualizing either a diplomatic (Figure 19) or critical version of the transcription.
A server for the images now exists, and we have a server for the transcriptions.
But the Mirador client still needs to be told where to find the transcriptions.For the demo I wrote a JavaScript component called "text_viewer" that can request the HTML representation for either the diplomatic transcription, critical transcription,

Along the Seams of Mirador
This is where we start to stumble upon some of the limitations of Mirador.The scholar who studies manuscripts would want a more granular connection between text and image.But as Mirador's developers chose to pursue one task and one task very well, any extras that the scholar might want will have to be added by someone  with software development capabilities.All this is doable, but it is harder work than what I outlined above, and there I omitted the nitty gritty details of trying a number of unsuccessful solutions that I abandoned in deep heaps of Linux system level error messages that I-being a skilled web application developer but not a very skilled systems admin-could not solve quickly or conveniently.
Up to this point, development consisted of adding whole components together into services that could usefully speak to each other.To realize a more granular linking between text and image, however, we will have to delve into the code of Mirador itself and make some things possible that are not supported by default.This is, then, the point where we get a feel for the seams of Mirador, for the rough edges of its codework.As much as reusing and wrapping components is a most brilliant strategy to reduce maintenance and reinvention, it has certain disadvantages.Mirador uses code that has been written by many different people, and this shows.Programmers use different styles of coding-and there are many styles (cf.e.g.Croll 2014).It appeared to me that the developers of Mirador are apt JavaScript programmers, which makes for well-written code.Even so, it is not like looking at a Rembrandt or a Van Gogh.It is more like Rembrandt, Van Gogh, and Picasso came together and decided to work concurrently on the same painting.
For scholars or programmers wanting to integrate Mirador into their project and   html) to a particular area of the facsimile.Here we come upon a rough seam in the IIIF protocol that Mirador is using.
According to the IIIF specification, there are actually several ways to achieve a more granular linking between text and image.One is the ability to define ranges-these may indicate a range of pages, for instance, or a particular area on a page (http://iiif.io/api/presentation/2.1/#range).Another way is to use a segment selector in a URI (http://iiif.io/api/presentation/2.1/#segments).Neither solution is very satisfying, however.For one thing, the IIIF specification is still an evolving specification, and the ranges model is a good example of its current volatility.IIIF community discussion around ranges led to the deprecation of the current specification for ranges, which is to be fully replaced in IIIF version 3.0 (https://github.com/IIIF/api/issues/1070).
More importantly, both solutions assume that knowledge about the transcription is part of the description of the facsimile.From the point of view of decoupled distributed scholarly resources maintained in a context of specific expertise, this is unsatisfying because it establishes a strong coupling between the facsimile resource and text resource.In keeping with the idea that services should be as contentagnostic as possible, it would be preferable that any Mirador application, similar to how it reaches out to an image repository, would reach out to an external service that on request would provide just enough information for it to link specific parts of the transcription with specific parts of the facsimile.
Fortunately, the authors of the IIIF specification decided to follow the web annotation recommendations by the W3C that provide exactly this type of model (Cole 2017).The web annotation model became an official W3C recommendation on 23 February 2017 after years of preparation by the W3C Web Annotation Working Group (https://www.w3.org/annotation/), which derived from another grassroots initiative called the Open Annotation Collaboration (http://www.openannotation.org/).It is this Web Annotation Model that allows us to call another independent service into action that exposes annotations to the Web that are independent of the description of that facsimile by the image resource.Mirador can then retrieve annotations on a facsimile from this service.Conveniently-for the demo in any case-there exists a ready-made SimpleAnnotationServer that will act as just such an independent resource for annotations (https://github.com/glenrobson/SimpleAnnotationServer).This service can provide information about annotations available for the facsimile to both my self-rolled SimpleTranscriptionServer and to Mirador.Mirador is able to depict these out of the box (see Figure 21).However, to enable the user to click on a particular part of the transcription and to have Mirador then pan and zoom to the corresponding part of the facsimile, we need to hack a few lines of code deep within Mirador's innards.Mirador encapsulates its own event handler mechanism that enables it to publish events and to subscribe to events of other components.For example, if a user clicks on a verse, the custommade text_viewer component publishes an event called request_fit_bounds, which includes information about the location of the image that was clicked.After we have modified its code a bit, Mirador can listen for these events and, when one occurs, pan and zoom to the verses that correspond to the location given in request_fit_bounds.Clicking on the first character of the transcription, for instance, zooms to the enlarged initial just to make the case (Figure 22).
The fact that IIIF relies on the Web Annotation model of the W3C is fortunate in more than one sense.It ties into my contention that knowledge quality is best served when it resides with exactly the expertise it needs.That in turn serves to keep knowledge within repositories to the bare minimum needed to serve a very specific purpose, and with this comes efficient maintenance and other practical benefits.But it is also fortunate in the sense that, this way, the IIIF specification runs less of a risk of bloating.The same phenomenon that is a risk for integrated infrastructures (i.e. that they topple under the maintenance of ever more tools and data being integrated) is a risk for protocols and standards too: their authors may be tempted to expand their coverage and expressiveness forevermore.Signs of this kind of bloating may be found  In the case of manuscript images and scholarly transcriptions, IIIF and TEI have much to gain from each other.But it remains to be seen how they should be aligned or connected.This is an issue that has already seen some recent discussion on the TEI mailing list (cf.Stutzmann 2017).In the demo, I challenged myself to make Mirador pan and zoom towards a particular area that is annotated with a particular part of   van Zundert: On Not Writing a Review about Mirador Art. 5, page 39 of 48 { "@context": "http://iiif.io/api/presentation/2/context.json","@id": "http://localhost:9999/annotations/annotation/anno1", "@type": "oa:Annotation", "motivation": "sc:painting", "resource":{ "@id": "http://localhost:9099/reynaert/diplomatic/folio/192v#xpointerfolio/19 2v#xpointer(tei:text/tei:body/tei:div[@type='folio']/tei:div[@ type='part' and @n='1_1']/tei:l/tei:c)", "@type": "dctypes:Text", "format": "application/tei+xml" }, "on": "http://localhost:9999/reynaert_fragment/folios/folio_192v#x ywh=100,100,500,300" } nor the solution proposed on the TEI list (cf.Holmes 2017), to strongly couple parts of transcriptions to segments (areas) of images using, for instance, a facs attribute: is really satisfying.Again, the reason is that editors of scholarly texts are best not bothered with specific image-related description, and a protocol or standard ought not to push this highly specialized knowledge on them.This is of course not to say that it is forbidden ground for the textual scholar, but if she wants that knowledge she ought to find it in the designated place, and should not be bothered by it out of necessity.
The schemes above, moreover, effectively preclude competing transcriptions.
Suppose you have two competing transcriptions for the same facsimile.With the strong coupling of the transcription fragment inside the image segment (book1/ canvas/p1#xywh=0,0,600,900) in the IIIF scheme, a viewing client like Mirador has no choice: the image description dictates that the client should go look for one specific transcription (that of the very specific XPointer denoted in the segment definition).This type of strong integration goes exactly against the nature of distributed resources and nullifies the ability to discover distributed knowledge.
If there are multiple competing transcriptions for one particular facsimile, then a viewer for that facsimile should be able to discover any or all of the transcriptions.
The strong coupling above forces this work of discovery onto the creator and/or maintainer of the facsimile image, which is to say, a person whose immediate interest and expertise is probably not geared to that task.Instead, and in the interest of epistemological gain, we ought to register the transcription with an additional independent service.A client like Mirador can in that case just ask from such a service: "Is there any transcription for this particular facsimile?"The service will then answer with the appropriate resources, and if there are competing transcriptions, the viewer can choose one or present them as alternatives.Introducing such an intermediate service is called "adding an indirection," or "making resources dereferenceable," to put it in stark information technology terminology.
To my knowledge there is no community consensus about a formal protocol to support this type of service.It could be tremendously productive if both the IIIF and TEI communities were to enter in a dialectic on that topic.For the moment this type of behavior can be mimicked at best by utilizing the Open Annotation schemes that IIIF adheres to, as demonstrated by the Mirador-based application presented.

Conclusion: The Risks to Mirador's Distributed Worldview
Where do we stand after a long journey from Mirador along IT architecture,

Figure 3 :
Figure 3: The same image, zoomed and panned.Image rendering controls expanded at the top left.
revolutionary.Robinson argues that neither what we do as digital textual scholars, nor what we make constitutes a revolution in scholarly editing at all.We are still editors of texts after a critical fashion.Digital resources and environments may scale our work, but essentially do not warp us into any undiscovered paradigm.But Robinson continues to argue that there is still a truly revolutionary aspect to digital textual scholarship.It changes who we (textual scholars) are: Every edition I have discussed so far has been made according to what we might call the Alexandrian consensus.The librarians gathered the many texts of Homer together; the scholars studied them and created a text; a grateful world took that text and read it.This model rests on two pillars.The first pillar is that only qualified scholars may examine the primary documents.

Figure 9 :
Figure 9: Example of making do with a single photograph.These pages, taken from Brinkman and Schenkel's edition of the Comburg manuscript (Brinkman and Schenkel 1997), show one of the very few reproductions (cut and scaled down) in the print edition.(Image courtesy Verloren Publishers and authors.)

Middle
Dutch Comburg manuscript (Brinkman and Schenkel 1997) the repository of the source-the Württembergische Landesbibliothek-did indeed bring high resolution images online, some thirteen years after the print edition was published according to the associated MARC21 information ("Comburger Handschrift -mittelniederländische Sammelhandschrift -Cod.poet.etphil.fol.22"n.d.; "SWB Online-Katalog" n.d.).The facsimiles and the diplomatic transcripts of one of the "flagships" of middle Dutch literature, the Comburg manuscript, lead for the moment a rather unsatisfying-from the scholarly perspective-divorced life.The facsimiles are available on the website of the Würtembergische Landesbibliothek, the full diplomatic transcript only as an offline print edition.Being able to link them up through an architecture as proposed by Mirador would no doubt greatly improve the epistemological value of both.

Figure 14 :
Figure 14: An empty image repository is born.

Figure 17 :
Figure 17: Mirador is up and showing images.
van Zundert: On Not Writing a Review about Mirador Art. 5, page 31 of 48 or the TEI-XML source from the TranscriptionServer.This component was integrated with the Mirador viewer which results in an application that can show facsimile and transcription together (Figure 20; consult Appendix 1 for the source of the text_viewer component).

Figure 18 :
Figure 18: The TEI-XML file for the transcription (fragment).

Figure 19 :
Figure 19: A diplomatic transcription served through the SimpleTranscriptionServer.

Figure 20 :
Figure 20: A client combining Mirador viewer for facsimiles and a text viewer for transcription.
achieve a more granular linkage between facsimile and transcription.In the demo I wanted to be able to click on any verse in the transcription to cause Mirador to pan and zoom to the corresponding verse on the facsimile.This would seem to me a basic prerequisite of convenience for any digital scholarly edition that ties together medieval text and manuscript facsimile, because either the transcription is used as a reading aid or the facsimile is used to verify the correctness of the transcription.Such linking requires some way of relating a particular TEI l-element (i.e.line element, http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-l.

van
Zundert: On Not Writing a Review about Mirador Art. 5, page 35 of 48

Figure 24 :
Figure 24: Mirador's unmitigated book view, suggesting that this text starts on a recto.

Figure 25 :
Figure 25: Mitigating Mirador's book view by inserting a blank page.
monoliths and epistemology, to distributed knowledge and the construction of a scholarly edition demonstrator from distributed resources?My conclusion is van Zundert: On Not Writing a Review about Mirador Art. 5, page 41 of 48 that things look pretty bleak with regard to the potential success of distributed resources in scholarship.Not, of course, because distributed resources are a bad idea.In fact, I would contend that from a scholarly point of view a distributed architecture is the only IT information and knowledge architecture that makes sense.It fits better with the tenets of scholarship, which values multiple perspectives and intersubjective interpretation.But IT infrastructure is often overlooked as both a metaphor for and a formative agent of epistemological construction.That it can be a normative epistemological means is-I would argue-hardly recognized in scholarship.Since it is perceived as pretty much unrelated to the core of their epistemology, scholars are thus unlikely to meddle much with the architecture of their IT infrastructure.As argued, there should be a modest epistemological gain in distributed resources.However, as this is currently a technological promise at best, it is only a weak argument in favour of distributed digital scholarly resources.The deep involvement of scholars with the requirements specification for Mirador and IIIF have no doubt contributed to their respective success stories so far.My worry, however, is with the integration of these technologies in existing institutional contexts.Mirador makes a very strong statement for distributed architecture and the connection of distributed knowledge and expertise.But this statement is in code, in technical architecture, and in the technical specification of a protocol.As such, it currently can only be really understood at all levels by software developers, or scholars who are skilled developers too.As my own demo shows, a high level of IT expertise is needed to create scholarly tools using Mirador as a component.Of course, this is not to suggest that developers do not listen carefully to scholars formulating requirements.Mirador is obviously an excellent case in this regard, for the developers understood very well the need for scholars to compare images from different remote sources.But this does not mean the distributed architectural vision carries over automatically to local contexts.As I have argued, distributed knowledge is not part of a general scholarly worldview, rather, distributed architecture only emerges as relevant to scholars in the very specific case where they cannot easily obtain a very specific resource.The generalized case of having all digital objects

What is the Epistemological Case for Digital Scholarly Editions?
sake of argument I use their premises as examples of what advocates of digital humanities often seem to do: assert some digital ideal and make a case for what, methodologically, would fit this idealistic situation.Fischer and Robinson construct situations that are ideal for their reasoning, respectively that there are ever more digital editions and that editions should be publicly open and sharable.These are subjective practical and pragmatic ideals to start with.One might wonder however, if practical and pragmatic ideals resulting firstly from a digital medium and only secondly from scholarship are appealing to conventional textual scholars.Are textual scholars not primarily interested in what can be known about a text, and should we not therefore demonstrate the added epistemological value of the technologies we propose first of all?
(Schreibman, Mandell, and Olsen 2011)rly editing towards open and distributed digital editions seems not to have happened.Do readers really want to be editors?Moreover, most editors seem to be reluctant to embrace different, more open methods.The arguments cited in the previous section strike me as deterministic.That a digital technology exists and a futuristic ideal can be based on it does not necessarily mean that particular utopia can and must be reached.Could it possibly be that most textual scholars judge that the model of the singular unified complete text-or codex in any case, be it a digital or print one-is simply sufficient, or even superior to any open and machine-readable digital model yet presented?Fair is fair: we have little evidence that scholars and readers see a reason for a shared, interoperable, distributed model for text resources.At best there is evidence of the contrary in many a failed tool, the lack of use being made of digital editions(Porter 2013), and the persisting preference for print over digital by promotion and tenure committees(Schreibman, Mandell, and Olsen 2011).The open and social edition that is passionately argued for by Ray Siemens and others(Siemens, van Zundert: On Not Writing a Review about Mirador Art. 5, page 19 of 48 if the information within these silos were to be exposed in a way that non-human agents, such as web crawling software, could navigate, a lot more information could be related much more quickly than now, with the associated epistemological gain.Distributed information systems multiply this potential.If I need to create a digital edition that takes its images from one server and takes its transcriptions from another, and its annotations from yet another, I have to make the interface application on my computer talk to these other computers.And if my computer can, so can other computers.
Thus, we have two epistemological arguments in favour of open distributed digital scholarly editions.The second in particular is an indistinct and opaque artificial intelligence promise at best, colloquially known among developers as the "semantic dream."Even though the dream of a fully digitally networked "apparatus fontium" is beautiful, its pursuit seems not to be a very attractive proposition to textual scholars: most of the essential infrastructure and, veritably, all the appropriately curated content is missing, and creating them requires great effort and technical skills that are not in abundance within the textual scholarship community.The promise of the first argument, that we can further knowledge by leveraging quality of information, is only slightly less opaque, but at least the state of the art in digital infrastructure makes the attainment of this benefit feasible.
For an image repository on the Web to advertise its content according to IIIF rules, it needs to serve a so called manifest file in JSON format (https://www.json.org/)that describes the content and structure of the given resource.The exact semiotics are all documented in detail on the IIIF site (http://iiif.io/api/presentation/2.1/#manifest).
The answer is highly dependent on the facility of the technical solution provided.That is: how well and how easily does Mirador let itself be used by scholars and developers alike?If Mirador is set up in the right way and if the image repository it uses supports the IIIF protocol, then Mirador brings a scholar a long way.IIIF is short for International Image Interoperability Framework (http://iiif.io/).If you want a distributed ecosystem of scholarly resources-that is, the ability to reuse resources no matter where they are