NCES IPEDS data for Database/IT professionals #3

If you were reading my previous post about importing the NCES IPEDS data, you might be wondering what will be the next.

Well, it turns out that nothing is easy. I have spent most of the past 3 months devised R functions that can help me retrieve data from the few IPEDS data I have imported. I finally reached a point where I have a reasonable approach that can allow me to search interested variables and check related information concerning that variable. For example, if I am interested in the head count of American Indian, I would like to know how the head count can be broken down - for example, by students level, by full-time/part-time enrollment status, or by the program enrolled. In addition to be able to see how the head count can be broken down, user may also interested in if that variable also available for other years or if there is a definition changes over the years.

The R program also allows advanced user to retrieve aggregated data instead of the raw data which will improve the efficiency in processing and analyzing the data.

After the prototype of the R program is done, I resumed the process of importing more data. As all experienced data analysts should know, there are always show stopper when you obtained data from external source - no matter how reputable the source is. If you are in a data chain that received clean data from your colleague, you should appreciate the work they have done.

Just to demonstrate how things can go wrong even with an well established IPEDS operation, I will list few, just few, problem I ran into. It is true, if you can envision all possible errors or situation and devised all solutions for it, you can argue that all thing should be automated and manual work will never be needed. But, aren't you too unrealistic? Most likely, to achieving automation in that level, you will first run into a whole sets of unexpected situation and you worked you butt out to devise the alternates. But who is to say, the latest unexpected is the last unexpected?

Here are few issues that I ran into with the IPEDS data:
1.  Extra comma are at the end of the data lines
2.  Column names is in the wrong order/column or places
3.  Variable names do not match the column names.
4.  Leading and trailing blanks around the real data.
Beside the above, the use of dot as the indication of NA/NULL is also not the easiest to handle with some software tools. Speaking of the software tools, while is it totally possible to develop tools from beginning to the end, it is usually not the fasted way to get things done. On the other hand, no matter what tools you used, it is not likely to meet all your need and you will be limited and restrained by the tool you can find and used.

In my case, my database importing tool has very restrict rule on the csv file it will accept - for example, extra comma behind the data is a no-no. Dot will not be treated as NULL... etc.

At this point, I can import about 10 years of data in less than 2 hours. But it is those few exceptions that will take me days and days to figure out why it won't import and devise solution around it. As to this day, I am still fighting exceptions.

Traditional data analyst/researchers are satisfied to clean up a data set by hand and proceed to analyze the data. They do not have the ambition and fore-sights of engineer or science worker - generalization is to be sought and the goal is to handle many many data that is to come - a system is what is sought not a special/single case.

People of general are ignorant in the work involved in achieving automation. It seems that the automation is every where and anything less than total automation is considered failure or defect and unthinkable. They haven't realize that the beautiful automation they see is the work of a major software company - not the work of an individual or a less comprehensive team of software worker. The reason they are commercial software should have put you to think straight - but still, people are naive - discount the efforts of a less comprehensive team - they believe there would be no manual work for the less comprehensive solution. The especial sad thing is these are people received benefits while refuse to credit works been done by others.

No work and knowledge should ever be worth to share with these ignorant.

NCES IPEDS data for Database/IT professionals #2

This is a continuation of my previous blog on importing the NCES IPEDS data into database for IT/Database professionals.

As described in my last blog, I was able to apply few IT know-how and managed to download all IPEDS data automatically to my desktop. The next mission is to import those data automatically into database. 

One of major task to support social science research, as described in my previous articles about the ACS PUMS data, is the ability to import and provide the label information for both variables and values. In current case of NCES IPEDS data, these information can be obtained from various places.One possible place is to use the 'Dictionary zip file' download provided by the IPEDS. Browsing through few of the information provided by the dictionary zip file, you realized that is really not the idea place to get these kind of information. The zip file provided by IPEDS do not have consistent format. In some years and surveys, the information is provided in Excel format. In other years and surveys, these information were provided as web-page html formats.

After studying how IPEDS made their data available to statistics software, I, actually, think it is quite unique and workable - IPEDS provide a single, or 2, .csv file to support all statistics software. It then provide a 'program/script' for each statistics software. The program or the script, basically, provide instructions to import the .csv file, to assign variables labels to each column and to assign value labels to each values. So, basically, all the label information for both variables and values are embedded in the program/script file. The question, of cause, is how to extract those information - For programmers went through bachelor degree training, they understand that this is a topic under the compiler study.

Based on my work long time ago, I was able to modify the parser and parse the info in the .sps file into database. The code to pull data in the csv to database is largely the same as I did with the ACS PUMS excepting few reformatting and unzipping. Some of the IPEDS csv files using the dot '.' to mean NA and some of the quoting isn't very consistent. I decide to convert tabs in the file to space first, then transform the file to tab delimited and that seems to work fine.

