List of undergrad Classics programs - more pandoc & github

I've kept ("maintained" would be too strong a word) a list of undergraduate classics program for a while now. I first started it when I was the webmaster for the American Classical League back in grad school and early in my career, but then I just kept it around because it seemed like a shame not too.

The other day I got a now rare update from someone on the list, and I thought this would be a good time to change the way I handle the whole thing.

First I figured I'd switch over the basic form of this very simple page from html to the easier to manage markdown, and then change my workflow to use pandoc to generate the html from this markdown whenever necessary. This part was fairly simple, though there were a few complications. For example, pandoc doesn't like html name tags, so in order to keep a bunch of internal links I had, I needed to convert those anchors to spans with IDs that matched the names I was using. BBEdit and its nice search-and-replace functionality to the rescue. I then did some minimal tweaks to the new pandoc-generated markdown file, so that pandoc could now generate some decent html from it.

Step 2 was to put the new markdown and html up on GitHub, instead of in my institutional filespace. Not only does this give me some version control over the files, but I can let other people edit the markdown and send me pull requests, instead of emailing me updates that I then put into the file. I don't think I'll get a lot of these, but you never know.

So I can now (1) make changes to the markdown myself, or accept pull requests with them in it, (2) sync my local github repo with the on-line version, (3) run pandoc on my local copy, and (4) sync it back to GitHub where I release a new tagged version. I then link to the files directly via rawgit. (The tag in GitHub is needed to make rawgit grab the correct version instead of the one it caches.)

The relevant links are here:

• GitHub repository
• The list itself

Check out the list and let me know about any updates via a pull request!

Self-publishing with pandoc, etc

Depending on your thinking, I'm either just done with or approaching the end of a sabbatical. ("Just done with" if you think that once commencement occurs, it's just a regular summer.) Among the things I produced in the past few months is a very short "note" on a topic that doesn't fall within my usual area of research. I sent it to a couple of OA journals, but neither wanted to publish it as is. I'm not interested in doing more with it at this time, but it seems silly to have it just sit on my hard drive doing nothing. It's the kind of thing I'd do as a conference paper, if I went to a conference at which I think it'd be welcome. But since I don't go to such conferences, I figure I'll just put it out there for people to check out anyway. (The advantages of tenure and the internet!)

I could do it as a blog post, though it's already written in a more "academic" style than I write this blog in. Instead I'm going to post it as html on github and as a pdf on my account at figshare, where it's easily accessible, archived, and even gets a DOI. I'll also link to it from my academia.edu page (as well as here, obviously).

The Workflow

I've started using markdown with pandoc to generate documents. I was inspired by Dennis Tenen and Grant Wythoff's post last year, "Sustainable Authorship in Plain Text using Pandoc and Markdown," but I've long been a fan of avoiding proprietary formats that are likely to become obsolete (no doubt in part because I work with very old texts and materials professionally). It's easy enough to do simple stuff this way, but getting to more complex documents requires some work. Here's a list of stuff I do/use:

• For editing my markdown documents, I use the free MacDown, which gives a nice split screen, showing the raw markdown on the left and the interpreted version on the right. There are a number of pandoc "enhancements" to markdown that MacDown can't handle, but it gets the vast majority of the formatting right and it prevents me from making stupid mistakes in that majority.
• I keep all my bibliography in Zotero. I export it all as a a bibtex file using Better BibTeX, which provides some nice customization of the export entries. Once this bibtex file is created, I can easily cite the works in it within markdown and then let pandoc-citeproc expand them as appropriate.
• I've given up on using pandoc to produce final versions of the same file in different formats. I'm mostly interested in html, OpenDoc, pdf and—sadly—Word. There are just too many complications in academic documents (footnotes, etc) and my skills and time are limited. LateX PDFs have a certain look to them, but anything I can print, OS X can turn into a PDF, so that's not a big deal for me. In most other cases, I don't need both html and odt/docx versions, so I can skip it there too. (I was really hoping that I could generate my CV in html and PDF directly, since I've been maintaining html and odt versions, the latter of which I turned into PDF via OS X, but I've yet to get enough into LateX to be able to reproduce my mildly complicated CV format.)
• For html, I use a few different versions of my standard css file. It's all up on github, so you can see what I've done. I just discovered rawgit.com, so now I'm converting my html files to refer to the css files there, instead of on the institutional server that I've been using (and which has recently become a bit more difficult to keep updated from home). FYI, I usually edit css field manually with BBEdit, but I'm trying out CSSEdit, which seems to have been EOL'ed.
• On the pandoc side, I've tweaked the default templates for html, odt and docx, so that they can handle multiple authors, as well as a license field in the header. Again, all on github.
• To tie it together a bit, I wrote an applescript that takes the frontmost document in MacDown and runs it through pandoc, outputting whatever type of file you want (based on extension) and also allowing user-inputted pandoc switches.

