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

[developerbuzz]

@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)

[WeaverStever]

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]

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]

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]

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]

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]

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

[RichardWallis]

@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]

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]

@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]

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.