Sam Barbett at IPEDS was also contact about the release of 'Final' data - IPEDS, in general, release data in two phases. The first one is called provisional while the second one is called final. According to Sam, when the final data released, the new/final csv file will have a '_rv' suffix added to the file name, even though the .sps file isn't updated.

The other problem I run into is line termination used in the downloaded .sps file. Most of my processes is run/executed under Windows environment which means that lines in a file are terminated by the Carriage-Return/Line-Feed pair instead of a single Line-Feed character used in most Unix systems. By modifying my code to accommodate that, I was currently be able to process couple years of data without run into errors.

Overall, the process is smooth and the next task would be how to use these data effectively and efficiently.

NCES IPEDS data for Database/IT professionals

Personally, I am an IT professional worked in an education agency. (Have) Been in this position long enough and dealing with social science researchers a lot. One of the interesting observation is that even though the social science researcher dealing with data all the time, without the IT background still limited their ability to handle large amount of data efficiently. A lot of time, these staffs relied on expensive commercial software and computer hardware to perform their tasks. When leading projects, often times, they are limited by their vision to provide and deliver efficient data products.

On the other hand, people with strong IT training can have better visions on how things work and know the real limits of things and set the goals that others can't - I love this Elon Musk story Simple math is why Elon Musk’s companies keep doing what others don’t even consider possible, where Physics is said to be applied first, which is the fundamental that dictated the limits. The value of a real STEM training is the vision and the know of limits. Apply to the data processing, the IT is the know.

The Integrated Postsecondary Education Data System (IPEDS) refers to a set of data collected from a large set of Postsecondary Education Institutions of United States. The survey is conducted by the National Center for Education Statistics. The data collected is available for anyone's use. For causal use, you can easily obtained the data you are interested in, manually. However, as we all know, the real power of data multiplied if you can have all the data in one place in a readily to be used state. Yes, most likely we are talking about a database.

Glance over the data retrieval option offered by NCES/IPEDS, the 'Complete data files' option seems to be the best way to retrieve the whole IPEDS data set. Practicing a bit manually, you soon realize that manually select and download will still take you a long time to even download the file let alone importing them.

With enough IT knowledge, a reasonable approach to this problem could be: 1) Save the download page; 2) Make minimal fixes to the page so that it conform to XML; 3) Device a short XSLT translation script; 4) Copy the translated page into database; 5) With the list of file to download on hand, wrote scripts to download files automatically.

In addition to the above implementation, to facilitate the continuity of time available for download, a scheduling mechanism is also implemented.
  

Population migration derived from ACS 2015 5-year PUMS dataset

Now that we have got all the data imported, let's have some fun.

For those of you who knows me, I have been an advocate for open source movement for a while now. The statistic software I preferred to use have been the R. However, I had not spent a lot of my time on R - I think we all understand that people got a lot of things to do and we revisit a tool when we needed to.

Couple months ago, I spent my spare time and wrote quite a bit of code in R and I thought that I will be right at home when I decided to take on this migration project. Boy, am I wrong about this... gosh. Well, spent almost whole day and end up fixing some of the bugs - well, not really a bug but because I have decided to include the NA definition into my definition database, it caused some problem when referencing these definitions from my old code. Anyway, got it fixed but did not really use the R.

Well - my IT training kicked in - I realized that instead of using the statistic software for this project, a few SQL statement will largely simplify the task to nothing. Come to think about this, the SQL not only easier, it actually run much faster - Database is designed to run from hard disk, it is not like most statistic software will load all the data into memory and tied up the computer resources. By the way, a while back I have this idea of using database as my statistic software. I actually check out MS SQL documentation on customer functions and, do you know what, it is totally possible. Now, the question is who is going to take on this project.

Anyway, I end up running few SQL statements and dumping it into Excel with a bunch of formula - sorry, I haven't really invested in the Open Office yet.

OK. Let's get back to the topic. American Community Survey is conducted by US Census Bureau in an annually basis. The PUMS file is sampled from the collected data and allows user to use these sample to derive results that weren't readily tabulated by the US Census Bureau.

Inside the ACS survey, there is a question that asked respondents where they lived a year ago. Based on this question, we can look into the PUMS data and derive some useful information from it. One of the interesting application of this question is when it is combined with the education attainment info of the respondents. This allowed data analysts to see that, for people moving out of a state, what kind of education these people acquired and, hence, the brain drain if highly educated people left a state.

Click here for the resulting file - please noted that for any result derived from sampling, there are associated errors - this file does not come with the 'margin of errors', which describes the range the real value may lie. In our case, with large enough margin of errors, the real value for an in-migration could end up in negative and, hence, associated with the idea of  an out-migration. So, the file is for references only. The author is working on consolidate some of the categories and, hopefully, can report some data with reasonable 'margin of error'.