DMLBS online on

i_logo_brepolis We are pleased to announce that the text of the DMLBS is now available online (by subscription) on the Brepolis platform.

Followers of the DMLBS project will be aware that online publication has been a long-term ambition of ours to complement the printed Dictionary. Although our own plans to develop and host an online platform for the Dictionary had to be discontinued, we are extremely pleased now to have been able to join in a partnership with Brepols to make the DMLBS more widely available.

The Brepolis platform also for the first time gives Dictionary users new methods of using the text of the DMLBS, making searches possible not only by headword (as in the printed dictionary) but across the full text, including etymologies, senses, and quotations. Although the results of full text searching must of course be used with caution (since the Dictionary is emphatically not a comprehensive collection of all the examples of use of every word cited in the whole of British Medieval Latin), this new functionality will surely open up new research possibilities for medievalists to exploit the extensive data of the Dictionary.

Further information about the Brepolis DMLBS can be found at

(Please note that Brepols is wholly responsible for the online platform and that the DMLBS project is unable to offer technical or other support for its users.)

Revision (part III)

In the third of a series of posts looking at developing a revision workflow, we look at the editorial workflow and considerations around types of changes, approval, and the first steps in transforming from one stage to the next.

III. Editing

Now we have the data structure framework to underpin our processes, we need to establish some corresponding processes for getting from some existing entry (if there is one) and the note of some possible change to a finished entry ready for integration back into the dictionary data.

As with the development of the structure, so too for the processes we start by looking at the editorial demands. We note first that the processes here are going to be applied chiefly to individual one-off changes, i.e. those concerned with single entries or parts of entries (though the new revision structures, being XML, and transformations, as XSL, should therefore be equally suitable for handling global changes in due course): each change will be different in what is being done, where, and to what.

Reviewing the noted problem or existing proposed change, doing appropriate research, and deciding what change to draft into the new structure will be the core of the editorial task, and the protocols and procedures for these will doubtless evolve with time as our experience of this way of working grows. Key to them, however, will be an underlying assumption of validity and stability: the existing text was the result of painstaking research and checking and so it merits prima facie respect as being reliable. While any publication that has been the work of so many people over many decades inevitably exhibits a degree of variability through its pages, pretty much regardless of the strictness of its protocols, the fact that a portion of text is not precisely as consistent as it might be with other parts or is not as we would do ourselves now is not per se a reason to decide to amend it: not only are there multiple ways of treating any particular matter that are good (albeit in different ways), but also there maybe complex (even unseen) dependencies resulting from the printed text in earlier parts being what editors made reference to when preparing later parts.

Our aim for now is not the preparation of a fresh edition, which would be a wholly different undertaking. Instead the process is intended to correct or remove error and to supplement where there is significant omission (e.g. of an entry or sense). A principle of minimal interference will help us avoid (a) during our limited time being distracted from the important corrigenda/addenda by rearranging things that do not strictly need it and (b) inadvertently causing knock-on problems.

Looking at each problem or proposal in view of what is currently printed, we can decide whether to make a change, what the (smallest) change would be (e.g. of a quotation, subsense, sense, cross-reference, or whole entry), and whether it is of the kind that it should appear in a printed list of corrigenda: the most minor changes, e.g. inserting a missing bracket, can simply be made ‘silently’, to be visible in the data when published online.

Once decided, the change can be keyed directly into a copy of the entry. The former unchanged version, if there is one, will be the <for> child of the <revision> element, and the newly amended version, if there is one, will be the <read>. For some changes that we want to print notices of, e.g. ones that fall within longer elements such as a change of a word within a quotation, we will expect a <print> element to give the relevant printable details in a correctly tagged form. A <note> explaining or justifying the amendment may also be provided.

All these amended copy entries are gathered to be reviewed by the editor. At this point we have several transformations to assist in and carry out the processing. First, all the changes can be reviewed in draft by an XSL transformation run across all the amended files as an XML collection (using the invaluable collection() function) that pulls out the relevant <for> and <read> instructions. Any that are obviously problematic can be identified and returned for further drafting.

After this each entry containing a draft amendment can be looked at individually and the change considered in context. If approved, its form is finalized, including marking of the approval and a decision on whether the change is to be printed.

Finally, the approved draft changes are implemented in the entries and the entries sorted for reintegration back into the overall dictionary data, from which a formatted list can subsequently be exported for publication.

