20 November 2015

Peer-Review and Publication of Unprintable Materials

The following were my remarks at given at the American Musicological Society meeting in Louisville, November 2015, as part of the discussion "Beyond the Printed Page: Electronic Publishing and its Implications for Musicology," sponsored by the Committee on Career-Related Issues, the Committee on Technology, and the Committee on Publications, organized by James V. Maiello.

In thinking about the future, I find it’s always helpful to reconsider the past.  What were the roles of publishing in the age of print and print only? Why was it important to have ideas published? [Back then], only publishers could get an idea out to a large audience that would want to read it. Publishers had distribution networks that could take it from a single location (the city that we still cite in footnotes) and make it available throughout the world. The publishers took on financial risk in printing and distributing material: if they did not print ideas that were worth reading, scholars and librarians would stop subscribing to journals or purchasing books, leaving them unsold inventory in the present and less influence in the future. The publishers’ sense of the market would give an idea of how much interest there would be in the idea while peer review would ensure the quality of that idea. Initially, the reputation of a journal or publisher would determine how many people purchased and read it. Later, public review would help individuals and libraries decide which material to pick up after the initial sales.

While people sometimes speak of electronic publishing, particularly open access publishing, as changing everything, some of the prior paradigms remain and some disappear. Costs in production have certainly changed: The costs of an online publication (rights, editing, hosting) are basically the same whether its distributed to one reader or a million. Access, in the case of OA publishing, has absolutely changed. I doubt there is a single person on earth who has access to a print journal such as Acta musicologica who doesn’t also have access to the Internet.

What hasn’t changed at all though is the mark of quality and reputation that one journal or press has over another. Perceived differences in reputation or importance for online vs. paper has largely to do with the newness of most online journals. If the Journal of the American Musicological Society or Oxford University Press started publishing exclusively online, I doubt they’d take any hit to their reputation. It’s the name and the history that determines the importance of what is published, not the method of distribution. This authority—bound to decades of (mostly) good decisions about what to publish—is what is generally lost with electronic publishing.

If this hypothesis be true, then one need ask how can journals and publishers use their authority and reputation to advance scholarship better through digital publishing. I’d like to call on journals and the Society to be more open to peer-reviewing and “publishing” born digital materials, especially data collections, such as image archives, score collections, and spreadsheets that are of particular value to the scholarly community. Such publications used to be common in Anglo-American scholarship and particularly on the European continent. Here’s an example of what used to be published: An article by Gilbert Reaney in Musica Disciplina, where the text is largely introduction and connecting tissue around the main contribution of the article: pages and pages of charts describing the actual contents of some new finds. 



Or this contribution by Claude Palisca to JAMS in the 1950s, whose second part largely consists of organized musical examples of a surprising nature extracted from a large counterpoint treatise.  


Yes, both articles have text, but what mainly was peer-reviewed and published was data and a short justification for the significance of this data.

You won’t find many articles like these published today. In part there’s been a backlash against perceived empiricism without theoretical reflection, a new direction for scholarship, and so on, but this is not all of it. A larger reason is that our data has gotten too big to publish on paper, economically.  The best theoretically grounded article still would never appear in a major journal if it included a 300-page chart. Relatively forward-thinking journals have started to sometimes offer these tables, etc. as digital appendices. That may be fine for some people, but sometimes the table is not the appendix: it’s the article; if anything, it’s the introductory text that’s the appendix. The tables, hopefully in an original layout, sortable, filterable, and in original formats, can be the main text.

There are other important contributions to scholarship that are not included in peer-reviewed publication not because of their lengths but their formats: video, interactive explorations, computer software, or raw music notation files (such a curated collection of all the parallel perfect consonances in Bach chorales).

