It doesn't make sense for these to be unique applications, they are 100% identical across the board. I think whatever method they're using to cull out this information is duplicating entries, there are too many of the 100% identical duplicates for any other explanation. If it was one or two companies I could write it off as bad paperwork habits, but every search I do in any city going for any time frame gives me at least 1 of these per page. That's gotta be a bad data procedure on their part. Also if you hilight text you'll find there are invisible characters all over the place, when you include that these become unique entires, I think they have something to do with why these dups are showing up. Now I'm a nice guy so I'll assume sloppy code not deliberate falsification of data, but either way the site isn't presenting an accurate picture.
Not ONCE in there do I mention dead companies. That's the post you were replying to when you said I wasn't using it right. Clearly you were saying the DUPLICATES, which was the ENTIRE subject of the post, were the result of user error. If you're such a bald faced LIAR that you'll now claim you were referring to an entirely different subject do us all a favor and get the hell off FR. We don't need LIARS around here, and until you can admit the TRUTH you are a LIAR across the boaard 100% nothing you say should EVER be believed by ANYONE.
Liar.
BUT, when you have the gall to launch absurd accusations and lies about me, then I have no choice but to respond accordingly. You childishly nitpick the VERY minor issue of whether or not I had told you at some point that you may not have been using the selection screen correctly, yet you ignore the EXTREMELY relavent fact that you WERE completely wrong about your ridiculous "bad data" theory. You resort to smears and name calling in an effort to discredit the facts concerning this issue. So if you want a complete rehash of what was said and who said what, so be it. Apparently, this is what you want. You may soon realize that it wasn't the best course of action for you to pursue. I'll address this issue post by post, and comment on each matter at hand.
To begin, let me just say your analytical skills are non-existant, and you jump to conclusions that fit your pet theory for little or no reason. You see something that you don't understand, and you instantly conclude that the database has invalid data.
You initially complained about the fact that there were companies that no longer existed in the database. Well, those companies DID in fact exist when they filed their H1-B visa applications. Let me refresh your memory on that exchange.
From post #166
To: FormerLurker
Hey that's real cool how this thing doesn't weed out for companies that don't exist anymore, sure helps make the problem look huge. Also interesting how it includes every single application by a company, even the renewals, to fluff the numbers.
I like the one you posted a couple of weeks ago that gave state by state numbers. Much more useful.
166 posted on 11/04/2002 2:03 PM PST by discostu
Looking back at this post, it becomes plainly obvious that you have no concept of what a database is. You think that simply because a database contains historical data, that there must be some sort of conspiracy to "fluff" the numbers. Databases are SUPPOSED to contain historical data, and if you can't understand that, you have no business arguing with me about anything. By definition, data that is stored in a database is historical. By applying selection criteria against that data when performing queries, only that data that fits the criteria is returned. Of course you need to filter out that which you aren't interested in, and if you don't you obviously aren't going to see a valid dataset. For instance, if you wanted to count the number of people that lived on a certain street, you would perform a query for all people on that street and sum the result. If you didn't filter out those who DIDN'T live on that street, you'd get an invalid result.
So, you apparently couldn't understand the concept that when you looked for records without specifying a date, the query would return records for ALL dates. And since the data contains records from prior years, there are of course records relating to companies that are no longer in business.
Thus, I posted a response to your post 166.
From post #168
To: discostu
Hey that's real cool how this thing doesn't weed out for companies that don't exist anymore, sure helps make the problem look huge.
I didn't see any companies that didn't exist when I used it for my area. I searched on applications for 2001, and the max limit of 500 applications was returned. A significant number of those applications had anywhere from 5 to 20 workers on them..
168 posted on 11/04/2002 2:10 PM PST by FormerLurker
Realistically, I should have told you that you didn't know what you were talking about and to simply go away, but I was trying to be civil.
Next, we have your post 169. There you continue with your concerns about "stale" records.
From post 169
To: FormerLurker
If you search on Tucson you'll find Integra Technologies International, which went bye-bye Thanksgiving week 1998 (well they laid off all but 2 employees, who were working paying support contracts, and they got sold with the contracts in early '99). Actually it got bought by Ikon Office Solutions in 1996 (but they never could decide what the name of the company was supposed to be after the buy), who did a great job of finishing running the company into the ground then put gave it the Ol' Yeller in '98. For the life of me I can't remember the name of the New York company Itegra merged with that's how we (that's where I started, but I saw the handwriting on the wall and was actually in the process of stealing employees when the axe fell) got the H1Bs in the first place. But I'm betting that company shows up on the list too.
169 posted on 11/04/2002 2:25 PM PST by discostu
So you "bet" that a particular company shows in up in a database that contains records of companies that submitted H1-B applications, as if there was something incredulous about that. The database is SUPPOSED to contain ALL records of H1-B applications submitted, not just those that relate to companies that are still in business. Again, you seem to be challenged with that concept.
I responded to you in post #170
To: discostu
As I said, you need to look at the application dates. You still see enourmous numbers for recent years.
170 posted on 11/04/2002 2:41 PM PST by FormerLurker
So here I told you that you should use the date criteria in your query. Of course, you should have already known that you should do a query by date if you only wanted to see the records that relate to recent applications, but obviously you didn't.
Then we have your response in post 171
To: FormerLurker
But the way they make the listing it makes things look worse. Over and over in there you'll see the same company with numerous identical listings, probably they're the same thing getting counted twice. As I said when looking at one of your own links ( http://www.nomoreh1b.com/h1-bCostPerState.aspx ) it clear this is only a problem is certain states, oddly enough all Democrat strongholds. And even in those states the depth of the problem is arguable because we have no corolative data between H1B's field of work and the unemployment numbers within those fields. There's a lot of assumptions built into saying H1Bs are responsible for the unemployment numbers, especially given the consentration of H1Bs in tech and the dot-com meltdown (which had its roots in bad business "plans").
171 posted on 11/04/2002 3:05 PM PST by discostu
You juggle the discussion between unemployment, the validity of the database, and your opinion of who caused the problem. You ramble about dot coms and business plans. It is here you begin to notice that which you later incorrectly refer to as "duplicate" records. We know now that those records are in fact valid, but at this point you raised the question. So we have the first mention of possible "identical" records at this point. You appear to lament that this database is supposed to relate H1-B visa applications with unemployment figures by state. The database is simply a collection of H1-B visa applications supplied by the Department of Labor and is not tied to any other database.
Next we have post 172...
To: discostu
But the way they make the listing it makes things look worse. Over and over in there you'll see the same company with numerous identical listings, probably they're the same thing getting counted twice.
Wrong. The multiple listings are separate H1-B applications which can contain multiple workers per application. Each unique listing is a unique applicaion. Nothing mysterious or magical about it.
172 posted on 11/04/2002 3:37 PM PST by FormerLurker
Here I correctly informed you that you were mistaken in your theory that there are records being "counted" twice. The records are not counted, they simply exist in the database. Each record represents a separate H1-B application, and those records were entered by the Department of Labor into their database.
Now here we have your infamous post 174.
To: FormerLurker
Are they? Seems odd to me that companies would have multiple identical H1B applications filed on the same day. See I go there and I see 4 listings for DCM ASIC TECHNOLOGIES LIMITED, all for programmer analysts all making $60,000/yr all starting on 2/15/01 all set to expire 2/14/04, all for 30 H1Bs; further down the page I see one for INFOSYS TECHNOLOGIES LTD for 100 employees so I know that 30s not the max for a single filing, don't know if you could file for 120 but I know you could file for 100 on one and 20 on another; further down still I see 3 listings for UBICS INC. all 100% identical again for 50 employees each.
It doesn't make sense for these to be unique applications, they are 100% identical across the board. I think whatever method they're using to cull out this information is duplicating entries, there are too many of the 100% identical duplicates for any other explanation. If it was one or two companies I could write it off as bad paperwork habits, but every search I do in any city going for any time frame gives me at least 1 of these per page. That's gotta be a bad data procedure on their part. Also if you hilight text you'll find there are invisible characters all over the place, when you include that these become unique entires, I think they have something to do with why these dups are showing up. Now I'm a nice guy so I'll assume sloppy code not deliberate falsification of data, but either way the site isn't presenting an accurate picture.
174 posted on 11/04/2002 5:09 PM PST by discostu
I was WAY more forgiving of your allegations back then than I should have been. You make SERIOUS allegations in relation to this body of data, and obviously did NOT read the FAQ or bother yourself with any meaningful thought in relation to what you were seeing. Let's pick this post apart item by item..
First of all, you again question the fact that there are mulitple records with seemingly identical data. It is now clear that it is standard practice to submit multiple applications with identical start dates and job title. It wasn't clear at the time, so we went on to discuss in later posts the reasons why we might be seeing this particular phenomenon.
HOWEVER, you shamelessly and recklessly raise allegations that this is "bad data", that there is "sloppy code", and that it might even be DELIBERATE FALSIFICATION OF DATA. From one who doesn't understand what a database is or how to use it effectively, I find that to be not only a wild and reckless statement, but patently dishonest.
If you don't know what WHY you're seeing something that doesn't make sense to you, it's ok to raise a question. But instead of asking WHY you were seeing what you were seeing, you come to the conclusion that "the site isn't presenting an accurate picture". Who are YOU to make that statement and arrive at that conclusion?
Let's look at exactly how you arrived at your "esteemed" conclusions;
If it was one or two companies I could write it off as bad paperwork habits, but every search I do in any city going for any time frame gives me at least 1 of these per page. That's gotta be a bad data procedure on their part.
That is highly questionable. Some might call it a lie, but I'll just say that it's questionable. I highly doubt that you did enough queries to get a meaningful sample in order to honestly make that statement. Of course we see seemingly identical records here and there, and we now know that it is common practice to submit applications in that manner. But there are MANY records that AREN'T identical for most any given company, and to state that every query returns at least one "duplicate" is a bit of a stretch. Maybe you just got lucky, who knows..
But to say that it HAS to be a "bad data procedure on their part" is more than just a bit of a stretch, it is a rash and faulty assumption. You might have said we need to determine WHY we are seeing what we are seeing, but you instantly come to the conclusion that there HAS to be a "bad data procedure on their part". You'd never make a good engineer, that's for sure. You'd be saying it HAS to be this, and it HAS to be that, when in fact it is something entirely different. You need to look at what it MIGHT be. If you said there is a POSSIBILITY that there is a problem with one of their "data procedures", then that would have been a valid and logical statement. You did not have anywhere near enough information at this point to state that it HAD to be anything.
Also if you hilight text you'll find there are invisible characters all over the place, when you include that these become unique entires, I think they have something to do with why these dups are showing up.
If you had bothered reading the LCA Database FAQs, you would have seen the following explanation..
Why is the Database so Difficult to Copy or Print?
It's no accident that the data is tough to copy or print because it's designed that way. Some limitations include disabled right clicks, disabled menu bar, insertion of random characters into the background, and colors to make it difficult to print large amounts of data. This won't be a barrier for people copying small amounts of data because these things can be cleaned with minimal effort. For most purposes people don't need more than a page or two of data to prove their point. People who want to copy large datasets should contact the webmaster to see how to pay for large reports.
In the future ZaZona.com would like to allow complete and unrestricted use of this data. For this to happen an organization that would be willing to help with the costs of running this database needs to come forth. Recently several labor friendly organizations that oppose H-1B have been contacted about sponsoring the database or even hosting it on their site but they have not yet agreed to help. Users will just have to live with the limitations that have been imposed until these technical and financial problems are solved.
So those "funny characters" have NOTHING to do with what you noticed as far as identical records, and have more to do with your lack of effort to read the FAQ.
Now I'm a nice guy so I'll assume sloppy code not deliberate falsification of data, but either way the site isn't presenting an accurate picture.
It's nice that you think so well of yourself, but I don't share your self image. You conclude that since you don't understand what you are seeing, it must be the fault of "sloppy code" if not the "deliberate falsification of data". You were so off base it is pathetic, you had nowhere enough information to make a qualified statement concerning the validity of the data, yet you declare that the website "isn't presenting an accurate picture". The picture that presents itself might not be something you'd like people to see, but it is there for all to see nonetheless. Your desperate attempts to discredit this information is beyond pathetic.
Now we have my response, post 178
To: discostu
The website is down right now, so I can't verify what you said. I doubt you were setting the search criteria properly though, as NONE of the searches that I've performed had any of the characteristics you describe. I'll check back later and see what I can find about the specific case you mention.
178 posted on 11/04/2002 5:49 PM PST by FormerLurker
So THERE YOU GO. The damn website was down, and YOU'RE making a big issue over the fact that I suggested you weren't setting the criteria correctly. This is what you call PROOF that I was "lying" to you, and that I am a LIAR for saying that I didn't tell you that it was a user error related problem. Hey shucks, if you want to say that at one point I suggested that it might be a user error problem, if that would REALLY trip your trigger, have at it. But to salivate and rant over the fact that I might have told you that your search criteria might be incorrect when the website was inaccessible and I had no way of verifying demonstrates some degree of insanity on your part. THAT IS the crux of your argument now that you have nothing left in your bag of tricks.
I even TOLD you I'd look into it when the site came back up. And I DID look into later, and we DID relentlessly discuss the issues and possibilities. In the end, you were WRONG, the data IS valid, and that IS the way it is. No matter how much you cry, pout, hold your breath and stomp your feet, the facts remain the same. And no matter HOW much you attempt to smear me and falsely accuse me, I'll come back and demonstrate that you are a very disturbed individual who shouldn't post on subjects that he has very little knowledge about.
Not it's MY turn to arrive at some conclusions here. I'd say that I have enough data to work from in order to correctly arrive at my conclusions. You HAVE to have some sort of stake in this issue. You HAVE to be one of the following;
You are a pathetic little man. Now go away and stay away...