The overall process then runs like this: write in MacDown, incorporating the citation keys from Zotero; process that with pandoc to generate the desired final file type; publish/share/whatever.

It's seems easy when I write it like that.

Numbering for citation

My one concern with html output of the note that I just wrote was that html has no default pagination, and pages are usually the way one cites an article. So instead of numbered pages, I decided to go with numbered paragraphs. (Read about Sebastian Heath's approach to articles he's editing for ISAW.) But how to number them, so that the numbers were visible (for easy citation) and so that I didn't have to manually put them in? With a little help from the pandoc Google group, I combined some features of pandoc with css. Since pandoc automatically gives IDs to headers and css allows for formatting those headers and even for auto-numbering them, I put a nearly empty level-6 header at the start of each paragraph in my markdown document and I used css to number them and put that number off in the margin. (They're nearly empty because markdown won't create empty headers.) Although the numbers are visible to a human reader, the IDs aren't ideal: section, section-1, section-2, and so on, but they are sequential and linkable. The headers are also a bit ugly in markdown, but they work and they also make it possible for me to indicate logical paragraphs instead of the actual ones. This is useful, for example, when there's a block quote, which technically creates a new paragraph, right in the middle of a logical paragraph.

One more thing, since I'm using css to number the paragraphs in the html version, those numbers are technically part of the display of the article, not part of its content. So you can see them, but you can't find them if you search in your browser. That's not the case in the PDF; there the numbers are "real" and you can find them in a search.

The Article

So about the article itself...it has to do with the original nature of the Golden Calf in Exodus 32. I speculate that it was in origin a "corn calf," to be associated with a lost harvest ritual. Go have a read:

• HTML
• PDF

The Humanities Open Book Program (@NEH_ODH)

The NEH and Mellon Foundation just announced a new project today, under the broader auspices of the NEH's The Common Good: The Humanities in the Public Square project. It's called the Humanities Open Book Program and will provide funds so that organizations can "digitize [out-of-print scholarly] books and make them available as Creative Commons-licensed 'ebooks' that can be read by the public at no charge on computers, mobile devices, and ebook readers."

This is great. There are lots of books that fall into this category and would see a lot more use if there were available digitally. I'd love them for myself, but I can also imagine assigning them (or parts of them) more frequently to my students. Also great is that the program insists that the books be released in the EPUB format, which is open, looks good on lots of readers, and makes it fairly easy to get the text out.

Regarding that last, a potential limitations that I hope we don't actually see too much of results from the program's lack of a specific requirement that the work be re-usable. Instead what's required is a CC license. Any CC license. That means that in reality there's no guarantee that it will be possible to reuse the work (apart from the usual fair-use ways). I tweeted this question and @NEH_ODH replied quickly (love those guys):

@NEH_ODH Great news! Will there be ability to freely make derivative works too?
— John Muccigrosso (@JD_PhD) January 15, 2015
@JD_PhD It depends on which CC license the publisher chooses. But generally, yes.
— NEH Dig Humanities (@NEH_ODH) January 15, 2015

So let's hope that lots of publishers do make the choice to allow such re-use. I'm worried about it in part because we know what publishers can be like. On the other hand, the program explicitly solicits applications from more than just presses: "scholarly societies, museums, and other institutions that publish books in the humanities," and these groups might be a little more inclined to use a more permissive license. A little outside pressure might not hurt either.

(If @NEH_ODH would like to comment, I'd be curious to know why they didn't impose a more open licensing requirement. Worried that publishers might not respond so openly?)

Police-related Killings

Like a lot of people, I've been viewing all the recent (and not so recent) news about police-related killings with a mix of sadness and outrage. I was really surprised to find out that the government doesn't collect good data on this and that the number that's often tossed about is just plain wrong.

In the 538 article I just linked to, a few crowd-sourced projects are mentioned:

• Killed by Police - a Facebook page which 538 cite as the best source of data.
• FatalEncounters
• U.S. Police Shootings Data - located at Deadspin

