The Problem​

Documentation is an integral part of all software products, and for it to be useful, it must be comprehensive and detailed. However, this presents a challenge for both users and developers. Users, especially those who are newcomers to the software, can find it daunting to sift through large blocks of text, while developers often struggle to make documentation appealing and digestible.

Throughout university, I have been in the former category. As a user, I have always found documentation difficult to grasp. It often left me with more questions than answers. It especially did not help that the documentation websites I used often had terrible navigation and few resources to help me grasp what I was reading, leaving me scouring through various sites to find information that was tucked away in some hidden corner.

As a co-op student with LINCS, I was tasked with migrating the Canadian Writing Research Collaboratory (CWRC) documentation site. This website provided information about and access to the three ontologies developed by the CWRC, each with its own set of documentation. This had me worried, because how could I develop a website that could display documentation effectively while taking into consideration navigation, aesthetics, and page layouts?

Docusaurus​

This is where Docusaurus comes in. Docusaurus is a powerful static site generator built with React, which enables users to quickly and easily create documentation-focused websites. Because Docusaurus is built specifically for documentation, I was able to focus on presenting the content instead of worrying about the design. Rather than relying on HTML tags to display content, Docusaurus makes use of Markdown (MD) and Markdown eXtended (MDX), a user-friendly language with a simple syntax that can be picked up easily, and which also provides support for Javascript XML (JSX). This allowed me to combine the simplistic nature of MD while also harnessing the flexibility and power of JSX. Docusaurus combines everything as static HTML files that I could easily deploy to the CWRC website, and it even allowed for embedded React components. Without sacrificing functionality, Docusaurus has streamlined the process of creating and publishing documentation.

Docusaurus made it easy for me to create the sort of website that the CWRC documentation needed. A goal of migrating the CWRC Linked Data website was to enhance the accessibility and readability of CWRC’s information. The original website, while functional, lacked consistent structure and navigation, making it difficult to use.

(Figure: Before and After)

These difficulties also translated to the implementation, as the coding structure for the documentation felt cluttered due to the number of HTML tags needed to display the text. This is where the simplicity of Markdown shined, as it streamlined the process of transitioning information over to the new website. While I was unable to fully transition from HTML tags, much of the documentation is now formed with Markdown, which will aid in the process of future refactoring or editing.

Useful Tools​

This isn’t to say that Docusaurus is only useful for its Markdown capabilities, as it also has many useful components and hooks. One such component that I used often was <Link/>, which enables linking for both internal and external pages. What separates this component from basic HTML linking tags like <a/> is its ability to preload resources before navigating to the resource’s page. By making use of the “onMouseOver” event to fetch the requested resources of that page, Docusaurus preloads those resources to ensure seamless and efficient page transitions. Access to additional information through both internal and external links makes documentation clearer and easier to navigate, therefore reducing for users the sorts of struggles that I have had using documentation for other software.

In tandem with its various components, Docusaurus also supports ESLint plugins with additional rules, which are compatible with its unique components. These plugins allow users who are new to Docusaurus (myself included) to develop code while adhering to best practices and making full use of the capabilities of Docusaurus. In other words, Docusaurus is built to make using it easy. This is not just a benefit of using it but also a great example of how to make documentation and tools that are easy to navigate and easy to use.

Do not use an `<a>` element to navigate. Use the `<Link />` component from `@docusaurus/Link` instead. See: https://docusaurus.io/docs/docusaurus-core#linkeslint@docusaurus/no-html-links

To Sum It Up​

While dense, text-heavy documentation still proves to be difficult to display in a digestible way, Docusaurus helps developers focus on their content instead of the nitty-gritty of creating a site. With its growing community and source code readily available to help newcomers learn and collaborate, it is no surprise that Docusuarus is a leading site generator for documentation-focused websites. While I continue to learn the ins and outs, I continue to be impressed by the thoughtfulness and intuitive nature of Docusaurus and will continue to make use of its capabilities to the fullest.

I have spent most of my summer improving the accessibility of the LINCS project website. During this process, I have learnt so much about how those with disabilities navigate the Internet. There has been a lot to do, and it's taken up a lot of my time—but it certainly doesn't have to be that way! If designers incorporate accessibility from the beginning, minimal extra effort makes for a better experience for all users, not only those with barriers.

27% of Canadians have one or more disabilities that hinder their daily activities according to the Canadian Survey on Disability.

Furthermore, an estimated 1.5 million Canadians have sight loss, and 6 million more have a disease which could lead to sight loss. Without the use of screen readers, these individuals would find it difficult to, and in some cases have no way to, navigate the web. Think about how much you rely on your phone or computer for banking, contacting people, searching for information, booking appointments, finding jobs, creating calendars—the uses are endless. An inaccessible web would make it difficult or even impossible for millions of Canadians to perform a multitude of everyday tasks.

When doing a small accessibility audit of the LINCS project’s home page, I discovered that the first heading level (H1) was being used all over the page. While it looked just fine to me, I came to realize just how important it is to have a logical descent of heading levels when navigating a webpage using a screen reader. I also discovered how important “alt text” is for those who cannot see the images—and I subsequently spent a lot of time adding alt text to photos on the LINCS site.

Although some accessibility issues are obvious, a lot go unnoticed. Barriers are often invisible to those with good vision, hearing, or dexterity. Fortunately, accessibility testing tools and software made for those with disabilities make it possible for designers to experience their own websites from the perspective of their users. My first action when auditing the LINCS website was to enable Windows’ screen reader and attempt to navigate with my eyes closed; it was a lot harder than you’d think! A large part of this difficulty was due to the overuse of H1 headings.

The following video demonstrates how a popular screen reading application, JAWS, announces the information on a well structured webpage. Notice how JAWS relies heavily on heading levels to convey importance and to group relevant information together.

Accessibility improvements make it possible for more users to access content or use tools, while simultaneously improving the experience of all users. Consider, for example, accessibility features for audio. More than 50% of Americans either use closed captioning some or all of the time according to CBS, and this number is as high as 80% for those in Generation Z. As CBS explains, popular streaming services such as Netflix originally implemented captions for all of their content because of the advocacy of the National Association of the Deaf in 2010. Captions have since become an essential part of all streaming because they are useful to all: if you’re in a loud environment, have no headphones in a library, want to watch something made in another language, and so on. User retention has actually been seen to increase when closed captions are present, with a joint study by Verizon and Publicis Media providing the following statistics after conducting a survey on U.S. consumers of videos and advertisement:

• 80% of viewers are more likely to finish the video if it has captions
• 69% view videos with sound disabled
• 50% state captions are important, commonly citing reasons such as being in a quiet place, no access to headphones, or for multitasking
• 37% of viewers were inclined to turn on sound if captions were available

Another example of accessibility benefiting everyone are the hands-free capabilities that people often use in the car or while busy with other tasks such as cooking or cleaning. Audiobooks, originally meant for those with sight issues, have boomed in popularity; the Audio Publishers Association’s annual sales survey revealed that sales figures have had double-digit growth for 11 years straight.

This all proves the point that accessible design is simply good design. It is for that exact reason I have been so thankful for my first experience in the world of web development being focused on accessibility, as it is an essential foundation to have and has no doubt molded me into an inclusive and more effective web developer.

What can you do to help?​

Even if you aren’t a web developer or product designer, you can help to make the web more accessible by advocating for accessibility, making your voice heard, and asking for things such as closed captioning or transcripts. When you catch something that doesn’t feel accessible—for example, some hard to read text on a poster—provide feedback!

If you use social media such as Instagram, LinkedIn, Facebook or X, be sure to include alt text, a descriptive blurb explaining the contents of the photo being posted. For helpful tips on alt text, see Tug’s Guide to Alt Text on Social Media.

Also be sure to capitalize each new word in a hashtag! Screen readers have difficulty reading out one squished together sentence. For example, #ILoveAccessibleWebsites will read exactly how you intend, but #Iloveaccessiblewebsites might be attempted to be read as a single weird and very long word.

To learn even more about web accessibility, check out this introduction by W3.org.

Advocating for accessibility, providing feedback, and using inclusive practices on social media are simple yet impactful ways everyone can contribute. I look forward to making good, accessible designs in my career. Let’s all commit to making the web a place where no one is left behind.

Image: Woman punch card operators working on Roberto Busa’s Index Thomisticus. Back left: Rosetta Rossi Bertolli; bottom right: Livia Canestraro. CC-BY-NC. Thanks to Melissa Terras, “For Ada Lovelace Day,” 2015.

I am surprised and thrilled that someone thought it worth nominating me for the Roberto Busa Prize, and overwhelmed to have been placed by ADHO in such illustrious company, fully aware that there is so much superb work in our community deserving of this recognition.

All knowledge is relational. It is fabulous to have recognition of scholarship that emerges from an intersectional perspective and is embedded in process: from making things that try to leverage technology in new ways, trying and failing, and yet continuing to try to make a difference to how we work and to enable us to create and share knowledge together, in better ways, in a changing world. For such work, collaboration is essential, which is to say it’s all about people.

My absolutely stellar colleagues here at LINCS gelled into a phenomenal team, even though we came together remotely, many of us for the first time, at the height of the pandemic, to build an infrastructure for linking scholarly knowledge across disciplines. The core LINCS team is at the heart of a growing network of scholars, students, and professionals who are, thanks to the combined efforts of these brilliant people, able to engage in serious exploration of the capacity of linked data to enhance cultural research and cultural experiences. The CWRC virtual research environment has involved 200+ wonderful people (and counting, since our credits need updating before we launch this spring as an instance of the LEAF software framework). And my belief in the magic of producing knowledge collaboratively in new digital ways grew out of formative experience as a new scholar in the Orlando Project, whose sterling participants include as active contributors ~150 students.

