Frequently Asked Questions

The following content will help take you from LEWIS novice to Expert.

1. What are the flags associated with each cell?

The EDS2000 export format has three numeric flags in each record:

  • CONFFLAG
  • RSEFLAG
  • QUALFLAG
These flags provide reason information about which data in the cell is not publishable.

CONFIDENTIALITY:

There are three separate confidentiality tests. Test one requires that a cell have at least three employers. Test two requires that the top unreleased employer's raw employment not exceed than 50% of the total weighted employment. And, test three requires that the sum of the raw employment from top two unreleased employers not exceed 75% of the cell's total weighed employment. If either the "exclude imputed data" or "alternate estimation method" options area used, there could be differing numbers of employers and different top employers, so separate panel of tests to the employment and wage estimates. CONFFLAG is simply the SUM of all the individual reason codes shown in Appendix A of The LEWIS User Manual.

For the 2001 round, you can check whether a cell passes the confidentiality tests simply by checking its value against zero. If it is greater than zero, it failed a test. However, for the 2000 round, you must concern yourself with which tests failed. For example, "and"-ing the confflag with a mask of 213 removes the wage tests and leaves just those tests related to employment. Similarly, "and"-ing it with 234 removes the employment tests and leaves just those test related to wage. If the result is still greater than 0, then the indicated statistic is not publishable.

STANDARD ERROR:

There are two standard error tests. Test one requires that a published cell have an employment standard error less than 50%. Test two requires that the wage standard error be less than 30%. Since the wage standard error is undefined when there are less than two responding units, there must also be two responding units in the cell. If the employment test fails, the employment is not publishable but the wage estimates might be. Similarly, if the wage test fails, the wage estimates cannot be published but the employment might be. RSEFLAG is the sum of all the individual reason codes shown in Appendix A of The LEWIS User Manual. The simplest way to check whether a cell passes all the standard error tests by checking its value against zero. If it's greater than zero, it failed a test. To publish the maximum data, you must concern yourself with which tests failed. For example, "and"-ing the rseflag with a mask of 1 removes the wage tests and leaves just those tests related to employment. Similarly, "and"-ing it with 2 removes the employment tests and leaves just those test related to wage. If the result is still greater than 0, then the indicated statistic is not publishable.

QUALITY:

QUALFLAG indicates whether the data has met a BLS-specified threshhold for publication. For 2001, a cell should have an unrounded weighted total occupational estimate of at least 10. If the cell passes, this flag is zero; otherwise the flag is 1.

SPECIAL NOTES:

  1. You can view these flags by displaying the cell details in LEWIS. From the "Estimates" tab, click "Details", then double click on the line where you want to view this information. The reasons are shown in the "Publication Screening" box.
  2. The "LEWIS (EDS) wage table" export option which limits the export to "publishable data only" considers these flags. Fields which are not publishable are replaced with NULLs.
  3. The publication files distributed by BLS contain fields with these same names. While the FIELDS have the same meaning, their VALUES are different. BLS uses a simple character indicator with "1" indicating that the data passed the respective test and a "0" indicating that it failed. To get the data that is releasable, you'll need to look at the comment in the "Release" field.

2. Can you magnify the map on the area properties tab?

The map size changes in proportion to the main window. If your screen resolution permits, enlarging the window can significantly enlarge the map. You can do this either by stretching the window or by clicking the "Maximize" button in the upper right corner. Depending on the resolution of your display, doing this can also significantly increase the number of areas shown in the selection table. If enlarging the window does not yield acceptable results, try "rubber-banding" the desired area on the map. To do this, move the mouse within the map to any corner of the desired area. Press and hold the left mouse button. Drag the cursor to the diagonally opposite corner of the desired area. As you drag the cursor a "rubber band" will appear around the area. Release the mouse button. Presto! The banded area is magnified. The displayed area is restored to state defaults each time that you select a different estimation area. Alternatively, you can right click anywhere in the map area and select "Go To State" from the popup menu.


3. How are the top employers on the area profile determined?