Then there are some Wikipedia pages on the same topic, with killings listed by month. (Here's November, which is fairly complete.) I've been contributing to the Wikipedia pages and also the Facebook page.

Finally there's the Gun Violence Archive, which is a broader project aimed at providing "accurate information about gun-related violence in the United States."

As I'm watching a lot of communication and cooperation around data projects in my academic life, I'm wondering why these projects can't do the same thing. With at least four separate crowd-sourced projects tracking essentially the same data—though the Facebook page and Wikipedia pages don't include as much detail as the others—that's a lot of duplication of work happening. It would be easy enough to generate most of the entries in the Wikipedia tables from the data in one of the other two projects in the list above, so some of it could be reduced, but there would still be a lot left in those two projects. In addition they've got their data in Google docs, which are handy, but mean a lot of anonymous editing and a reliance on Google to keep the service around (which I realize is more of a long-term worry). FatalEncounters has already had a problem with vandalism and has moved to a much more labor-intensive method for updates.

So I've emailed the responsible parties there and am hoping there can be some deeper cooperation and maybe some better current and long-term access to the data arranged (GitHub?).

I'll keep you posted.

PS In addition to 538, there's also this effort to work with the Facebook data, which also provides a link to those data, which are hard to get from Facebook directly.

Pole Aerial Photography on an archaeological dig

A recent post by Chiz Howard over at the Urban Archaeology blog covers his efforts to make a pole-mounted camera. I figured I'd share my own experience doing something similar on our site in Italy.

I was mainly interested in getting better quality overhead shots for archival purposes, so what I wanted was a camera view of as close to perpendicular to the ground as I could get, and, ideally, from a fairly high vantage point to include as much ground as possible. It turns out—not surprisingly, in retrospect—that there's a whole community of people out there on the internet who do this sort of thing (PAP, for "pole aerial photography, not to be confused with KAP for "kite"), so I didn't need to re-invent the wheel on this.

PAP in action, with our former apparatus in Paolo's hand in foreground.

My choices were also partly informed by a very practical reality: I had to get this stuff to Italy from the US, since I wanted to test it before going, and I wasn't sure I could get everything once in Italy and I certainly didn't want to have to pay for extra shipping. (Honestly, I hadn't tested far enough in advance to trust the Italian mail to get it to me either.) There is a big Home Depot-type place (Leroy Martin) about 45 minutes away, but I wasn't going to take a chance on them having what I needed.

The Rig

The Camera

Camera equipment

For my camera, I went with a light-weight, inexpensive, but fairly good quality digital camera, the A4000 from Canon (in electric blue), which I picked up for about $100. Canons have the added advantage of being programmable (really "hackable," which is loads of fun in its own right), and of course there's an on-line community for that too. This meant that I could use an existing program (an intervalometer) to have the camera take photos at predetermined intervals all on its own for the whole time it was on the pole. The A4000 is also nice and small, so it's a good camera to travel with. I also picked up a few extra batteries and a charger that shipped with a 12-V car-plug adapter (which I ended up not using). For memory I used 16GB SD cards, which effectively means I never had to worry about running out of storage space. (For the extra-cautious, I find SD cards are also a great way to back up your season files, photos and all, before traveling home.)

Since most pictures were taken in full daylight during the Italian summer, the auto setting on the camera resulted in a low ISO, small f-stop and fairly short shutter speed. For example, in the shot below (as you can see from the embedded EXIF), the ISO was 100, shutter speed 1/1000, and f-stop 3. All of which means I didn't have to worry about the photos being out of focus because of any slight movement in the pole, though the picavet works to dampen those anyway. Just to be sure though, I forced the camera to use ISO 100. The intervalometer program I linked to above also allows you to set a minimum shutter speed and aperture, so you can make sure to get good photos in more marginal lighting conditions. Yet another advantage of the A4000 is a large depth of field, another thing that works to mitigate focus problems.

The Pole

Me setting up with partially collapsed pole

The travel and shipping considerations meant that a lot of the options for poles were out of consideration, unless I wanted to pay for extra shipping or baggage. In the end I went with a 6m (20') collapsible flagpole. Since the camera only weights about 150g (6 ½ oz), I figured that was a lot less than any flag in the wind. It came in a box that was under the "big" baggage limits for the airlines, so I could take it with me without a problem.

The Mount

For attaching the camera to the pole, I decided to go with a picavet, an apparatus that would keep the camera perpendicular to the ground. This requires two attachment points to the pole, and conveniently enough the flagpole shipped with several adjustable mounts. Out of concern for weight I decided to use a cloth picavet.

Conclusion

I ended up being very happy with the results. Not only did we get better overheads than in previous years, from a greater distance and better quality, but they were easier to get, meaning that we took a lot more of them. I was also able to do some photomosaicking with the photos, as I wrote in my last post, which was very nice. (In fact I'm working on a larger-scale one now; food for a future post.) For the future, I'm going to try to make a rigid picavet from plywood or aluminum. The cloth is handy and works, but it gets a bit messy with all the string around. I'd also like to use WIFI SD cards, as I wrote above, so I don't have to keep taking the card in and out.

Overhead of the crew at work. 5m or so wide.

Photo fun: Using Hugin

Back from my annual month in Italy to lead the excavation at the Vicus Martis Tudertium site and it's time to get cracking on various associated tasks. First up is putting together some of the more adventurous photography work I did, including some pole aerial photography (PAP, as they say, about which I'll do another blog post soon) and 3D work.

For the 3D work, I've been using the for-pay Photoscan application, which works great for me, especially now that I upgraded my laptop to 16GB of RAM. (I'd like to use a freeware option, like VisualSFM, but I can't get it to run yet on my MacBook Pro. I'm working on it now that there's a new installer on GitHub.) The PAP work needs some stitching to create photomosiacs. For that I'm using the freeware Hugin, which is very powerful, but not tremendously well documented, so there's a bit of a learning curve partly due to adapting the old tutorials to the newer versions with their nicer interface.

I already got one photomosaic done during the campaign this summer, just to make sure it was going to work. Here's a small version of the photo. You can catch my feet in more than one place:

It's nothing fancy, just a dry wall, but the technique worked for a ~12m-long stretch, so I've got some more ambitious ones to assemble on. (FYI, the orange things are kids' soccer-field markers that I got to help with aligning the different photos.)

Big inscription from the Roman theater at Ostia Antica.

I'm trying to get up to speed on Hugin's various capabilities in the meanwhile, so I get full use of it. One nice thing it can do is remove various kinds of distortion from photos, including vertical and horizontal effects resulting from your perspective when you take the photo. They call this "Perspective correction". It's fairly simple to do with Hugin and also the kind of thing that's very handy for those of us who take a lot of photos from the ground of big architectural things that therefore end up distorted in the photo. To test it out, I grabbed a photo from Ostia Antica, taken on my last day in Italy this year.

Same inscription corrected.

You can easily see how the nice rectangular inscription shows the expected distortion from being photographed from below. It also has nice straight vertical and horizontal lines, so it's a good object to test the process on.

Following the tutorial, I was able to create a "corrected" version in under half an hour. I used MorphX to create a short video that morphs the original into the final version.

All in all, I'm pretty pleased with the outcome and looking forward to using Hugin with my existing photo collection.

PS In the first version, I incorrectly linked to the "Simulating an architectural projection" tutorial, which is similar, but doesn't include the horizontal correction.

NYTimes scapegoats ACA subsidies

Katie Thomas, Reed Abelson and Jo Craven McGinty have an article in today's NYTimes on how the new Affordable Care Act is leaving some middle-class families "caught in the uncomfortable middle." By this they mean that those with incomes just above the cut-offs for subsidies are paying much more than they would if their incomes were just a little less. Unfortunately the math doesn't quite work out on this.
The calculation that matters is how much money a family has left after they pay for their insurance. Look at the families the article gives the numbers for (I'll assume the numbers in the article are correct):

Family	Actual Income	Premiums	Net Income	Lower Income	Lower Premiums	Lower Net Income	Savings
NH	$100,000	$12,000	$88,000	$94,200	$6,000	$88,200	$200
Polk Cty.	$50,000	$9,801	$40,199	$45,000	$2,228	$42,772	$2,573
OKC	$50,000	$3,279	$46,721	$45,000	$2,425	$42,575	($4,246)

So in two out of three cases the Times describes, the families either have more income after insurance (OKC), or effectively the same amount (NH) that they would have if they made the lower incomes described in the article (ignoring the effects of income tax). At least one of the other families is likely in a similar position (the Montana bakery owners, who would pay $1,500 more a year if their income rose by some unknown amount, which is likely more than $1,500). Most families will have more net income if they make the higher income, even with the higher premiums. In other words, the subsidies are doing what they're supposed to, making the insurance more affordable for those with lower incomes. That they're not helping families who don't qualify for them seems beside the point.
What the article is really about is how for some people ACA insurance will cost more than they currently pay, and it mixes in this mostly inaccurate attack on the subsidies. But even here the article falls down because it doesn't compare all the old and new health-care costs of the families. Premiums are only one part of those expenses: there are co-pays for office visits, medicines to purchase, and so on. Granted, it's not easy to calculate that. You'd need a lot more data than are presented in this article, but that's why this health issuance stuff is hard.
Who's spending more or less on health care because of the ACA? We know as little at the end of the article as we do at the beginning.