Data management is extremely important on the back-end side of a project, which is where I’m situated right now. Honestly, data management is most of what I need to do. The most important aspect of it (and will eventually affect how the data is sent to and from the front-end) is how the data tables will be laid out. To achieve this, I’ve begun work on something called an entity-relationship diagram. Some of you might recall that I wrote a blog post about them last semester. They are a way to lay out exactly what the tables will be, what attributes they will have, and how they connect to each other. For the data management plan, we need to know that our database is workable.

I went about making a very rough diagram and came out with four distinct tables. The first will be for users and their login info, the second will be for users and their profile info (email, name, etc…), the third will be for XML posts (date posted, text of it, author and name of poem), and the last is for connecting the user table to the posts table. Of course, this is still subject to change based on how the project will morph over the coming weeks and months. There might be tables we don’t even know we need right now.

For the database itself, we’ve decided to go with cloud storage and use a free database like PostgreSQL or MongoDB. This will then be connected to our web app on the back-end. It’s important for any data management plan to know where this data will be stored and have a trusted database technology behind it. PostgreSQL and MongoDB are scalable and can be used easily at the start and can continue to function well beyond the early scope of this project. These are also up-to-date and modern, and are used throughout the field of data management. There’s very little concern that they will be deprecated any time soon. Using these should help to show that we have an understanding of the potential longevity of the project.

To sum everything up, my research into what technologies to use and how to use them are going to be affected by the data management plan. What we’re storing and how the app will work will determine how I go about building the database in the end.

After reading a bit more into data management plans, it’s very clear how useful they are not just for large scale projects, but for my own research practices for a couple of reasons.

Outlining what data you believe you’re going to collect for a project is not just helpful for record-keeping, but also determining the scope of the project. Expected data deals with what you believe the project or research is going to capture throughout its duration. It’s not just a number – an outline of expected data includes file types and original locations. Not outlining what kind of data you’re expecting to aggregate could be detrimental to your operations due to unexpected size, storing, and backup issues. It’s also important to have a grasp on what kinds of file formats you’re going to be dealing with. There’s not just data to worry about but metadata as well that has to be accounted for when dealing with any of this data (in terms of transfer or context).

Hard drives and cloud storage can eventually fill up and become quite costly. Data types for a project or research might slowly grow in size over time, and it’s important to have a schedule of what to keep. On a personal level, not knowing how long you’re going to retain data is dangerous because you can be blindsided by storage issues if you cannot handle the lifecycle of a project or research endeavor. Related to this is data security – with the amount of data that’s being processed and stored, there’s a large risk for partial or total loss. There might also be sensitive materials that need to be stored but kept classified. Having a plan for all this mitigates risks that might come from any research project including these types of data.

On a more blunt note, DMPs will always be useful for personal research practices because they’re required for grants. If your DMP isn’t strong, or there’s information that’s missing, you’re less likely to get approved for funding.

After the rush of last week, I’ve started to focus on the details of end/line (the new, group-approved name for the “encoding as close reading” project). I’ll be serving as project director and project manager, articulating its overall vision and ensuring that our group of five keeps it on track. Obviously, the need to communicate its goal of providing a platform for a particular mode of poetry/poetics and digital humanities pedagogy will prove challenging, as will the quick turnaround required for this project. Though I’ve never directed a project before, I hope to attend the 13 March GCDI workshop on digital project implementation. And while I do have some professional experience managing web development projects, I’ve only done so in existing infrastructures where, for example, third-party vendors handled all hosting or database tasks and details or we hired a professional designer to produce the marketing material. With end/line, I’ll need to think all of those tasks that I’ve previously taken for granted. I’d also like to hone my existing project management skills, and have started reading a host of articles on the subject at A List Apart.

Despite these challenges, however, I’m excited about the prospects for end/line for numerous reasons. First, the Textual Coding Initiative is a longstanding digital humanities community (dating back to the 1980s) and, by interacting with its verse module, even in this small way, I think we can articulate its ongoing importance to the field (and to literary studies in particular). Second, my work at the Graduate Center has drawn me, increasingly, to twentieth- and twenty-first-century experimental poetry that might frustrate encoders and challenge close readers. When the class workshopped my initial proposal, Eddie mentioned Susan Howe as an example of someone whose work would be difficult to encode. I’d love for our final prototype to demonstrate, technically and visually, how encodings are themselves acts of reading that produce interpretations. Third, as Professor Brier often explained last semester, much digital humanities work ignores pedagogy; this project does not. And, finally, translating last semester’s thoughts, ideas, and curiosities into an application like this seems like a worthwhile goal.