The point isn’t the numbers but the sense of expanding networks: there are overlaps between projects and roles, so the counting isn’t exact, indeed cannot ever be exact, because there will inevitably be inadvertent omissions, and because the strands of influence just keep linking out. I’m so grateful for all the rich relationships that infuse this work, amazed at what we’ve created and learned together, proud of those who’ve put it to work in other contexts and fields.

And there are so many other relationships, other people to whom credit is due. Mentors who bolster my confidence. Models whose thinking and practices inform and inspire mine. Co-authors and co-presenters who help me see things differently as we struggle to express ourselves together. Students and colleagues in courses and workshops whose reactions and questions spark such insight. Colleagues who carry on and remain dedicated despite the deplorable precarity of the conditions in which they work. Collaborators on projects led by others, in which I have learned so much, including Collective Biographies of Women, INKE, Lesbian and Gay Liberation in Canada, NovelTM, Staging Better Futures/Mise en scène de meilleurs avenirs, The People and the Text, Voyant,The People and the Text and the Women Writers Project. The creators and activists whose work reflects, reimagines, and reshapes the world we live in.

So many other projects that have worked with CWRC and LINCS, and the incredible array of digital humanities initiatives from around the world, working collectively to figure out how to make and share knowledge differently in this age of incunabula. Those in university administration—at the universities of Guelph, Alberta, and many partner universities—as well as funding organizations—CFI, CANARIE, DRAC, Mellon, SSHRC—who get that this work doesn’t fit the old moulds, who strive to remove barriers, and who develop new models. Colleagues who keep scholarly organizations like CSDH, ACH, ADHO, ACCUTE, ACQL, MLA, BWWA, VSAWC, and NAVSA ticking along so we have collegial spaces in which to connect. Colleagues on panels and boards who help me grasp the bigger picture and alternative views. Partners in GLAM and the knowledge ecosystem, like CRKN, CHIN, and Library and Archives Canada, who share the vision of what is possible if we work together.

Everyone in this particular web who is motivated by a sense of how the complexity and value of human cultures and histories—especially of women, BIPOC, colonized, 2SLGBTQI+, impoverished, and otherwise marginalized people—could register in digital space in different, more vibrant, nuanced, contextualized, respectful, and equitable ways.

When designing and building a web application, ensuring that it is responsive is paramount. A responsive application looks good and functions well on all screen sizes and devices. LINCS applications are being designed to be viewed in a wide range of ways: from tablets to laptops to whiteboard-sized interactive screens. It can be quite hard to achieve this level of responsiveness, but with the help of CSS tools, techniques, and frameworks, the task becomes a lot easier...

There are commonly used layout systems built into CSS called Flexbox and Grid. In addition, CSS has a feature called media queries, which allows content to appear differently depending on the size of the viewport. There are also CSS frameworks like Bootstrap CSS that are easy to use and great for responsive design.

If you are using vanilla (standard) CSS and want full control of the design, you can either use CSS Flexbox for a one-dimensional layout or CSS Grid for a two-dimensional one. Flexbox offers customizable properties that control layout and alignment. Items inside a flexbox container are called flex items. Flex items can be arranged horizontally or vertically depending on the flex-direction property that is set (row, column, row-reverse, etc). Furthermore, flex items can be centered vertically or horizontally and can grow or shrink as their parent container increases or decreases—options that let you make a layout suited to your needs. CSS Grid similarly has properties that can be configured. I often turn to CSS Flexbox when designing for LINCS’s ResearchSpace, as it allows me to horizontally or vertically align the many components we need to display, keeping the page’s elements distinct no matter the screen size.

Making information accessible is one of the key goals of LINCS and ResearchSpace, and ensuring that users can clearly see what information is on their screen is part of this. Media queries are a great CSS technique for this kind of task. Media queries allow you to create different layouts depending on the size of the viewport (the user’s visible area of a web page), which make it quite a powerful tool. For example, you can rearrange items in a container so that they adjust to suit the screen size. If it is large-sized, you can have the items in one row. If it is medium-sized, you can have the items in two rows. Rendering content according to screen size is essential in a responsive web application, as it allows your user to view the right amount of information for their screen.

Lastly, there are CSS frameworks like Bootstrap CSS. With Bootstrap, you can quickly and easily make responsive layouts that look good on all different screen sizes and devices—including mobile devices. Bootstrap is commonly used to build responsive grid layouts. A bootstrap container is divided into twelve columns, and all you need to do is specify, for example, how many columns an item should take up. The responsive features are already built into the layout, so all the work is done for you when it comes to making the layout responsive. ResearchSpace uses Bootstrap CSS. One instance where its application was necessary arose during the redesign of the entity aggregation page. In this case, I needed to construct a grid layout in which I relied on Bootstrap CSS. The resulting design, as shown from the following screenshots, showcases its responsiveness across different screen sizes, including the iPad Pro (1024px x 1366px) and the standard full HD monitor (1920px x 1280px).

ResearchSpace on an iPad Pro (1024px x 1366px).

ResearchSpace on a standard full HD monitor (1920px x 1280px).

These CSS tools and techniques have helped me redesign the appearance of ResearchSpace to make it more responsive. They are quick and easy to use, and they also have very good documentation online, so it is not difficult to find information about how to use them. In turn, I hope that implementing them for ResearchSpace will make it easier for users to find information using LINCS.

In my first meeting this summer as a data science research assistant, we each followed our personal introductions with declarations of our favourite ice cream flavours. Mine was and continues to be Häagen Dazs’ Strawberry Cheesecake ice cream, and I was pleasantly surprised to learn someone else on the team felt the same. However, the biggest surprise was learning that someone enjoyed microwaving their ice cream to change its texture. At that point is it still ice cream? Is it soup? Or a milkshake? What even counts as ice cream? ...

Shelving those questions, I dove head first into a different, non-dairy, world—the world of knowledge organization systems. I was swimming in a sea of acronyms (RDF, SKOS, OWL, CWRC, and TTL to name a few) and organizational structures. I was busy understanding how humans could use organization systems and languages developed for the sole purpose of knowledge representation to wrangle computers to view the world in human-made categories.

Spoiler alert—it’s messy. But first, a mini etymology lesson.

Ontology comes from the Greek words onto (being) and logia (study), effectively meaning the study of being. Ontologists question how things are grouped into categories, which categories are at the topmost level, and how these categories inform the classification of everything. In information science and Digital Humanities (DH), an ontology refers to a model of the broadest categories in a specific knowledge set. While ontologies feature generic concepts, they do not include specifics—those are left to vocabularies. Vocabularies expand on the generic concepts in ontologies by giving them contexts and meanings.

For instance, an ontology of desserts may include a class of dairy desserts with a subclass for ice cream. However, ice cream flavours may be omitted from the ontology due to their specificity; instead, they may appear in a vocabulary about desserts. May is the key word in this example. The creator of the ontology may decide strawberry cheesecake ice cream is important enough to add to the ontology and so other flavours should be there too.

May kept on popping up not only while I thought about ice cream but also as I navigated LINCS’s ontologies and vocabularies. One of my main roles this summer was to implement changes made in the ontologies to the vocabularies as well. This included fixing redundant relationships in the Genre vocabulary such as feminist theory being declared as being part of the philosophical and scholarly genre when the philosophical genre was in fact a subset of the scholarly genre. As a result, I became well versed in the ins and outs of the CWRC, Genre, and Illness & Injuries vocabularies.

A quick aside before I explain about the much-dreaded may. The ontologies and vocabularies I worked with were not drawn on a whiteboard where I could erase concepts and add connections between classes as I pleased. Instead, they lived on the web where they were encoded using semantic languages and structures such as OWL, RDFS, and SKOS. Computers thrive on binaries where a decision flips a switch on or off; ambiguity stalls the system as machines cannot infer implied meaning like a human brain. Semantic models such as ontologies and vocabularies therefore try to replicate methods of typing and categorizing that seem like second nature to us for computers.

So to recap: computers operate in binaries but we do not. The entirety of the web’s data is stored in ones and zeroes, but our brains see the world in much more complex, nuanced ways.

While ontologies and vocabularies may seem similar (they both help categorize things), ontologies are strict in how concepts can be grouped since they use formal logic. A vocabulary, in comparison, doesn’t claim that ice cream is a dessert—it only helps describe concepts, such as the many decadent ice cream flavours. Writing it like this makes it seem intuitive that logic doesn’t apply to vocabularies, or as W3.org writes:

[Some Knowledge Organization Systems] are, by design, not intended to represent a logical view of their domain. Transforming such KOS to a formal logic-based representation may, in practice, involve changes which result in a representation that no longer meets the originally intended purpose.

It’s true that hindsight is 20/20 because while it seems obvious now, I spent countless hours agonizing over conceptual hierarchies in the vocabularies that just did not make logical sense. The fictional genre may fall under the literary genre, but it also may fall under the narrative genre. If I was asked this question out of nowhere, I would ask why not both, but I was so keyed into the binary thinking of computers that I felt blindsided when I saw the fictional genre as an offshoot of the literary and narrative genre.

Visualization of the Genre vocabulary based on the Genre ontology produced using WebVOWL

It was easy to fall into the pattern of thinking where a concept was either A or B, especially when the categories were already in front of me. It was harder to recognize that things in real life are much more complicated and nuanced than a coded system could neatly categorize.

