Deep Maps: Blue Humanities is one of three experimental book pilot projects selected by Copim's Experimental Publishing Group as part of the Open Book Futures project. As part of the experimental book pilots, we are documenting the writing, review and publishing processes to share, learn and reflect and to provide starting points and resources for other authors and presses that might want to embark on similar ventures.
For Deep Maps we are planning to develop a workflow based on Markdown files, that will be rendered into an online monograph using Juncture. The technical setup, basically a way of assembling a bucket full of Markdown files and media items, corresponds to the ambition to create a deep mapping, or layering of interconnected texts and media. In line with the ambition to layer text and media, the documentation too will be a layering of notes from a series of conversations. We are recording and transcribing each conversation with the help of various machine tools. Staying close to the audio recording gives the transcript a conversational, searching tone that we feel jive with the spirit of deep mapping. Editing the transcripts adds a flow and concistency whereas the audio at times decends into rambling, which is why we decided to publish the edited transcripts rather than the audio recordings. The edited transcripts, enriched with screenshots and links to relevant resources will be folded into a Deep Maps making-of section.
We will also be sharing our conversations here on the project blog of Copim's Experimental Publishing Group.
Deep Mapping Sessions #1
Monographs 'n' Markdown
Julien
So, yes, we are recording. Yes, okay, welcome to the first Deep Maps: Blue Humanities Documentation sessions with James Smith and Simon Bowie. I am Julien McHardy. I will host the sessions in conversation with James, the author of the Deep Maps, and my colleague Simon at the Experimental Publishing Group.
In each session we will cover one aspect of the making of Deep Maps to share our experience with others. We are working with Westminster Press, a fairly traditional publishing house, that developed this project with us to open their portfolio to new ways of publishing. We will hear from Westminster Press about their experience in a later session, because the plan is to invite our partners to relevant conversations. We are also working with ITHAKA the foundation behind JSTOR, and more specifically with JSTOR Labs. JSTOR Labs, a kind of innovation group at JSTOR, has developed Juncture: a really interesting publishing tool that allows you to dynamically display text and other media alongside.
For Deep Maps we are going to use Juncture, which was designed for journal publishing, for a monograph for the first time. We will hear more about this in a later session with our partners at JSTOR Labs. Today, we're starting with the basic building blocks of Deep Maps, Markdown writing. James, could you introduce yourself and say a little bit about the book project?
James
Sure. I'm James Louis Smith. I'm an environmental humanities scholar. I also work in university funding. Deep Maps is a book I've been working on for a long time, in my head, and I've always wanted it to be an experiment.
I held off publishing a second monograph because my first book was quite conventional with a traditional publisher in medieval studies. I'm happy with that, but I wanted something new. And this pilot program was the perfect thing for me because it really gives me the chance to work with different partners, with the publisher, with JSTOR Labs as a toolmaker, and with Julien and Simon to try something different.
Deep Maps: Blue Humanities is a combination of my interest in the Blue Humanities, which is a multitransdisciplinary study of the oceans, the rivers, the watery spaces of the world. And in this case, the depth of the oceans; and Deep Maps, which is a method of layering a lot of different contents of different kinds on top of each other and creating a kind of thick description.
Deep mapping is creating a hungry corpus that sucks up a lot of different content and you lay it on top of each other, and no journey through the content, and no argument is ever quite the same twice.
And I wanted to work on something where the structure would mirror the content. And I tried to do that as well, as we're going to talk about today, with my writing process because I'm writing in pieces in a sort of bricolage way, which is actually something I've always done to some extent. But in this case, I'm going even further on that. So this is the first step on that journey.
Julien
Simon, would you also introduce yourself and maybe say a few words about the pilot project program that accommodates Deep Maps?
Simon
Yeah, of course. I am Simon Bowie, I am an open source software developer at the Centre for Postdigital Cultures at Coventry University and am part of Open Book Futures. My experience is in supporting open source projects in library systems, information systems, and publishing projects like this. So I've worked on helping to develop open source tools for various publishing things, including this project.
Open Book Futures is supporting this pilot project. Open Book Futures is a three-year research project, which is extending the work of the Copim project. Under the umbrella of these projects, we founded the experimental publishing group with Janneke Adema, Rebecca Kiesewetter, Julien McHardy and myself, to support experimental publishing and showcase interesting experiments in the world of publishing. As a part of this, we are supporting pilot book projects along the way by offering technical support or publishing expertise or what have you. This includes James's book. I'm very excited to be working alongside James, supporting him on this book and talking about some of the technical things that we're doing as part of this project.
Julien
James, you have started to write Deep Maps in Markdown. Can you explain what Markdown is and why you are using it?
James
So essentially, the reason I'm doing Markdown is... Let's start at the beginning. It's increasingly common now for people to write in a sort of incremental way. As a method, it's actually very old. I think since the '50s, it's known as the Zettelkasten method, which is a method for collecting cross referenced notes, popularised by the sociologist Niklas Luhmann, who was known for having this real knack for linking things together. Another example that might be quite famous is the collection of Aby Warburg now housed in the Warburg Institute in London. In a kind of revival, there's a lot of people now doing blogs and what are called digital gardens of different maturities of notes. What I wanted to do was grow my writing.
The Obsidian Graph View of the notes surrounding the book project, taken 2024-09-06
Here you can see a kind of a cloud of links between the different tags, the graph view. The red ones are the paragraphs and the green ones are how things relate to other things. It's also easy to get it to reassemble itself in different ways. You can do search for different types of tags and it's an easy way of managing your text. The whole thing is part of this sort of vision of a modular, simple, interoperable way of writing. It challenges, as you can imagine, traditional publishing workflows such as copy editing. Some things are just fragments, they're like a bud. Some things are more mature, full paragraphs or sections. You can recombine them and bricolage them and build something out of them. And Markdown is a great way of doing that. And Obsidian is a software that is great at organising Markdown notes.
The notes can be stored locally, or you can use cloud computing to keep copies of all your files and sync them. Markdown files are very lightweight and they are easily interoperable, which means that you can open and manipulate them with different software instead of being locked into one particular editor. And you can store media items with the Markdown files and link them. And important for our project, Juncture, the tool that we are using to render the book, is also Markdown based.
Juncture has its own custom tags, its own flavour of Markdown. But the default paragraph text is very vanilla Markdown for want of a better word. It's links, it's hyperlinks, it's footnotes, it's plain text, it's italics and special characters. And then you have media items that you can set up to appear in different ways alongside the text. Using Markdown text files with Juncture means that we can keep the whole thing in a sort of iterative fragmented environment where it doesn't have to fully coalesce, but still hangs together.
Obsidian screenshot of a note fragment (left) with a continuous scroll of linked paragraphs on the right, taken 2024-09-06
Julien
Let's step back, to introduce Markdown in a bit more detail. Simon, could you tell us about Markdown and how it differs from other text formats?
Simon
Sure. So on a very basic level, Markdown is a very easy to use markup language for creating formatted text, for creating structured text. It's kind of similar to the .txt files that come out of Notepad on Microsoft Windows: just very simple text. Markdown is like the next step up, because it's got structure. You can add structure to it with headings and other formatting like bolds and italics and basic formatting that isn't available in a simple .txt. The formatting is not separate from the flow text, but written into the main text. Putting a * before and after * a bit of text, for example, renders that text part in italics, # will create a level one header and so on. Including the formatting in plain text, in the text file is less complicated, less complex than the structure you'd find in a Microsoft Word document, for example. It stems from a radical publishing tradition, having been developed by John Gruber and the dearly missed hacktivist Aaron Swartz who pushed the idea of doing different things with text and looking at text—computed text—in a different way than big scholarly publishers. In terms of the advantages from a development perspective, Markdown is very easy to work with, precisely because there is no formal differentiation between content, structure and formatting. It is essentially plain structured text. A Microsoft Word document, by contrast needs to be compiled to become readable. This makes manipulating Markdown with a coding language like Python very easy. I can simply read a Markdown file into Python, for example, and use code to divide it up however I want, using whatever section, hashtags and whatnot. At the same time, we're looking at it on the screen right now, and it is very human readable as well as being computer readable. So for me, it has the best blend of being computer- and human-readable. It just works really elegantly. I use open source note software called Joplin, which keeps all my notes in Markdown. I've got them stored encrypted on a server somewhere. I can use them in developing stuff. In short, we can very easily manipulate, edit, sort and render the notes that James is producing in a range of different software, and that's made easy because Markdown is interoperable and computer readable. It works really well. It works really easily. And it's just a simple way of doing things.
Julien
Looks like we're a group of Markdown converts. I started to do all my writing in Markdown about a year ago, using software called iA Writer for composing and focus and Obsidian for organising and linking notes.
To summarise, Markdown has a couple of advantages. Firstly, it's human and computer readable. Secondly, many people find that they get less distracted by formatting options when they write in Markdown. Thirdly, your notes are not locked into any particular software, unlike like most text formats. This means that you can use Markdown files in a lot of different programs. In the case of Deep Maps, we're using a workflow where the text is written in Markdown and then will be rendered later into the monograph using Juncture. James, can you take us through your Markdown writing workflow?
James
Sure. I should also add, it's not that dissimilar from a lot of other digital humanities projects: it's a bunch of styling and sort of simple files for rendering it in a browser in HTML. Behind the scenes, all that Juncture and a lot of these things is, is a bunch of JavaScript or scripting files that determine how the content is rendered and a big box full of Markdown documents and media items. So all it really is, is yeah, like a particular way of reading and displaying Markdown. A footnote, for example, in Markdown is just square brackets and a number. And you know, then you have a matching call out here.
Footnotes from a draft paragraph on the topic of 'Surfacing', Deep Maps: Blue Humanities
A URL link in Markdown is also just text. You can change the text of the hyperlink and the URL of the hyperlink.
The same link as above showing the markdown without Obsidian's reading view
It's just, it's very, very simple. And then you can basically just spit it out a very easily in different formats. You can make a conversion, for example by using Pandoc. Which also comes as an Obsidian plugin. I use it on my computer to Markdown into something else. You know, you can turn anything into anything really quite quickly. And if you have all of your metadata in place, which can also live directly in the Markdown file, in a really short sort of style header, and put it through Pandoc, it comes out the other end as a PDF or HTML or any other format. You can even have, or style sheets to tell Pandoc how to render the file. Here is an example header taken from Tim Miller, Getting Started with Templates in Obsidian, https://obsidian.rocks/getting-started-with-templates-in-obsidian/:
You have huge amounts of options basically. The other thing I am doing, is to pull my notes into a kind of continuous text using another plugin called continuous mode so I can imagine what combining notes would look like in a single document.
But I've been working off notes that I wrote in Markdown. For media items, I keep a set of notes about things I might want to have between paragraphs. Here is an example of a sound track from my media item on the topic of 'Ocean Grunge', an obscure and abandoned sub-genre of music based on Vaporwave, Drone and Grunge based around thalassophobia, the persistent fear of eerie boundless depth within the ocean.
I chose this item from my note about Ocean Grunge because it is from the Internet Archive and thus public domain, can be embedded into the eventual draft of the chapter, and encapsulated the high pressure sense of unease that epitomises my first chapter. I decided to just dip into my deep mapping resource and randomly pluck out a media item, since this is what I will be doing when designing this component of the book.
I also often write draft things on my phone and the notes sync automatically to my Obsidian vault. I write myself little bits of text and send them to my own cloud. The other thing about Obsidian is there are huge numbers of third party plugins for it. But there is a sort of balance thing about plugins, because plugins introduce security vulnerabilities. It's the same with websites. I also find it very freeing because there's a lot of formatting features missing that actually I find to be a distraction when writing. I find it just keeps me focused.
Julien
So you, write down ideas and short paragraphs, and then you end up with a bunch of notes, which you can display in different ways in Obsidian. How do you go from a bunch of notes to a chapter?
James
Well I guess you're looking at them as a sequence, you know, you get smaller documents and you combine them to make larger documents. So that's a familiar workflow, but at the same time, you have to look at them on their own and refine them so that they are complete in themselves. And that's the same way that a paragraph has to be: complete in itself, but also part of a sequence.
Julien
So a lot of it, is looking at old writing problems in a new way?
James
Yes, you can look at your text at whatever scale you need to and keep working on it. And then you have the ability to see them in sequence. And then, once your finished, you can look at the whole thing as this continuous sequence and save and export it as such. And if you need to take it out of Obsidian, out of Markdown and see it in another way, you can easily do that as well. Most traditional writing tools or workflows emphasize the idea of linearity and one continuous piece of text. With the Markdown note method, you create notes that can be stitched together in different ways to become linear, longer blocks of text.
Julien
I wondered about the role of non-linearity and bricolages. Does writing in this way feel different or leads to different kinds of writing? Does working in a structure that consists of chunks change how you write?
James
I found, for example, that it's a great way to adapt the writing to different outputs such as a blog post, or an article. It also helps to modify pieces of text: to see how a paragraph could be expanded in a different direction to where you're going. So breaking the text up, helps me to see the relationships within it differently. I mean, with bricolage you never quite know what the sum total of the effect of something is going to be until you've assembled it in sufficient quantity. That's what I would describe as an emergent property, which is also what deep mapping is about. So there's this overlap with this writing method and the idea of deep mapping: It's hard to say what emergent property something is going to have until it gets sufficiently large. So there's always a surprise around the corner.
Simon
I went to a conference presentation just last week, actually, about the overuse of the metaphor of ecosystems. But I think it's appropriate here. I really like the metaphor of the garden that you raised earlier, James, and thinking of these, these different pieces or fragments as kinds of plants or beds that all come together to form a garden, growing in different ways and at different speeds, so that as a whole, it becomes something new, something beautiful.
James
I was just going to say that like a garden, the recipes or designs you can make from the ingredients will vary as things are maturing. There is a certain seasonal quality. I mean, you don't want to overextend the metaphor, but there is actually a sort of care thing: like slow, slow scholarship.
Simon
I love that.
Julien
I think that the garden metaphor is really persuasive, but almost as a counterpoint, the process also sounds quite technical. I'm sure like many of our listeners are into gardening, but they might be put off by all the technical terms. Isn't all of this just too difficult for your average Microsoft-bound academic writer?
James
I think it's... I mean, personally, I find it easier, but I can understand the issues with making that switch. When you've worked with a piece of software for a long time, you get used to it, you get used to its idiosyncrasies, they become part of how you write. I've always said the tools that you use affect how you do an action, in this case, writing. People for example are bound by this kind of idea of text as linear, which is encouraged by Microsoft Word, as we already discussed. Microsoft Word wants you to think of text as a scroll, as one long continuous piece of text. Moving away from that requires a kind of gestalt shift, I guess, in thinking about text, and in practicing writing. We've talked about non-linearity, bricolage and the fragmentary nature of text. I think the barrier is about making that gestalt shift, because on a technical level, I don't think it's harder to use than Microsoft. In many ways, it's easier.
Speaking with my editor hat on, I've had circumstances where a writer passes me a piece of text, and the footnotes that appear for them are entirely different to the footnotes that appear for me, because we depend on how different versions or software interprets the structure of the text. But with Markdown, there is a consistent, non-proprietary approach. The text will always be the same. It will always be structured the same. It might be rendered slightly differently based on what rendering engine you're using, but it will always be structured the same, because the structuring is so basic and fundamental. So in many ways, I find it easier, but I can see that it might be hard to shift.
Simon
I find it extremely calming somehow.
James
Exactly.
Simon
I like writing in Markdown because it doesn't have all the cruft of Microsoft asking me to add different fonts and different stylings and making this a header or whatever.
James
It's just, it's a lot plainer. So I can engage with the text more without getting distracted for 20 minutes choosing a font.
Julien
As a writer, I'm fully converted. As a publisher, we at Mattering Press have only dipped our toes into how to make books with Markdown. I like about this project that I get to learn alongside you, what a Markdown workflow for monographs can look like.
One concern that is often raised, is if experiments like this make it hard to preserve the book for future readers. Simon, could speak a bit about digital preservation and Markdown?
Simon
We have a digital preservation and archiving project at Open Book Futures. There is an entire team working on digital preservation. To my mind, using something like Markdown really enhances the preservation quality of your work, simply because there are more ways to render it and to save it. It's an open format, so anyone can write a piece of software to render it. We've talked about Obsidian, we've talked about Joplin, we've talked about a few of the many different programs that can do it. I use VSCodium a lot, which can render Markdown. If you have these different ways of rendering Markdown, it's a lot less likely to become unreadable in the future.
If Microsoft decides to stop supporting Microsoft Word, it's very quickly game over for .doc files. But Markdown is open, anyone can preserve it, anyone can render it in any way they want. That makes it a lot more flexible. James mentioned Pandoc. Pandoc is a piece of software for converting files into different formats, and it's incredibly easy to move Markdown into HTML, doc if you want, PDF, text. It just makes it easier because it's so open and because it's so simple. And if something is easier to do, it's generally easier to preserve for the future and easier to archive.
Julien
And as a writer, again, it's also great that you can manipulate the same files in different kinds of software for different purposes. I use a really, really basic editor to craft text, iA Writer. Then I organise the same note in Obsidian, where I also take quick notes. I use Scriviner to stitch notes from Obsidian into longer text documents. The point is, being able to manipulate Markdown file in different editors for different purposes allows for simple and flexible workflows.
Simon, how does not being locked into particular software packages fit within the idea of using minimal computing for digital books?
Simon
I think, like you say, there's something of a drive towards minimal computing, certainly in the humanities. We're looking for a way of creating books that is sustainable as well as experimental. Markdown's simplicity lends itself to that. It's quite low requirement in terms of hard disk space and RAM, which are the things that use up CPUs, which are big drivers for heavy computing. So, it's lower impact, and it's just more sustainable having a smaller digital footprint for each file. We're talking megabytes, kilobytes instead of gigabytes. And that's always going to help with driving down the overuse of computing power.
Julien
Our conversation also turns out as a bunch of connected notes, held loosely together. I like that, but I'd also like to get clearer on how you arrange notes into a longer piece of writing and how you then move it to a different stage. Let's say pre-publication, as part of this book, we are thinking of pre-publishing versions, which then might get feedback both from the kind of experimental publishing community and from the blue humanities community to build engagement with the text.
Simon
Can I ask you, as a publisher, how would you approach a text in this kind of fragmentary way? Do you have Markdown play any part in your existing publishing workflows?
Julien
Actually, it doesn't at the moment, which is why I'm really excited in this project, both as a writer and as a publisher. I'm hoping to document my own learning here with you, make it available to others, which is also why I hark back to the question, how do we make a book now from a collection of Markdown notes?
I understand that eventually we'll have a bucket of ordered Markdown files that will be rendered by Juncture. Do we have a plan? How do we go from a bunch of notes in Obsidian to something that we can share for review, commenting and publication?
James
Part of the answer to that is preparation. Once we have a set of these Markdown documents that are developed to a certain level, they are, if we're going back to digital gardens, fully mature plants. Then we can make them into something for Juncture that will display nicely. At the same time then there's no reason why they couldn't also be rendered for other purposes. They couldn't be just hosted and read on, for example, a GitHub release. There's lots of different ways to publish and share the text once you're at that point of maturity.
Julien
OK. But do we have a notion of how to prepare Markdown for commenting, for example?
Simon
I think it comes down to the kind of flexibility of Markdown. Like James says, you can host Markdown files anywhere. You could shove them in a GitHub repository to make them public. That is a form of publishing whereby they are available to whoever wants to read them. It won't be the fanciest way of reading. It's not quite traditional scholarly publication, but it puts them out there and you're able to annotate them and get people to comment on them. I believe it's also possible or it will be possible to annotate through Juncture in the future, the tool that we're using for the eventual publication of this work. So that's another option. But there's a whole host of kind of annotation software available that can take in Markdown because it's so flexible. I would do a little plug here and direct people to the experimental publishing compendium, which we have developed, and in particular, our section of tools that enable annotation. Most of those will take in Markdown.
Julien
Thank you.
As you hear, we are working this through as we go. In the next sessions, we will talk more about how we publish pre-publication releases from Markdown notes, possibly on PubPub or on Ghost via GitHub. And then as a follow up, we will think about pre-publication peer review and how that can be enabled by Markdown.
As a designer I take away, that it's incredibly exciting to have a bucket of Markdown files and media that can be dynamically rendered into different outputs. James, do you have any closing thoughts?
James
I'm trying to keep my mind open about what's possible because it is an experiment and part of the experiment is keeping some of the options that Markdown provides open, so that we can try things later on. I'm always listening to Julien and Simon, and our other collaborators. And that's part of the process for me, to learn. We are already learning things about what's possible. And by the time the book comes out, there'll be a whole different approach or imagination of what's possible, but it's incremental. So this has been the first step. I look forward to continuing to learn more with you all.
Simon
Sorry, I got distracted... I've got a takeaway coffee cup here. And it's got some wonderful kind of oceanographic design on it. It's just made me think how serendipitous this is and how the ocean, the blue humanities figures into all of our lives. In terms of kind of closing thoughts, I would encourage any author or writer who wants to experiment with Markdown to just give it a go. It's such an easy format to pick up, there's so few rules for how to do it. There's a great website I refer to fairly regularly, just called Markdown Cheat Sheet. You can learn it in an hour, if you just to start write in Markdown. Get a Markdown editor, get Obsidian, for example, and you'll figure out how to format and structure it as you go.
Julien
That's us for today. Thanks for listening. Until next time.
...
I think we have to listen back to it and see whether it makes sense to publish it as an audio file. What did you think?
James
We can definitely write up something nice from this.
Julien
I noticed I was drawn into two directions, to explore, you know, kind of intellectually and nerdy possibilities and to give more hands on instructions. If we start doing really instructional stuff, then there's obviously an enormous amount of work to talk to someone through the whole process step by step. I don't know if we should do that. What's your take?
Simon
We've struggled with that with experimental publishing more generally. We kind want to offer people ways into it, but also say, think about the possibilities. We're drawn between those two twin poles of the practical and the utopian. And I think we struck a balance in this conversation.
James
I wouldn't say we're negative towards one or to the other. There's also not necessarily any reason why anyone else would have to do exactly what I've done. I think the whole possibilities approach is like get Obsidian, try using Markdown. That's the hardest barrier. After that, the whole point is customization. You wouldn't want to be too prescriptive about what people can try with it.
Simon
I'd lean more towards the kind of dreams and radical possibilities rather than kind of technical instructions since you can get those anywhere.
Julien
You know what's rubbish about Markdown? I can't find a good Markdown formatting to typeset this conversation properly.
Resources ✨
Markdown editors we love
(open source or from small software companies)
VSCodium (Markdown editor primarily used for code but can handle all kinds of eccentric texts)
Springett, Selina. ‘Going Deeper or Flatter: Connecting Deep Mapping, Flat Ontologies and the Democratizing of Knowledge’. Humanities 4, no. 4 (16 October 2015): 623–36. https://doi.org/10.3390/h4040623
Dawkins, Oliver, Duncan Hay, and James Smith. ‘Tracing Hyperobjects: Digital Deep Mapping in the Anthropocene’. Digital Deep Mapping, 8 September 2021. https://doi.org/10.21428/c3ec81d9.83263f58.
Creative Commons Attribution 4.0 International License (CC-BY 4.0)
