Author: languageinlyrics

Fàilte! Welcome back to #TechTuesday, and to our Kitchen Table series. We’ve been rocketing around various corners of the web with the last few posts, exploring WordPress and wikis.

In case you missed those, they are worth checking out here and here. This week’s post will make more sense once you have that background.

Today, we’re tackling Content Management Systems.

(They’re not as intimidating as they sound, promise).

You may not have realized it, but actually, over the entire #TechTuesday series we were laying the groundwork for what we’re talking about today.

This is the week where everything is coming together. Ready? Let’s go.

Let’s look back for a moment

Think back to the two #TechTuesday posts where we were looking at all the various Gaelic resources that are available to us on the web. In the posts about Online Gaelic Resources, we examined a lot of online archives, both in Scotland and North America. Back then, we alluded to the fact that most of those sites are powered by systems other than WordPress or wikis.

They’re powered by Content Management Systems (CMS).

But wait, what is a CMS?

It’s time for us to define Content Management System. CMS is the shorthand for Content Management System. A CMS is a type of software that can be harnessed to create and organize any kind of digital material, whether that is used for an external website or used internally by an organization.

Without a Content Management System, a website would have to be coded from scratch. For example, the static HTML webpages we looked at during our survey of online Gaelic resources.

Content Management Systems are made up of two distinct parts: they have both a front-end (user interface) and a back-end (where all the information is stored).

Cast your mind waaaay back to the first three posts of the #TechTuesday series for a moment. Back in Post 1, Post 2, and Post 3, we were talking about online heritage projects and digital humanities. (I told you this is the week where everything’s coming together!). We talked about how many digital humanities projects fall into the category of archival or digitization projects – basically, organizing and making objects available online. We revisited this idea during our survey of Gaelic Resources, as we discussed above. In order to make digital objects available online, organize them, and make them easily searchable, you really need a Content Management System. For example, when you search for a record on, say, Tobar an Dualchais, your search terms send a query to the back-end database, which returns any hits to the front-end user interface that you see on the web.

This is kind of dry stuff, so let’s try a metaphor. Every time I say Content Management System, imagine a refrigerator.

A place to put all your stuff, something that preserves it, and somewhere that has a built-in organizational structure with its shelves. The first shelf is for yogurt and eggs, the second for the fresh meat, the crisper for fruit and vegetables, and the pockets in the door for your milk, orange juice, and leftover white wine. When someone calls from the living room that they’d like a tipple, you know exactly what to do and where to look to find what you need.

Ok, I’m being purposely silly, but this is essentially how content management systems work.

The fridge is the database…

which contains an organizational structure (the shelves)….

which in turn hold the information and data (the food labels)…

and the objects themselves (the food)…

to preserve them (by keeping it cold)…

and it can be queried (the person hollering from the living room)…

to retrieve (that’d be you)….

the data and their associated objects.

Voila!

In a nutshell, that is how Content Management Systems work. Now we’re ready for some real-world examples.

Some examples of CMS

Here’s a selection of the Content Management Systems that we investigated for the Language in Lyrics project, and what we learned!

WordPress

WordPress is one of the most popular Content Management Systems out there, and it powers about 30% of the web. We talked about its pros and cons a couple posts ago, so click here in case you missed it!

AtoM

AtoM is short for Access to Memory. It was developed by Artefactual Systems. It’s Canadian, and it’s also free and open source. To “organize its fridge,” as it were, it uses standards-based archival description for its data fields. It’s very respected in Canadian digital humanities circles. Around this neck of the woods, it has some very high-profile users, including the Dalhousie Archives and MemoryNS.

Islandora

Islandora is an open source CMS created by the University of Prince Edward Island. Being open source, in the right hands you could tailor it to fit the specific needs of your project. Also, it offers a supportive community, which includes an Islandora camp, Islandoracon and Use-a-thon (a Hack-a-thon).

CraftCMS

CraftCMS is a newer kid on the block. We got the tip from the Irish Traditional Music Archive, and we were suitably impressed. Unlike AtoM and Islandora, CraftCMS is not designed with data fields specifically for archival collections. Their fields are completely customizable – a rarity for Content Management Systems in the heritage field. Many different users take advantage of Craft because of its flexibility. The user interface, the dashboard, is also very simple. It’s won “Best WordPress Alternative,” among other awards. There is a free version, and a paid plan. But it could be worth it for your project. Really, this is one to watch.

Collective Access

A few years ago, the Association of Nova Scotia Museums decided to change up their software. After much deliberation, they chose Collective Access. And it’s easy to see why. It was developed by New York company Whirl-i-Gig, and they were looking to create something specifically for libraries, museums, archives, and special historical and artistic collections. CollectiveAccess is a paid service. When setting it up, it allows you to choose from preset library/archive description standards, or your own custom fields. Sounds kind of like a cross between archives-specific Islandora and AtoM and the flexibility of Craft! More than 50 individual museums use Collective Access, as well as the online database NovaMuse.

But why are we talking about this?

With the fridges and the shelving and all the rest, this has probably been our most technical and most metaphorical #TechTuesday yet. But we thought a whole post of Content Management Systems was worth going into because CMSs and how exactly they work are something that can be hard to keep straight in one’s mind. Our emails sent back and forth between Language in Lyrics team members can attest to that!

But also, as we’ve been researching the best options for our Gaelic song database, a lot of our best leads about which Content Management System might be right for us came directly from word-of-mouth.

We wanted to collect some of the tips we’ve gained from the process, and gather the information in one place, so you could have the information for your future projects, and we could all share around the Kitchen Table.

(And now, we’ve added a fridge to our kitchen, too!)

Til next time,

Le beannachd,

Aleen

Fàilte! Welcome back to #TechTuesday.

Last time, we were talking all about WordPress, and the advantages and disadvantages of using WordPress.com and WordPress.org to create your own website. This time, we’re moving on to talk about another way to make your own website: wikis. While they are similar to other platforms we’ve mentioned, wikis are also very different in ethos and design from anything we’ve talked about before. They are their own digital breed.

Chances are, most of you have consulted a Wikipedia page in the past day or two. To check if that certain song did in fact go to number one in seven countries, or to see about the historical accuracy of the portrayal of Bonnie Prince Charlie on Outlander, or to help remember the definition of Digital Humanities (true story).

Wikipedia is an endless font of information. It is also the most famous wiki in the world.

But Wikipedia is just one of many wikis out there in the internet world. A wiki is something altogether different than Wikipedia. Wikipedia is merely a website that uses an underlying wiki software – in this case, MediaWiki – as a foundation to build their site.

