Value Labels

Minnesota Population Center


Value labels in the ipumsr package

Integrated variables in IPUMS data often have value labels, which attach text labels to the values taken by a variable (for example the HEALTH variable has value labels: 1 = “Excellent”, 2 = “Very good”, etc.). The ipumsr package does import the labels, but not as factors, which may be how you were expecting them. The values can be hard to spot at first:

ddi <- read_ipums_ddi(ipums_example("cps_00015.xml"))
cps <- read_ipums_micro(ddi, verbose = FALSE)

#> # A tibble: 10,883 x 13
#>    <dbl>  <dbl>   <dbl> <int+lbl> <int+lb> <int>  <dbl>  <dbl> <int> <int>
#>  1 2016. 24138.   3249. 55        1        3         1.  3249. 54    73   
#>  2 2016. 24139.   3154. 55        1        3         1.  3154. 54    73   
#>  3 2016. 24139.   3154. 55        1        3         2.  3154. 52    73   
#>  4 2016. 24140.   1652. 55        1        3         1.  1652. 38    60   
#>  5 2016. 24140.   1652. 55        1        3         2.  1503. 15    10   
#>  6 2016. 24140.   1652. 55        1        3         3.  1652. 38    73   
#>  7 2016. 24141.   3049. 55        1        3         1.  3049. 85    30   
#>  8 2016. 24142.   1637. 55        1        3         1.  1637. 27    111  
#>  9 2016. 24142.   1637. 55        1        3         2.  1637. 27    111  
#> 10 2016. 24142.   1637. 55        1        3         3.  1887. 2     1    
#> # ... with 10,873 more rows, and 3 more variables: INCTOT <dbl+lbl>,
#> #   HEALTH <int+lbl>, MIGRATE1 <int+lbl>

The first clue that some of the variables are labelled is the <dbl+lbl> that appear below STATEFIP, ASECFLAG and other variables. The tibble package prints the variable’s type information below the variable name, and this “+lbl” indicates that the variable uses the labelled type. You also can use the is.labelled() function to check if a variable is labelled.

#> [1] TRUE
sapply(cps, is.labelled)
#>    FALSE    FALSE    FALSE     TRUE     TRUE     TRUE    FALSE    FALSE 
#>     TRUE     TRUE     TRUE     TRUE     TRUE

There are a few options to see what the actual labels are:

# Printing the variable directly (or a subset)
#> <Labelled integer>
#> [1] 3 3 3 3 3 3
#> Labels:
#>  value     label
#>      1   January
#>      2  February
#>      3     March
#>      4     April
#>      5       May
#>      6      June
#>      7      July
#>      8    August
#>      9 September
#>     10   October
#>     11  November
#>     12  December

# Just get the labels
#> # A tibble: 12 x 2
#>      val lbl      
#>    <dbl> <chr>    
#>  1    1. January  
#>  2    2. February 
#>  3    3. March    
#>  4    4. April    
#>  5    5. May      
#>  6    6. June     
#>  7    7. July     
#>  8    8. August   
#>  9    9. September
#> 10   10. October  
#> 11   11. November 
#> 12   12. December

# or if you're working interactively you can use ipums_view
# ipums_view(ddi)

Why use the labelled class instead of base R’s factors?

The usual way to connect numeric data to labels in R is in factor variables. Though this data type is more native to R, and more widely supported by R code, it was designed for efficient calculations in linear models, not as a general purpose value labeling system and so is missing important features that the value labels provided by IPUMS require.

Factors only allow for integers to be mapped to a text label, and these integers have to be a count starting at 1. This doesn’t work for IPUMS data because often our variables have specific meanings for the codes. For example, the variable AGE uses the value to mean the actual age, but does have labels for age 0 and the top codes.

#> <Labelled integer>
#> [1] 54 54 52 38 15 38
#> Labels:
#>  value               label
#>      0        Under 1 year
#>     90 90 (90+, 1988-2002)
#>     99                 99+

cps$AGE_FACTOR <- as_factor(cps$AGE)
#> [1] 54 54 52 38 15 38
#> 84 Levels: Under 1 year 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ... 99+

It may seem like the new AGE_FACTOR variable is okay, but it can be very confusing!

#> [1] 35.0226

# mean(cps$AGE_FACTOR) # error because data is a factor not numeric

mean(as.numeric(cps$AGE_FACTOR)) # A common mistake
#> [1] 35.94836

# The "more" correct way, but NA because of the text labels
#> Warning in mean(as.numeric(as.character(cps$AGE_FACTOR))): NAs introduced
#> by coercion
#> [1] NA

Because the factor variable has to assign values starting at 1, but the AGE variable started at 0, most values were 1 higher than they should have been. Not all values are 1 higher though, because not all values exist in the data, so 85, 90, and 99 are 82, 83 and 84 respectively.

Other variables have special meanings behind certain codes. For example, often missing or NIU values are indicated in IPUMS by values starting with the number 9 that are offset from the typical values. R’s factors do not allow for this separation, so the missing codes will be harder to distinguish.

Factors also require that every value be labelled, which is not always true in IPUMS data. In the AGE variable, the only values with labels are 0, 90 and 99. For all other values, there is not additional label information.

Is the labelled class a panacea? (Hint: no)

Though the labelled class does express all of the meaning provided by IPUMS value labels into R, many R functions cannot use them or even actively remove them from the data.

#> # A tibble: 5 x 2
#>     val lbl      
#>   <dbl> <chr>    
#> 1    1. Excellent
#> 2    2. Very good
#> 3    3. Good     
#> 4    4. Fair     
#> 5    5. Poor