Read the other posts in this series here.

Revision (part II)

In the second of a series of posts looking at our creation of a revision workflow, we look at the second stage of the process, building the editorial core.

II. Structure

It’s all very well recording possible items for review. When it comes to doing something with these proposed corrigenda, the situation is more complex. We need to have not only a final revised version of the text but also a record of what changes have been made (e.g., with a view to printing a list of corrections).

Our starting point is the fact we have complete well-formed XML for the whole dictionary (as far as it has been published or drafted), valid against our own specially designed XML Schemas. Because the dictionary is still in preparation, we need our XML data for that published part to continue to reflect the dictionary as it was published (so that we can rely on it for reference, e.g. for preparing cross-references involving the part already published); at the same time we naturally want to implement any revision changes in the data as we go so that we can also see the most accurate and up-to-date version of our dictionary. If we need both these versions in any case (at least until the new version of any text being amended is published), it makes sense for us to hold them in such a way that we can extract straightforwardly a list for publication of the changes made.

We therefore can’t just start making changes to the data as and when we feel like it. We need to know the status of the data at any point, and at the heart of this is the fact that in any case changes need to go through due editorial review before being released (just as the draft dictionary is carefully reviewed and revised during its editorial workflow towards publication).

Now, we do already maintain version control through successive editorial stages in the drafting process using Subversion (in the form of VisualSVN Server and TortoiseSVN), so why not use that to control different versions arising through revision? This kind of solution turns out in a number of ways not to be sufficient on its own for our needs. For instance, though there are various ‘diff’ tools available for comparing successive versions, they usually work by displaying two versions of a file side-by-side, and so they highlight the changes without necessarily enabling an editor or reviewer to see why the change has been made (which would seriously slow the editorial review process). The results of such diffs on XML data are also themselves very hard to interpret, with only raw plain text XML display available rather than visually styled display that has revolutionized our drafting process over the last few years. Moreover, such diff tools work best (sometimes they work only) on a line-by-line basis, which makes changes to inline elements (especially small changes such as a correction of a single individual misprinted character) very difficult to spot and assess, and that is something that we will have a frequent need for. There are a number of other technical difficulties (with managing appropriate read and write repository access and so on) that would also need to be overcome for a Subversion-based solution, but the impracticality of the diff process for editorial review is in itself too great a sticking point to make their resolution worth investigating. Accordingly, although we’ll be continuing to use Subversion control for successive versions in the revision system (something it is very good at), Subversion won’t quite do what we need for handling old and new versions simultaneously and exposing both for XML processing.

We have instead decided simply to include the new version of some part of the data alongside the old version within any amended XML data file, allowing both to be seen and compared easily (and allowing for notes to be added as desired). This further enables a two-stage editorial process of formalizing an amendment (i.e. putting the appropriately tagged new version in its relevant place alongside the existing version) and then after its editorial approval incorporating it as the live version (basically by swapping the old and new versions, with the old one retained to provide part of any corrigendum instruction to be printed, e.g. For {old version} read {new version}).

Creating a structure that will handle the draft entry of changes, their editorial review and approval (or rejection), and their implementation in the data and collation for publication has meant some adaptation to the principal DMLBS XML schema as well as the devising of new transformations (e.g., to incorporate the approved changes, and eventually to produce a formatted list for publication).

Thankfully in addition to our data for the dictionary we have a perfect set of sample amendments as a testbed: an existing set of corrigenda, published at the start of vol. II of the dictionary.


Corrigenda (A-L) from Fasc. VI

So how did we go about formulating the schema changes to be made? We began by establishing our requirements. First, we roughly sketched out the key points of the editorial revision process: recorded suggestions (from the tracking system) are turned into draft amendments that sit in the relevant place in the data alongside the current version (stage 1); the draft amendments are then reviewed and, if approved, incorporated as the live version, with the replaced data retained for reference, marked as old (stage 2).

Second we considered the kinds of revision that we want to be able to make to the dictionary, such as substituting a word in a quotation for another, or moving a quotation from one entry to another. For this exercise the printed list was invaluable in suggesting possible kinds of revision; though we have not considered ourselves to be limited by the list, if the new system can cope satisfactorily with the majority of its changes, we can be confident that it can cope with the majority of our future needs. (Not all its changes, indeed, would be relevant in any case, e.g. those relating to things now carried out automatically, such as the running heads.)

What about additions or deletions? These can be treated as new versions with no old versions or vice versa respectively (with deleted entries being a special case, on which more in a later post). Thus a structure covering substitutions would be sufficient for both these scenarios too.

The two stages in the proposed workflow point to two different structures, related to each other. In the first, the substitution needs to be represented as alternatives, i.e. a grouped pair of siblings of the same type. For instance, a quotation <qt>quot1</qt> element to be replaced with a different <qt>quot2</qt> element might be best treated as sibling children of a <revision> within the usual parent of <qt> which is <q2>; this might point to:


The <revision> element could also allow notes as children and be marked for whether the revision would feature in a printed list or not (i.e. simply be incorporated silently).

<note>quot2 is a newer version of quot1</note></revision>

A disadvantage of this structure, though, is that the status of quot1 and quot2 as old or new versions is ambiguous, being implied only by position. Adequate though this might be for a substitution (in which, say, old might conventionally precede new), for an addition or deletion, the sole <qt> child would be indistinguishable in status. For this reason we instead mark both as old or new respectively, using <for> and <read> as intermediate parent wrappers:


Now an addition can be seen clearly, structured as a <read> without a <for>, and a deletion as a <for> without a <read>.

Two further matters arise: first, at what structural levels (i.e. in what elements) do we allow this kind of <revision> to appear? Clearly it makes sense for there to be some limits to this: review of the existing list suggests that the key levels are substitution of entry, lemma, sense, subsense (definition), subsense (quotation group), quotation. Although it is tempting to allow changes within the text of individual elements, their structure and downstream processing would be considerably more complex, and as a result, we decided that since every proposed change could be formulated in terms of a change at one or more of these levels, every change would be treated at the lowest possible of the levels identified.

This raises the second matter: though it is desirable to record all changes, even small ones, in such a unified consistent way, would it really be desirable to print a full quotation in both old and new versions in a corrigendum list when only a small part (perhaps just a single letter) was being changed? Clearly the answer is no, and so the structure is adapted to allow a <print> note to clarify for publication the change made, effectively summarizing the differences between the full <qt> children of <for> and <to>:

<print>in quot1 for 1280 read 1180</print></revision>

By having the new version present in full (with or without a <print> note), we can make the process of converting to the second stage of structure very much easier (on which transformation, more next time).

The necessary updates to the schema for stage 1 therefore permit <revision> elements at their relevant levels, with appropriate children allowed within the <read> and <for> children (e.g. within <q2> the children of <read> and <for> are <qt>, while within <entry> the children of <read> and <for> are <s1>), and allowing for <note>, <print>, an indication of type (print/silent), and editorial authorisation.

The second structure needs to hold an amended entry at the end of the process and reflect its heritage while fitting in seamlessly, i.e. sharing a structure, with other unamended entries around it. Of course, one option is simply to mark the change as authorized and leave it as is:

<print>in quot1 for 1280 read 1180</print>↩
<auth incorporated="2013-07-01"/></revision>

But this makes it harder to distinguish and process the amended file in among lots of other unamended entries where, for instance, the other (live) <qt> elements are direct children of <q2>. The second structure therefore has the new version in the position it would have been in an unamended entry, i.e. in the place where the <revision> element was, with the replaced version retained, now as its descendant.

 <q2><qt>quot2<amended incorporated="2013-07-01" type="print"><qt>quot1</qt>↩
<print>in quot1 for 1280 read 1180/note></amended></qt></q2>

This structure works well for substitutions and insertions (which would, e.g., lack the <qt> child of <amended>) but less well for deletions. For these the logic simply points to:

 <q2><amended incorporated="2013-07-01" type="print">↩

Of course, this might look like the record of a substitution for the parent <q2>:

 <q2><amended incorporated="2013-07-01" type="print"><q2><qt>quot3</qt>↩

However, the node names in fact prevent ambiguity. In the case of a deletion the parent and child of <amended> have different names, whereas for a substitution they will have the same name. So no confusion need ever arise: each type of change at each level can uniquely be identified by structure and/or name.

The coding of these alternatives in XSD was not straightforward (‘unique particle attribution’ is a real and unnecessary pain here: why should we care which pattern is matched if an element matches more than one valid pattern within its type, provided it does match one?) but finally we have a working Schema that captures both stage one with <revision> and stage two with <amended>.

In the next post we look at the editorial workflow itself and considerations around types of changes, approval, and the first steps in transforming from one stage to the next.

Read the other posts in this series here.

Revision (part I)

Discarded carnation in an Oxford streetExam season has been upon Oxford over the last few weeks. Throughout the city we’ve seen students in formal academic dress (‘subfusc’ and gowns) usually ornamented with colourful carnations (white, pink or red, according to whether a student is on the first, middle or final exam of a series) making their way to and from exams, often armed with bundles of notes for last-minute revision. Whether taking preliminary or final exams, most students have spent at least a few weeks in careful preparation for this moment, and revision is a key part of that process.

In preparing the dictionary too, the process and the result depend not only on an initial stage of drafting that can be likened to a student’s first forays into each new subject; preparation similarly continues through repeated readings and improvements, a series of ‘revision’ processes in which the content is reviewed and refined. Although such revision is perhaps somewhat more ordered and systematic than the labours of even our most diligent students, it is nonetheless a good parallel: by looking again at the draft text with fresh eyes and concentrating on particular aspects, we can find that problems that have not previously been noticed can stand out, while solutions to others that have previously seemed intractable can suddenly open up.

In fact, as well as the fascicule(s) in preparation at any point, the dictionary as a whole can equally be considered a work in progress too, as can only be expected for the output of nearly 50 years of concerted editorial work. In that time we have published well over 3,000 pages of text, and within them many tens of thousands of entries containing hundreds of thousands of quotations. Thus even after a fascicule has gone to press, sometimes many years afterwards, we are bound to observe things in the published text that we would wish to correct or amend in the light of discoveries made by us and by others as work has gone on.

Because of the size and complexity of the dictionary, handling these corrigenda is by no means a straightforward exercise. Therefore establishing an appropriate revision workflow has been an important task for the project over the last couple of years, especially as we now approach the time when we will wish to do the work of dealing with these both in print and in our final XML data. This development process has gone through some significant steps in the last few weeks, and so this is the first of a series of posts in which we take a look at how we have gone about this task given the various constraints we have to operate within.

I. Collection

As the first stage of the process, clearly the possible corrections need to be recorded when they are noticed. Possible corrections come in many types. Sometimes we know what the desired change is, i.e. we know what we would want to print instead of what has already been printed, whether that is a deletion of some existing text, an insertion of new text (such as an additional quotation), or an amendment. Sometimes, however, we can only recognize a difficulty in something published but we do not yet have enough information (such as a full quotation or its reference) to be able to know what we would want to print; for these, further research will be needed before we can decide what, if anything, to do.

Editorial Management System interfaceFor many years suggested items for attention had been collected on slips in the traditional manner and sorted alphabetically in boxes. In more recent times they have been recorded electronically within our Editorial Management System, an installation of the issue-tracking system Redmine (also used by the project for more general tracking of the editorial workflow for material being prepared for publication). The tracking system allows us to record in a structured searchable form as much information as we have (and to add to it as new information is found). This means that we can concentrate on our current primary task of preparing new material for publication, leaving ourselves a well-ordered set of queries to work through in due course.

Using a structured form for recording ‘issues’ means, for instance, that we can categorize possible changes as being either ones that affect only our electronic data (e.g. discrepancies in tagging or between the captured XML and the printed text), such that it would not relevant to publish a correction of this kind in print, or ones where a amendment should be included in a published corrigenda list. Similarly, we can record whether an issue would affect only a single entry or whether it is something we might wish to amend globally across the whole dictionary text (e.g. changing a bibliographic abbreviation or sim.).

Neither of these groupings would have been easily extracted from the earlier box of paper slips (though admittedly the former distinction would not be relevant to a purely paper-based dictionary, and the latter largely impossible to implement without having structured data such as XML or the like on which to work)! Both are important distinctions, however, because they will allow us to prioritize and order the revision process: for instance, a global change could affect any entry and so it will be important for us not to have entries undergoing individual revisions at the same time in such a way that they miss a relevant global change or in such a way that the results of the two changes are incompatible.