What is a wiki?

So what exactly is wiki software? (Also sometimes called a wiki engine). There are self-hosted software options like MediaWiki, TikiWiki, and DokuWiki, or more full-service web-based options like Wikidot, Tettra (a spin-off of Slack), Wikia, and PBWorks.

And what do they do? Well, the actual dictionary definition of the word “wiki” gives us a clue. It’s an abbreviated form of the Hawaiian word wikiwiki, which means “quick.” And if any website could be described as quick, it’s a wiki. They are definitely fleet-footed. A wiki is a website built page-by-page by multiple editors and authors. It’s collaborative, cooperate, and ever-changing. Think about Wikipedia – it’s constantly being edited, altered, and added to every single day. (For more on the definition, I thought it would be fitting to direct you to Wikipedia’s entry for wikis here).

The basic idea for wikis is that any visitors can edit the site’s content directly through their web browser. That’s why they are so popular with crowd-sourced encyclopedias like Wikipedia or pop culture fandom sites in Wikia. It’s the freedom and the accessibility of it. But wikis can also be private, used internally by companies for internal knowledge sharing between employees (say, in a large research university or a Silicon Valley tech company).

Interestingly enough for a collaborative software, we can trace the invention of the wiki to a single person. Ward Cunningham created what is now named WikiWikiWeb in 1995. In case you’re interested in falling down a rabbit hole of wiki history, he has a page detailing the full year-by-year development of the wiki approach on his site. Overall, Cunningham’s vision for a wiki is, in his words, “The simplest online database that could possibly work.”

Sounds good, doesn’t it?

This collaborative, unstructured approach to a website may seem like a world away from what we talked about last week with WordPress. But in reality, both WordPress and wikis are content management systems, albeit different types. And at heart, both are based on the ethos of the open web.

But unlike WordPress, a wiki is not necessarily built to be a blogging platform. They’re not built to be anything in particular, actually. Wikis have very little internal structure. But that’s part of the appeal. You can build a wiki as you go. It’s not built in stone – think of it as built with lego blocks and held together with stretchy elastic.

Examples of wikis

But you may be wondering, what does this look like in practice?

Let’s start with the obvious examples. You’ve probably heard of WikiLeaks, Wiktionary, Wikiquotes, or WikiHow. They are all based on wikis. There are also plenty of other, lesser known wikis. But for now, let’s start with one of the more famous ones, one you’ve probably used yourself at some point or another.

WikiHow

Let’s take WikiHow for example.

WikiHow was founded in 2005, and now, fifteen years later, the site continues its mandate of accessible public education on an amazing plethora of topics in bite-sized how-to articles. Its mission is “to empower every person on the planet to learn how to do anything.” Like Wikipedia, WikiHow uses MediaWiki as its backend structure. In fact, WikiHow was inspired by Wikipedia’s mandate and its use of MediaWiki. Also like Wikipedia, WikiHow’s articles aren’t written by a single person – they’re written, edited and revised by multiple members of the site. The sharing of information, the connections through hyperlinks, and the advanced search function are all quintessential elements of any wiki.

But WikiHow’s content is a lot different than what we’d be doing with Language in Lyrics.

Scottish Gaelic Grammar Wiki

Another example that’s a little closer to our own mandate is the Scottish Gaelic Grammar Wiki.

It was built by the Arizona Scottish Gaelic Syntax Project and the Arizona Gaelic Phonology and Phonetics Project, both funded by the National Science Foundation. At first glance, it looks a lot like Wikipedia. Visually, it has the same rectangular box building blocks, the hyperlinks on the side, and the logo in the top corner. These are classic features we’ve come to associate with wikis. The website has subcategories for semantics, syntax, morphology, phonology, and phonetics, and all the pages are related to each of those subcategories. Every topic has its own article, like on Wikipedia. But it does differ from Wikipedia, WikiHow, and others like them when it comes to its approach. Unlike other wikis, the articles are written by the Scottish Gaelic Grammar Wiki team. While readers can send in comments, they can’t directly edit the pages. Similarly, the copyright to the website’s content is retained by The Scottish Gaelic Grammar Wiki. There’s more central control than in other wikis. But, thinking about the very niche technical knowledge that this wiki contains, and the fact that it is principally authored by the wiki’s staff, this makes complete sense.

Traditional Tunes Archive

One last example, also similar to the mandate of Language in Lyrics, is the Traditional Tunes Archive. The Traditional Tunes Archives uses the ABC and Semantic Web to organize traditional music from Scotland, England, Ireland, United States, and Canada.

Formerly the Fiddler’s Companion, the site takes a slightly different approach to a song database. Their mandate, specified on the homepage, is “the gathering of as much information as possible about folk pieces to attempt to trace tune families, determine origins, influences and patterns of aural/oral transmittal, and to study individual and regional styles of performance.” The Archive focuses on the historical evolution and development of each tune in the database, and how songs are interconnected to one another. In their own words:

“Many musicians, like ourselves, are simply curious about titles, origins, sources and anecdotes regarding the music they play. Who, for example, can resist the urge to know where the title Blowzabella came from or what it means, or speculating on the motivations for naming a perfectly respectable tune Bloody Oul’ Hag, is it Tay Ye Want?

Knowing the history of the melody we play, or at least to have a sense of its historical and social context, makes the tune ‘present’ in the here and now. . .”

Traditional Tunes Archive

Making songs “present in the here and now” could also be described as one of the main goals of Language in Lyrics, actually!

---

What can we learn from wikis?

When we were doing our research for our own song database at Language in Lyrics, the approach of wikis really appealed to us. They’re stretchy. They’re fun. They’re not authoritative. They fit lots of different uses. They’re often free and open source. They’re not hemmed in by certain categorical constraints or metadata standards. And most importantly, with wikis, it’s not about the experts at all – it’s about the community.

That’s the emphasis we wanted for Language in Lyrics. Yes, the database will mostly be compiled and authored by us, but we want it ultimately to be a living document used by the Gaelic community. Otherwise, what’s the point of the project? Our very best-case scenario is if the database we create becomes a go-to tool for the community. Something to be heavily used, interacted with, and made relevant by people on the ground, working to revitalize Gaelic language through song. For this reason, wikis were an option we seriously considered.

Of course, absolutely perfect options don’t exist. The catch with wikis is, if you want a wiki with no imposed limits (storage, editor permissions, number of pages, etc.), you need to go with a self-hosted wiki. MediaWiki and its self-hosted cousins require quite a bit of coding knowledge. To give you a sense of how much, let’s look at what underlies the Traditional Tunes Wiki on its Version page. Luckily, wikis are often very transparent about what went into building them:

