On Collaboration and Building II: Digital Architecture and BL 35157

In order for a digital project to really live up to its potential–the possibilities it has over print–it has to include an infrastructure. We have already been working on creating structured data, but now we have to think about building a repository for that data.  As long as data is confined to a particular space–be it a book, laptop or even cloud service–it is accessible only through the entry points that medium makes available.

Many formats make it easy to access information, but difficult to put that information into relationship with other information. What is more, that information is largely from a single source (an author) and cannot be changed or updated as new information comes available, nor can it be altered by anyone other than the author.

That is the power of digital projects: by building an online architecture for your data, you make ongoing collaboration and community-sourced data possible.

Advertisement

Translating Touch Data in Laud656

Talking about touching parchment, this week’s code blog is all about how to add touch data to our JSON descriptions of manuscripts right now, before parchment surface experimentation is perfected (watch this space, it might happen).

I’ve chosen to use Oxford, Bodleian Library MS Laud Misc. 656 for this particular endeavor because it has some really fascinating, really feature-rich, really bad parchment.  And, bad parchment is really the best, because you can see and touch so many features of it.  Unlike really high quality parchment, which has eradicated so many of its distinguishing features that it makes you forget–however momentarily–that it is skin, bad parchment carries reminders of what it was, where it came from, marks of class and production, and so much more.

So, this blog is about capturing that kind of awesome badness in code.  Now, the code to date has a few features that allow me to talk about this thing that fascinates me (the touch of parchment):

The Making of a Manuscript: TCC B.15.17

The visualization post this week was about making a manuscript and the various different economies, ecologies, and congealing materialities that bring forth parchment, the material support on which a text is eventually written.

One of the things I want to draw attention to in that post and the upcoming ones is the fact that a manuscript is specifically more than a text, and thus requires us to look at it with different eyes and tools than we use for looking at texts.  A manuscript contains, or even embodies texts, but it also is and does myriad other things that all affect the way that it matters–the way it signifies in both a material and symbolic sense.

To highlight what I mean, today we are going to encode and examine Trinity College Cambridge B.15.17, a manuscript with a little more known history than most, and I’m going to draw attention to choices I make in coding that aim to bring the manuscript object itself into focus, rather than just simply the texts contained therein.

CUL Dd.1.17 in Spacetime

This week’s code post is going to be short and sweet, unlike this week’s manuscript!

Encoded this week is Cambridge University Library Dd.1.17, one of my favorite manuscripts, and the second largest compilation manuscript in the Piers corpus.  It is, however, a far cry from the Vernon, with only twenty-some-odd items as opposed to close to four hundred.

What I find so amazingly interesting about this manuscript is its tight concentration on a very particular type of text. In particular, its concentration on history and travel literature.  Now, I am by no means an expert in all these contents, so if you happen to work on one of the texts named here, I’d welcome any input you have in the comments below!

What I can see, however, is a very distinct trend towards cosmic history and Orientalia. If we take the larger network graph, and make it its own graph, with full articulation, it would look like this:

Digital Piers Deluxe Edition: The Vernon Manuscript

This week’s Material Piers is dedicated to one of my very favorite manuscripts, the Vernon.  That is, Oxford, Bodleian Library MS Eng. poet. a.1, the single most deluxe manuscript of Middle English in existence. Yeah, really, it’s that epic. And if you don’t know about it already, check it out. Odds are, though, if you know me, you already know about my thing for the Vernon.

The reason this week’s blog is all about the Vernon is two-fold.

A. To celebrate an article I have coming out this week in View: Theories and Practices of Visual Culture on “Picturing Queer Desire in the Vernon” (about something other than Piers) I thought it would be great to talk about my favorite deluxe Middle English beauty.

B.  Because the Vernon is so big and so complex, it merited its own über post.  What better time to talk about it than when we’re talking about  the temporality of Piers Plowman anyway (which both last week‘s and next week’s blogs will be about).

GeoJSON and Trinity College Camb. R.3.14

This image is taken from the Project Gutenberg edition of Whitaker’s text (made from TCC B.15.17) that includes this rendering of a drawing on the opening folio of TCC R.3.14.

To pair with yesterday’s visualization of Piers Plowman in space, I’m going to do a post today about GeoJSON.

GeoJSON is compatible with JSON-LD; both different uses of JSON are trying to link object data (or “feature” data) to other data.  In the case of GeoJSON, that is very specifically linking data with spatial components, particularly in such a way that this data can be mapped.

In order to write GeoJSON, all data has to exist with a single object, which is something we’ve covered before.  A GeoJSON object can only represent very specific types of data, though, that comes as a geometry, a feature, or a collection of features.

Linking CUL Dd.3.13 to the Digital Middle Ages

Don’t worry, this week is going to be much easier, in case you got a little fatigued last week with adding @context to upgrade your JSON to the high-falutin’ JSON-LD.  

In order to make JSON-LD worth our while, we want our data to be linked to other data, preferably data that is already available online. So today’s post is about how to signal within your own data connections to other data in other databases.  

 

Some of the key databases that are going to come in handy for us include:

@context for Trinity College Dublin MS 212

Last week, we went over how to write simple JSON to describe a manuscript object.  It wasn’t a perfect description (in fact, if you noticed, I used the same “name” in two different “name”/value pairs to mean two different things! I used “folios” to refer to how many folios the MS contained and which folios Piers occupied), but it was valid code.

 

What I want to talk about this week is how to write descriptions in JSON that are able to be incorporated directly into a linked data framework.  Now, I’m going to talk at more length in a later post on linked data and the basic principles thereof.  To define it in brief, though, I’ll share this definition from W3C:

Linked Data is a way to create a network of standards-based machine interpretable data across different documents and Web sites. 

Today, I simply want to show you how to go from JSON to JSON-LD in a few simple steps that aren’t very much harder than what we did last time.

Bodley MS 851

That’s, right, let’s begin with the Z-text.  For a first JSON post we are going to start with one of the earliest manuscripts, and I am going to do nothing but talk about JSON and describe the Z-text manuscript in valid JSON code.

So, to get going, let’s talk for a second about this horrifying acronym, “JSON,” which stands for Java Script Object Notation. JSON  is a simple way to store and send STRUCTURED DATA. It is typically used for allowing a web page to exchange data and messages with the server without the whole page having to refresh or update.  It’s simple, it’s complete, and it doesn’t interfere with your ongoing activity on a page but allows you to see more.  Think about things that pop up when you hover over an object, or a shopping cart that may show what’s in your cart without leaving the page you’re on.

Why JSON for data? Well, we are going to talk more about JSON-LD for linked data in the next blog post, but the simple answer is that it allows us to describe a real world object in code in such a way that the resulting script is BOTH human- and machine-readable.

I swear, it’s not scary at all.  Simple JSON often looks like this:

{

“name”: “Jane Medievalist”,

“institution”: “Medieval University”

“books”: [

“name”: “The Middle Ages Rock”,

“name”: “You wish you were medieval!”,

“name”: “So you think you can alliterate?”

]

}

What is this? Well, it’s a JSON Object, which we know because the whole thing is enclosed in the curly brackets { }. JSON operates on objects which can be as simple and elaborate as you like.  Today, I’m presenting the Z-text manuscript as a SINGLE JSON OBJECT.