In the world of the Blake Archive, Blake Camp is one of the highlights of the year. We talk about it as a magical place where tricky problems will be solved and difficult decisions finally made, and even use it to measure time, referring to events as happening “before” or “after” Blake Camp. This year, I was going for the first time.
In his post on the history of Blake Camp, Morris explains that “there is no virtual stand-in for meeting in person.” He’s right, of course, as our weekly BAND meetings prove, but it feels very odd to prepare for a two-day meeting with people you’ve never met before. We’ve spent a lot of time emailing and skyping, but what if we don’t like each other In Real Life? What if our 3D personalities clash in a way that our 2D ones do not? Scary stuff indeed.
Of course, my worries were groundless and I was welcomed with open arms: you’ll be glad to know that 3D personalities are really basically the same as 2D ones. This is neither the time nor the place for me to join the ranks of my many compatriots who like to write about their impressions of the United States (hello Dickens and Stephen Fry), but I had a great time. Yes, the meetings are intense with a fully packed agenda, but an amazing insight into the inner workings of the Archive. I got to eat fried chicken and barbecue and spend time in a charming college town. Bonus points: the UNC campus is honestly really rather beautiful, and just how Europeans want American colleges to look.
We’ll post an update on the wider business of Blake Camp in more detail soon, but for now I just wanted to share one of the problems that I brought to Chapel Hill on BAND’s behalf. As well as an editorial planning session, one of Blake Camp’s most important functions is to provide an opportunity to actually talk about any issues that have arisen over the past year. We all know how convoluted even the most straightforward email conversation can become when many people are involved (no, Digital projects are not immune to that problem), and so often, specific questions are shelved until we can discuss them in person. Our work on the typographical editions in particular, has led to a lot of head-scratching as we try to work out if our existing tagset can be stretched to include the encoding issues that arise with these new works.
Here is the definition of the element <lg> from our documentation followed by the questions I brought to Blake Camp.
<lg>. This element identifies line groups–i.e., blocks of text on the object, such as stanzas or paragraphs. For verse, simply use <lg>, but for prose text (i.e., not poetry), use the type with value “prose”: e.g., <lg type=”prose”>.
- We tend to use <lg> to describe blocks of texts as they appear on the object and not to describe a unit of related thought, like a stanza. So, for example, if there is no space between two paragraphs, we would consider them to belong to the same line group; and if there is a space between two lines within a paragraph, we would encode this as separate line groups. Note: <vspace> cannot sit inside <lg> tags.
- We’ve notices an inconsistency about using @type. For example, some BADs use both <lg type=”prose”> and <lg type=”verse”>.
- Some text does not fall within these categories: should we class a title as “poetry” or “prose”? Or do we need a new (perhaps general) value?
The first answer turned out be quite simple because we had been misinterpreting the definition of <lg> . We should think of a line group as a visual entity, lines that look like a unit on the object, regardless of any linguistic meaning. This also explains why <vspace> cannot be a child element of <lg>.
The second and third questions brought more discussion as we wondered whether it is actually necessary to distinguish between genre in our encoding. What advantages and disadvantages accompany this separation? Our golden rule of “transcribe what you see” would suggest that it is not really necessary since doing so could be considered an editorial interpretation beyond our remit. However, at the same time, we don’t know what kind of display, sorting or searching capabilities might be affected down the line. Leaving out the @type would also solve the problem we encounter in question 3.
In the end, we decided to stop using @type. Right now this seems like the simplest decision that will lead to the greatest consistency in our encoding, which has to be a priority. As we move forward with new challenges, such as Blake’s Notebook or the Four Zoas, we’ll let you know how this decision works out.
—