It is in fact worth highlighting the decision we have made to use an off-the-shelf system rather design or cobble together our own from generic tools such as a database, spreadsheet, or set of word-processed documents (e.g. mimicking the previous collection of corrigenda slips): it illustrates the fact that these days there is rarely a task so specialized that there is not already some existing software solution readily available, very often free and open source, that can be used directly or at least with easy adaptation to meet the demands. While such software will come with some of its own challenges (in setting up, customizing and learning) that might be absent if one used more familiar software (Word, Excel, etc.), there are certainly long-term benefits of getting a more specialized solution that does roughly what is wanted and adapting it to the particular needs.

Redmine, for instance, is easily customized for various types of workflows and classifications for issues (i.e. items for correction), and for various user roles and privileges with regard to their review and management; at the same time it provides a user-friendly interface for editorial staff to contribute items, and it can securely handle multiple simultaneous users. (It is also exceptionally easy to deploy, using the Bitnami stack.) In a later post we will look at how the workflow management capabilities of an issue-tracking system transform a simple database of issues into a powerful organisational tool to enable efficient processing.

In the next post, however, we look at the amendments made to our XML schemas to enable the various stages of the workflow once a suggested issue gives rise to a change that is identified as needing to be incorporated into the dictionary.

Manuscripts online

Cuthbert digging with a monk

MS British Library Yates Thompson 26 f. 41: Cuthbert digging with a monk, from Bede’s prose Life of Cuthbert, ch. 18

It’s easy to see that the advent of digital technology has revolutionized the modern world by enabling us to do things that would simply not have been possible before, and of course in many ways this is true. However, it is often easy to overlook those many ways in which technology enables us to do things that were previously possible more quickly, easily, or safely. The availability of digital images of manuscripts online from libraries around the world proves invaluable to us in this respect.

Much can rightly be made of the impressive collections of beautifully illuminated and decorated manuscripts that are increasingly being made available in this way, such as those at the British Library (further information here). The value of these as works of art and especially in inspiring interest in the medieval world is ample justification for this programme. But of course there is so much more to medieval manuscripts than their illustrations: their texts too are of fundamental importance to scholarship, and the increasing availability of images of these original sources is worth celebrating for what it enable researchers such as us to do.

Manuscripts and editions as evidence

The DMLBS uses the evidence of surviving Medieval Latin texts to identify and document the vocabulary of the language as used in British sources during its period. Sometimes this evidence is indeed available only in the original manuscript sources themselves, such as those in the National Archives; often, however, we are able to use editions of texts (printed or electronic), in which an editor has reviewed the manuscript evidence for a text and attempted to establish what was originally written by the author.

One question that regularly crops up as a result concerns the extent to which we should trust or rely on the available editions. A whole range of factors might bear on whether a particular edition is overall a reliable version of its text (or at least, whether it is as good as could reasonably be expected given the surviving evidence). Certainly a reading of a word or phrase in an edition can be treated as sufficient prima facie evidence for us to investigate the apparent usage, especially if it is unusual in sense, grammar, or spelling: indeed even when an edition has been superseded by another one that seems more comprehensive or reliable as a whole, the earlier version may prompt us to further research in respect of that part of the text.

In all editions, though, even those that we might consider generally reliable, at any particular point we may find a clash between our expectations as lexicographers (given all the other evidence we have for Medieval Latin, some of which may have been unknown to the editor of the text) and the text the editor has printed, which we might take to be based on the editor’s expert/specialist knowledge of the whole text, its author, the context of its composition, its manuscript tradition, etc. In such cases one strategy we may adopt is to review the manuscript evidence for ourselves to see how the edited text relates to it. What we see in the edited text could, for instance, simply be a typographical error in the edition that slipped through its proofreading or a misreading by the editor of a manuscript witness to a text.

At this point, then, we are in the position for an edited text that we are in for texts that have never been edited and exist only in manuscript form, such as the many archive documents that were read to provide material for the dictionary.

Checking physical manuscripts

Whereas we may have our own copy of an edition or have ready access to it in one of Oxford’s many libraries or online, the obvious difficulty with manuscript sources for the lexicographer is that they are unique: where they are is generally where they have to be consulted, and even another manuscript containing (apparently) the same text is just that, another manuscript (i.e. parallel or complementary evidence, if there even is another such manuscript). Thankfully many of the manuscripts in which we are interested are within collections that we can access fairly easily in person (e.g. in the Bodleian library, Oxford college libraries, the British Library, the libraries of Cambridge University and its colleges, the National Archives).

