Data Sets and Data Collection Ethics

A state park takes reservations for its campsites, and each reservation becomes one record. This lesson plans a computation over those records, and then asks what the records can and can't be trusted to say.

Each row below is one camping permit, and each column is one fact the park recorded about it.

The table isn't the data set itself. It's one way of showing it, and the park could keep the same permits as a stack of paper forms. Drawing it before any code is written still helps, because it shows exactly which facts an algorithm will have to work with.

Suppose the park wants its number of camper-nights, where each person on a permit counts once for each night. An algorithm can't take in the whole table at once. It reads one row, does its work on that row, and goes on to the next. So a running total has to hold what it has found so far.

The plan starts total at 0 and, for each row, adds the product of its Nights and its Party. After the last row it reports total. The products are 8, 2, 18, 6, and 20, so the running total goes 8, 10, 28, 34, and 54. After three rows it's 28, a number that looks just as finished as 54, so the report waits until every row has been used.

Over a full season, the permit table can say which site is reserved most often. It can't say how many people hiked the park's trails. Day hikers need no permit, so they never appear in it, and no algorithm can count rows that were never recorded.

Every row also describes people. The reservation form asks for a phone number too, which the table above leaves out. It lets a ranger reach a party if a storm closes the road. That's a reason to collect it. Nothing in the camper-night count uses it, though, and it has no use at all once the trip is over.

For the permit system, that means asking only for what some use requires. It also means deleting the phone number after the trip, and letting only emergency staff read it. A permit table anyone could download would show where each party is camped, and its ZIP codes would narrow down where their homes are.

Permits are reserved online, starting six months ahead, and the popular sites are gone within the hour. So the table mostly records people with internet access and plans made far in advance. Suppose the park writes a program that learns from past permits how many sites to hold back for visitors without a reservation. Those visitors are rare in its history, so it holds back too few every season, and they're turned away every season.

The permit records still answer questions about people who reserved sites. The error comes when they're treated as a picture of every visitor.

Some campers arrive without a reservation, and the ranger at the gate writes them a paper permit. If those forms are never typed in, the table is incomplete, and the camper-night total comes out low for every weekend with walk-ins.

One mistyped value does damage too. If the party of 5 on permit 4111 had been entered as 50, the total would rise by 4 × 45 = 180, to 234. Nothing in the plan would notice.

A check that each value is plausible, such as a party no larger than a site allows, would catch the 50 before it reached the total.