Understanding Society User Support

Hello Michael,

For a similar issue, please refer to Issue #2248, which you can access here: https://iserredex.essex.ac.uk/support/issues/2248.

I hope this information is helpful.

Best wishes,
Roberto Cavazos
Understanding Society User Support Team

Hi Roberto,

Thanks for the reference - this clarifies what the issue is. However, this does not really resolve the issue in my case, as the UK Govt's definition of key workers is a cross-reference matrix of SOC2010 and SIC2007. I am also using the HRMC definition of furloughed industries, which only uses SIC 2007. Without an accurate representation of SOC/SIC this could possibly make the group estimates unstable.

In terms of a solution, would you recommend using the samejob flag? This seems to produce quite similar estimates to the previous wave once weighted, see image attached:

Alternatively, I could use jbsic07_1_cc and just look at the first job for wave n?

Another option would be to consider, as you explained, highlighting the individuals with multiple jobs and only using the first job for their sic classification? It would be good to get some guidance on a specific method as it is not possible to reliably use the latest wave (n) otherwise, and I'm looking at the recovery since Covid, so it's really the crux of my project.

Also, in order to externally validate the study results, e.g., with the LFS, it is necessary for the UKHLS SIC codes to be accurate and based on the same definition as the current job definition in the previous waves a-m.

Many thanks in advance,

Michael Francis

Hi Michael,

What we’ve found so far is that jbsoc00 appears to be the best option, as it has fewer missing values. I think you could use the ONS look-up tables to convert SOC2000 to SOC2010 codes and then make use of the cross-reference matrix you mentioned. (I’m attaching the file)

The analysis on the best way to address these issues is still ongoing. Once we have a reference guide or recommendation, we could share it with users as a tentative solution, at least until the next information release. I’ll keep you updated as soon as we know more.

I think it’s a good idea to use the samejob variable to help identify those who actually changed jobs (and therefore their SOC might change) versus those with only apparent changes. Just keep in mind that this question is only asked when the respondent has the same employer (jbsamr = 1), which means there could be people working for the same employer but in a different role or position, so their classification may still change. I think you can handle this by considering all possible combinations of the cjob, jbsamr, and samejob variables.

Regarding jbsic07, you could consider populating the main job classification when it's missing, by assigning classifications from multiple jobs when jbhas == 1. At the same time, you could apply the approach mentioned above.

I hope this information is helpful.

Best wishes,
Roberto Cavazos
Understanding Society User Support Team

Dear Michael,

The only possible fix for the n_jbsic07_cc variable is to backfill it using data from Wave 13. This should have been done before the data release in November 2024, but unfortunately, it wasn’t, due to an oversight on our part. However, we have since discovered that multiple jobs variables series (n_jbsic07_x_cc, e.g. n_jbsic07_1_cc, n_jbsic07_2_cc, and so on) are also partially incorrect. As a result, this fix can only be applied to respondents who had only one job in both Wave 13 and Wave 14. In such cases, the fix should be applied as follows:

gen n_fulljbsic07_cc=n_jbsic07_cc
replace n_fulljbsic07_cc=m_jbsic07_cc if n_jobcodechk01==1 & m_multijobs==1 & n_multijobstotal==1 & inrange(m_jbsic07_cc,1,99).

Regarding the lookup tables – the Special Licence provides access to the 4-digit version of SOC, which will make your task somewhat easier, though it won’t eliminate the issue of multiple possible matches for a single SOC2000 code. Unfortunately, we don’t have a better solution at this time.

The discrepancy between jbsoc00 and jbsoc10 (i.e. missing values in the latter) arises from individuals in continuous employment who haven’t changed jobs since the introduction of SOC2010 in Wave 3. Please see the text of our reply to a similar query from a few years ago:

we use dependent interviewing (DI) to minimise spurious changes in occupations, so instead of asking for a new description of the current job every wave we ask whether the job is still the same as last time interviewed. If it is still the same, the previous occupational code is fed forward. When a new classification scheme is introduced, such as SOC 2010 in w3, there are no values from the previous wave that could be fed forward, hence we see the data gap [-9] in W3 (or later) for those cases who continue to have the same job as they had before. 'Before' in this context may actually refer to a job the respondent held in the BHPS already (DI started in BHPS W15). Plucking this data gap requires resource-intensive coding of the freetext data.

We understand that this is inconvenient, and we will consider releasing a simplified 1:1 correspondence table between SOC2000 and SOC2010. However, I can’t guarantee when this might happen. I’m sorry for what I understand may be a somewhat disappointing response.

Best wishes,
Piotr Marzec
UKHLS User Support