And this goes on for pages and pages. And very few lines of that contain words that most of us can understand. Uh oh! When we began to realize this, we started feeling a little over our heads.

With wikis, we couldn’t really find a good happy medium: we could either sign up with a wiki software like Tettra, and have extreme limitations on content and functionality (which we really needed for our project), or we could downloaded one like MediaWiki, and would be completely on our own.

But we decided to talk about them in our #TechTuesday posts because, even though ultimately we decided we’d go another route, wikis remain very attractive option for many people (including us!). Also, they are a little misunderstood. Most people have probably heard of WordPress, but they might not have realized that Wikipedia wasn’t the only “wiki” that people were talking about.

We hope this dive down into the specifics of wikis was helpful, and perhaps even enabled you to see a favourite site in a different way. That’s what we’re aiming for with #TechTuesday!

Til next time,

Le beannachd,

Aleen

Do bheatha gu #TechTuesday! Last time, we finished our survey of online Gaelic resources. But there was one particular one we purposely left out.

If we had used our own website for Language in Lyrics as an example in the previous posts, we would’ve had to have mentioned a certain system that powers roughly 34% of the internet, as well as our little site.

You may have heard of it: WordPress.

WordPress is one of the world’s most popular blogging platforms. It is also, as I mentioned, the structure behind about a third of the websites on the entire internet. According to Forbes, it is “the most popular CMS [Content Management System] in the world.” WordPress powers sites like BBC America, The New Yorker, Time Inc., Facebook Newsroom, Disney, Sony Music, The New York Times, Mozilla’s blog, and even Beyoncé’s official website. There are countless others.

WordPress.com vs WordPress.org

While many people have heard of WordPress, what many people don’t know is that there are actually two different categories of WordPress. (Oh, how we wished we realized this when we were starting out!)

WordPress.com is a web-based blogging platform.

WordPress.org is a self-hosted open source blogging platform and content management system (CMS).

WordPress themselves are, unsurprisingly, the best people to explain the difference. They do this very well here and here. There is also some great information from WebsiteSetup.org about the differences here. Here’s a summary we’ve created to help explain the differences between WordPress.com versus WordPress.org (and keep it straight in our own minds).

Let’s use the Language in Lyrics site as an example to explain the differences between WordPress.com versus WordPress.org. Early on, we began the site on WordPress.com, not realizing there was a choice. But our missteps are our collective learning opportunities! Here’s what we didn’t know when we started.

We had two needs when we first started Language in Lyrics. First, we needed to create a place online to collect information and connect with the public about the project. Second, we needed a home for the song database.

At first, we thought maybe we could do both on our WordPress site. But then we ran into some kinks. There was no problem at all with making simple information pages for our staff and events or writing blogposts. For a site like Language in Lyrics, which is hosted on WordPress.com, administrators have full freedom to create posts and pages. Those posts and pages, however, can only be comprised of the options that are available in the WordPress Block editor (photos, paragraph formatting, embedded videos, etc.).

It sometimes feels like working with the Block editor amounts to colouring within the lines of a box. You can’t control the overall look nor anything more complicated than adding photos or embedded internet content. You can’t really create the function and feel of the site just as you want it. You can’t build your own page. That’s great if you don’t have any coding knowledge and have no need of it. But it can be limiting.

Our Mac-Talla Adventure

We quickly learned this when we were building the sneak peek of the Mac-Talla database. At first, we did some research and thought we could add a new custom database to the backend database of our site. Then we had our “wait a minute” moment. Duh, we didn’t have a downloaded database, because we were on WordPress.com, not the self-hosted WordPress.org.

Then we thought we could do a table instead. Reality soon came calling again. Inserting a table required an HTML <frame>, which we couldn’t do without a plug-in. Which we couldn’t download, because of our plan on WordPress.com. Back to the drawing board.

Okay, not giving up yet. Then we tried coding the table with the HTML Editor view, staying within the boundaries of the “add new page” function. Which worked great! A little fiddly, but we can deal with that. That is, until we saved it and worked on another post with the Visual Editor. When we clicked back to the HTML Editor of the Mac-Talla post, all the custom code had been overwritten! Ouch, lesson learned.

Maybe it was a glitch? So again, we coded 100 entries of the table line by line. We tried much more carefully this time to stay only within the HTML Editor view while working on all the other posts. Open the Mac-Talla draft page, and all the custom HTML is overwritten AGAIN. While the basic entries remained, all the formatting had been erased. Double ouch, lesson really learned that time.

Lessons Learned

This sad tale shows the differences between WordPress.com and WordPress.org clearly, and also demonstrates what hitting the limitations of one feels like. We hit the limit of the capabilities of trying to fit a database project within WordPress.com. But there are many other tech ceilings you can hit when working with WordPress.com. If a site were hosted on WordPress.org, administrators would have options for custom databases, plugins, SEO optimization, more themes to choose from – all of which either don’t exist or exist in much-diminished form on WordPress.com.

A simple way to explain the differences: the features and functionality you get by default on WordPress.org are only available as premium plans on WordPress.com – but in return, you’re handed the reins of the whole thing with WordPress.org. You have to organize your own domain, your own hosting, your own maintenance. Some people don’t want the reins, for good reason.

Ultimately, it’s a trade-off. To paraphrase everyone from the Apostle Luke to Spider-Man: with more freedom comes more responsibility. You have to know very clearly what the aim of your project is, and how that might grow over time.

If you just need to blog, and you need a simple, low-stress option, plus you have minimal interest or knowledge of IT, WordPress.com is a great solution. If you need to build a fully functioning website that’s more than a blog, plus you’re good with technology and/or eager to learn, WordPress.org may be your ticket.

One final note. If you realize mid-way through your WordPress experience that your needs are different than you thought they’d be, like we did, it’s not the end of the world. It is possible to migrate from one to the other if, for example, you start on WordPress.com but realize you need the capabilities of WordPress.org. Basically, it involves:

(1) getting a domain name and setting up website hosting,
(2) exporting and downloading your data (blogposts, pages) from your existing site,
(3) downloading the WordPress.org software, and
(4) importing the downloaded data using WordPress.org’s Importer tool.

If you’re interested in the above, you can read detailed instructions here.

Hopefully you’ll enter the WordPress world better informed than us, and learn from our mistakes!

The possibilities WordPress presents are boundless. This blogpost is meant as just a short introduction to the software that powers so much of the internet behind the scenes.

Le beannachd,

Aleen

---

Glossary of Selected Terms

