Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ISCO08 classification for occupationalCategory instead of BLS O*NET-SOC #2192

Closed
developerbuzz opened this issue Apr 1, 2019 · 14 comments

Comments

Projects
None yet
6 participants
@developerbuzz
Copy link

commented Apr 1, 2019

@developerbuzz,

It seems to me we should follow the example set in https://schema.org/Organization, where we have a field for isicV4 and naics industry codes.

When I write a script for a client, I provide both. I don't want my US client to be excluded from a Euro-centric search and vice-versa.

Whilst isicV4 would go some way and I do agree an industry classificationis would be beneficial, it doesn't tackle the classification of the occupation itself., only the industry in which the occupation resides. ISCO08 would be a far more suitable classification for the occupation and is an international standard not just targeted to Europe or North America

Originally posted by @developerbuzz in #1698 (comment)

@developerbuzz developerbuzz reopened this Apr 1, 2019

@developerbuzz developerbuzz changed the title > @developerbuzz, Addition of ISCO08 classification for occupationalCategory Apr 1, 2019

@developerbuzz developerbuzz changed the title Addition of ISCO08 classification for occupationalCategory ISCO08 classification for occupationalCategory instead of O*NET Apr 1, 2019

@developerbuzz developerbuzz changed the title ISCO08 classification for occupationalCategory instead of O*NET ISCO08 classification for occupationalCategory instead of BLS O*NET-SOC Apr 1, 2019

@WeaverStever

This comment has been minimized.

Copy link

commented Apr 1, 2019

I disagree with the one system approach, I'd prefer to see separate properties, one for the North American SOC and another for the International ISOC(08). While the systems are similar, they are not identical and the previous version of the ISOC was in 1988. Twenty years between updates for occupations is far too long. The SOC (NAICS) has major updates every decade, and minor updates during the decade.

Using https://schema.org/Organization as an example, the schema provides a field for the North American (NAICS) industry system and the ISIC international industry system. It makes sense to do the same for occupations and let the consumer decide which system, or both to provide or query for.

Additionally, it appears the schema is missing a way to provide Classification of Instructional Programs (CIP) codes. (College majors and minors)
https://nces.ed.gov/ipeds/cipcode/Default.aspx?y=55

I don't know if there is an international equivalent to the NCES-IPEDS CIP system.

Some info on the UNESCO, International Standard Classification of Education (ISCED)
https://en.wikipedia.org/wiki/International_Standard_Classification_of_Education

http://uis.unesco.org/en/topic/international-standard-classification-education-isced

@rlzijdeman

This comment has been minimized.

Copy link

commented Apr 10, 2019

