Readers are invited to participate in a promising and methodically thought-through experiment in social editing.
The University of Victoria’s Electronic Textual Cultures Lab‘s Devonshire MS Editorial Group invites contributions to a new project involving collaborative knowledge curation. The project aims at attributing contributions and ensuring scholarly authority.
Guided by Ray Siemens, the ETCL’s editorial group is producing a collaborative electronic wikibooks edition of the Devonshire manuscript, which contains 185 items from the 1530s and 1540s, including complete poems, transcriptions, verse fragments, excerpts, anagrams, and notes by many authors and transcribers.
Because 125 of the poems are attributed to Sir Thomas Wyatt and have been transcribed and published in print, the miscellany was long considered exclusively as a source for his work. Arthur Marotti notes, however, that this “author-centered view of the miscellany obscures its value as a document “illustrating some of the uses of lyric verse within an actual social environment” (Marotti, Manuscript, Print, and Renaissance Lyric, 1995). In addition to Wyatt, other contemporaries contributing to the manuscript include Henry Howard, earl of Surrey, Lady Margaret Douglas, Richard Hatfield, Mary Fitzroy (née Howard), Lord Thomas Howard, Sir Edmund Knyvet, Sir Anthony Lee, Henry Stewart, Lord Darnley, Mary Shelton, and perhaps Anne Boleyn.
The Devonshire manuscript wikibooks site states that the purpose of the edition is to
preserve the socially mediated textual and extra-textual elements of the manuscript that have been elided in previous transcriptions. These “paratexts” make significant contributions to the meaning and appreciation of the manuscript miscellany and its constituent parts: annotations, glosses, names, ciphers, and various jottings; the telling proximity of one work and another; significant gatherings of materials; illustrations entered into the manuscript alongside the text; and so forth. To accomplish these goals, the present edition has been prepared as a diplomatic transcription of the Devonshire Manuscript with extensive scholarly apparatus.
The miscellany illustrates the social use of verse and provides what Colin Burrow calls “the richest surviving record of early Tudor poetry and of the literary activities of 16th-century women.”
Currently, a PDF version of the edition is under review at the University of Toronto’s Iter Gateway. In July, the PDF and Wikibooks versions will be compared and a final edition will be published by Medieval and Renaissance Texts and Studies.
Readers are invited to participate in the editing of this interesting and complex manuscript. Some immediate questions include the following:
- How should blank spaces–often tellingly omitting one name to suggest another–be presented?
- How can the manuscript’s structure be maintained, while allowing for efficient navigation? For example, use of “forward” and “backward” buttons might misrepresent the complex spatial relationship among the poems, which frequently appear side-by-side in the manuscript.
- What is the best way to ensure credit for Wikibooks editors?
Access to the digital facsimile is available to subscribers of Adam Mathew. The link can be found at the bottom of the Devonshire Manuscripts’ wikibooks page.
Early Modern Online Bibliography 
February 29, 2012 at 8:45 am |
TCP partly addresses the problem of maintaining the original printed page’s look by allowing readers of the printed transcription to click on an image that presents the EEBO digital facsimile page. This has been very useful for TCP and EEBO users and might help showcase the spatial relationship of items in the DM.
LikeLike
February 29, 2012 at 11:40 am |
Many thanks for a fine post on this highly interesting, worthwhile project, Anna.
Your suggested solution for conveying the original printed page’s appearance is a very sound one. Poems that appear side-by-side could be constructed by using codes for columns.
Could you say more about the questions surrounding the blank spaces? Is the issue whether to present a single underscore? replicate the number of underscores? Or presenting potential content for those blanks?
As for ensuring credit, the project’s main page does list the main editors involved. Is the issue detailing what each has done? Or how to credit others who lend their assistance to the project? Again, the acknowledgment page seems adequate for giving credit–and it could be as detailed as the project directors think fit.
Finally, will the final edition that will be published by Medieval and Renaissance Texts and Studies be a print or electronic one? I take it the Wikibooks version would remain. Given the complex authorial and other issues that the Devonshire manuscript presents, this project might be one that would benefit from a forum/space for adding new information, conjectures, evidence, and the like.
LikeLike
February 29, 2012 at 12:19 pm |
Alyssa McLeod distinguishes between strikethroughs and superscriptions, which can be transcribed, and blank spaces, which look more awkward. In an email to me, she cites as an example the poem “O very lord / o loue / o god alas,” an excerpt from Chaucer’s Troilus and Criseyde, where Thomas Howard substitutes a blank space for the name “Criseyde,” presumably implying Margaret Douglas’ name. As she notes,
Do we need a new digital convention to indicate a blank space left in a manuscript or is a digitized blank space enough?
LikeLike
February 29, 2012 at 1:18 pm |
To me, the blank in this example does not look awkward on the page, and the bracketed blank space is explained in the accompanying notes. The mark-up used is the code designated for whitespace (&nbps), duplicated several times. This choice is better than using the tag “gap” with the attribute “Reason: missing” because this mark-up typically signals an omission by the transcriber. In this case the gap occurs because the manuscript/document is torn, has a hole, or the like, and thus the text is literally physically missing.
I should have also mentioned that atypical page appearances could be handled through other kinds of coding that designate surface and units within that surface; in other words, coding for columns is not the only option for dealing with an unusual layout.
LikeLike
February 29, 2012 at 2:04 pm |
I just looked at TEI documentation guidelines and discovered that there was indeed a convention already established for handling this issue of blank spaces: the use of “space” placed within the less than and greater than brackets.
LikeLike
February 29, 2012 at 5:48 pm |
Thanks, Eleanor! That convention has the benefit of calling attention to the intentional use of space.
The use of “space” between less than and greater than signs will make readers want to consult the digital facsimile, if they can’t see the original. Is there a chance Adam Matthew might allow links to the digital transcription?
LikeLike
February 29, 2012 at 7:01 pm |
Hi,
Heavens, thank you both! I am going to out myself, both as a member of the Devonshire MS editorial group and as a fanatic about the details of TEI use. The TEI encoded version of MS uses rather than “space” to represent the gap in the text — I would love to discuss the best practices for the just representation of atypical sections of our (or any!) MS.
LikeLike
March 1, 2012 at 12:31 am |
We are so pleased that you have joined the discussion, Constance! Your remark about what the DM project is using to indicate blank space did not appear because the comment coder translated your mark-up as a literal space. When I looked at the source code for the example Alyssa offered Anna, I saw that the DM project repeats the standared entity for a space (the & followed immediately by “nbsp”) several times within brackets.
LikeLike
March 7, 2012 at 7:52 pm
Hi,
Ah, the perils of carets. We have been marking up the gaps using as
space quantity=”6″ unit=”chars”
which we transform into six non-breaking spaces (nsbp) in the wiki markup.
LikeLike
February 29, 2012 at 7:41 pm |
One can also add additional elements (“quantity=X” and the a definition of the unit) after the “space” tag but before the closing greater than bracket to indicate the size, extent, dimensions of the space.
Example from TEI:
As <space quantity=”7” unit=”minims“/> han within her oratoryes
I had wished for a link to the digital transcription when examining the Devonshire example (and actually the TEI example, too).
LikeLike
February 29, 2012 at 9:59 pm |
A link to the digital transcription of “o very lord” can be found here.
The spaces occur on lines 5 and 20 and are discussed in the notes.
I think the TEI guidelines with Eleanor’s example can be found here, but Eleanor please correct me if I am looking at outdated guidelines.
LikeLike
March 1, 2012 at 12:34 am
Yes, the link to TEI that you provide, Anna, is the same one I provided in my citation above. It’s my understanding these guidelines are current.
As for the digital transcription, I was, of course, able to look at the Devonshire Maunscript project. Instead, I meant that I had wished for access to the Adam Matthew digital facsimile when looking at the DM project’s transciption and also for access to a digital facsimile of the original manuscript the TEI uses for its example of space.
LikeLike
March 1, 2012 at 12:51 am |
Echoing Connie above, thanks for the interesting discussion. I’m a doctoral student working on the Devonshire project in the ETCL; I’m going to add my two cents on the issue, although I shouldn’t be held as speaking “officially” for the project.
Part of this weirdness, it seems to me, is because of the transition from XML undertaken with TEI in mind to the code used in Wikibooks. In Wiki markup, I believe we have used a nonbreakable space to try and get as close to possible what was in the original text, while I believe the XML is much more usual in character. In fact, looking at the first version of the page (which you can get to by viewing entries in the “View History” tab at top right), I see that there were originally no spaces, simply a closed bracket set. To me this says that when we transformed our XML into Wiki markup with XSLT the spaces were not taken into account. Looking further at the history of the page, I can tell that the nonbreakable spaces were added by hand on Feb 23, while the original text was uploaded on mid-December. I don’t have the XML in front of me, but when it’s available on the WIkibook edition (which it will eventually be, most likely), comparing the two different treatments of this poem will be fascinating. It seems to come down to a question of coding for presentation (Wiki markup) vs encoding for logical structure (XML). Charting that transition, especially for a manuscript as idiosyncratic (in a delightful way, of course!) as the Devonshire MS, is a fascinating exercise.
As for the previous/next functionality, I would very much love to hear thoughts on how it might be seen as distorting the original nature of the manuscript. We’re having a version of this debates right now as we build this into the edition.
Thanks for your input, and I look forward to hearing more!
LikeLike
March 1, 2012 at 11:08 am |
Yes, many thanks! I had suspected that the difference might be attributable to the differences in the Wikibooks and the TEI XML-based code. WordPress coding also uses the nonbreakable space character for indenting and designating space.
Also, I had wished that the TEI guideline example–
As <space quantity=”7“ unit=”minims“/> han within her oratoryes
—-had shown not only the coding, but the appearance that coding created. When one uses “space” with a defined quantity and number, does that convey the approximate spacing in the original?
LikeLike
March 1, 2012 at 12:18 pm
I think you’ve hit upon one of the most critical things to understand about XML. It is a markup language, meaning that the goal is to describe something else, in this case a text. The TEI consortium’s Gentle Introduction to XML is a great place to look for helping to clarify this issue (http://www.tei-c.org/release/doc/tei-p4-doc/html/SG.html).
A short excerpt: “Generalizing from that sense, we define markup, or (synonymously) encoding, as any means of making explicit an interpretation of a text. Of course, all printed texts are implicitly encoded (or marked up) in this sense: punctuation marks, use of capitalization, disposition of letters around the page, even the spaces between words, might be regarded as a kind of markup, the function of which is to help the human reader determine where one word ends and another begins, or how to identify gross structural features such as headings or simple syntactic units such as dependent clauses or sentences. Encoding a text for computer processing is in principle, like transcribing a manuscript from scriptio continua, a process of making explicit what is conjectural or implicit, a process of directing the user as to how the content of the text should be (or has been) interpreted.”
So, in a real sense, there is no default appearance for anything in XML. It’s descriptive, not proscriptive, if that makes sense. The goal of TEI rules are to capture a text so it can then be displayed in a variety of different forms, most of which are governed by a CSS or the like. Using the example above, I could, for instance, using a CSS, tell my browser to read any instance of “space” in my XML as a line break, which would place everything after it on a new line. I could also tell it to insert however many nonbreakable spaces I wanted, from a default value to a unique number of spaces based on the value of the attribute (in this case, it would be 7).
In a larger sense, in my view this is also one of the most interesting points to consider with TEI rules: As logical markup, they are interested in what the text _is_ rather than how it looks. Which of course to many literary critics is a somewhat problematic position, especially if you take the view that form and content (appearance and “text” as separate from the individual instance of that text) as different and prisable things. It gets tricky because in situations like this, we are attempting to mark up something that isn’t there, and the way to do that is to somehow try to reflect what kind of space it is by referring to the rest of the document, which is where the other attributes come in. Minims, as you likely know (but I had to look up), are “Minim: the shortest and simplest stroke: the vertical (upright) stroke used to form the letters “i,” “m,” “n,” and “u.” The word “minim” itself would be written in Gothic script with 10 minims.” (http://www.ualberta.ca/~sreimer/ms-course/course/pal-ltrs.htm). So in the above example, the minim is the scale of the height of the space, or unit we are using to describe it. Crucially though, the minim only means something here in relation to other characters in the text. The quantity attribute means, unless I’m mistaken, that it’s seven characters wide. So, without any other information but the text surrounding the space, we can see that it’s about the height of a lower-case letter and around 7 spaces long; This is all descriptive.
In Wiki markup, we’re turning this on its head and through some XSLT transformations we’ve turned this descriptive XML into code that can be put into Wikibooks to produce a particular appearance. We’ve transitioned from capture to presentation, which requires, to put it mildly, a bit of tweaking.
I hope all of that’s not too impenetrable, and please throw any questions out there!
LikeLike
March 1, 2012 at 9:39 am |
Thanks for this inside account of coding for presentation.
For those of us new to TEI, could you say more about how previous/next would function?
LikeLike
March 1, 2012 at 12:26 pm |
Hi all, I’m not sure whether the blog ate one of my comments. It was in response to Eleanor’s follow up question, so please let me know if it pops up?
LikeLike
March 1, 2012 at 12:37 pm |
It’s restored–it went to spam for some reason, so thanks for alerting us to its existence.
LikeLike
March 1, 2012 at 12:38 pm |
It just came through! I deleted my reply asking to resend.
LikeLike
March 1, 2012 at 12:39 pm |
Thanks to the both of you!
LikeLike
March 1, 2012 at 12:52 pm |
Thanks so much for this, DJ. Yes, your point about mark-up language is why I find it so interesting. Years ago I attended the Center for Electronic Texts in the Humanities, and one of the very first things I took to heart was that coding [constructing the Document Type Definition (DTD) and so forth] was crucial intellectual labor. It is interpretive work and can teach us so much about a text. On a related note, brief assignments to mark up a text can assist undergraduates greatly in learning about structure and formal properties–especially when dealing with poetry.
I should note that I’ve not been working with TEI and XML coding regularly for quite a while, but I had achieved a fairly strong foundation about a decade ago and was then involved with ongoing projects for a while. I had to look up “minims,” too–but I also interpreted the “quantity=7” the way you did.
LikeLike
March 1, 2012 at 2:28 pm |
I see that the previous and next links are available through f. 17r.
Is that just because the project is in process, or is there a specific
problem on 17v?
Would the poems on f. 22v make for a good discussion regarding how spatial relationships of poems on the same page might be preserved in the digital transcription? Having a specific example to discuss might help.
LikeLike
March 1, 2012 at 8:26 pm |
You are exactly right! We are in the process of adding previous and next links poem by poem, so some pages have not yet been updated.
The poems on f. 22v (“The knot which fyrst my hart dyd strain,” “He Robyn gentyll robyn,” and “A wel I hawe at other lost”) prove an interesting challenge to represent in print. Notice the different levels of indentation for each poem, and how tightly constrained Mary Shelton’s “A wel I hawe at other lost” is at the bottom of the page. The challenge in any edition is of course to represent the poems themselves accurately while still remaining reader-friendly!
LikeLike
March 2, 2012 at 12:03 pm |
Can you say a bit more about how the spatial arrangement of the poems on 22v might be suggested or represented?
I’m also curious about the answer to Eleanor’s query about whether the final edition will be print or electronic.
LikeLike
March 7, 2012 at 8:01 pm |
The final edition will be both print and electronic, as it happens. Once we have incorporate the best editorial suggestions from our advisory group and from the Wikibooks community, Iter/MRTS will be releasing a print version and a fixed electronic version (for e-readers) of the text. These two fixed versions will represent a snapshot of the text at a particular point, but I expect that the project will keep evolving online, as we add more features and attract more scholarly contributions.
LikeLike
March 7, 2012 at 8:08 pm |
Thanks for the clarification. As someone on the sidelines, the plan makes sense to me. I would also expect that work would continue online–perhaps leading at one point to a 2nd edition of the e-version if not print, too.
LikeLike
March 7, 2012 at 8:31 pm
I can certainly imagine a second or third fixed edition. We are currently working out the best way to move into print while still preserving the (upcoming!) features of the Wikibook. We’ve found that through linking we can bring parts of the edition into conversation with one another in a way that would be difficult in a print edition… we are still at the drawing board.
LikeLike
March 7, 2012 at 9:33 pm |
There are many complicated issues involved, so it is quite understandable that you are still in the midst of working out numerous matters.
While the Svoboda Diary project at the University of Washington is quite different from the Devonshire Manuscript, the two nonetheless appear to share some similar logistical/technical issues. Consider the following description taken from its successful 2011 NEH grant:
The sample pages provided on the Svoboda Diary’s public website help convey what is involved.
We will be presenting some other winning projects in a few posts from now, but your remarks about publication plans made me think of this one. I am sure there are other examples, too.
LikeLike
March 8, 2012 at 1:37 pm |
Thank you for these Eleanor. I quite like how the Svoboda Diary project has leveraged the interlinking and side-by-side textual comparison made possible by an on-screen reading environment. I will be interested to see how they transform these features for the printed page.
I am looking forward to you commentary on the other NEH projects.
LikeLike
March 8, 2012 at 7:55 pm |
Thanks for your referral to this project, Eleanor! I agree with Constance that the side-by-side comparison allowed by the reading environment is quite fascinating. I’m also intrigued by the “Svobodapedia,” the internal wiki the project is developing. I wonder if this will be a tool for editors wishing to contribute to the project, or if it is simply to aid collaboration?
LikeLike
March 9, 2012 at 6:44 pm |
I can respond to this string and add a few comments in my role as PI for the Svoboda Diaries Project. We are, as we have been in the past, working on increasing the functionality of the web version of our text (soon to be “texts” as we add new Svoboda diaries to the project). We are looking on the web version of the text as our primary text because we are continuously up-dating it as we learn more about the family from the other diaries. It is precisely this issue–the immediate out-datedness of a snapshot version–that made a traditional print book seem impossible to us. The collection of diaries we are working with potentially include 40-60 diaries by Svoboda man and one (the Travel Journal) by his son.
We are using our wiki (the Svobodapedia) to collect the information that we glean constantly from the diaries and other sources. That way we keep the notes to the text brief without discarding information and our resources grow as new information comes in. All of the people working with us world-wide contribute to the Svobodapedia but it is not open to anyone who does not join the project. Our contributors include Svoboda family members scattered throughout the world, an undergraduate writing a senior thesis, a post-card collector in London, our undergraduate research interns, and some of our colleagues in Middle Eastern Studies.
The programatically produced print-on-demand part of the project has suffered and will likely not be realized in the period of our present NEH Digital Humanities Start-up grant for several reason, some of which may be relevant to your project. A major problem was that the conversion of our XML TEI mark-up turned out to be structurally unsound as our attempt to represent all the features of a complex document did not result in output well-formed enough to allow creation of a program that would set it in type. [And, as we began to address this problem, our programmer found a better job…!] This was ultimately a failure in our DTD analysis. However, given what we have learned, I still believe this will be possible, especially if we do not need to deal with automated typesetting of a book in both Arabic and English. I am hoping that the easily updated POD book will be realized in the next step of our project.
The problems of converting our XML to HTML for the web-display were addressed by creating some clever work-arounds that ultimately should not be necessary with a better structured XML base text.
Other questions about our project are welcome!
LikeLike
March 9, 2012 at 9:09 pm |
Many thanks, Walter, for the details about the Svoboda Diaries Project. All very interesting. The project itself is a fascinating, ambitious one, made all the more so by the plans for the POD. Although the project has hit a very disappointing stumbling block, I am heartened that it still seems that before too long it will be possible to generate that “easily updated POD book.” The project’s interest in re-thinking the print book from the perspective of digital possibilities appealed to me. Often the print book is left behind or (often rightly) faulted for hindering re-imagining the book in terms of the web or digital media models.
LikeLike