Understanding Society User Support

Many thanks for your enquiry. The Understanding Society team is looking into it and we will get back to you as soon as we can.

We aim to respond to simple queries within 48 hours and more complex issues within 7 working days. While we will aim to keep to this response times due to the current coronavirus (COVID-19) related situation it may take us longer to respond.

Best wishes,
Understanding Society User Support Team

Dear Matteo,

First of all, I am sorry for the inconvenience, I understand that sometimes the waiting time to get access to UKHLS data can be frustrating and full explanation of all aspect of the data is not always readily available. We are currently investigating why these codes were assigned in some cases, I will get back to you when I know more.

Regards,
Piotr
UKHLS User Support Team

Dear Piotr,

thanks for your reply and appreciated efforts - and apologies for the initial disgruntled tone. Looking at the labeling of values, I can now guess what is perhaps the case (and perhaps also documented somewhere) - that is, that the ISCO88com version has been used. The class headings of those non-matching classes track the European version much better than the international version. In three cases, the code actually exists in ISCO88com (2470, 9320, 9330). However, the problem remains for all other codes. I attach the completed version of the list provided above.

Two other apparent anomalies. In all observations coded 2470 (again, existing in the ISCO88com version), the limited 3-digit version is always coded as missing value (-9). Moreover, the code for "Armed forces" seems to be mistaken in its own way: the ISCO88 is 0110, the ISCO88com is 0100, while the survey code for jbisco88 is 100 (and its limited version 10) - in other words, the problem here is not a trailing zero in place of a positive integer, but a missing leading zero (vis-à-vis ISCO88com) or an altogether different number (vis-à-vis ISCO88).

I wait for your updates.

Best,
Matteo

Dear Matteo,

Thank you for your additional clarifying comments.

The coding into ISCO-88 in UKHLS was done by translating the SOC 2000 (the British Standard Occupational Classification) codes using a correspondence table, in other words, the coding into ISCO-88 was not done from the raw text fields. Wherever it was impossible to find a match for a given SOC 2000 code, one of the codes you identified was assigned. A few examples:

1140 "SENIOR OFFICIALS OF SPECIAL-INTEREST ORGANISATIONS" (non-existing 4digit ISCO-88, but present in the UKHLS variable) - the SOC 2000 code in this case was Senior officials of special interest organisations, so it's more general that the 3 ISCO-88 unit group titles (1141,1142,1143), hence a direct match is impossible

2110 "PHYSICISTS, CHEMISTS AND RELATED PROFESSIONALS" (non-existing 4digit ISCO-88, but present in UKHLS variable) - the SOC 2000 code in this case was 2113 "Physicists, geologists and meteorologists", again, a direct match is not possible, because the ISCO-88 unit group titles combine individual occupations differently, that is, meteorologists are a separate unit group and so are geologists

Thank you very much for your feedback, we will review the coding procedure to see if we can make it more accurate. However, please note that in case any amendments were to be done, this would be available - at the earliest - in the next data release, i.e. November 2023.

Best wishes,
Piotr
UKHLS User Support Team

Hi Matteo,

I'm really sorry we missed your follow-up. Yes, your description of our coding procedure sounds about right. Also, the merging procedure you're proposing is sensible. Thank you for highlighting the issue with the code 2470, we will have a look at it.

Best wishes,
Piotr Marzec,
UKHLS User Support