For others we regularly rely on the custodian archivists and librarians to examine the relevant manuscripts in their collections and check the readings on our behalf: without their efforts the work of the dictionary team would be very much more difficult and we are always grateful to them for all that they do in support of our enterprise. Recent enquiries have included, for instance, a check of a manuscript held by the Royal Irish Academy in Dublin which confirmed a reading in the printed edition of the Acts of the Privy Council in Ireland (HMC Rep. XV App. III (1897)).

Manuscripts online

We are nevertheless very conscious that we should not impose excessively on the good will of those helpful but busy archivists and librarians nor is it good for original source materials to be handled any more than strictly necessary, whether by them or us. For this reason it is now making a huge difference to our work that good quality digital images are becoming available of manuscripts that we might need to consult and that the creation of digital copies of their material is being increasing seen as a core part of the conservation work of libraries and archives.

It has in fact long been the case that many libraries or archives would be willing and able to supply traditional images of manuscripts in full or in part, but the process was typically slow and expensive: the DMLBS indeed holds a small collection of microfilms of manuscripts (and early printed works, to which some of the same considerations apply).

Now, however, we can often easily check readings for ourselves in manuscripts distant from us without troubling either their custodians or handling the physical artefacts directly. A couple of examples that have arisen in the last week go to show how much of a difference this facility can make.

(i) Throwing in the towel?

Col. 755 of T. Wright & R. P. Wülcker’s Anglo-Saxon and Old English Vocabularies (2nd ed. 1884) is part of a 15th century pictorial vocabulary list and includes the text:

WW col. 755 lines 8-24

WW col. 755 lines 8-24

The entry for touale is the cause of the query, with an English gloss perhaps meaning ‘towel’. We have many different spellings attested for a Medieval Latin word (tualia, toalia, etc.) corresponding to English ‘towel’ (itself also spelled in various ways at the time), and so this is not implausible per se. However, this entry is in a list of nomina ecclesie nessessaria (sic), and while the presence of a ‘towel’ (such as a lavabo towel or a cloth laid on an altar) in such a list is also far from impossible, the immediately preceding entries are for books, mainly liturgical in nature (missal, gradual, troper, antiphonal, etc.), as is the following (temporal). Since and n are commonly very similar in appearance in manuscripts, this was an ideal case for checking the original if at all possible.

The MS edited here is now MS 594 in the Beinecke Library at Yale University and it is available digitally. A check of the relevant part (f. 3v col. 2, item 3) shows that the reading is very possibly hoc tonale, A. a tonal (i.e. a ‘tonale’ or tonal, a type of book pertaining to or containing chant tones, for which the Medieval Latin term tonarius is also found). [This is in fact the reading of WW silently adopted by the OED s.v. tonal at sense B.] This reading fits better in the context, is compatible with the MS evidence, and goes with the other examples we have of tonale (as, e.g., the 1368 inventory of church goods in the archdeaconry of Norwich, Norf Rec. Soc. XIX 29: j martilogium cum tropario, bonum tonale).

(ii) A Harrowing Tale?

Our second example concerns a quotation for a word elsewhere commonly spelled traha. In the course of our research we have come across an example printed thraa in Hervieux’s edition of the Fabulae of the 14th-cent. author John of Sheppey, no. 26 (Les Fabulistes latins IV (Paris, 1896) p. 427):

J. Sheppey, Fabulae no. 26 (ed. Hervieux)

J. Sheppey, Fabulae no. 26 (ed. Hervieux)

The fable concerns a harrow (the traha or ‘thraa’) and a toad, a proverbially familiar combination (cf. Kipling Pagett, MP: “The toad beneath the harrow knows | Exactly where each tooth-point goes”). Here again we wished to check for a possible error in the edition, and again the relevant manuscript images are available online (MS Merton College, Oxford 248 f. 26v). This time the reading of the edition as thraa is confirmed (top of col. 2), and we must take this simply as an example of the ordinary vagaries and variation of medieval Latin spelling (th for t, and h being optionally dropped).

When the DMLBS was first envisaged, the digital revolution could scarcely have been imagined, but the use of manuscript evidence was considered essential. A hundred years later we remain just as committed to such fundamental principles but can take advantage of new ways to see them into practice.

On another edition vs. manuscript question see Mark Thakkar’s recent post on sopositus.