JAMS has begun to open one part of the publishing process to digital projects: the public peer review. The “digital and multimedia scholarship” section since 2014 has reviewed scholarly contributions that have already been released publicly on the internet or through other means.  It is a valuable part of e-publishing, validating, though after the fact, scholarship in non-traditional forms; Ian Quinn’s review of my music21 toolkit helped my tenure committee understand it as a book-equivalent project. (Dmitri Tymoczko's review in Music Theory Online had a similar impact for the theory world). But not all digital projects are book-length and thus subject to public review. And many projects would benefit from the process of peer-review earlier. It may seem odd at first to open an issue of JAMS and see nothing but a title, author, one or two page introduction and a web link to the materiel of the publication, but it is a necessary step towards using publication to even out the playing field between traditional and newer forms of scholarship.

Given the sponsor of the session, and the importance of teaching in our careers, I’d like to end with an appeal to pedagogy. We try to teach our students to distinguish between good information and less reputable. Articles appearing in JSTOR tend to be pretty good; random websites turning up from a google search are more problematic. Yet, if there are whole classes of scholarship: digital projects, data sets, videos, that cannot be recommended due to lack of peer review, lack of a press or journal name attached to them, we are shutting out our students to many of the top fruits of our scholarly labor. I hope we can change that.

Errata: 2015-11-20: The original version of this post mistakenly identified the third committee sponsoring the session. It is the Committee on Publications. It also referred to a slide of parallel perfect consonances in Bach chorales that was not included. The text has been adjusted.

08 August 2015

Merge upstream into your fork in GitHub

[Update: 12 August 2015: it is now possible to do this much more easily in the Beta version of GitHub Desktop]

For years I’ve been trying to get student assistants to use GitHub more effectively to work on larger projects.  One of the main problems though has been that the process of using forks + pull requests to submit their code to the main project has always required going back to the terminal for one key step: pulling and merging others’ changes from the upstream branches.  Today even for many seasoned programmers, the terminal/command prompt is a bit of a mystery to students.  Thus it would be great if the GitHub graphical client made this simple or at least possible.

The most recent versions of the GitHub client (at least on Mac; untested on Windows; I’m on v. 208) don’t exactly make the process simple, but at least they make it possible.

Open the GitHub client and if you haven’t worked on the project in a while, hit Sync. You should see your own fork; I’ll assume that you are working on the “master” branch and want to merge changes from the upstream (main project) master branch into your own branch.

Your screen should look something like this.  (I’ll be demoing on the amazing Latin dictionary program “whitakers-words”[*] which I do not have commit access on, so it’s like what my contributors to my projects would see).  All I’ve done is created a little demo text file.

Next I’ll pull down the tab on “master” and switch to the main developer’s master, “mk270/master” (third from bottom).


Click “Sync” in the upper left hand corner to copy it down.  The sync button will turn into a progress bar:

This actually creates a temporary branch confusingly called mscuthbert/mk270/master (or YOURNAME/THEIRNAME/BRANCH) but will just be displayed as mk270/master on the GitHub client.  No matter.  Now click the button next to the progress bar to create a pull request.  You will want to pull from this branch to your master branch (the one marked default branch):


You can leave the description blank since you’re just making a pull request to yourself. Go ahead and click “Send Pull Request”.

Click the link below the “Good work!” button to open up GitHub in your browser.  You should see something like this:

Scroll down to the bottom and you’ll see this.  Go ahead and click “Merge pull request” then “Confirm merge”.


Now you’ll see the option to delete this branch.  Go ahead and do it.  You are actually deleting “mscuthbert/mk270/master” not “mk270/master” — I hope it won’t let you delete the upstream master!

After doing so you’ll see this confirmation.

Now return to the GitHub client and switch back to “master” if it hasn’t already put you back there.

Go ahead and click “Sync” again for good measure.  Then you can check your History and see that you have all the most recent upstream commits:

Ta-da! Well, assuming that there aren’t any conflicts or anything of that sort.  In a case like that you’ll probably still need to get out the ol’ command-line tools, so you will still need to be a bit familiar with them (or have a friend who can help you out). Hopefully the next version of GitHub for Mac/Windows will make this much easier. But for day-to-day work, it’s now possible to stay in sync with the main repository on a more regular basis for people who use the graphic interface tools almost exclusively.

[*] edit August 10: EEK! Autocorrect originally changed “Whitaker’s Words” to “Whiskers-Words” — Fixed! That app only does Cat-latin (catin?): maumo, maumare, maumavi, maumatus  V (1st)     1 1 [GXXEK]   — meow;” not what we want!

06 August 2015

NL vs. AL leadoff hitters

Often while marveling at Ricky Henderson’s amazing stats, I wondered how much greater a leadoff hitter he would have been if he had spent his whole career in the National League. He had 11,180 plate appearances in the AL but only 2,166 in the NL. In both leagues, the leadoff hitter leads off the first inning, but is not guaranteed to bat leadoff in any following inning. However, I figured that in the National League, batting after the pitcher, it’d be substantially more common that the person batting first in the order would get to lead off. The pitcher almost always makes an out, so I figured it’d be pretty common for him to make the third out (and because of situations where the eighth batter is walked to get to the pitcher, probably more common than one in three).  The eighth batter isn’t that strong in the AL, but a lot stronger than almost any NL pitcher.

I’ve been working off and on over the past two years (more off before getting tenure, more on after getting tenure) on an extremely flexible python toolkit for examining baseball games and it finally got to the state of development where I could test my findings.  I’m not ready to release the toolkit yet (it needs to be polished enough that I’m proud of it), but here’s the code I used to work:

  gc = games.GameCollection()

  gc.yearStart = 2000

  gc.yearEnd = 2014

  gc.usesDH = True

  allGames = gc.parse()

  totalPAs = 0

  totalLeadOffs = 0

  for g in allGames:

      for halfInning in g.halfInnings:

          for p in halfInning.plateAppearances:

              if p.battingOrder == 1:

                  totalPAs += 1

                  if p.plateAppearanceInInning == 1:

                      totalLeadOffs += 1

  print(totalPAs, totalLeadOffs, totalLeadOffs*100/totalPAs)

It gets a collection of games where the DH is used or not used, looks at each game, then at each half inning, then at each plate appearance. If the batter is #1, then it checks whether it’s the first appearance in the inning, then prints out the percentage of all batter #1 plate appearances which are leadoffs.   The results were surprising to me. 

       PAs  Leadoff    %
No DH 183,033 75,364 41.2%
With DH 163,1781 63,451 38.9%

The average difference in the percentage of leadoff plate appearances between the two leagues (accounting for interleague games) is only about 2.5%. This works out to about 15 PAs a year different for Ricky in his prime. So one hypothesis down, but many more to be investigated soon.

17 September 2014

Recent Research

A few recent articles and software of interest and some older articles that might have been missed: