Virtual Research Environment (VRE)

SQE Website Usage General Overview

The Scripta Qumranica Electronica project is currently preparing two web sites, or web applications, for enhanced exploration of the Dead Sea Scrolls. Both sites are centered around the concept of digital editions of the individual Dead Sea Scrolls, you may think of a digital edition as web accessible version of a print edition of a text, with all the added functionality that attends a digital format.

One web application, the virtual research environment (or VRE), is a tool used to create digital editions. The other web application, the digital edition viewer, is a portal that people will use to explore “published” editions that have been created with the VRE.

Virtual Research Environment

The virtual research environment is an online editing program that enable collaborative, real-time, editing of Dead Sea Scroll manuscripts. It provides direct access to a large amount of curated data in the form of images of the Dead Sea Scroll fragments, transcriptions of the text on the manuscripts, and various other information being prepared with AI (e.g., we have already clipping masks to extract a fragment from the image background, we have some fairly successful matching of fragments in various images, and some linking of letters on the manuscript with the transcriptions).

The VRE is currently under rapid development. It is being constructed in a modular fashion with specialized components designed for specific tasks of the editorial process (see below). The platform is collaborative and already provides an invitation system to request new collaborators and a corresponding permissions system for setting read, write, and admin access. The database keeps a record of who made each change in each edition and we will be adding tools for accessing that information.

Editing Activities

The process of preparing an edition involves several steps that may at times be performed out of order or in various configurations:

  1. Gathering all fragments belonging to the manuscript.
  2. Extracting the manuscript fragments from their images by means of clipping masks and then naming each fragment.
  3. Aligning the “image stack” for each fragment. There is usually more than one image of each fragment, these must be aligned in such a way that they can be stacked underneath the fragment clipping mask so that an editor or reader can easily scroll through the stack (this is complicated when the fragment itself has drastically changed shape over time).
  4. Aligning the front side of the fragment with its back side. With the front and back fragments aligned the editor and viewer is able to flip the manuscript over, which is useful in many regards.
  5. Noting any parts of one fragment that correspond to another. For instance, ink from one fragment may have transferred to the back of another, or one may wish to mark corresponding holes or other damage that occured when the manuscript was rolled up (or folded, etc.).
  6. Mapping transcriptions of each fragment to the ink on the fragment image. In our system we are mapping transcriptions at the letter level.
  7. Laying out the fragments onto a virtual manuscript. This involves placing all pieces in their supposed proper location in relation to each other. Most of our fragments can be arranged into series of sheets, which contain columns, which contain lines.
  8. Establishing the reading order of the text. These manuscripts often have text in between lines or in the margins that are intended to be inserted into the main text of the manuscript. The editor will establish one or more reading orders based on placement and content.
  9. Noting any overlap between the text of the manuscript and other known full or partial instances. This may occur when one is editing, for instance, a biblical scroll for which text is rather well known in the modern period, but also for literary works that were unknown before the discovery of the Dead Sea Scrolls, like Musar LeMevin, which is found in several copies at Qumran. This also applies to shorter overlapping text like the quotation of a well-known biblical verse in the middle of an otherwise unknown religious treatise.
  10. Commenting on the manuscript and editorial decisions. The process as layed out above typically involves many editorial considerations and the editor will want to document the motivation for many of the decisions that went into preparing the edition as well as to call attention to specific problems and issues of interest.

Present and Planned Modules

We have envisioned several modules aimed at carrying out the tasks performed above, they are as follows (items in bold have been already constructed):

  • An “artefact” editor used to create the clipping mask for one or more fragments (we call the artefacts) in a single image (point 2).
    • Clipping masks are preprocessed for each image by our computer science. Often the preprocessed clipping masks need a small amount of correction, either by including some material it missed or by deleting some material it erroneously included. Less often there is more than one artefact on a single image and each of these must be discretely marked and labeled.
  • An “image stack” or alignment editor (point 3 and maybe 4).
    • This should alow the editor to add or remove individual images from the image stack. The editor will need to be able to move, rotate, and scale each image in the stack (linear transforms). It is also necessary here to enable the editor to change the form of the clipping mask, since an old PAM image may have a less damaged form of the fragment. For similar reasons, the editor should also be able to set the polygonal region in the image that belongs in the image stack (thus being able to exclude portions of individual images in the stack).
    • At some point in the future we would also like to support non-linear transforms (setting corresponding point) for fragments that have warped or changed shape over time. Some of the data for this is already being preprocessed by the computer science team. Probably this would require a different editing module.
    • Perhaps this module could be used as well for the front/back alignment of number 4 above.
  • A “corresponding features” edition (point 5).
    • This would be used to mark the spatial relationship between transferred ink from the front of one fragment to the back of another.
    • It should also be possible here to describe the relationship between fragments that were found in modern times in a stack (or wad).
  • A transcription mapping module for linking transcriptions to the ink on the fragments (point 6).
    • Each letter of a transcription can be linked to a square or polygonal region on the manuscript where the ink marks of the letter can be found.
    • The transcription have been prepared in advance, and outside of heavily damaged areas of a fragment there is generally little need to change them.
    • Because of the way our project aims to maintain a record of how each manuscript edition is related to all others, it is more robust to change transcriptions letter by letter than to erase whole sections of text and type something new in its place. We will probably add a textual diff feature in the future that will enable such functionality, but at least initially we want to discourage that use case in favor of maintaining a clear and intentional relationship between all variants in the editions.
  • An attribute editor (part of point 10; we had a component for this in an earlier iteration of the website).
    • The editor should be able to apply metadata to individual letters, groups of letters, or marked area on an image. These are called attributes in our system. Attributes are open ended and any user may create their own beyond the standard ones already available in the system.
    • Perhaps this is a small panel, or even a menu that can appear in various modules in the platform.
  • A virtual manuscript module for laying out the fragmentary remains of a manuscript (point 7).
    • Part of reconstructing a manuscript involves laying out the fragments in relation to each other to form a reconstruction of the manuscript as the editor imagines it may have looked when it was created.
    • This process will often involve creating small groups of fragments that form a “join” whether actual or distant (i.e., not actually touching). Such groupings will often correspond to several lines of text that belong together up to one or several columns of the manuscript.
    • The virtual manuscript may also include reconstructed text, text that the editor believes may have been lost to damage. This text should be laid out in the virtual manuscript in a font and sizing that matches the actual manuscript, but be editable. It would be nice for the web app itself to notify the editor when a reconstructed text exceeds some bounding criteria for the manuscript. (nothing in this point has yet been implemented.)
  • A reading order editor for establishing the reading order of the text in the manuscript (point 8).
    • The text in the Dead Sea Scrolls is generally written from right to left (for Hebrew/Aramaic) and from top to bottom, but there are frequent interlinear insertions (as well as marginal) and also scribal corrections of various types that require interpretation. Our platform allows forstoring multiple reading orders (or streams). This is useful if the editor wishes to show, for instance, the reading order of the first writing og the manuscript alongside reading orders that include scribal corrections. The editor can rank these reading orders according to preference.
  • A parallel text mapper (point 9).
    • The editor should be able to mark correspondences between manuscripts on a word by work level.
    • This is especially helpful for establishing reconstructed text between fragments of a manuscript.
    • This is also very important for those who study textual development and all the issues concomitant with that.
  • A commentary module (point 10).
    • This should be a pane or menu item that can be accessed from various places within the platform allowing editors to add comments. The comments may become complex and should be allowed to include hyperlinks. Perhaps we would allow Markdown or something like that in the comments.


As you have already seen, we have a starting page with lists of editions. This should be an ergonomic portal to an editors work. This work involves either continuing work on an existing edition or creating a new edition. The editor may create a new edition from one of her existing editions (i.e., forking the edition) or the editor may use one of the default editions in our system as the base for his new edition. We will add the possibility to create a new empty edition as well, but that is a much less common use case.

Once the editor has chosen an edition to work on, she should have some overview that facilitates her to get quickly into the work at hand. You have also seen this screen. This screen should provide quick and easy access to any of the various modules mentioned above. It is probably at or near this high lever that the editor is able to add or remove fragments (and their images), see point 1 above.