HEALTH2 <- ifelse(cps$HEALTH > 3, 3, cps$HEALTH)
#> # A tibble: 0 x 2
#> # ... with 2 variables: val <dbl>, lbl <chr>

Therefore, your first task when importing an IPUMS data set will usually be to convert the labelled values to other data structures. The bad news is that there’s no good automatic way to do this; a lot depends on how you plan to use the variables in your analysis and your preferences.

The good news is that the ipumsr package provides several functions to make this process easier.

I think it is easiest to learn them by seeing them in action, so see below for a workflow for bringing in the CPS example extract. For your reference, here is a list of the functions:

Workflow example using ipumsr functions


The HEALTH variable is structured just like a factor and so can be converted directly. The as_factor() function is the easiest way to do so.

The ASECFLAG and MONTH variables can also be converted directly (these were included by default by the IPUMS extract engine, but aren’t useful here because this data set only has respondents from ASEC in March)

as_factor works on data.frames by converting every labelled variable to a factor. However, this can create confusing variables like AGE_FACTOR from above, so this isn’t the best thing to do right away.


I may decide that for my analysis, the AGE variable is most useful as the numeric values. The zap_labels() function removes the labels.

The top-codes (which are only available on the CPS website) indicate that the value 80 actually indicates 80-84 and 85 indicates 85+, so another option would be to convert them to a factor with age ranges.


This extract only contains data from a few states and I don’t want the factor to have a level for the unused ones. The lbl_clean() function keeps only labels for values in the current data set and returns a labelled variable which we can convert to a factor.


The INCTOT variable has 2 labelled values that are not actually incomes: 99999998 indicates “Missing” and 99999999 indicate “Not in Universe”. On the CPS website, the Universe tab indicates that the Universe for 2016 is respondents age 15+. Let’s say for my analysis, I can treat these values as missing.

The lbl_na_if() function takes the variable and a function that refers to .val and .lbl (the values and labels respectively) and returns an indicator of whether to set those values to NA and remove the label. You can also use the ~ notation from the purrr package to create succinct anonymous functions.

The .val and .lbl only refer to values that already have labels, they do not apply to unlabeled values. See the lbl_add() and lbl_add_vals() functions below for working with unlabeled values.


The EDUC variable provides an example of a common IPUMS practice of grouping categories together by the starting digits. For example, the value 10 indicates “Grades 1, 2, 3, or 4”, and 11 - “Grade 1”, 12 - “Grade 2”, etc.

Let’s say that I only care about those more general categories provided by the first 2 digits. The lbl_collapse() function allows me to provide a function that takes .val and .lbl and returns the value to assign it to. If that code is already used, then the all of the values assigned to it will get that label, otherwise the label of the smallest value is used. Just like with lbl_na_if(), the purrr-style compact syntax using ~ functions is supported.


Sometimes you may wish to move the labels into new categories. For example, the categories in MIGRATE1 may not quite map what I want to use in my analysis.

The lbl_relabel() function provides a more flexible way to group existing labelled values into new ones. It takes a two-sided formula, where the left-hand side is a label (defined with the lbl() function) and the right hand side is an expression that can use .val and .lbl to evaluate to a logical indicating which values should be assigned to this label.

lbl_add() and lbl_add_vals()

These functions allow you to create labels for values that aren’t already labelled. It’s harder to come up with real world examples of when these functions would be useful, but just in case you come across such a situation, here’s how they work.

Ready for analysis

And now, after converting all those labels to factors, I’m ready for analysis! If you think of any other helper functions that would be useful for dealing with labels please let us know by filing an issue on github.

More detail on how the lbl_* functions work

One implementation detail that may help you understand the lbl_* functions better is that the value labels are stored separately from the actual data. This can be important because it allows for values to exist in the data without labels (such as the non-special codes in the INCTOT variable from the example above) and also for value labels to exist even if they don’t exist in the data (like the STATEFIPS that we didn’t include in our extract).

The .val and .lbl pronouns that are usable in functions like lbl_na_if(), lbl_collapse() and lbl_relabel() only include these labelled values, not all values in the dataset. Though this makes many calculations simpler, because only the labelled values are considered, it can be confusing when you want to work with the unlabeled values.

For example, considering the INCTOT variable, if there are unlabeled values that you want to set to NA, you cannot use lbl_na_if() directly.

# Reload cps data so that INCTOT is a labelled class again
cps <- read_ipums_micro(ddi, verbose = FALSE)

# Try to set all values above 1000000 to NA
test1 <- lbl_na_if(cps$INCTOT, ~.val > 1000000)
test1 <- zap_labels(test1)
max(test1, na.rm = TRUE)
#> [1] 1230006
# Didn't work

Instead you should add the value labels with lbl_add_vals() (or you could use a function that doesn’t use the labels, such as dplyr::na_if())

test2 <- lbl_add_vals(cps$INCTOT)
test2 <- lbl_na_if(test2, ~.val > 1000000)
test2 <- zap_labels(test2)
max(test2, na.rm = TRUE)
#> [1] 990003

Other resources

The haven package vignette ‘semantics’ has some more details about the motivation and implementation of the labelled class. You can view it by running the command: vignette("semantics", package = "haven")

The labelled package provides other methods for manipulating value labels. It is not installed by ipumsr, but is available on CRAN via the following command: install.packages("labelled")

The questionr package includes great functions for exploring labelled variables. In particular, the functions describe, freq and lookfor all print out to console information about the variable using the value labels. It is also not installed by ipumsr, but can be installed from CRAN using: install.packages("questionr")

Finally, the foreign and prettyR packages don’t use the labelled class data structure from haven (which ipumsr uses), but do have very similar concepts for attaching value labels. Code designed for these packages could be adapted for use with the haven labelled class without too much difficulty.