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.

Teaching with ORBIS #lawdi

On the last day of our Linked Ancient-World Data Institute this summer, sponsored by the NEH Office of Digital Humanities, I argued that it was important to show how all this exciting work could have practical implications for what professional classicists (and other ancient-world types) spend a lot of time on, teaching. To that end, I promised to do a post describing how I had assigned my Classical-archaeology students some short homework using Stanford's great new tool, ORBIS. What's ORBIS? In the words of the site, ORBIS "reconstructs the time cost and financial expense associated with a wide range of different types of travel in antiquity." More simply it allows you to map routes between two places in the Roman world given certain constraints for cost, time, and type of route.

Naturally the fine people at ORBIS did a nice upgrade to the service after I made that promise, but before I got it completed, so I had some more work to do before this post. (Fair enough, I dragged my feet for too long anyway. Nemesis strikes!) But finally here it is, suitable for framing (or at least bookmarking).

A Very Short Guide to Using ORBIS in your Classical-Archaeology Course

1. RTFM

Make sure that you understand as much as possible about ORBIS, what it is, how it works, and so on. You don't need to be an expert, but you should at least be able to do more than your students will by the time they finish the assignment. It won't take more than an hour to read the "Introduction to ORBIS", "Understanding ORBIS" and "Using ORBIS" tabs on the website. Don't miss the nifty how-to videos. Although there's more there to read, these three sections will get you far enough for step 2.

2. Make sure you know how to use it

Play around a bit yourself on the "Mapping ORBIS" section. Try to get from one place to another. Change the various parameters. Use all the controls, so you know how to change the views of the route and so on. Click the buttons and links and sliders. Go nuts. Depending on your technological prowess, this will take you a few hours at most.

3. Demo it in class

Once you're confident that you can show your students the basics of the site with confidence, have your student read those same three sections of the ORBIS website that you read up in #1 in preparation for a short demo of ORBIS that you'll do in class for them. Nothing fancy, just enough to show them the basics. I like to point out to them how long travel takes when you don't have motorized vehicles and how much faster travel over sea is than over land, but be sure to walk them through creating a route and choosing the various options, no matter what extra details you cover.

4. Assignment 1 of 2

Have your students use ORBIS to find a simple route between two places that you specify. Have them do it under multiple conditions. (I used three different sets.) Then have them either print out or take a screen shot of the result, with all routes shown. Here's one with routes between three sets of cities, one taking the fastest route, another the cheapest, and the third the shortest.

Since you've set the parameters, you'll know what the correct routes should be, and thanks to the different colors, it's easy to tell at a glance whether the student got it right. Successful completion of this will indicate that your students can handle using the basics of ORBIS. Make sure they all successfully complete this first assignment. Then they're ready for part 2.

5. Assignment 2 of 2

This part is up to you. Depending on which section of your course you're using ORBIS in, you'll want to find some question you can answer, or some issue you can illuminate via ORBIS. I actually did something that was completely out of ORBIS' chronological span.

To help my students understand the rationale behind some of the placement of early Greek colonies in the west, I had them examine routes between Delphi and Naples. The latter was used as a proxy for the earliest colony of Pithecoussae. (This was actually a variation on an assignment I had made up years ago using a QuickTime movie with links to the Perseus website.) The biggest travel difference between the later Roman empire, the time in which ORBIS is "located", and the geometric period was the roads in use. Obviously none of the vast Roman road system was in place, and so I made sure the students used only routes that avoided long portions over land. (I want to use this assignment again, so I'm not giving away all the details!)

6. Put the students to work

If you subsequently have your students come up with their own ORBIS projects, odds are they'll find something useful and interesting to do, perhaps something you hadn't quite thought of. A set of mine, for example, used ORBIS to explore the different travel experiences of three characters from the ancient world with differing socio-economic backgrounds, complete with clever backstories!

And there it is. Hope this encourages you to use ORBIS and other terrific ancient-world-related DH tools in the classroom! I'd love to hear in the notes about your experiences with ORBIS or with any other tool.

Were the Ancient Minoans Europeans?: A Comment on doi:10.1038/ncomms2871

Just got around to reading "A European population in Minoan Bronze Age Crete" <doi:10.1038/ncomms2871>, which argues for a European origin for the ancient Minoans based on genetic analysis of mitochondria from some ancient Minoan bones. Their analysis suggests that the ancient Minoans were most closely related to other ancient peoples and, among moderns, the populations of northern and western Europe. This contradicts Arthur Evans' theory that they were related to ancient Egyptians.

This isn't a field I'm entirely up on the research in, but it does overlap with my old interest in biochemistry and my current work in archaeology. Some of what I write here may therefore be easily corrected by those in the know, but I had a few problems with the paper (which I enjoyed overall). Please enlighten me in the comments.

Inconsistent Data

Table 1 of the pairwise genetic distances between Minoans and other populations seems to be based on the data presented in Supplementary Table S5, but it doesn't give the same data. For instance, the first group is Bronze Age Sardinians, which have an average pairwise distance of 2.75111 in S5, but 2.89 in Table 1. Maybe that's because these two tables were calculated using two different versions of the same software (Arlequin 3.5.1.2 vs 3.5.1.3), but that appears unlikely, since the Arlequin updates page doesn't seem to list any such change between versions.

[BTW, if you're going to give a supplementary file of data, why not put it in some nice format like CSV instead of a PDF? I fixed it up with Tabula, but that was an unnecessary expenditure of my time.]

"Ancient"?

The authors divide their comparison population groups into two chronological categories, "ancient" and "modern." Their ancient group includes 11 distinct samples: 6 neolithic, 3 Bronze Age, 1 medieval/Iron Age(!), and 1 Byzantine. They seem to be taking the nomenclature of their original sources, so it's worth noting that Byzantine means 11th −13th centuries and Iron Age-Medieval-Nordic means 1st - 14th centuries (and that the original authors did not apply this catch-all term). I didn't look up all their "modern" samples, but the remarkable chronological span of the their "ancient" ones already raises some doubts in my mind. You can't lump together millennia of data like this and act like you have homogeneous groups. This makes map b in Figure 3 misleading as well, even ignoring the way the map is colored in areas where there is no data at all (like all of North Africa, on which more below). Line c of Figure 4 does break these ancient sets up into three distinct groups, leaving out the Neolithic, but even this obscures the fact that one of these groups has a much higher sharing than the others: the one from BA Sardinia with 52%, compared with a maximum of 12% for the other two BA sites, and 15% for all four of the other locations. I'd question this approach, as it's a great example of why the mean can sometimes be a bad choice for comparison: with an N of 3 in the BA group and a standard deviation that's larger than that, you'd be better off reconsidering your choice to group these data points, or at least use the median.

If we break out this Sard group then, we're left with a much more consistent sharing with the Neolithic groups (mean=24%), and fairly low sharing with the other BA, the Byzantine, and the (absurd) Iron Age-medieval group. In short, with that one Sard exception, all the European post-Neolithic "ancient" groups match the Minoans about as well as the modern Middle Eastern/Turkish/Caucasian sets. Since the Minoans are BA Mediterraneans, that makes me wonder why the Minoans are so different...you know, assuming again that that small N isn't to blame.

Line d of that same Figure 4 breaks down the six Neolithic locations into three sub-groups based on a north-south positions. Again, I'm not sure how far you want to go with an N of 1 in the northern set. The largest sharing with the "southern" group—really France and Spain—is not surprising, given their proximity to the Mediterranean and the likely mixing of those populations in the Neolithic (as discussed, for example, in the article they take one of their datasets from).

More troubling though is the complete lack of any ancient sample from anywhere further outside Europe than Asia Minor (modern Turkey). If you're going to claim that Minoans aren't like ancient Egyptians or Middle Easterners, you'd probably want to have some sample of those groups to compare them to. The authors do note the lack of the typical African L haplotype in the Minoan group, but I'd still like to see a direct comparison with some North African Neolithic and BA data.

Note revealing my ignorance

I find the methodology of creating the haplotype sharing quite interesting. Count the individuals from each set who have a haplotype that appears in any of the Minoan individuals, then divide by the total number of individuals in that set to get a percentage sharing. For example, say you have a population with three haplotypes, A, B, and C, distributed in the population at 80%, 10%, and 10%, respectively. Another population with all the same haplotypes distributed 1%, 1%, 98% would have 100% sharing, while a third population with 85% A and 15% B would score 90%, even though the distribution of haplotypes was more similar than the second group's in overall distribution.

So in the data in this paper, we see that the Sard BA sample had the largest overlap of any group, but with only two shared haplotypes, while the North Africa set had a much lower sharing percentage, but 6 shared haplotypes. I realize part of the problem is the small N's involved, which often don't permit for a great representation of the overall distribution of haplotypes within the total population.

Update: A post from a more knowledgeable guy than myself are here.