The "top employers" option on the area profile reports produces a list of top employers, presumably for the occupation. But how are these employers determined? Since the microdata schedules represent a SAMPLING of the employers, it is not possible to obtain this information directly from there. However, a complete listing of employers and their corresponding employment is available in the EQUI. So, to get any output for the top employer listing, you must first import the EQUI. Although the EQUI contains information for all employers, it does not break out that information by occupation. LEWIS determines the percentage of total employees that belong to each occupation based on survey results for the selected area and the employer's industry. The appropriate percentage based on the employer's industry is multiplied by the employer's TOTAL EMPLOYMENT to get the employer's expected employment for the occupation. These are then ranked by descending expected employment. This matching is based on the most detailed industry estimates that are available for the area. These estimates need not be published. For best results, you should have estimates on file at the SIC-3 or NAICS-4 level. Without SOME industry estimates, LEWIS is forced to work at the all-industry level. This will yield the same percentages and, therefore, yield the same top employers for ALL occupations.


4. What areas are included in a statewide estimate?

Most people know that you can select areas on the estimates tab in LEWIS either by clicking on the map or by checking the appropriate check box in the table. But if the whole state is colored red, does that mean that the correct microdata will be selected for a statewide estimate? OR, if you click on the "Select All" button on the screen, does that mean the correct areas for a statewide estimate have been selected? The answer might surprise you! First, let's consider the map. Every state has some areas that cannot be selected by clicking on the map. For example, FIPS codes 995, 996, 998, and 999 are assigned to "Statewide", "Foreign location", "Out of state", and "County not Assigned". To select these areas you MUST check the appropriate box in the table. The same is true if you have a geographic area that, for some reason, cannot be displayed on the map. For example, a county or township may have been created after the last update to the mapping software. Once again, to tabulate surveys assigned to that area, the area must be checked in the table. Now, let's consider the "Select All" button. As expected, it selects all the subareas shown in the table. But is THAT really what you want? According to BLS, "Foreign location" (FIPS code 996) should be EXCLUDED from a statewide estimate. This is the default when you install LEWIS. The OFFICIAL list of selected subareas is ALWAYS shown in the table. These areas are enumerated in the log when you run estimates.


5. Why can LEWIS estimates differ from BLS?

Difference #1: Raw data

When BLS provides microdata files, those files only include establishments that are surveyed by your state. However, when BLS produces estimates for an MSA and that MSA crosses state boundaries, BLS includes the appropriate data from the other states in the calculation.

Difference #2: Use of the "Update wage estimates" feature

As part of the wage estimation process, microdata from prior survey years are adjusted to the latest year of survey data using employment costs indices. Sometimes referred to as ECI factors, these indices are applied based on the survey year and the industry group for the occupation. Note that the effect of this is that estimates viewed via the "Details" panel will have rounded employment but unrounded wages. Those viewed in a publication or export file will have BOTH rounded employment and rounded wages. The latest year of survey data is NOT adjusted during the estimation process. AND, since the publication process can considerably lag the date of the latest survey, the estimates may actually reflect wage levels a year or more old. When the "update wage estimates" feature is checked, exported final wage estimates are updated using the appropriate current ECI factor for the occupation. The purpose of the feature is to adjust the wage estimates so that they reflect provides an representation of what someone might make today, rather than when the survey was taken. Since the ECI factors tend to increase over time, you can often identify this situation by using the "Details" button to view the estimates. If the wage estimates on the detail panel match the BLS publication but the exported estimates are all higher, your export may have been aged.

Difference #3: Rounding

The publication files distributed by BLS are pre-rounded. Employment estimates are rounded to the nearest 10, annual wages to the nearest $10, and hourly wages to the nearest $0.01. Rounding occurs at different points in the process with LEWIS. - Employment estimates are rounded during the estimation process. This always occurs to the nearest 10. - Wage estimates are rounded during the publication process. The amount of rounding is specified as a publication option. Note that the effect of this is that estimates viewed via the "Details" panel will have rounded employment but unrounded wages. Those viewed in a publication or export file will have BOTH rounded employment and rounded wages.

6. What are occupational clusters?

The SOC coding structure nicely divides occupations into hierarchies of groups. Much of the time these hierarchies are adequate to represent groups of occupations that you may want to study. But what happens when you need to prepare an estimate for an occupation that doesn't exactly match the SOC? For example, you receive an ad-hoc request for "Application Programmers and Analysts". These are included under the 15-1000 group. But this group also includes many non-applications occupations that you may want to exclude from the aggregate, for example: "Computer Software Engineers, Systems Software". More often than not, you hand the detail estimates over to the person making the request and let them figure it out for themselves. But what if the request came from your director? And, can ANYONE really figure out a percentile for themselves without scrutinizing the raw data? So what is an occupational cluster? And, how can that help? An occupational cluster is simply an aggregate of one or more surveyed occupations. LEWIS calculates an estimate for the cluster just like it was a surveyed occupation. In LEWIS, you can define your own "special aggregates" and produce estimates for them. The Occupations information on the "Advanced" panel has been significantly enhanced. You can add occupations and control which microdata gets rolled into it.


7. What are occupational classes?

Did you ever want to treat a GROUP of occupations the same way? The Occupational Classes feature that allows you to group occupational codes. There are several predefined classes:

  • All occupation
  • Two-digit SOC
  • Three-digit SOC
  • Normal occupation
  • No employment estimate
  • No employment or wage estimate
  • Special aggregate
Once grouped, you can select:
  • Whether you want to produce estimates for each occupation in the group
  • Whether you want to publish employment, wages, both, or neither for each occupation in the group
This feature is particularly useful with occupational clusters. You can calculate ad-hoc estimates that are never published. Similarly, you can exclude ad-hoc occupations from the estimation process for areas where you have no interest in the result. Under the "Advanced" panel, an "Occupational Classes" tab has been added. This displays all the occupations in the class and allows new ones to be added. The enhanced "Occupations" tab also provides a way for the occupation's class to be set.


8. What happened to the summary occupations?

OK, you’ve clicked “Details” to look at your estimates. But there are no summary occupations anywhere! And, when you publish the area profiles, there is no wage history. So, what happened to the elusive summary occupations? If your occupations are exclusively BLS estimates, the answer to this question lies in the BLS publication files themselves.

The “IN” (or so-called “Internet”) publication files contain no summary occupations! To get the summary occupations, you must load the corresponding “SO” file. For example, to get the North Carolina 2000 statewide cross-industry estimates for both detail occupations and summary occupations, you would need to load two files: INSX0NCF.dbf and SOSX0NCF.dbf! But what if the estimates are LEWIS-calculated? How could the summary occupations still be missing? Well, you have to work at this one but it IS possible! In LEWIS, the summary occupations are assigned to various classes. By default, the “all occupation” code is in class 0, the SOC-2 occupations are in class 2, and the SOC-3 occupations are in class 3. Also by default, classes 0 and 2 are estimated and class 3 is not estimated. These setting are controlled via the “Estimate Properties” panel. If you do no check the box next to the class, the class is not estimated. And what about the wage history? The wage history section of the area profile report compares an occupation against “All occupations” and “Occupational Group”. If the corresponding wage is not available or is not publishable, there is nothing to compare against and one or both sections are omitted. To get the section displayed, simply ensure that there is a publishable summary occupation available. You can do this either by estimating the summary classes or by loading the appropriate BLS publication file.


9. What is the difference between mean and median wage?

The OES program produces estimates of wages by occupation. These occupational wage estimates are either estimates of mean wages or percentiles, such as the median wage.

Mean

A mean wage is an average wage. An occupational mean wage estimate is calculated by summing the wages of all the employees in a given occupation and then dividing the total wages by the number of employees. Since the OES survey collects counts of employees in pre-defined classes of wage (COWs) rather than actual wages, each year BLS determines a single mean wage for each class. This mean is based on data collected during the National Compensation Survey and can be viewed in the "Midpoint" column on the "Subintervals" tab of the "Advanced Estimation Properties" panel. For the most recent survey year, every worker reported in the COW is assumed to have the same wage regardless of their occupation. But when prior survey data is considered, the interval means for each COW are adjusted based on the ECI family of the reported occupation. After adjustment, workers reported in the COW that year are assumed to have the same wage only if they are in the same ECI family.

Median

median wage is a boundary. An occupational median wage estimate is the boundary between the highest paid 50% and the lowest paid 50% of workers in that occupation. Half of the workers in a given occupation earn more than the median wage, and half the workers earn less than the median wage. When prior survey data is considered, the wage ranges for each COW are adjusted based on the ECI family of the reported occupation. This results in a large number of subintervals which, after overlapping is removed, can be used to provide a precise estimate of where the median or any other desired percentile lies.

Who Cares?

