A suggestion that I submitted to the roxygen2 project for R has been implemented, allowing the use of all "MARC Relator" codes when describing authors' roles in a project.
When creating an R package,A "package" in R is similar to an “add-on” or “extension” in a web browser such as Mozilla Firefox or Google Chrome -- it is freely available, can be installed by a user, and adds or makes easier new functionality for the base program. For information on R packaging, including this topic specifically, see Hadley Wickham's excellent and freely-available book on the topic.participants' contributions are listed through standardized codes. For example, authors are noted using the code aut, package creators with the code cre, funders with the code fnd, etc. Previously, roxygen2, which is widely used to facilitate creating R packages, understood 10 roles: author, compiler, contributor, copyright holder, creator, contractor, data contributor, thesis advisor, translator, and funder.
With this new change, roxygen2 will now accept all codes in the "MARC Relator" list, a standardized collection of almost 300 different project roles into which individuals can be classified (for any type of project). This will allow giving credit more specifically where it's due, including, for example, to:
Consultants to a project (csp)
Allowing use of all MARC roles also follows Allen, Scott, Brand, Hlava, and Altman's (2014) call in Nature to assign credit more broadly and accurately, by allowing authors to use codes that map well onto Allen et al.'s proposed taxonomy of credit.
This is a minor update, but I think that its utility will be large. I'm grateful for the roxygen2 team's consideration of it!
Often celebrated and criticized as the next big thing in humanist research and teaching, “the digital humanities” get a lot of press for shaking up the way things are done. But is “dh” a continuation of some of the most “traditional” scholarly work in the humanities: bibliography, textual criticism, and book history? This conference, convened by the Center for the History of Print and Digital Culture at the University of Wisconsin-Madison, aims to study how digital humanities grows out book history, how “bh” and “dh” continue to be mutually informative and generative, and how they also contradict each other.
veccompare (Vector Compare) is a package for R that I've authored in consultation and collaboration with Heather Wacha, Dr. Wacha and I are both CLIR postdoctoral fellows, she at the University of Wisconsin–Madison, and I at the University of Pennsylvania. particularly to help to automate the process of analyzing medieval maps. It is also the first R package I've written.
The latest development version is also available, via GitHub.
On August 31st, I gave a new presentation at the Wharton School for University of Pennsylvania staff. I called the presentation, "Some Thoughts on Non-Psychometric Survey Design, Or, Creating Surveys that Measure what you Actually Want to Measure." By "non-psychometric," I explained to the attendees, I meant survey design that isn't going to include validation steps or other psychometrics Psychometrics is the subfield of Psychology (and especially Personality Psychology) that deals with measure creation. tools -- put differently, survey design for authors who are not interested in making a "validated" measure, but who would still like to take lessons from professional psychometricians.
Title: Creating Surveys that Measure what you Actually Want to Measure
People are often poor participants in research. They are inconsistent (e.g., reading questions differently than a survey author intended), complex (e.g., refusing to distill their thoughts about a topic into the one specific aspect a researcher is trying to measure), and biased (e.g., answering either to impress or to spite a researcher).
Unfortunately, people are also often poor authors of research surveys. They write items that are inconsistent (e.g., worded differently throughout a survey in a way that fatigues respondents), complex (e.g., asking multiple questions as part of a single item), and biased (e.g., leading a participant toward a particular response).
This workshop will address the latter in the hope of minimizing the effects of the former.
Topics we will cover:
Why people are bad at answering survey questions (impression management, being affected by moment-to-moment circumstances, different people having different baseline responses, and more!)
Types of responses (covering topics like this: https://www.qualtrics.com/blog/optimal-scale-labels-why-they-matter/)
What does "measuring" psychological traits mean? What is a "valid" measure?
What makes for a "good" survey item?
Creating surveys using Qualtrics (https://upenn.qualtrics.com) (High-level overview of Qualtrics' interface and functionality)
(If we have time and there's interest) Advanced features of Qualtrics, which could include:
Complex survey flows
Using Qualtrics' API (using as an example some code I released several years ago for showing users customized graphs of their responses vs. the average response)
This is a small tip, but it took me four years of active thinking to come to it. I started using it two years ago, just before I authored Markdown Mapper. Markdown Mapper is an R script for reverse-engineering network maps from notes written in Markdown format, incorporating the hierarchical structure of outlines, metadata about the notes, and tags (like #hashtags) in the notes' text.
When I started my graduate career (which I recently concluded), I struggled to find a way to sustainably incorporate handwritten notes from meetings, classes, and brainstorming sessions with typed notes that I would alternatively create on those same types of occasions. Inevitably, my handwritten notes, lacking a coherent indexing strategy, would become forgotten or remain unconsidered as I reviewed the notes that I had typed.
My answer to this: Rather than focusing on constructing an index per se of my handwritten notes, I now just "tag" the notes. I follow this approach when taking handwritten notes (including, and especially, in mindmap format):
Rather than using #hashtags, I double-underline any word or phrase I want to "tag" in my notes.
Periodically, I digitize (i.e., save a digital copy of) my handwritten notebook.I most recently digitized a notebook by placing it on a tabletop, taking a photograph of each page, and sending it to Voussoir, as I described here. Just photographing each page with a camera or camera-phone can alternatively work well. Digitizing periodically also allows less worry about losing the physical notebook, because the notebook is "backed up" in a workflow like this. I save the photographs (either separately or combined as a PDF) alongside my typed notes.
Once per week (or month, etc.), for each page of un-processed handwritten notes, I type the title of that page, the date, and a list of the double-underlined "tags" from that page. I save this list alongside my typed notes.
At this point, I have a computer-searchable index of my handwritten notes alongside my computer-searchable typed notes. The full directory of notes files can be searched together, combined, etc. The presence of the digitized copy of the handwritten notebook allows looking up any page of notes regardless of whether the original, physical notebook is available.
For me, the utility of this approach is that the index arises naturally out of the text I write, and that the indexing process (typing up the "tags") can happen as frequently or infrequently as my projects require.