I spent so much of the summer trying to understand how the world could fit into neat little boxes that I forgot about the human aspect of categorization–the messiness and maybes that often comes with making decisions. While the polished world of ontologies and vocabularies may seem far removed from everyday life, it took me a better part of the summer to remember that they’re based on human-made categories—categories whose boundaries can shift over time and vary by user.

That’s all to say that by the end of the summer I had an answer to my burning questions from the start of May: it’s all subjective! This may be a non-answer in the binary yes-or-no sense, but as long as there is some sort of consensus (whether between two people or millions), the fate of melted ice cream, like vocabularies, can exist in the gap between absolutes.

I’ve always found that context changes everything when learning something new, especially when it comes to understanding why that something matters. The first example I can think of is how, for all the general chemistry courses I’ve taken, the concepts never really clicked, nor did I see why I had to learn them. Four of these courses later, I wasn’t very excited to take biochemistry, but when I did, I couldn’t believe how much of a difference it made to have a real context: the human body, where chemical reactions happen for a reason. Suddenly, the abstract became pretty important—I could see how it all fit together, and in turn, my understanding of general chem probably increased threefold. Rest assured, this blog post is not going to be about chemistry. Rather, it’s about how the same phenomenon occurred this summer, when working on the Orlando Project changed the way I think about data...

Prior to my time as an Orlando research assistant, my only exposure to and understanding of data was in the form of numerical values. Data as I knew it was only a means of generating statistics or drawing a conclusion at the end of a paper, though beyond the context of a particular study or experiment, the data itself wasn’t very relevant. So, when I was first introduced to the idea of Linked Open Data (LOD), I couldn’t exactly conceptualize what it was or why it was so impactful. It was only after a few weeks of using Orlando’s database that I began to appreciate its LOD at work: every time I ran a search for a person or a place, I incidentally learned about many others as well—authors who had been their close confidantes, as Iris Murdoch was to Brigid Brophy; authors who believed in common causes, like Felicia Skene, Christina Rossetti, and Sarah Grand’s support of the anti-vivisection movement; and authors that had a common inspiration, such as P. D. James, Stella Benson, and Margaret Kennedy’s mutual admiration of Jane Austen—all because Orlando had gathered these lists for me. Now, instead of seeing data as something that stands in isolation, I see it as a way of making sense of history, where connections are a form of data in and of themselves.

Each of the tasks I’ve worked on for Orlando this summer, from constructing entries for authors and historical events to entity matching , have involved looking at the past in context, rather than getting only scattered glimpses of it. When reconciling—matching a person in the database to their correct web identifier—for example, the most helpful tool is the data Orlando pulls about them from other profiles and pages, which alleviates much of the need to go on a wild goose chase for details. A little later in the summer, when I began researching, writing, and tagging an author profile for contemporary poet and activist Seni Seneviratne, I realized I was doing more than creating a resource to learn about her life and work. Rather, I was adding data to an ecosystem, one that would allow a researcher trying to learn about contemporary women poets of colour, or perhaps trying to gather a list of poems that address the Israeli-Palestinian conflict, achieve their research goals in the span of a few searches.

Through my own research this summer, I’ve seen how LOD makes information more visible and accessible, leading to discoveries I’d never have made otherwise: I’ve learned about suffragettes of the past by name, like Emily Davison and the Pankhurst sisters; women who were suffragists and authors both, like Ethel Arnold; and just how many authors can be linked to Virginia Woolf, either as contemporaries or because she inspired their work decades later. Now that my first semester with Orlando is coming to an end, I can say that my summer of working with LOD has helped me understand more about the world, replacing the fragments of historical knowledge I used to have with a broader, more comprehensive picture. Much like my experiences with biochemistry, LOD has shown me how to make information more impactful: not by removing information from its broader context, but by focusing on its potential for connection.

LINCS is using ResearchSpace as a platform for exploring relationships in interlinked cultural datasets. With ResearchSpace, researchers can browse, search, and visualize data in the LINCS datastore. In summer 2022, I was part of a team that was developing new features for LINCS’s version of ResearchSpace.

Our team was a collaboration between contributors with a background in user experience (UX) and contributors with a background in software development. We worked in tandem: the UX group recommended features to improve the experience of using the web application. These recommendations were turned into tickets in GitLab. The tickets described what the desired end product would be, and it was up to the developers to determine how to achieve this goal. The development lead shared tickets out among the software developers, dividing them up based on what would be required to build the suggested features...

Most of the tickets I was assigned were for components that required React.js. When I started with LINCS, I did not have much experience with React. While I was already familiar with React Hooks, I needed to learn the class-based React that was utilized in ResearchSpace. Often, I needed to know more than just what my ticket asked me to do. I had to understand the project’s sizable codebase and how it operated while also extending my skills. As a result, I developed expertise in TypeScript and React and I learned how Docker and Docker containers function. These things may have been confusing at the start, but now they are familiar. For example, I now have a good understanding of the functioning of Docker Compose files and I have lots of experience using Handlebar templates for bug fixes.

I learned a lot more than just technical skills. I have a lot of gratitude towards my team members. Zach Schoenberger, who supervised my work, helped me develop the crucial skill of how to explain technical concepts to non-technical people. Dawson MacPhee, a senior student developer, taught me how to approach my work. From him, I learned to start making improvements gradually, to do several tests, and to divide my objectives into manageable pieces. Dawson taught me to refer to the documentation whenever necessary and encouraged me to ask questions as I went.

Making modifications without upsetting what had previously been established was challenging, but with the skills I learned from Zach and Dawson, I was able to successfully make gradual changes. ResearchSpace has many interconnected React components. While at first I found it hard to make changes without breaking other things, over time I developed both my technical and non-technical skills, which meant I was able to turn the UX requests into functional components.

If you’ve ever listened in on a technical conversation between computer scientists, you might’ve heard them refer to something called an Application Programming Interface (API). What exactly is an API? Let’s break it down...

An application is any software that performs a distinct function. Microsoft Excel and Google Sheets are good examples of common applications that lots of people use—even those who are not computer scientists.

Now, every application has specific rules for how to interact with it. For example, most users of Microsoft Excel know that they can bold the text in a cell by clicking on the B button on the ribbon toolbar that appears at the top of Excel’s interface. An interface is a contract that defines rules for software interaction.

These two terms—application program + interface— join together to make Application Programming Interface or API. An API is a way for two or more applications to communicate with each other using requests and responses. As Junior Research Analysts working for LINCS, we’ve had plenty of opportunities to work with APIs as we try to join together the applications that make up LINCS.

One of the APIs that we have worked on is the Diffbot NLP Vetting workflow. The purpose of the Diffbot Vetting Workflow is to assess the performance of the Diffbot Natural Language Processing (NLP) API on LINCS datasets. The Diffbot NLP API uses machine learning and computer vision algorithms to look for meaning in text. In particular, it identifies entities (e.g., people, organizations, products) and data about them (e.g., the relationships between them).

For example, when provided with the text, “On 11 November 1741, Abigail Smith (later Abigail Adams) was born in Boston, Massachusetts,” Diffbot created the following knowledge graph:

Using data from the web, Diffbot was able to identify the text’s entities (circles) and also the relationships (arrows) between them, which it refers to as facts. Diffbot’s AI algorithm consistently identifies entities and facts correctly in many of the applications for which it is used outside of LINCS; however, error-free identification is not always possible given the complexity of the data LINCS is working with. To help with this, we wanted to create a tool that would analyze the accuracy of what Diffbot was telling us: the Diffbot NLP Vetting Workflow.

In essence, the Diffbot NLP Vetting Workflow is a few steps contained in a Jupyter Notebook; using it does not require extensive programming experience or in-depth knowledge of how Diffbot works. Behind the scenes, however, the workflow’s few lines point to a complex Python code that handles the API communication and adheres to Diffbot’s many standards.

Starting with plain text as input, the workflow sends a request to Diffbot to identify all of the entities and facts in the text. The response that comes back looks something like this:

{
  "entities": [
    {
      "name": "Boston",
      "diffbotUri": "https://diffbot.com/entity/E7vnJ0j-OP4qXP4s9wNDbEQ", 
      "confidence": 0.9994205,
      "salience": 0.4442726,
      "isCustom": false,
      "allUris": [
        "http://www.wikidata.org/entity/Q100"
      ],
      "allTypes": [
        {
          "name": "location",
          "diffbotUri": "https://diffbot.com/entity/BiCyWUm41NziqgLHx47iAIQ", 
          "dbpediaUri": "http://dbpedia.org/ontology/Place"
        },
        {
          "name": "administrative area",
          "diffbotUri": "https://diffbot.com/entity/EcTIultWKPoula6qZtSpc4A", 
          "dbpediaUri": "http://dbpedia.org/ontology/PopulatedPlace"
        },
        {
          "name": "city",
          "diffbotUri": "https://diffbot.com/entity/EzdJrGHiyMWu0XbSn101rFA", 
          "dbpediaUri": "http://dbpedia.org/  ontology/City"
        }
  ],
  "mentions": [
    {
      "text": "Boston",
      "beginoffset": 163,
      "endOffset": 169,
      "confidence": 0.9994205
    }
  ],
  "location": {
    "latitude": 42.36028,
    "longitude": -71.05778, 
    "precision": 15.231546
  }
},

This result, which takes the form of a JSON response, is not all that easy to assess. To make it easier to vet the data, our program calls on the Google Sheets API to generate a spreadsheet:

Google Sheets, in turn, applies some default formatting: hiding, resizing, and freezing columns, as well as applying bold and colours to the text. Each function is associated with a different API request; a lot of trial and error was involved in creating something that would be easy for a human to review.

The resulting spreadsheet shows the entity, Diffbot’s confidence in its own prediction (a number between 0 and 1, with 0 being least confident and 1 being most confident), and a link to a matching entity in Wikidata, and more. A person reviewing the data can use all of this information to confirm or correct the accuracy of Diffbot’s work. To make this review as simple as possible, the last column in the sheet shows where in the original text Diffbot found the entity, so that the reviewer can refer back to the original easily if further checks are needed. Using the information in the spreadsheet, the reviewer can then either approve or reject Diffbot’s results (by entering yes or no in the spreadsheet; columns L, M, and N in the image above).

The newly vetted information (as well as overall accuracy scores for the data being reviewed) then continues its path onward, through a further series of steps that involve both applications and people—a multistage process best saved for future blog posts. At the end, what started out as a sentence in a document can be discovered as entities and relationships in LINCS’s triplestore. And, thanks to the Diffbot NLP Vetting Workflow, those using LINCS’s data can have confidence that the content they’re exploring is accurate!

The UX team has been conducting user research on LINCS tools to get them ready to move from development to production. So far, we have completed card sorts, usability tests, surveys, and interviews. This research has provided us with a wealth of information. However, if we want to translate what we’ve learned into meaningful, productive changes to the tools’ designs, we must keep actionability at the centre of our research practice...

During my UX studies, I took a course on user research techniques. Going in, I thought that UX research methods were fairly straightforward: speak to your users, synthesize the data you gathered from these conversations into personas and journey maps, and voilà—you’ve completed your user research. Sadly, I was mistaken. In one of the course’s assignments, my classmates and I were asked to observe participants as they completed a shopping task. When we noted that they were struggling, our professor simply asked, “Ok, but how?” In our first attempts at user research, we only looked for the problem; we had not yet grasped that we needed to understand exactly how and why participants had trouble with their task. Without digging deeper to understand our users’ goals and behaviours, our findings were not actionable, meaning that solutions could not be derived from our research.

This lesson taught me the difference between research and good research. New designers often conduct research to tick it off a checklist—to show that users have been consulted. Experienced designers conduct research to understand the user, and they turn that understanding into action. When user needs are not clear, the research does not serve the design, resulting in solutions that are not actually user centred.

During my time at LINCS, I’ve found it essential to think deeply about actionability while working on one of its tools—ResearchSpace—as it has moved through the design process. Site-wide usability tests for ResearchSpace, led by Robin Bergart (UX librarian) and Evan Rees (UX designer), had just begun when I started my position. I had the privilege to facilitate a few of the tests that were being used to determine how users understood LINCS ResearchSpace’s functionalities. Throughout the tests and as we subsequently analyzed our findings, I thought about actionability at both a low and a high level.

From a low-level perspective, I tried to make each observation into an actionable piece of data. During the tests, I wrote down detailed observations to connect participants' actions with their thought processes as they described them. When observing participants complete a task, I noted their specific actions, ranging from elements they clicked on to functionalities they noted as standing out most to them. For example, we asked participants to search for an entity in ResearchSpace. Many participants found entities successfully by accessing the contents of a dataset; in doing so, they overlooked the search box in the navbar, which they also could have used. Via observations about both what users did and did not do—and their descriptions of their actions as they were taking them—we uncovered rich data that allowed us to synthesize our results into meaningful patterns and themes.

Once we had these findings, we needed to find a way to extend actionability to others outside the UX team. For instance, we needed to share our findings with the developers who we were collaborating with to generate meaningful and feasible improvements to the tools. In practice, this meant that we had to find a way to transform our messy virtual UX whiteboard, scattered with ideas on digital sticky notes, into a format that the broader LINCS team would be able to read and understand. To do this, we wrote a report that defined each finding by highlighting pain points and our related key observations. This process helped us get our ideas across, but with hindsight I think we could have been even more effective if, instead of just presenting our findings at the end of the synthesis process, we invited a broader range of stakeholders to participate in the whiteboarding process. This strategy would have broadened the team’s understanding of the findings and invited more people to brainstorm solutions.

Even with some bumps along the way, our findings have uncovered pathways to solutions. For example, I designed an improvement to navigation by providing users access to ResearchSpace features right from the home screen. User needs informed my design’s layout, as the user research showed me that we needed a design that allowed users to quickly find and use ResearchSpace’s myriad resources.

Thus, with actionability in mind, our user research directly fed into our design solutions and helped address real user pain points. It has been exciting to put into real-world practice the user research methods I had previously only learned in theory. I cannot wait to see what is in store as we continue to research and design!

When I began my first co-op placement, I had no idea how software development worked in a professional environment. Previously, my experience had only been in the classroom, where  my classmates and I developed software for assignments. When I moved into a professional context, I was exposed to new ways of collaborating, among them stand-up meetings, or stand-ups...

What are stand-up meetings? Stand-ups are short, daily meetings where a team meets to discuss different tasks about a project. Nowadays, stand-ups are core to lots of software development projects, but they were originally popularized in agile development, which is a well known methodology in the industry. Software development projects can be complicated, so agile development breaks complex problems down into manageable, achievable components.

Meeting daily is an excellent way to build a large project. It encourages the team to set goals that can be met in one day, and then to follow up the next day to identify problems, address issues, and sort out confusions quickly. Stand-up meetings also boost communication. They help the team become comfortable with each other through frequent communication. Stand-ups make everyone feel included.

Stand-ups keep everyone on the team productive by giving each member a daily reminder of the goals that they need to work on and how these goals fit together with the project as a whole. Although software development is often an individual effort, getting feedback from a supervisor or a peer as problems arise is an effective way to not only reduce roadblocks but also expand the team’s knowledge. Stand-ups are a great way to achieve transparency, as they encourage people to share problems and solutions.

When I started working at LINCS, I didn’t understand the value of stand-ups. But I found that the more stand-up meetings I did, the more easily I was able to look for help and the more comfortable I felt asking questions. In turn, I discovered that I was able to quickly adapt my thinking and resolve the issues I had. Stand-ups helped me to focus on the tasks at hand, and they provided me with the structure I needed to work effectively and efficiently.

Because stand-ups take place frequently, they are also meant to be very short. Thanks to the limited time that we set aside for the meetings, I learned to ask my questions concisely and to get straight to the point. It became clear to me that I find it more effective to have smaller and shorter meetings because they help me address small issues before they become big problems. I have always been a shy person, so having stand-up meetings often helped me grow more comfortable talking to my colleagues.

I thought that my co-op would teach me about software development. I did not expect to also learn so much about collaboration, teamwork, or about myself. Stand-ups have provided me with an excellent tool that I will use throughout my career.

As an English student, I was always told to keep my writing concise. Doing so was often easy because I could assume that the person reading my work would be an English scholar, so their expectations of my writing and the knowledge they brought to it would sit within a very specific range. In this way, I trained myself to default to an academic tone and level of complexity and to produce writing that was comparative and analytical.

This summer, however, as a member of the LINCS documentation team, I worked on an entirely different kind of writing: user guides and instruction manuals for the many software tools developed or employed by the project. To begin writing documentation, I first had to relearn how to write...

Writing instructions begins with simplicity. I thought that since I was a concise writer, I would be able to write simply and clearly, but when the first draft of step-by-step instructions for maintaining the LINCS documentation website was edited, I saw that my word count had been cut nearly in half. As I scrolled through pages of my writing, I saw that the entire intention had been flipped—not just a matter of simply swapping in synonyms, but a wholesale reworking of voice and perspective.

Explaining the process of creating a merge request, for example, I first wrote this wordy and personal paragraph:

To work on an issue, you will need to create a merge request. This will create a new “branch” on our GitLab repository, which will allow you to make and track any changes without affecting the main branch of the repository (and in turn, the website itself). Later, once you are happy with your changes, they can be added to the main branch so that they can be published to the documentation website.

Working with the documentation team to revise my first attempt, we started by recasting my draft to have an active tone. We removed excess statements like “make and track” and “in turn, the website itself,” making the whole section much shorter without compromising the quality of the information:

Create a merge request to work on an issue. This request will make a new branch in GitLab, allowing you to make changes without affecting the main repository. When your changes are complete and checked, they can be added to the main branch to be published on the documentation website.

We developed a style guide to help direct our choices, and while it helped to keep me within the lines for the most part, I still found it hard to suppress the English-student essay writer who had made his home deep in my brain. In a way, I found writing instructions far more challenging than writing an essay. I could no longer hide any lack of clear vision or shortcomings of understanding behind words that just sounded good. If there was no clear meaning, my writing fell apart.

When I began breaking the instructions down into sections and the sections into individual steps, I saw that it was easier to write simply. Yet, my instincts were still not quite right. I was still looking for ways to make the writing flow between sections. I imagined an audience who was following me from step to step, travelling through the tasks in the same order that I was: starting at the same place and ending with the same goal. What our style guide reminded me, however, was to view the writing from the audience’s perspective. Like me, my reader could be a beginner who was new to using a platform like GitLab, and who needed to know every step along the way. But equally, my reader could be a veteran user who forgot only one step and skipped straight to a specific subheading. Each tiny section therefore needed to function as an independent piece of documentation. I couldn’t assume that my reader would have read all of the preceding sections. In adhering to this principle, I found myself having to sometimes break one of my personal golden rules of writing: avoid repetition! This process—though it created writing that repeated information that had appeared in previous sections—was helping to make these tools usable to as many people as possible.

This repetition also signalled the variation in readers we needed to write for. From the earliest days of planning our documentation strategy, we sought to identify the imaginary audience for whom we were tailoring the complexity and technicality of each piece. As a field, Digital Humanities (DH) welcomes participation from those with a broad range of academic backgrounds and levels of technical expertise. We understood that we would need to cater to everyone from undergraduate arts students to experienced software developers, which meant assuming a basic level of technical ability but no more.

For my process as a writer, trying to meet the needs of such a diverse range of users meant taking another circular approach. I came to the tools I was documenting as a beginner, and as I familiarized myself with them to learn what needed to be documented, I became an expert. Then, I had to return to the role of the beginner (to the beginning of the circle), writing for someone who was new to the tool. I had to learn to use tools with which I was previously completely unfamiliar to the point of being able to write their instructions, and then immediately assume the position of my former self, who didn’t know the tools at all.

Thanks to my experience writing documentation, I now have not just a commitment to concision and simplicity, but an entirely different approach to writing. Writing documentation has pushed me to consider the audience’s point of view and to not be afraid to break some of my own writing rules. Writing in circles has taught me how to craft texts that are more accessible for my readers.

During my time at LINCS, the UX team has laid the groundwork for implementing an intuitive and effortless user flow for ResearchSpace. To accomplish this, we have conducted numerous user and usability tests, interviews, and card sorts.

Working on ResearchSpace was my first real experience in the world of UI/UX. It was also my first time working on a design team, and I was blown away by the talent of my peers... I enjoyed the challenge of learning new UX concepts and learning about the team’s design and user testing process. Evan Rees, for one, had amazing skill when it came to answering and asking questions during a user test without pushing any sort of bias or leading. For instance, instead of asking a user, “Does this make you feel frustrated?” when they were clearly frustrated, Evan would ask them, “How does this make you feel?” instead. Evan’s carefully worded question allowed the user to answer honestly without being pushed in a certain direction. Jordan Lum and Nem Brunell both taught me a lot about how to use Figma to organize my work and create components.

My previous experience in design had only taught me about creating something that would be visually pleasing. Working as a UX designer changed my perspective drastically. I learned to put myself in the shoes of the user—to try to understand what they would want out of a design. Adding in the new elements of usability and practicality elevated my design thinking skills drastically. For example, when I create designs now, I determine the mood I want the viewer to feel and then I choose colours, typography, and so on accordingly. Even as I go back to traditional design work after this work term, I will continue to think about how typography, colour choices, and text placement will be perceived by the viewer.

One challenge I faced while working as part of a UX and broader development team was learning to accept that my ideas may not always be practical enough for implementation. There were instances of me thinking I had come up with a design that would solve a user’s problems, only for it to be shot down in a second. For example, when the UX team was trying to solve the problem of hover-dependent icons on ResearchSpace cards for tablet users, I proposed a dropdown menu built into the entity card as a solution. However, if a dropdown menu had been implemented, all the cards on the screen would have had to move down the screen to make room, which would have been difficult to implement. The UX team ended up adding the icons on the bottom of the card without altering the card dimensions—a solution that could be implemented more practically! I have never taken these critiques personally and am happy to say that these experiences helped me develop my creative problem solving skills.

Working on the UX Design team was a rewarding experience that has already helped me land a design job for the upcoming fall and winter semester at the University of Guelph. I have had the pleasure of meeting so many talented people and I am beyond grateful that I had the opportunity to work at LINCS!

Over the past two years I’ve had chances to work on many aspects of the Orlando Project, but the work that I’ve consistently found the most engaging has been researching and writing author profiles. Orlando’s profiles are collaboratively authored scholarly histories, which are structured by a custom XML tagset, and which allow researchers to explore the intersections between women’s lives and their creative production. During my first summer as Digital Humanities (DH) Research Assistant, I began work on the profile on Lili Elbe; in the past year, I started writing a profile on Gurpreet Kaur Bhatti. As I put the finishing touches on these profiles, I’ve noticed that both women’s life stories highlight the overlap between the personal and the political, and between individual identity and the limits imposed on creative work...

On the surface, Lili Elbe and Gurpreet Kaur Bhatti differ vastly, both in terms of their experiences and the types of work they produced. Lili Elbe was a Danish painter and in the 1920s was one of the first trans women to receive gender confirmation surgery. She went on to write and publish From Man Into Woman—a text that has been described by the Lili Elbe Digital Archive as a life narrative—about her experience. This narrative is unconventional in its blurring of fact and fiction: it details real events, but these events are narrativized and intentionally obscured through the changing of names and the omission of particulars, such as certain medical details. By contrast, Gurpreet Kaur Bhatti is a contemporary British-Indian playwright whose work explores themes such as gender, class, social and cultural expectations, and the experiences of British South Asian immigrants. Yet, one thing ties them together: works by both of them have been subjected to attempts at censorship.

Shortly after Lili Elbe first secured a publication deal for her life narrative, an article calling the proposed book scandalous for its discussion of changing conceptions of gender appeared in a local newspaper. The negative publicity generated by this article led Elbe’s initial publisher to pull out of their deal. In response, Elbe published an article defending her book; through this act of resistance, she changed public perception and successfully secured a deal with a new publisher. Yet, the mark of censorship remains a subtle presence in the published narrative—a presence that is revealed through the omissions and alterations made in order to preserve Elbe’s image of respectability (as it was defined by the conventions that regulated gender performance and sexuality at the time). In From Man Into Woman, Elbe speaks about the intense anxiety she experienced when going out in public following the publication of the critical article, as well as the financial strain that the scandal put on her, as it made it nearly impossible for her to sell her paintings, which were then her sole source of income. Thus, it is not hard to imagine why she would have felt compelled to leave out of her narrative any details that might have subjected her to further public attack.

In her narrative, therefore, Elbe goes to great efforts to depict herself as conforming to the heterosexual “norm” following her transition—insisting that any romantic or sexual feelings for her wife Gerda ended with her transition. Yet, as Nerissa Gailey (2017) has observed in an article discussing historical constructions of trans identities, historical documents such as the lesbian erotica that Gerda painted using Elbe as a model blatantly contradict the heteronormativity claimed in Elbe’s life narrative. The clearest explanation for Elbe’s omission of this aspect of her identity is that while she successfully overcame attempts at complete censorship, the threat of scandal associated with her story shaped the degree to which she allowed her art to depict her true life and experiences. For example, in From Man Into Woman, Elbe explains that following surgery, she distanced herself from Gerda to prevent acquaintances from connecting Elbe with her pre-transition identity. She also describes how she petitioned the Danish King to declare her marriage to Gerda invalid out of a desire to “free” Gerda, which would permit Gerda to live a full life (thus implying that a full life is inherently heterosexual). Yet, Elbe also writes that she maintained a lifelong loving friendship with Gerda.

Of course, it’s impossible to know what Elbe’s true reason for distancing herself from Gerda was, but reading between the lines offers some insight into why Elbe might have told an altered version of her story. In From Man Into Woman, she frequently expresses her belief that her story could be a valuable educational resource for the medical community, and for others with identities similar to her own. Considered in this light, Elbe’s desire to separate herself from Gerda, and by extension her past identity, makes sense: this separation would help to ensure that her identity was taken seriously, allowing her story to have the positive impact she desired. Furthermore, Elbe’s insistence that she wanted Gerda to be free to live a full life—in combination with the women’s continued friendship following their divorce—suggests Elbe’s deep, unselfish love for Gerda. It is quite possible that Elbe’s choice to depict their relationship as platonic in her narrative stemmed from her love for Gerda and her desire to shield Gerda from the sort of persecution that Elbe knew she would face if their relationship appeared in any way subversive.

A similar pattern of censorship and resistance appears in the reaction to Gurpreet Kaur Bhatti’s play Behzti (Dishonour) and her response to the criticism she received. Bhatti’s play centres on a sexual assault that occurs in a Gurdwara (a Sikh temple) and is committed by a Gurdwara official. Bhatti’s decision to set this act of violence in a Gurdwara was criticized by members of the Sikh community, who organized protests outside of the Birmingham Repertory theatre, where the play was being staged. These protests began as peaceful but quickly escalated to violence. Following one particularly violent night of protest during which protesters broke into the theatre and interrupted the play, the theatre decided to cancel the remaining performances. Just as Elbe published an article when her book contract was cancelled, Bhatti (2005) published an article that pushed back against the censorship she faced. She defended her right, as a Sikh woman, to speak honestly and thoughtfully about issues in the Sikh community. Other writers (Patel, Bakewell, & Adams, 2004) responded in support of Bhatti, publishing statements about the importance of free speech, and Bhatti recovered from the event. She went on to write many other successful plays (including Behud [Beyond Belief], which fictionalizes the Behzti controversy), and subsequently won the Susan Smith Blackburn Prize for Behzti. Yet, none of these triumphs change the fact that the initial run of performances for Behzti was shut down prematurely. In the moment of the play’s shutdown, there was nothing Bhatti could do to combat the censorship being enacted upon her. Bhatti’s experience, much like Elbe’s, demonstrates the fine line between succumbing to and overcoming creative suppression.

Evidently, both Elbe and Bhatti tested the limits of what was deemed acceptable to discuss in their respective times and environments, and in doing so they risked the suppression of their work. Each of them responded by creating something new out of the censorship they faced, and in doing so, they added additional layers of meaning to their messages. However, it is interesting to note that the value of work changes within different contexts. In the context of Orlando, it is the very subversiveness of Elbe’s and Bhatti’s work that makes their work so valuable. A simple Google search on Bhatti reveals that her best-known play by far is Behzti. Essentially all of the results that come up in a search on her name mention the Behzti controversy, and with a little bit of reading it swiftly becomes apparent that it was this very controversy—and the strength and resistance with which she reacted to it—that brought her work the level of visibility that it has today. If it weren’t for the public outcry stirred up by her insistence on the necessity of pushing boundaries, it’s possible that Bhatti never would have gained the attention needed to be included in Orlando. Likewise, it is the controversial nature of the subject matter that Elbe wrote on that makes From Man Into Woman an invaluable historical resource. The fact that Elbe dared to test the boundaries of what could acceptably be written about means that she has provided us insight into early conceptualizations of trans identities, early trans experiences with the medical system, and the changing ideas of gender that inspired the development of gender confirmation surgeries. It is this insight that makes Elbe’s profile an essential part of Orlando. The tradeoff of personal security and stability that both Elbe and Bhatti made in order to write meaningful, boundary-defying work should not be taken lightly, but it is deeply valued and respected by Orlando.

Working on both of the Elbe and Bhatti profiles made me think about the power and importance of projects like Orlando, which, rather than separating writers’ lives from their creative work as if they were distinct and unrelated concerns, draw attention to the ways that personal identity and experience are woven into the fabric of creative production. Public responses to creative work (including violence and efforts at suppression) can only be fully understood within the context of a writer’s life and identity and the socio-political climate in which they lived. Understanding this interconnectedness is a pursuit that, to me, seems vitally important. By calling attention to the real-world concerns that impact what is and is not allowed to be expressed in art, we assure that the aspects of creative works that censorship has sought to erase are celebrated for their boundary-defying subversiveness.

Works Cited​

Bhatti, Gurpreet Kaur. “This Warrior is Fighting On.” Guardian. January 13, 2005. https://www.theguardian.com/stage/2005/jan/13/theatre.religion.

Gailey, Nerissa. “Strange Bedfellows: Anachronisms, Identity Politics, and the Queer Case of Trans.” Journal of Homosexuality 64, no. 12 (2017): 1713–1730. https://doi.org/10.1080/00918369.2016.1265355.

Patel, Pragna, Joan Bakewell, and John Adams. Violence Must be Exposed.” Guardian. December 27, 2004. https://www.theguardian.com/world/2004/dec/27/religion.uk.

During my graduate courses in the Faculty of Information at the University of Toronto, I gained a high-level understanding of Linked Open Data (LOD) and the CIDOC CRM ontology, a theoretical and practical tool for information integration in the field of cultural heritage. Because I am an Archives & Records Management student, I never expected to understand LOD and CIDOC CRM to a significant degree, and certainly not to the degree that my position as a Metadata Specialist co-op at LINCS requires of me...

LINCS takes Canadian humanities researchers’ data and transforms it into LOD. Structurally, we transform it using the CIDOC CRM ontology. After the researchers’ data has been cleaned and mapping patterns have been approved, the data is transformed using an open-source tool called 3M, the Mapping Memory Manager. My primary role at LINCS is to set up and run these transformations. To do this, not only did I have to gain a deeper understanding of LOD, I also had to learn CIDOC CRM and 3M.

The training process took almost a month, twice as long as my fellow summer student hires spent on training for their respective roles. I spent half of the month digesting readings and the other half battling 3M. Taking in so much knowledge within such a short time frame was sometimes overwhelming, but even though I finished my workday feeling like my skull had been cracked open by a gaggle of drunk monkeys performing brain surgery, I loved it. I love learning! Always have. And now I’m getting paid to learn? I’m getting paid to acquire this extremely technically and conceptually difficult skill set? I’m getting paid to think about the theoretical quagmire of whether an action is an addition to a previous production event, or whether it is—in fact—an entirely new production event, and how the distinction between these two things comes down to the intent of the data itself? What a wonder, what a privilege! I haven’t taken notes this detailed since first-year undergrad.

Thanks to a training assignment, by the end of the third week I understood the CIDOC CRM well enough to explain how entities and properties related to each other, and I felt comfortable navigating the scope notes of the latest stable version. When given a mapping pattern and source data, I could manually write out a representation of the data following the CRM using Turtle syntax. Of course, doing this manually for thousands upon thousands of entities would be a highly impractical endeavour, which is where 3M comes in. If I could set up the mapping in 3M, then it would apply the CRM ontology and write the Turtle file for me. The trouble, of course, was setting it up. I remember being disoriented the first time I saw 3M, partly because it looked very much like early internet software and partly because the manual used extremely technical language. I had to make sense of how the matching table (which assigned CRM classes and properties to elements in the source data) related to a generator (which assigned Uniform Resource Identifiers (URIs) and rdfs:labels to entities), how to use the generator to create temporary LINCS URIs or to direct it to a pre-existing URI, how to write a generator file so I could get the appropriate custom labels, and more. It was frustrating at times, but the frustrations only made the successes all the more satisfying. When I uploaded the input and target schema files correctly, when I used a variable for the first time, when I pressed “Transform” and there weren’t any errors, all these successes made me feel like a level 20 tech wizard.

A high-level view of CIDOC CRM.

Looking back, the first dataset I transformed for LINCS, the Map of Early Modern London (MoEML) Personography, was incredibly straightforward compared to the datasets I’m currently transforming. Nonetheless, I still feel immense fondness for it as my first transformation, not to mention deep gratitude to Erin Canning (Ontology Systems Analyst) and Natalie Hervieux (Senior IT Analyst) for helping me through the process. In fact, now transforming data in 3M is one of my favourite parts of my job. I can spend hours in 3M fixing errors, making edits, and chasing the thrill of finally getting things to work. It is all the more gratifying to know that the work that I’m doing will benefit others in a tangible way. I’m doing this work so that other people, whether it be researchers or other members of the LINCS team, can copy my mappings or build off of them, can use my documentation to create their own mappings or review datasets, can conduct research and find new connections in their work thanks to the data I transformed. I learned something difficult, so that it will be easier for others!

3M is a beast and I have conquered it. Sort of. The thing about learning is that it is a continuous process. One of my former bosses told me that, and I nodded along because I desperately wanted to chomp down on one of the croissants he had brought in; half-listening to his career advice seemed to be the prerequisite for acquiring the pastries, but my teenage self should have listened in earnest because he was right. Every day I learn something new about 3M or CIDOC CRM. Every day there’s something else to tweak, some alternative perspective to consider. When I attended the 2022 LD4 Conference on Linked Data, I had the pleasure of listening to LOD professionals discuss problems that I had never considered before, that I didn’t even know were problems requiring solutions. It was eye opening and invigorating to learn that, despite all the knowledge I have acquired so far, it is only a small slice of what there is to know. There are innovative applications, organizations, and people out there doing things I can’t even imagine. Linked Open Data is an exciting, ever-evolving field, and I cannot wait to see what I learn next.

The Digital Humanities (DH) was not something I had a lot of experience with before starting as a LINCS undergraduate research assistant. My work with LINCS pertains to the Early Modern London project, working alongside the Map of Early Modern London (MoEML) team. Part of my job is what LINCS refers to as entity matching, or what MoEML refers to as disambiguation...

I am given a person from MoEML’s Historical Personography—a list of figures referenced in historical documents from Early Modern England. The personography entries for these people are largely derived from references in John Stow’s A Survey of London, specifically the versions published in 1598 and 1633. I am tasked with matching these people to entries for them in places on the internet like Wikipedia, Wikidata, or the Oxford Dictionary of National Biography. This is done to aid the enhancement of a virtual map of Early Modern London, which shows how London’s spaces were used and reused in the sixteenth and seventeenth centuries. More than just mapping places in London, MoEML plots people, historical documents, literature, and more onto the topography of Early Modern London to show how they relate through that environment. My work involves finding links online for those people mentioned in historical documents from the period, so that we may have a better understanding of the time and place of Early Modern London.

The difficulty of this work is that I’m working off of what John Stow’s A Survey of London, first published in 1598, tells me. That can be a lot or very little depending on the person. Some entries tell me the titles these people hold, when they were born and when they died, what offices they may have held, where they were buried, what relatives they had, etc. Some entries say nothing more than their surname. It was quite easy to find a match for St. Francis of Assisi. It was impossible to find a match for Mistress Dane, benefactor of the poor. With information on some of these people being scarce, it can be a challenge to find a match if I can find one at all.

Another problem is that sometimes the little information provided by Stow is outright misleading. While doing reconciliation for one Richard of Cornwall, it turned out that he had two separate personography entries on MoEML. The problem stems from the fact that in A Survey of London, Stow refers to Richard differently. In the “Downgate Ward” section of A Survey of London, Stow cites him as “Richarde Earle of Cornwell, king of Almaine.” In the “Liberties of the Duchy of Lancaster” section, however, he is mentioned as “Richard king of Romaines.” What could explain this discrepancy in Stow?

The seal of Richard of Cornwall. The inscription reads: RICARDUS DEI GRATIA ROMANORUM REX SEMPER AUGUSTUS ("Richard by the grace of God King of the Romans ever august").

Richard Plantagenet, Earl of Cornwall (1209–1272) was the second son of King John I of England (1166-1216). Using his vast wealth and powerful connections, he bribed and cajoled his way into getting four of the seven prince-electors of the Holy Roman Empire in 1257 to elect him Rex Romanorum, King of the Romans. This was the title granted to the rulers of the Holy Roman Empire who had not yet been crowned Holy Roman Emperor. Only the Pope had the ability to crown the Holy Roman Emperor, before that requirement was abolished in 1508. Prior to that time, it was not uncommon for the elected ruler of the Holy Roman Empire to not officially be invested Holy Roman Emperor, and Cornwall was among them, as he passed away in 1272 before he could receive the imperial regalia. This is why Stow labelled him “king of Romaines,” but what about this “king of Almaine” business?

Those titles, King of the Romans and Holy Roman Emperor, are potentially misleading to those unfamiliar. The Holy Roman Empire governed what is largely now Germany, not Rome as one may guess. This had led some scholars to refer to those titles as the Emperor or King of Germany, so as to not confuse it with the old Roman Kingdom, which lasted from approximately 753 to 509 BCE. This is where the “King of Almaine” comes from. The Alemanni were a group of Germanic people who settled in what is now Germany after the fall of the Western Roman Empire. The region they settled, and later Germany as a whole, were referred to in Latin as Alamannia. This informs the Old French term for Germany, Alemaigne. That word was brought to England after the Norman Conquest of 1066, rendered as Allemaine or Almaine in Anglo-Norman. Almaine became a popular way to refer to the region of Germany in Middle English. Eventually Almain fell out of use in English, being replaced with the term Germany.

So, we know why the problem exists and can potentially combine those two MoEML entries into one. But if they are combined, what do we call him: King of the Romans, King of Almaine, or maybe King of Germany? As I said before, King of the Romans can be a confusing term, even if it was the official title. The problem with both King of Almaine and King of Germany is the title never was either of these. The king may have ruled over the geographic area of Germany, but it was never called the Kingdom of Germany. Also, that title could easily be confused with the Kingdom of East Francia, lasting from 843 to 962, which was occasionally referred to as the Kingdom of Germany by later scholars; or with the later German Empire, which lasted from 1871 to 1918.

When I finally figured out the problem, I forwarded this information to MoEML, telling them about the duplicate entries and the problematic terminology. For the former, they made a note of it. For the latter? Rather than choose one name over another for Cornwall’s entry, or attempting to manage the problems with calling him King of Germany or King of Almaine or King of the Romans, they simply removed the reference to Cornwall’s kingship in his entry. You know what they say: if you can’t win, don’t play!

If each part of a ship were replaced over time, when, if ever, does it become a new ship?

Little did Heraclitus, Plato, and others know that the problems posed by the “Ship of Theseus” paradox would continue to vex digital humanists in the twenty-first century...

During my MLIS co-op at LINCS I contributed to a vocabulary that aligned the place types of REED London Online (REED), Map of Early Modern London (MoEML), and The Digital Ark (Ark). To complete this task, we first needed to determine how each researcher represented place within their data.

Having worked for MoEML during and after my undergraduate degree, I knew this process would not be simple. Digital Humanities (DH) scholars use digital tools and technologies to study human society and culture from a critical perspective. Research questions are nuanced, which creates a complicated—albeit compelling—tension between the ambiguities of the humanities and the explicit systems and rules necessitated by technology. This tension results in a dilemma: digital humanists have to navigate the biases and values embedded in software, algorithms, and encoding standards to make sure the nuance and detail in their research is not being unfairly simplified.

My favourite example of this tension is the debate between function and structure: in a dataset, should a single location be represented as multiple entities if its function or structure changes? During the early modern period, the site of the Charterhouse assumed many functions: at various times, it was a burial ground for plague victims, a Carthusian monastery, a royal residence, a hospital, a school, and a pensioners’ home. Is Charterhouse, the monastery, the same place as Charterhouse, the pensioners’ home? What about structure: the timber from the 1576 Theatre was used to construct the 1599 Globe. In 1613, this Globe burnt down and a new Globe was constructed. Other places, such as Somerset House, underwent extensive renovations during the early modern period, not to mention that thousands of buildings—including St Paul’s Cathedral—were partially or fully destroyed in the 1666 Great Fire of London.

Making a claim that one location is the same as another is not straightforward. It often depends on a project’s underlying assumptions, research questions, and scholarly goals. This task becomes even more complicated when pulling together multiple projects, each with their own objectives, but all referring to the same places.

In the vocabulary we developed with REED, MoEML, and Ark, we decided to divide places into four broad categories: Administrative Unit, Structural Place, Functional Place, and Topographical Feature. In doing so, we were able to distinguish places we believed to be primarily defined via their structure—for example, bridges, gates, and roads—from those primarily defined via their function—for example, prisons, churches, and playhouses. Below is a visualization of the vocabulary we developed.

“Place types in early modern London” vocabulary developed in conjunction with REED London Online (REED), Map of Early Modern London (MoEML), and The Digital Ark (Ark). Declared in SKOS and visualized in SKOS Play.

Nevertheless, some edge cases defy simple categorization. For example, Newgate is both a gate (Structural Place) and a prison (Functional Place). London Bridge is a bridge (Structural Place), but could also be considered a place of commerce (Functional Place) because it was home to hundreds of shops during the early modern period.

The lack of a one-size-fits-all solution is not necessarily a bad thing. Contemplating edge cases with the researchers led to productive discussions about how to represent nuance while adhering to the structure imposed by the vocabulary. Most importantly, the creation of the vocabulary helped the researchers rethink how they were categorizing and labeling places within their datasets.

While our vocabulary is yet to be applied to the datasets, it will be integral to facilitating the interoperability and specificity of data categorization. Most importantly, its application will lead to more analysis—and if this analysis is anything like our previous work, it will be complicated, nuanced, and exciting.

My first job in the museums field was in 2008, right at the height of the Great Recession. The digitization team I joined had just lost roughly a quarter of their staff in a series of buyouts and layoffs, and the mood was grim. We were tasked with getting a large collection of historic photographs online, and the sooner the better—the only rub was that the collection wasn’t fully catalogued, and doing so properly would take time that we did not have. The pressure was on to justify our jobs, and so the discussions we had about metadata leaned towards the provisional. If the database is unpopulated, does just the accession number suffice? Okay, what about the accession number and artist? The solutions we came up with reflected the stressors of that moment: we aimed for something good enough in lieu of something exemplary, carefully balancing data requirements with the drive to generate content.

For the next decade and a half or so, Winnicott’s “good enough” parent has been a guiding principle in my role as a data custodian... I have been a “good enough” cataloguer at a number of different institutions, only ever providing my database the simplest of things: where it is, who it’s by, who gave it to us, and whether it will fit in our freight elevator. I have been a “good enough” digital curator when it comes to sharing collections material online, giving only the metadata required to make our digital assets usable for local contexts.

Working at LINCS has been a major paradigm shift for me professionally, not least because “good enough” is a different benchmark in this new context. I’m currently a Metadata Specialist, assisting LINCS Ontology System Analyst Erin Canning in generating documentation for some of our partners in this project, focusing on the Canadian Centre for Ethnomusicology, HistSex.org, the Yellow Nineties Personography, and the University of Saskatchewan Art Gallery. For each of these, I’ve been responsible for generating TTL code snippets and diagrams that describe how data will be mapped into our triplestore using CIDOC CRM and FRBRoo, which extends the CRM to capture the underlying semantics of bibliographic information.

These diagrams and snippets form part of our application profiles—one umbrella profile that captures the LINCS project as a whole, and one for each of the datasets that LINCS comprises. These bring together ontology patterns, our metadata elements drawn from multiple namespaces, policies and guidelines related to their use, decisions we’ve made that deviate from community standards in order to accurately capture the nuances of our dataset, and other decisions relating to the data target we’re working towards. The application profile is a living document that enables communications between researchers, ontology specialists, data interface developers, and others, but it also provides a trail of breadcrumbs for other organizations that might be interested in replicating how we’ve mapped, ingested, and federated so many divergent cultural datasets into ResearchSpace. Documenting everything so completely requires a great deal of care and attention to detail, but that’s the point: while in some projects it might be good enough for someone to infer some unspecified detail from scanty documentation, or to phone a person and ask them what they intended, in this case, good enough documentation allows a project like ours to have an impact long after the grant funds have been spent and the final reports are filed. To be not only sustainable, but replicable, we need to take the time to document things now. In this sense, we’re attentive to both data and content: neither takes precedence over the other.

There is a kind of satisfaction that comes from doing something very well. While I’m happy to take part in any activity that eases communication over a large, geographically dispersed team, I also like the idea of casting breadcrumbs behind us as we go. Linked Open Data has yet to reach its full utility in the cultural realm, and I’m looking forward to the day when I can query a museum database to determine not only whether an artwork fits in an elevator, but more complex questions that reflect the kind of inferencing possible with semantic data. It’s exciting to know that what we’re doing might inspire others to follow—and that the documents there are good enough to guide their path.

The situation is this: you’ve been asked to design a way for a researcher to easily move between two tools. You familiarize yourself with both tools, learn about the known issues, and read about what’s already been tried. You spend a few days deciding on the best way to get from point A to point B. You spend a few more days designing how it will look. Finally, you unveil your prototype in a meeting with the development team ... only to find out that moving between the tools is not technically possible. Or that it would take too long to build your design. Or that moving between tools opens up new issues on the back end.

How do you go forward? ...

LINCS’s User Experience (UX) team is a collection of designers and developers who work in tandem to make using LINCS tools smoother for users, working on wide-ranging topics like system structures, improving access, or usability testing. The team meets twice weekly to prevent situations like the above. By connecting often, the team is able to keep up to date on what everyone is working on and can then weigh in on the positives and potential challenges of each others’ projects.

Robin Bergart, UX Librarian at the University of Guelph, has been with LINCS since April 2021. She considers the UX meetings essential. “Different people with different skills will bring different observations. It’s surprising when they see things you haven’t.” When developers and designers share their plans and are generous with their skills, they’re able to make sure that changes are possible (and desired!) before any one team member spends hours on something that is not likely to work.

Dawson MacPhee, who has been working as a developer with LINCS since May 2021, enjoys using his technical knowledge to help the UX team make informed design choices. Being involved in design also keeps him engaged: “If I were building an interface and wasn’t allowed to contribute to the design, it’d be harder to find interest and motivation.”

UX meetings are not without their challenges, however. The gap between what designers may want to do and what developers are able to do can be difficult to bridge. Justifying why they are saying no to a proposed design can be hard for developers: “It’s a challenge to convince the group that something wouldn’t be worth our time,” says Dawson. “It can be a challenge to find the right words for things in non-technical terms.”

A project of any scale benefits when its participants come together to share their knowledge and resources. “We’re able to have more thoughtful interactions ... because we have a shared context,” says Alliyya Mo, a developer with LINCS since May 2020. “Still, missing context sometimes leads to misunderstandings. But by getting to a shared consensus with the language we use, we can better communicate ideas, leading to a better product.”

The UX team brings its diverse strengths to work on many parts of a complex whole—meeting as a group not only allows us to combine our skills to create better tools for LINCS, but it also allows us to bring what we’ve learned back to our individual work.

By working together, the situation above turns from a design failure to a collaborative opportunity. Bringing the project to the team at an earlier stage opens the discussion up to learning about the limitations of a design so we can learn about new options, not stop in our tracks. We are able to make stronger, more informed design choices by recognizing the process as something we all are a part of. By having a space to share with and learn from each other, we are able to make sure that everyone has a hand in the work and the understanding needed to develop something meaningful.

The road to UX for me has been long and winding, and I, much like the LINCS users in the Tube Map in Figma, have found myself at various stations along the way, assessing where I should go next. Initially studying Life Sciences at University of Toronto, I made the switch after first year to a specialism in Sociocultural Anthropology. Upon graduation and unsure where to go with my career, I began a Masters of Public and International Affairs at University of Ottawa. I quickly realised that I was too passive by nature to be a diplomat, and I lacked the passion for politics that many in my cohort shared. What I really wanted was something related to my background in Anthropology.

And so, enter UofT’s Faculty of Information... I wanted to study at University of Toronto again, and attended an information session for their Culture and Technology concentration. Because I could attend two sessions the same day, I also attended the one for UXD. In the first five minutes, the professor mentioned that many Anthropology students pursue UXD due to the need for ethnographic skills and interviewing users to assess needs for interfaces. I was sold.

LINCS has been my second placement as a UX specialist. My interest in UX is multifaceted, but in large part I want to be able to contribute to something meaningful by applying my background in humanities and by using empathy to create products that are accessible, diverse, and broad in scope. Working at LINCS has allowed me to do all of these. Creating interfaces for working with the Semantic Web means trying to understand how researchers think and feel—and how they want their work to be used. Coming from a humanities background, LINCS has felt like home for me, as it has allowed me to put myself in the user’s shoes more than I had imagined.

My time at LINCS has been focused on ResearchSpace. I have been looking at ResearchSpace through an analytical, UX lens, finding possible pain points that users will encounter as they navigate through the tool and create the connections between datasets. In determining these pain points, I have taken into account the cohesion of the navigation, the clarity of the language used, the colour scheme as it relates to AODA standards, and whether sections that perform similar tasks could be aggregated.

Working with ResearchSpace, I also created prototype mockups of timelines for viewing events such as births and deaths, creation of artefacts, founding of groups, and so on.

I used Figma to create mockups that pulled together and built upon the best features of other timelines that the team and I had looked at. The best part of this process was seeing prototypes I had created come to life!

I am currently working on creating step-by-step scenarios based on the LINCS Tube Map created by a previous UX co-op, Sana Javeed. This map will help the development team determine LINCS’s ideal users, and will provide the team—and eventually the interface’s users—with a depiction of the pathways as users navigate between the LINCS tools.

Reflecting on my placement at LINCS, I have developed my skills as both a UX designer and as a researcher, learned about the back-end elements of making designs into functioning tools, and benefited from collaborating with a research team. Taken together, all of my experiences are part of working towards a more accessible Web for all researchers to use—and of creating even more roads for researchers to follow.

I joined the LINCS Project as an undergraduate research assistant, mainly to work on the Orlando Project. This position gave me my first real experience with Digital Humanities (DH). Before starting the job I could barely have come up with even a vague definition of DH (despite my best efforts and quite a bit of Googling). When I finally did start to get a sense of the nature of DH—a field that brings together humanities research and new technologies, birthing new possibilities and adding depth to research—there were elements of it that felt very familiar and in line with the sort of work I had experience with as an undergraduate student majoring in English... after all, there was little difference between wading into primary sources and digging through databases while researching a paper for an English class, and doing the same for a DH project. There were other aspects though (mainly on the digital side of things) that felt rather foreign.

Much of my work for the Orlando Project involves researching, writing, and tagging author profiles. While I was at first daunted by the prospect of learning the XML schema that is used to tag them, the research and writing was familiar enough to give me the sense that I hadn’t strayed too far from my comfort zone. As I began reading through existing Orlando profiles, and eventually started to write my own profile for the author Lili Elbe (forthcoming), I soon realized that Orlando’s markup is intuitive. I also began to appreciate the ways that thinking about Orlando’s schema helped me to structure my ideas. I realized that the rules of Orlando’s schema are not unlike the rules that structure the English language. In both cases, structure is simultaneously a framework, and a challenge—it constrains communication, yet it is these very constraints that produce meaning and order. When I began to understand this parallel, I dipped a toe into the digital side of DH and found that the water was not unwelcoming. At the same time, however, I was aware that I had only just skimmed the surface.

From the moment I got a glimpse into the world of DH, and more specifically, into the many interrelated projects that make up the LINCS Project (a project that seeks to create infrastructure in order to meaningfully represent the interconnectedness of cultural data on the web), I was acutely aware of just how much there was that I didn’t know. At first, I was content to simply figure out the things I needed to know in order to do my assigned tasks. I focused on my work and took pleasure in the beauty of being a part of a project that brings together an array of people with different knowledge and skill sets. I listened to other people’s conversations about developing the CWRC ontology, or about using SPARQL queries to find images on Wikipedia for authors who have entries in the Orlando textbase, and I was delighted to discover that one project could have so many unique components. After being surrounded by these conversations for a while though, what was once appreciation began to transform into curiosity.

The more I heard the same unfamiliar words and acronyms, the less unfamiliar they began to sound. The less unfamiliar they sounded, the more I wanted to understand them. Eventually I started to consider the possibility that if the parts of my work that had once seemed daunting had turned out to be so intuitive and enjoyable, then maybe it would be easier than I thought to learn about other things that initially seemed far outside of the realm of my skill set. This is how I ended up joining a SPARQL learning group, and began to craft queries alongside coworkers who know much more about computers than I do.

I used to find the thought of learning a language used exclusively by computers completely unappealing. I associated the language of computers with numbers and math—things that have consistently sent me running. Yet, as I’ve begun to learn SPARQL, I’ve discovered that query languages have nothing to do with math and everything to do with structure, logic, and figuring out the right way to ask the right questions. This was a revelation to me, because these are precisely the sorts of things that I love about the writing and research work that I’m accustomed to doing as an English major. I love the moment at the start of a research project when you have to sit down and figure out what questions you have about a topic, and then break those questions down into their essential parts to get at the essence of what you need to know about the topic. More than that, I love the “aha!” moment that occurs when you find the right language to express the questions you’re seeking to answer. Creating SPARQL queries has been full of those moments. SPARQL amplifies the necessity of precise questions and precise language, because query services only understand specific vocabularies in certain structures. Thus, learning SPARQL has been an exercise in finding the right words to ask my questions, and learning to adapt those questions to fit the structure of the query language while still maintaining the question’s essence.

For example, when crafting a query to find all of the women who have lit the Olympic flame, I discovered that this same question can be asked in either a way that centres the Olympic games, or in a way that centres the act of lighting the torch. Both of these queries are forms of the same question, and they both returned relevant data, but because of the way that Wikidata labels are applied, the data each query returned was different. This is the part of creating SPARQL queries that intrigued me the most. Just as is the case when beginning a research paper, when crafting a SPARQL query, there is value in finding different ways to ask the same question, and in finding different perspectives through which to examine the same problems. It is the necessity of asking the right sorts of questions when working with SPARQL that reminds me that “computer” languages are fundamentally human languages. Stubbornly pursuing an answer by asking the same question in different ways over and over until it at last yields useful results is a fundamentally human endeavour. In fact, this persistent need to question the very questions you are asking, and in doing so, produce opportunities for paradigm shifts, has always seemed to me like a vital part of the humanities. It is the very thing that drew me to the humanities.

I may still be in the very beginning stages of learning SPARQL, but I already see that I would have done myself a disservice if I assumed it was out of the realm of things I’m capable of, or have the potential to be passionate about, learning. While SPARQL at first seemed different from the type of work I’m accustomed to, in actuality it requires the type of thinking that I enjoy the most. It necessitates flexible thinking, and a constant awareness of small details, which may at first seem insignificant, but can prove to be vital. Throughout my intellectual life, I have consistently been drawn to literary studies because of the way that a single word or sentence can contain so much meaning. I am fascinated by the way that a few sentences have the potential to shift my entire analysis of a novel. I found the same sort of joy in working on Orlando, as I realized how a chance meeting with another author, or a small shift in economic resources can alter the entire course of a woman writer’s life. Now I’ve discovered the joy of small details yet again in SPARQL as I explore the way that the labels I use to build my query determine the data I will be returned as an answer to my questions. If I had not been a part of a DH project, I likely would have never heard of SPARQL, never mind begun to learn it, and discover the parallels that can be drawn between it and my other work. This is the beauty of DH—when different disciplines are brought together into one place, it creates new opportunities to expand your understanding and to re-think and test the limits of your comfort zone.