Aren't they about the same? Mean is a simply calculated, easily understood statistic. But it says nothing about the distribution of wages in the population. In a perfect normally distributed population, the mean and the median should be the same. But, how many populations fit this mold? Consider the following simplified example: Workers 1-9 make $7.25 Worker #10 makes $35.00 In this case, the mean wage is about $10. Not a bad average salary. But nine out of ten workers make less. Could worker #10 be misclassified? Could he be the supervisor, the owner, or someone else that isn't really doing the same job? Could it be a simple keying error? Of course not! This never happens! The median is only $7.25. In fact, the 90% percentile is also $7.25! Whenever you find yourself writing the words, "average worker" instead of "average salary", you should consider using the median to describe the situation.


10. How can I use CSS to dress up the HTML output?

The key to using style sheets with LEWIS is the eds.css file. This file gets created in the "root" or topmost directory where you publish tables. You can view and edit this file with a tool like notepad or wordpad. Or, Bradbury Software has a popular visual tool, TopStyle, which may also be used to manipulate cascading style sheets. A fully functional evaluation copy is available at www.bradsoft.com. If you open the default eds.css file, it will look something like this:

td {
   font-family: serif;
   vertical-align: top;
}
th {
   font-family: serif;
   background-color: #C0DCC0;;
}
a {
   text-decoration: none;//Potential Accessibility Problem
}
select {
   font-family: serif;
   font-size: 9px;
}

What does this mean? Each line modifies the default display behavior for a particular HTML tag. The first line affects "table data" identified by the TD tag. It puts in in a "serif" font and makes the data align with the top of the area where it is displayed. The second line modifies table headers giving them their ledger green color. The third removes the default underlines from hyperlinks (aka anchor tags). And the final line sets a font for the "select" boxes (dropdown selection boxes) used for the Java navigation. Well, that should look familiar. Ho Hum! Now let's make a few minor changes to the file and see what happens. After recent events, people in many parts of the country are displaying their patriotic spirit. You see red, white, and blue everywhere. People are flying the flag. Well, what could be more American than people making money? Hmmm....

td {
   font-family: sans-serif;
   font-size: 9px;
   vertical-align: top;
   color: red;
   font-weight: bold;
}
th {
   font-family: sans-serif;
   background-color: red;
   color: white;
}
a {
   text-decoration: none;//Potential Accessibility Problem
}
select {
   font-family: sans-serif;
   font-size: 9px;
}
body {
   background-image: url(afbg.jpg);
}

The first thing to notice about this file is that it is almost the same as the first file. We added attributes to display table data in bold red and modified attributes to display the table headers in white on red. The font was changed from a "serif" to a "sans-serif". And, in keeping with the patriotic theme, we put a watermark image of the American flag on the page. Wow! And the best part is that I can change this file days,or weeks AFTER I publish the estimates. There was NO CHANGE to any of the pages published by the system. Realizing that you guys are probably not going to publish this one, let's play some more. Here's the output from LEWIS published in a similar style to the old LEWIS download page. The background used is one that is supplied with FrontPage; however, there are literally thousands of backgrounds available for free on the web. Or you can take a photograph or gif images and use a tool like M$ Photo Editor (ships with Office) to create a watermark. Just stretch to size, reduce the contrast, and increase the brightness.

td {
   font-family: "Comic Sans MS";
   vertical-align: top;
   color: Maroon;
}
th {
   font-family: "Comic Sans MS";
   background-color: Maroon;
   color: white;
}
a {
   text-decoration: none;//Potential Accessibility Problem
}
select {
   font-family:"Comic Sans MS";
   font-size: 9px;
}
body {
   background-image: url(WB00516_.gif);
}

Finally, here's one more. Following the idea that green is the color is the color of money (and wages=money!), here's a page with a green theme. It uses the same background as the prior page but a more serious CG Times font. I also attempted to box the table data. This worked but not as well as I would have liked. If someone wants to do this but has heartburn with the extraneous boxes around the title send me an email...

td {
   font-family: "CG Omega";
   vertical-align: top;
   color: Green;
   border-width: 1px;
   border: 1px solid;
}
th {
   font-family: "CG Omega";
   background-color: #006400;
   color: #7CFC00;
}
a {
   color: Green;
   text-decoration: none;//Potential Accessibility Problem
}
select {
   font-family:"CG Omega";
   font-size: 9px;
}
body {
   background-image: url(WB00516_.gif);
}

Want to know more? Further information on the capabilities of style sheets is available at http://www.htmlhelp.com