Domain – If you’re using WordPress.org, you need a domain name. A domain name is a website’s address or identifier, e.g. example.com. A domain name is necessary on WordPress.org. On WordPress.com, it’s an optional paid-for extra, for example, languageinlyrics.com instead of languageinlyrics.wordpress.com.

Hosting – In addition to a domain name, WordPress.org requires a hosting platform. Together, the domain name and the hosting platform form the site’s home. If the domain name is the site’s home address, the hosting is the brick and mortar house. For a monthly or yearly fee, companies rent space on their servers to others who have a website that needs a home. With hosting, the website is accessible on the internet.

Plugin – A plugin is a package that is available on both WordPress.com (their paid plans) and WordPress.org. Plugins are little bits of extra programming, extra code, that allows extra functionality or more features on WordPress. For example, one of the most popular plugins is Yoast SEO, with more than five million downloads (see explanation of SEOs below). Plugins can be developed by companies, private citizens, or even WordPress themselves (e.g. the Classic Editor plugin). The WordPress Plugin Directory [https://wordpress.org/plugins/] has almost 55,000 plugins to choose from.

SEO – SEO stands for Search Engine Optimization. Search Engine Optimization allows sites to improve their performance on search engines like Google. It’s not a trick, it simply helps sites be able to be “read” more easily by search engines. If they are read more easily, then they show up when people search for relevant terms. Basically, Search Engine Optimization helps people find your website and can help fuel more traffic to your site. On WordPress.com, essentially SEO comes automatically with JetPack, a bundled basic toolkit.

Theme – Themes control what the WordPress site looks like – its style and design. Just as with plugins, WordPress has a directory of themes on its site [https://wordpress.org/themes/browse/featured/]. Some themes are available on WordPress.com (paid plans unlock more themes to choose from), but even more are available when using WordPress.org.

WordPress.com – WordPress.com is a web-based blogging platform.

WordPress.org – WordPress.org is a self-hosted open source blogging platform and content management system (CMS).

By Aleen Leigh Stanton

Bliadhna mhath ùr dhuibh! Happy New Year to you all! We’re back for another #TechTuesday. This is the second half of our detailed look into online Gaelic resources. Just like last time, we’ll investigate how the sites are built, and how each project compares to the needs of Language in Lyrics.

Last week we left off by talking about Gaelic resources in Nova Scotia. Now we are going to shift gears and jump across the pond to explore the resources that are available and based in Scotland (well, there’s one bonus from Ireland, but hopefully that’s ok).

If you have any more suggestions or questions about what we’ve covered so far, feel free to share them with us, and we’ll be sure to feature them in future posts and/or answer them as best we can.

Tobar an Dualchais: Kist-o-riches

What is it? >>>
Tobar an Dualchais: Kist-o-riches is one of the best known online Gaelic resources. The collection focuses on audio recordings spanning songs, stories, and oral history. The sheer number available online is astounding: almost 50,000. The site also has a very detailed search function to help you sift through all those recordings.

What’s behind it? >>>
The Tobar an Dualchais website is built, like most modern websites, on a backend database that is invisible to the visitor, but allows complex search queries, a highly visual interface, and other functions. The site runs on a bespoke database built especially for their purposes. The site was redesigned and modernized in 2018 by EDINA, a “centre for digital expertise and online service delivery” out of the University of Edinburgh.

Lessons for Language in Lyrics >>>
Like we discussed last time, having an outside firm design and build a website for a project comes with pros and cons. If you have access to a firm that is somehow connected to your project (through a different department, an affiliated university, etc.), then this could be a very sensible option. But if it would require hiring a completely unconnected outside firm on contract (which is often the case), then careful planning has to be done to ensure that the site can continue to be updated, patched, and secured long into the future. There are so many things to think about when building a website that aren’t immediately obvious, but which can greatly affect the budget and the future of the project.

Digital Archives of Scottish Gaelic, University of Glasgow and Sabhal Mòr Ostaig

What is it? >>>
Like Tobar an Dualchais, the Digital Archive of Scottish Gaelic (DASG) is a pillar of the online Gaelic community. The Archive is a joint effort between the University of Glasgow and Sabhal Mòr Ostaig on the Isle of Skye. DASG is organized into three main categories, or online exhibits, all on the top of the main homepage: Corpus na Gàidhlig (corpus), Faclan bhon t-Sluagh (fieldwork), and Cluas ri Claisneachd (audio archive). Corpus na Gàidhlig is a searchable database of Gaelic texts. Faclan bhon t-Sluagh, their fieldwork database, is a collection of documents and recordings which capture vernacular Gaelic vocabulary. Cluas ri Claisneachd, for its part, brings together five audio collections: the Historical Dictionary of Scottish Gaelic (HDSG), Mòthan, Guthan nan Eilean, Calum MacNìll, and Am Bàrd Bochd.

What’s behind it? >>>
DASG, like Tobar an Dualchais, is a bespoke website based on a backend database. In this case, we actually know a little bit about what is going on behind the frontend curtain. All of the information for the audio recordings on the Cluas ri Claisneachd, for example, is entered into phpMyAdmin, a free software. PhpMyAdmin, in turn, tells the database (e.g. MySQL or MariaDB) what to do.

Lessons for Language in Lyrics >>>
Databases, like MySQL, MariaDB, and others, power many digital humanities projects that need to organize a large amount of information. Language in Lyrics needs that power – we will likely have thousands of song records by the time we are finished the project. Some database software is commercial (e.g. FileMakerPro, Microsoft Access), while occasionally (e.g. mySQL, MariaDB) they are free and open access. However, you still would need someone on your team who knows how to use the SQL coding language if you decide to go for the more DIY option with a database.

The Pearl Project, University of Edinburgh

What is it? >>>
Established in 1996, The Pearl Project is an initiative from the School of Scottish Studies at the University of Edinburgh. What may be of particular interest for you, if you’re already interested in Language in Lyrics is their audio archive, called Tocher (Gaelic for “dowry”). Tocher was first established in 1971. There, they have digitized transcriptions of text, music, and stories held in the School of Scottish Studies at the University of Edinburgh.

What’s behind it? >>>
Like the MacEdward Leach Collection we looked at last time, The Pearl Project website is a series of static HTML webpages. We get a hint on the homepage, where it instructs us that the website requires a “frames-capable browser” – frames are a common way to embed content when coding HTML webpages. Another clue is the lack of a search function: the site is based on browsing hyperlinks and clicking around to explore. This is very different than our first two examples, which are structured mainly around a powerful search function on the homepage.

Lessons for Language in Lyrics >>>
We talked a little bit about static sites versus database-based sites last time, but here’s a great definition that is clear and in plain language:

“Most of today’s websites use server side programming languages that generate the website on the fly by querying the database. This means that every time someone visits a web page, it is generated on demand. On the other hand, a static website is generated once and exists as a simple set of documents on the server’s hard disk. It’s always there, not just when someone visits the page.”
–“How to Build A Low Tech Website,” Low Tech Magazine

Hopefully that definition makes everything clearer – I know it took me a long time to figure it out. The important take-away for Language in Lyrics that, although static HTML websites are easier on beginner coders and easier on the environment (as we saw last time), they don’t really work for our purposes. Our number one priority at Language in Lyrics is creating a searchable database and a user-friendly interface, which is just too complicated for static HTML pages.

Am Baile, High Life Highlands

What is it? >>>
High Life Highlands produced Am Baile. The site focuses more on historic material relating to the Highlands, rather than sources about the Gaelic language directly. That being said, it paints a cultural picture that complements the rest of the sites on the list. Their collection of historical photographs and their newspaper index are particularly impressive. The site also has a full Gaelic-language version.

What is behind it? >>>
Am Baile’s website is powered by Capture. Capture builds “digital asset management systems” for its clients. Basically, the company creates bespoke websites. Many of their clients are museums, galleries, and heritage institutions. For Am Baile and others, that also includes websites which can handle organizing a large amount of digital objects (photos, historical documents, recordings, etc.).

Lessons for Language in Lyrics >>>
This raises the same question we’ve been dealing with again and again – the pros and cons of bespoke websites. They are tailor-made, which can solve a lot of the problems that a complicated project like Language in Lyrics brings up. But, if you don’t have in-house expertise, you have to hire someone else to build it. This can be nice at first, but problems arise when it comes to site upkeep, as we’ve discussed already.

Ceòl nan Gàidheal

What is it? >>>
Ceòl nan Gàidheal is a digital resource from the National Library of Scotland. You can find it under the Digital Gallery page. The website draws from the Library’s own holdings to, as they describe on the homepage, “provide an initial insight into Gaelic music, its history, instruments and song, transmission methods and how the tradition is very much alive today.” The website has plenty of historical contextual information, as well as digitized music books, early examples of written Gaelic, and recordings from the Library’s collection. The textual sources are free to download for personal use – you can even download the entire book in some cases.

What is behind it? >>>
As a Digital Gallery within the institution, Ceòl nan Gàidheal was created by the National Library of Scotland. But, as with many institutions, it is not clear how the site is actually built. That being said, it’s safe to assume that an institution as significant at the National Library has the resources to hire web designers and IT professionals to create a site that meets all of their specific needs.

Lessons for Language in Lyrics >>>
Again, there is the lesson here of institutional partnerships and how important they are. Institutions often have the resources needed to build and run a complex website. Sometimes building from scratch is necessary, but it can be worth seeking out institutional partnerships if at all possible. With institutional support, a website won’t become a one-off, languishing after the initial push. It will continue to have a life, with continued traffic, security, and updates.

Irish Traditional Music Archive

What is it? >>>
Even though this last one isn’t technically Scottish, it was well-worth a mention. The Irish Traditional Music Archive features music from other related regions, including Scottish Gaelic songs from Scotland and Nova Scotia. Their website is very stream-lined and their search function is clear and easy to use.

What is behind it? >>>
The Irish Traditional Music Archive is very unusual, in that the archive staff explain in detail how the site and database were built on its Digitisation page. ITMA has two sections that make up its online presence: it has an online library catalogue for its physical holdings, and a selection that are digitized and available in the Digital Library section. The library uses SoutronLMS as its OPAC system. On the other hand, the Digital Library runs on Craft Content Management System, which itself grew out of Expression Engine (remember content management systems from the last blogpost? We’ll talk more about them in a later blogpost).

Lessons for Language in Lyrics >>>
The lesson here is one that we’ve touched on before, but there’s a twist. We’ve already discussed the lesson that an archive, by definition, has a different structure than something like the Language in Lyrics project. But, here’s the twist this time: CraftCMS is known for its flexibility. You don’t have to have objects in your database. It doesn’t have to be an archive. Craft is open source, but also has an option for paid support and help with updates. And the best part? You can create your own custom fields. This is absolutely essential for us at Language in Lyrics. This kind of content management system is certainly an avenue for us to explore.

---

So, with our survey complete, what are the overarching lessons for us?

Going over the Gaelic resources already available online gives us a good indication of the options available to us. Beyond the specific software we talked about, we can boil down these options to just a few main categories:

First,
There is the (1) content management system option;
there is the (2) static page option;
there is the (3) full database option.

Then,
There is the (1) contractor option;
there is the (2) institutional partner option;
there is the (3) DIY option.

Then, there is the fact that any of these can be used in combination. It’s enough to make your head hurt!

Looking back over the last two blogposts, and actually, the last few months working on Language in Lyrics, there is one lesson that is the biggest of them all. And it was the one I learned the quickest: it can be pretty difficult to figure out how sites we know and love are built. The curtain is thick sometimes – it’s not the kind of information that organizations usually place on their “About Us” page.

But that’s fair enough. Most people probably aren’t there to find out if they’ve used x database or y content management system. If you’re lucky, you might know someone who knows someone who works there who can draw back the curtain a bit. But otherwise, it can be guesswork. Maybe this will change in the coming years as more and more people become tech-literate and get curious about how the projects they care about were put together. For now, the curtain remains drawn. But the ensuing detective work is quite fun.

At Language in Lyrics, we’re hoping that, in sharing our own development process with you (warts and all), we might save others some time and tears if you find yourself involved in similar types of projects. If we share processes, talk with each other, and compare notes, all of our individual projects will only be the better for it.

I hope this jaunt through the Gaelic web has been helpful and useful to you!

Til next time,

Le beannachd,

Aleen

By Aleen Leigh Stanton

Welcome back to #TechTuesday and to our digital kitchen table. This week, we’re going to be exploring the online Gaelic world in a bit more detail.

We’ve talked a lot about context, about Digital Humanities, about philosophy. Now, we finally get to focus in on the intersection between technology and Gaelic specifically. As you probably know, Scottish Gaelic has a pretty extensive presence online. For now, we’re focusing on Nova Scotian resources. Next week, we’ll focus on their counterparts in Scotland.

But, why are we doing this survey? Aren’t there already lots of lists of Gaelic resources out there for speakers and learners? (See, for example, this comprehensive list from Dr. Emily McEwan, which is itself based partly on Gaelic Affairs and Highland Village Museum lists here and here).

Well, this list below is a bit different than the ones above. Basically, it’s an expanded excerpt of a document the team has been busy compiling, comparing, and contrasting behind the scenes as background research for the Language in Lyrics project. Part of preparing our own online database involved exploring what other resources are out there.

Think of it as a big Venn diagram. We did this survey to make sure our mandate didn’t overlap with any other project, but also, more importantly, to figure out what there was in common, and whether we could take away any lessons from how other people had built their databases and websites. As well, for any interested readers out there, this list may help you peek behind the curtain of some of the websites you visit often, and perhaps find inspiration there for your own projects.

This post will break down a selection of existing online Gaelic resources, and where known, explain what’s going on behind the scenes tech-wise. I’ve been inspired by Miriam Posner’s blogpost “How Did They Make That?“, and this post will follow a similar format.

Without further ado, here are some classic examples of digital Gaelic resources from Nova Scotia, and an explanation of the tech behind them.

---

An Drochaid Eadarainn / The Bridge Between Us, Highland Village

What is it? >>>
The Highland Village launched An Drochaid Eadarainn (The Bridge Between Us) in May 2012, coinciding with Gaelic Awareness Month. Its approach is innovative – it’s not like the digital humanities projects we talked about last week, which are more straightforward examples of digitization or online archives. It’s more of a portal than a website. It is designed to reflect how Gaelic language and culture is transmitted from generation to generation, and to create that social space and social transmission in the virtual realm. As many of you may know, the title of the site is a nod to the role of bridges as gathering places in traditional Gaelic culture. As the virtual equivalent, the site has a large interactive element. A section of the site, An Drochaid Bheò (The Living Bridge), allows users to upload their own content. The website is primarily Gaelic-language based. While there are English translations for many pages, not all are bilingual. It serves as a valuable resource and gathering place for intermediate and advanced Gaelic speakers.

What is behind it? >>>
An Drochaid Eadarainn is built with Drupal. Drupal is a back-end framework for building websites (WordPress would be an example of an alternate system that does the same job – we’re going to do a whole blogpost on WordPress soon). Basically, Drupal organizes and manages content and controls functionality on websites. Drupal is written in PHP, and it’s free and open source.

Lessons for Language in Lyrics >>>
Having a site specifically designed from scratch for Language in Lyrics was certainly an option to consider. But, usually, an outside contractor is required. So even if the code is open source, the labour is certainly not free. And when it comes to upkeep and maintenance, that’s where things get tricky. If your organization doesn’t have the Drupal expertise in-house, for example, then ongoing site upkeep over the years can prove unwieldy, expensive, and difficult. These are all factors to consider.

MemoryNS, Council of Nova Scotia Archives

What is it? >>>
MemoryNS is a hub site for archival collections across the province. It hosts an array of Gaelic archival material from the Nova Scotia Archives, the Beaton Institute, the Celtic Music Interpretive Centre, and many others. You can search the site for holdings, read descriptions, look at finding aids, and in some cases, view images. While obviously its records are not exclusively about Gaelic, MemoryNS could be used a gateway to find other things. For example, the Nova Scotia Archives has uploaded information on the MacLean and Sinclair family papers to MemoryNS, which might then lead you to their virtual exhibit called Goireasan Gàidhlig (Gaelic Resources), which uses the MacLean and Sinclair family papers as its flagship collection. You can find the exhibit on their website under the Virtual tab, the home of all their digitized archival content. They have a lovely introduction providing historical context, and in the right sidebar visitors can navigate to the different subcategories of Gaelic archival material. They’ve got photos, letters, poetry, petitions, government reports, newspapers, historical scholarly articles, sheet music, and more. That’s the great thing about MemoryNS – it can act as a gateway to help you explore other archival collections you otherwise might not have come across.

What is behind it? >>>
MemoryNS is powered by AccesstoMemory (AtoM for short, pronounced like the thing that’s made up of protons, neutrons, and electrons). AtoM is a content management system (we’ll talk more about content management systems in a later blogpost) made especially for description and dissemination of archival collections. AtoM was designed by a Canadian company and has quickly become very popular with Canadian archives. MemoryNS, for example, has 58 institutional members in Nova Scotia.

Lessons for Language in Lyrics >>>
AtoM was an option Language in Lyrics seriously considered in the beginning. However, as we discussed at the very beginning of this series in the first blogpost, our database doesn’t have objects. It is designed to organize song information, not historical documents or artifacts. It differs greatly from archival collections in that way. Also, the description categories for the songs in the Language in Lyrics database are very different than how archival objects are described. For us, we need fields like song title, air, first line (chorus), first line (verse), song subject, song structure, place of origin, composer name, composer patronymic, and more. For archives, they need to conform to archival description standards, which include fields like creator, date, physical description, format, language, and more. The categories are right there in the code, and can be very difficult to change (again, probably require outside hired help). One of the strong selling points of AtoM for heritage institutions is that it conforms to archival description standards (e.g. Dublin Core), but that is a stumbling block more than a selling point for Language in Lyrics.

Sruth nan Gàidheal / Gaelstream, St. Francis Xavier University

What is it? >>>
Gaelstream is the digitized collection of audio recordings from the Cape Breton Folklore Collections. Gaelstream is beloved by the Gaelic community in Nova Scotia. After St. FX’s site went down last year, the outpouring from the community was so strong that Gaelstream was quickly recovered and reinstated. The reupload is a temporary interface until a more permanent solution can be found, but all the content is there along with a search function.

What is behind it? >>>
Gaelstream is powered by Islandora. Think of Islandora as a cousin to AtoM. Like AtoM, Islandora is a Canadian, open source content management system. Like AtoM, it is also meant to be used to organize digital assests for archival collections. Islandora was originally built by UPEI’s Robertson Library using Drupal, Fedora, and Solr.

Lessons for Language in Lyrics >>>
Islandora is very similar to AtoM, and so the same problems persist. Archival description standards for our custom description fields, and content management for our database with no objects (e.g. the audio recordings tied to each record in Gaelstream).

MacEdward Leach Collection, Memorial University

What is it? >>>
In 2004, the Department of Folklore created the MacEdward Leach Collection’s online home. While the site is centered around the MacEdward Leach Collection, the contextual information spans much more. There are separate categories for communities, songs, and singers in Newfoundland and Nova Scotia. The site is built to be explored; for visitors to look at each page, follow links, and read all the information. And there are reams and reams of information when you start clicking around.

What is behind it? >>>
The MacEdward Leach Collection’s website was created before any of our other examples in this post. If you click around the site, you can tell it is built very differently than the others. Because it was built in the early 2000s, the website is based on a series of static HTML pages that exist on their own, rather than a content management system that constantly pulls information from a back-end database to create dynamic webpages (they don’t exist if you don’t click on them). The MacEdward Leach Collection was built with Dreamweaver (formerly Macromedia, now Adobe), an HTML editor. MUN is currently working on a project that will update and bundle the MacEdward Leach collection with a larger initiative – stay tuned.

Lessons for Language in Lyrics >>>
This one is an interesting case. There has been a recent resurgence of interest in static HTML websites recently, driven by the thought that they are greener than modern alternatives. Most modern websites are based on more resource-hungry content management systems hosted on server farms. (For an example of a “green” modern HTML site, see Low Tech Magazine‘s self-hosted, solar-powered website. They explain how it works on their About page). A static HTML website probably wouldn’t work for Language in Lyrics, because we need a very fulsome database and, most importantly, a powerful, advanced search function. But it’s fun to think of the old-fashioned HTML webpages coming back into fashion, and also having a smaller carbon footprint.

---

That’s all for this week. Next week, we’ll be looking at Gaelic resources across the pond, and exploring their approach to building their online content.

Le beannachd,

Aleen

By Aleen Leigh Stanton

And just like that, it’s #TechTuesday again. If you’re new here, welcome; if you’re visiting again, welcome back. This is the third post in the Kitchen Table series, and the second half of our discussion about Digital Humanities.

Last week we introduced the field of digital humanities, and talked about the various ways to define it. We looked at crowd-sourced definitions, definitions from academia, classic “textbook” definitions, and more. In the end, we decided the simplest definition was the best. Digital humanities does exactly what the humanities do: using technology, it tries to understand, explain, and shed light on the human experience of the world and our collective place within it.

We stopped last time on the edge of a precipice, right before jumping headfirst into some of the debate surrounding digital humanities. Now, let’s pick up right where we left off.

The Digital Humanities Debate

When the digital humanities create projects in order to understand the human experience, they strive to focus on openness and accessibility – which is exactly what we are trying to do at Language in Lyrics. However, not everyone agrees with how successful this approach has been in the past or will be in the future.

Even though the 2010s could be dubbed the ‘digital humanities decade,’ some scholars take issue with the field. We hinted at this tumult in the last blogpost. Honestly, before I started doing the research for these blogposts, I had no real sense of the debate within digital humanities. I had no idea that some scholars debated the effectiveness of digital humanities for solving real-world problems, or thought big data could solve it all just by its very nature, or argued that not enough was being done to restructure the field to welcome everyone, or considered some digital humanities projects as hokey, fad-ish, superficial, and not critically rigorous.

If you read some of the sources I linked in the last post, you might have run across some of the dissent. Now, it’s time we gather round and gather all these threads together to discuss them.

Critiquing Digital Humanities: MadLibs Edition

Criticisms are complicated. But let’s play a little fill-in-the-blank game to sum them all up (call it nerdy MadLibs if you’d like). It’s a fun, succinct way to show the ways in which digital humanities can be sometimes negatively seen.

Digital Humanities is . . .

. . . a fad.
. . . a gadget.
. . . a QR code.
. . . superficial.
. . . not rigorously researched.
. . . not critically argued.
. . . “a handmaiden to STEM.” (see Adeline Koh’s article)
. . . structured to impede diversity (Posner’s article and Bailey’s article)
. . . data-mining like “browsing in a store.” (see Stanley Fish’s article)
. . . “tinkering” without ultimate meaning. (see Leon Wieseltier’s article)
. . . a “cult of data” and arrogant scientism. (again, Wieseltier’s article)
. . . alienated from real world problems.
. . . a bandwagon for the technologically illiterate.
. . . just plain hokey.

The tide of criticism seems to have been at the high water mark in the early 2010s, just as Digital Humanities was itself experiencing exponential growth in tandem with technology’s growing grip on our everyday lives – especially mobile technology, apps, and Web 2.0. (Side note: Web 2.0 essentially means the social, interactive way we use the web now).

Although the harshest criticisms have faded a bit, the core issues of utility, diversity, and purpose remain. As with any academic field, it’s a constant balancing act of approaches, attitudes, and priorities. And as with any new field, there are growing pains.

The full debate over Digital Humanities (and there’s even debate over whether to call it that anymore) is too complex to tackle in these blogposts, but, again, reading the linked articles in these last two blogposts or the articles in Debates in the Digital Humanities will give you a fuller sense of the contrasting views that are out there.

All this back-and-forth disagreement could easily make you start singing the chorus of a familiar 1970s classic:

But We Can Agree on Some Things…

You’ll probably be relieved to know that there is some agreement, especially now. Despite the debate, most scholars can agree that digital humanities is an umbrella term. It remains faithful to its humanities roots by approaching problems and questions that affect all facets of our human experience. But in its approach, it uses the “digital” (in whatever form that takes) to help make sense of our world and our collective lives. Not replace it, as some have feared, but just to help understand it.

Most importantly, the underlying philosophy of digital humanities has also emerged from the noise as a clear chorus: openness. Open source, open access, open approaches, accessibility, public engagement, etc.

What a relief, to have that clear chorus! It’s a song we all can sing.

The underlying philosophy of digital humanities has also emerged from the noise as a clear chorus: openness. Open source, open access, open approaches, etc.

Types of Digital Humanities Projects

By now you’re probably tired of exploring an esoteric academic field’s mysterious identity, so let’s move on to some more concrete examples of DH projects. This is only meant as a quick survey, but if you’re interested in more detail and more examples, the Topics page of The Digital Humanities Literacy Guidebook has lots of information on digital humanities projects divided into similar categories.

Textual Analysis

The very first digital humanities project was actually an index, just like our project – indexing every word of the works of Thomas Aquinas, led by Father Roberto Busa with IBM in 1949. As John Simpson, the Humanities and Social Sciences Specialist at Compute Canada, explains in an interview: “The Digital Humanities is often said to have come into existence when the production of the Index Thomisticus (a tool for searching the entire works of Thomas Aquinas) began in the late 1940’s through a 30+ year collaboration between Fr. Roberto Busa, a Jesuit Priest, and IBM, who provided the computing resources to make the project possible.”

(For more on digital humanities history, see Duke University’s chronology here; and Cambridge University’s detailed history here).

With its own song index, Language in Lyrics is following a good tradition.

But textual analysis in the digital humanities can be more than indexes. Literary projects often run large datasets of text through software in order to find patterns that otherwise would be missed. Or, they publish new editions with long-lost marginalia. Or, they use technology to salvage books that otherwise would be lost. For the latter, good examples are the scanning and virtual unfurling of fragile Biblical scrolls, or an initiative by Omeka to virtually repair Broken Books.

Digitization and Online Archives

In digitization and online archives projects, museums, archives, and galleries come alive. They are online exhibits that let you interact with the artifacts, or they make primary sources like historical texts and photos available to view. Like we talked about a couple blogposts ago, these kinds of projects would be similar the British Library’s Flickr (by the way, the British Library also has a great blog about digital humanities) or the Association of Nova Scotia Museum’s NovaMuse.

This is one of the most popular categories of Digital Humanities activity, and like textual analysis, has been around since the nascent days of the field. Increasingly, full exhibitions are hosted online after they begin their life as a digitization project. Some award-winning project examples include Medieval Swansea and Mapping Hiroshima. I bet you can find many more on your own, too.

Cultural Analysis

Digital humanities projects in the cultural analysis category are a little more complex to explain than digitization projects or online archives. They are often based on large datasets, and use online maps, graphs, and other interactive elements to convey their findings with the public.

And those findings, in turn, often shed light on underlying cultural phenomena that we might not notice or be able to illustrate without the big datasets. Of all the categories, this is the one aside from textual analysis that “crunches the numbers” the most. A good example is Linked Jazz, which uses the open source software Linked Open Data to illustrate interpersonal connections between jazz musicians. This then shows how ‘loose networks’ play a large role in both history and our experience of the world around us.

Online Publishing

We’ve actually already talked about some of the best examples of online publishing projects. As previously mentioned, Blackwell’s Companion to Digital Humanities is free to read online. And it’s more than a digitized PDF; it’s a structured website based on the book. The other example we’ve mentioned is Debates in the Digital Humanities. Debates is powered by an open source publishing platform called Manifold. This enables the authors of the series to interact with their readers by allowing them to add highlights to passages and add terms to a crowdsourced index. As an additional plus, the interface is one of the cleanest, easiest-on-the-eyes online reading experiences out there.

Online Networks and Directories

You might have heard of HNet, a well-known example of digital humanities in the networking realm. Then there’s the Humanist Discussion Group, which has been going strong since 1987. Other major DH initiatives and organizations include University of Victoria Digital Humanities Summer Institute and centerNet. Another chance to learn and connect comes through The Programming Historian, where you can find tutorials on how to do pretty much anything related to digital humanities, and brush up on tech skills. There are also annual Digital Humanities Awards – you can explore past years to find other great examples of projects.

But Why Are We Talking About This?

By now, you may asking why all of this context matters. You’re probably wondering why we’ve spent so much time going through the ins and outs of an unfamiliar academic subfield. Why are we talking about this?

That, at least, is a fairly easy question to answer. Language in Lyrics owes its philosophy and methodology to the digital humanities. It has inherited digital humanities’ goal of public engagement, openness, and accessibility. Our song index won’t be data for data’s sake – it’s meant to be used as a tool by our Gaelic cultural community. And this is completely in keeping with the spirit of digital humanities.

Language in Lyrics . . . has inherited digital humanities’ goal of public engagement, openness, and accessibility.

Our song index won’t be data for data’s sake – it’s meant to be used as a tool by our Gaelic cultural community.

Now that we’ve explored where these digital humanities ideas come from, we can move on to explore other digital humanities projects within the online Gaelic world. Over the next two blogposts, we’ll be exploring what other digital resources are out there for Gaelic, especially music, both here in Nova Scotia and in Scotland, concentrating on how they harness technology. We’ll be comparing their approach and databases to the Language in Lyrics project.

See you next time for more kitchen table technology conversation.

Le beannachd,

Aleen

---

Nonrequired further reading:

Association of Nova Scotia Museums. NovaMuse. https://www.novamuse.ca.

Arts and Humanities Research Council, University of Southampton, King’s College London Digital Lab, Queen’s University of Belfast. City Witness: Place and Perspective in Medieval Swansea. http://www.medievalswansea.ac.uk/en/.

British Library. Digital Scholarship blog. https://blogs.bl.uk/digital-scholarship/.

Cambridge University. “Defining Digital Humanities.” Cambridge Digital Humanities. https://www.cdh.cam.ac.uk/cdh/what-is-dh.

Carnegie Mellon University. The Digital Humanities Literacy Guidebook. https://cmu-lib.github.io/dhlg/.

Cashion, Debra Taylor. Broken Books. Saint Louis University. https://brokenbooks.omeka.net/.

CenterNet (An international network of digital humanities centers). https://dhcenternet.org/.

Compute Canada. “Q & A with John Simpson.” Humanities and Social Sciences Research Portal. https://www.computecanada.ca/research-portal/humanities-and-social-sciences/.

Digital Humanities Awards. Highlighting Resources in Digital Humanities. http://dhawards.org/.

Fish, Stanley. “Mind your P’s and B’s: The Digital Humanities and Interpretation.” The New York Times. 23 January 2012. https://opinionator.blogs.nytimes.com/2012/01/23/mind-your-ps-and-bs-the-digital-humanities-and-interpretation/.

Gold, Matthew K. and Lauren F. Klein. Debates in the Digital Humanities 2019. (Minneapolis: University of Minnesota Press, 2019). https://dhdebates.gc.cuny.edu/projects/debates-in-the-digital-humanities-2019.

Hiroshima Archive Production Committee. Hiroshima Archive. http://hiroshima.mapping.jp/index_en.html.

HNet (Humanities and Social Sciences Online). Michigan State University. https://networks.h-net.org/.

King’s College London. Humanist (Journal and Discussion Group). https://dhhumanist.org/

Koh, Adeline. “A Letter to the Humanities: DH Will Not Save You.” Hybrid Pedagogy. 19 April 2015. https://hybridpedagogy.org/a-letter-to-the-humanities-dh-will-not-save-you/.

Manifold (affiliated with University of Minnesota Press and funded by Andrew W. Mellon Foundation). https://manifoldapp.org/.

Pratt Institute Semantic Lab. Linked Jazz. https://linkedjazz.org/.

The Programming Historian. https://programminghistorian.org/.

Schreibman, Susan, Ray Siemens, and John Unsworth, eds. A Companion to Digital Humanities (Oxford: Blackwell, 2004). http://www.digitalhumanities.org/companion/.

University of Victoria. Digital Humanities Summer Institute. http://dhsi.org/.

Wieseltier, Leon. “Perhaps the Culture is Now the Counterculture.” The New Republic. 28 May 2013. https://newrepublic.com/article/113299/leon-wieseltier-commencement-speech-brandeis-university-2013.