hi peeps, I (working with occupational classification systems as daily job) agree with @WeaverStever. Even if you were to find agreement amongst yourselves to find BLS or ISCO-08 to be 'the one classification', please know that these classifications are updated every two decades or so. (e.g. for ISCO, there's also 1968 and 1988). Thus minimally, you would need to provide the context with which you can adopt occupational classification systems (for this also check XKOS ( http://htmlpreview.github.io/?https://github.com/linked-statistics/xkos/blob/master/xkos.html ) )

@developerbuzz

This comment has been minimized.

Copy link
Author

commented Apr 10, 2019

Happy with the seperation approach in general, but how many properties should we have? What happens if Africa or Asia decide they need a classification, or the Grand Duchy of Luxemberg? If I understand @rlzijdeman correctly we should be flexible enough to suuport multiple systems and thus would be better providing just two properties.

  1. Classification system. I.e. SOC, O*NET, ISCO etc etc
  2. Occupational value. I.e. the occupation identifier of the corresponding system.
@RichardWallis

This comment has been minimized.

Copy link
Contributor

commented Apr 10, 2019

I share the 'how many properties should we have' concern.

The suggestion by @developerbuzz would be a step in the right direction.

However, it effectively duplicates the functionality introduced with CategoryCode and its super-type DefinedTerm.

To achieve the suggested outcome we could simply add CategoryCode to the expected types for the occupationalCategory property, plus add an example or two...

  ...
  "occupationalCategory": {
       "@type": "CategoryCode",
       "inCodeSet": "ISCO-08",
       "codeValue": "215",
       "name": "Electrotechnology engineers"
       }
  ....
@rlzijdeman

This comment has been minimized.

Copy link

commented Apr 10, 2019

and
3. https://schema.org/jobTitle

Explanation:

  • jobTitle is the basic building block: the minute description that people and companies provide to describe a series of activities performed at work: a job.
  • occupational code (or as you say occupational value) is indicative of an 'occupation': an aggregate of jobs in which similar activities are performed. E.g. in ISCO-08 occupational code, 5156 refers to the occupational grouping 'Driving Instructors', which entails jobs like 'lorry driving instructor', 'motor cycle driving instructor'.
  • classification system would then refer to the way jobTitles are aggregated, e.g. ISCO-08.

The people, like myself, who would like to go nuts on the internals of these classifications, could then use XKOS to provide more detailed descriptions, while being perfectly compatible with these more generic descriptions.

@developerbuzz

This comment has been minimized.

Copy link
Author

commented Apr 10, 2019

@RichardWallis Looks good to me, the example you provided makes complete sense and provides the flexibility we need. Many thanks for the contribution.

@RichardWallis

This comment has been minimized.

Copy link
Contributor

commented Apr 10, 2019

@rlzijdeman An interesting expansion of the proposal.

I would suggest that DefinedTerm is the appropriate expected type here. A job title is probably better described as a 'term' rather than a categorisation. As DefinedTerm is a super-type of CategoryCode your examples would still be valid.

@rlzijdeman

This comment has been minimized.

Copy link

commented Apr 10, 2019

Dear @RichardWallis, I don't have a CS background, so maybe reading this completely wrong, but I think you are suggesting that objects of the property schema:jobTitle were to be 'formal definitions' only. From a research perspective, this is only true in a minority of cases: even companies seldom use definitions, and people rather advocate themselves as 'software engineer' if working at Bad-Websites-R-US, while as 'Google software engineer' if working at Google. Both were to be classified as '2512' 'Software Developers' in ISCO-08 terminology.

I definitely would concur that 'Software Developers' in this example or 'Electrotechnology Engineers' in your example are of type schema:DefinedTerms.

Hope this makes sense.

@RichardWallis

This comment has been minimized.

Copy link
Contributor

commented Apr 10, 2019

@rlzijdeman I am suggesting that a jobTitle could be, as now, a Text value or they could be a formal definition if one was available. Thus keeping software engineers from both Google and Bad-Websites-R-US happy.

@rlzijdeman

This comment has been minimized.

Copy link

commented Apr 10, 2019

ah! that would be very nice indeed @RichardWallis. It would actually resolve an issue I have in creating Linked Data of historical occupations in HISCO (the 19th century ISCO). I now distinguish between 'raw' and more 'formal' jobTitles respectively through skos:hiddenLabel and skos:prefLabel, but your solution formalises that distinction.

RichardWallis pushed a commit that referenced this issue Apr 10, 2019

Added CategoryCode to range of occupationalCategory & DefinedTerm to …
…range of jobTitle.

Created examples for both.
Addresses issue #2192
@WeaverStever

This comment has been minimized.

Copy link

commented Apr 11, 2019

I like the proposed ability to allow the consumer to choose the dataset and not limiting to SOC v ISOC.

@rlzijdeman mentions legacy systems so I thought I would bring up the DOT system. Discontinued in 1998, but I do know that USCIS still reports in broad categories for H-1B visas. I would presume that other government agencies are still using DOT.

https://occupationalinfo.org/

@danbri

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2019

@philbarker - can you take a look at this please?

@philbarker

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2019

@danbri we already discussed it through the TalentSignal community group, see https://lists.w3.org/Archives/Public/public-talent-signal/2019Apr/0003.html & thread.(plus there were a couple of direct replies to me)

In summary: looks good.

A quick plug: those interested in this thread may be interested in joining the TalentSignal W3C community group We're just getting started, you would be most welcome.

RichardWallis pushed a commit that referenced this issue Apr 29, 2019

Removed duplicate definition of occupationalCategory
Updated description of occupationalCategory in respect of issue #2192
@RichardWallis

This comment has been minimized.

Copy link
Contributor

commented Jun 11, 2019

shipped in 3.7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.