Proposal for new Occupation type

[vholland]

A few times we have discussed adding an Occupation or Profession type (most recently issue #1410), but always from the perspective of the Person with the Occupation. For example, Jane is a Software Engineer or Joe is a Dentist.

For my work, I am more interested in the occupations themselves. What qualifications do you need? What is the estimated salary? Do these things vary by jurisdiction? (For example licensure requirements can differ from country to country.)

After reading through the past discussions, I have put together the following proposal, which I hope addresses the issues raised without having to create a lot of complexity.

• New type Occupation: A profession, may involve prolonged training and/or a formal qualification.

  • Many of the relevant properties already exist for JobPosting. The domains would be extended to include Occupation for:
    • educationRequirements
    • experienceRequirements
    • occupationalCategory
    • qualifications
    • responsibilities
    • skills
  • New properties would be:
    • estimatedSalary: The estimated salary for this occupation. The salary would be expressed as a MonetaryAmountDistribution. (See below.)
    • occupationLocation: The region/country for which this occupational description is appropriate. Note that educational requirements and qualifications can vary between jurisdictions.

• New type QuantitativeValueDistribution: A subtype of QuantitativeValue for describing a statistical distribution of values. Properties include:

  • duration: The time period the distribution is measured over.
  • percentile10: The 10th percentile value
  • percentile25: The 25th percentile value
  • median: The median value
  • percentile75: The 75th percentile value
  • percentile90: The 90th percentile value

• New type MonetaryAmountDistribution: A subtype of QuantitativeValueDistribution for describing a statistical distribution of monetary amounts. Properties include:

  • currency: The currency for the monetary values.

• New property on JobPosting:

  • relevantOccupation: The Occupation for the JobPosting.

• New property on Person:

  • hasOccupation: The Person's occupation. For past professions, use Role for expressing dates.

[thadguidry]

+1 generally Vicki. You did a great job ! covering the major potential pieces. Let's ensure we are not missing anything else. To that point, perhaps browsing actual datasets available can be helpful https://www.bls.gov/data/

One that I found just browsing the datasets is that of "Unions or Labor Unions" for particular Occupations ?
Probably others... just dig around and browse there. Great job again Vicki, I like it !

[jvandriel]

The only thing I have difficulty with is occupationLocation as it doesn't take (international) remote workers into account - a target group that's rapidly growing (which is an issue for JobPosting's jobLocation as well).

[vholland]

@jvandriel Agreed. I have been trying to figure out a clean way to fix this for JobPosting, but have not come up with an idea I liked well enough to propose.

[vholland]

See PR #1709

[philbarker]

Definition for occupationalCategory: "Category or categories describing the job. Use BLS O*NET-SOC taxonomy: http://www.onetcenter.org/taxonomy.html. ..." seems unnecessarily US-centric.

UK has SOC 2010, I'm sure other countries have their own, and there is the international ISCO-08. Ideally I guess that the coding scheme used would be that relevant for the occupationLocation

Perhaps list O*NET-SOC as an example rather than phrase as an imperative.

[vholland]

@philbarker I thought of that when I copied the existing text over. Ideally, we would allow authors to use any taxonomy. Whatever happened to the work to allow other vocabularies?

[philbarker]

@vholland Ah, yes, sorry only just noticed that occupationalCategory is an existing property reused. Is it worth noting this as an issue against that property? (and adding it as a use case for external enumerations!)

[danbri]

Talking with Sally and @subbuvincent from @TheTrustProject, there's a desire (see #1525) to be able to describe the skills/expertise of journalists on news sites. We thought about extending the use of http://schema.org/keywords but are now considering whether there's a connection to Occupation...

[thadguidry]

@danbri Journalists should be able to use skills and qualifications , once added to Occupation as @vholland laid out. (and that I and others are waiting on)

[mindyshaw33]

Why not connect everyone using maps, family search, facebook, google etc.. That way if ever a child gets lost we then could right away pull up google earth and in real time check the area, right? I keep thinking we need to connect everything, there could be a place that people could go to fill out forms on others too - for outside perspectives such as a boss (in relation to another) or a family friend or relative. It would be a huge project but a necessary one if we are going to live in "the future" one day.

…

On Wed, Aug 30, 2017 at 5:57 PM, Dan Brickley ***@***.***> wrote: Talking with Sally and @subbuvincent <https://github.com/subbuvincent> from @TheTrustProject <https://github.com/thetrustproject>, there's a desire (see #1525 <#1525>) to be able to describe the skills/expertise of journalists on news sites. We thought about extending the use of http://schema.org/keywords but are now considering whether there's a connection to Occupation... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1698 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGa9ec6eVThy8s4dMvLWljM0kVyRVSpIks5sdfbkgaJpZM4OXPBn> .

[vholland]

Merged into pending.

[danbri]

re occupationalCategory ... yeah we should have a look around the miniskos stuff and @RichardWallis had something related in Pending too. But it is an existing problem not one that was introduced here.

[rlzijdeman]

hi, also wanted to chime in on the occupationalCategory: there are so many and many people forget the historical ones... as in those from the 1950's-1980's still used today for comparative research, as well as the 'contemporary historical schemes', such as HISCO and OCCHISCO. I really would discourage, forcing people into a particular scheme...

[rlzijdeman]

also wanted to pose a question: for my work, I distinguish between job titles as taken from census and marriage data, like "nurse at St. Mary's hospital" or "baker at Buns and Croissants". While implementing the Historical International Standard Classification of Occupations (HISCO), the Historical version of ISCO-68/88/08, I related these as 'skos:hiddenLabel', while the standardized labels I qualified as 'skos:prefLabel' ('nurse', 'baker'). How do you propose I keep that distinction using schema.org? Best, Richard

[WeaverStever]

@rlzijdeman

occupationalCategory: I believe from prior conversations that occupations would best be externalized because it is dynamic and is already coded. IMHO the occupation could be a code, or a url or both, it would be the researcher's responsibility to create a query that matches the Classifications (s)he is looking for.

On your second post, I believe we discussed a medical group that would contain more than one specialty, or a journeyman who practiced more than one trade, so your employment history would probably work the same way.

Have a look at http://schema.org/additionalType. It appears to be valid under the proposed https://pending.schema.org/Occupation

Again, I don't believe that we should be creating static values for occupations, leave that to the paid experts NAICS/ILO and if you want the historical data, one would use a crosswalk for the query.

[tomj]

Apologies for just blowing in on this one but I'm quite interested in the skills property and this issue was linked from the schema.org skills page

I have a use case where a number of different skills need to be enumerated - currently I can have them concatenated in 1 large string but would prefer them to be separated in an array format. Is there some kind of strategy for that?

Cheers 😃

[thadguidry]

@tomj With JSON-LD format, sure.

{
"@context": "http://schema.org",
"@type": "Occupation",
"name": "Carpenter",
"skills": ["project management","measuring","sanding","detail oriented","geometry","sawing"]
}

[tomj]

@thadguidry very appreciative for the speedy reply. Thanks!

[thadguidry]

@vholland We didn't say anything about "gross" or "not gross" on the estimatedSalary. I was trying to map to this "base salary" https://www.wikidata.org/wiki/Property:P3618 but cannot until we get more clarity in the definition.

Any thoughts on more narrowed or broadening words added to estimatedSalary definition ? or should we ourselves keep this broad and unclear as currently defined to handle both "gross" and "not gross" scenarios that employers and others are searching for ?

or perhaps we also add "baseSalary" to have the best of both worlds to make finance depts. happy also ? :)

[vholland]

I am not sure I am following. We also have http://schema.org/baseSalary.

With that said, the data for JobPostings usually uses gross salary as calculating taxes and withholding is its own nightmare tied to a person's circumstance and geography.

[thadguidry]

@vholland doh ! thanks ! hmm, how did I miss that.

[orvn]

Unsure if this exists via another item, but it would be useful to associate an Organization with an Occupation, especially when defining the Occupation as part of a Role.

{
  "@context": "http://schema.org/",
  "@type": "Person",
  "name": "Albert Einstein",
  "hasOccupation": [
    {
      "@type": "Role",
      "hasOccupation": {
        "name": "Patent examiner",
        "occupationalCategory": "23-2099.00"
        "employer": {
		"@type": "Organization",
		"name": "US Patent and Trademark Office",
		"url": "https://www.uspto.gov/"
	}
      },
      "startDate": "1901",
      "endDate": "1906"
    },
    {
      "@type": "Occupation",
      "name": "Professor of Physics",
      "educationRequirements": "PhD in Physics",
    }
  ]
}

(modified example 4 here)

[davux]

Several terms use plural form, like skills. Shouldn't we stick to singular terms?

[orvn]

Several terms use plural form, like skills. Shouldn't we stick to singular terms?

Singular is definitely a better notation, I imagine the above mention of skills was just an oversight.

[danbri]

It was not an oversight. We do indeed default to singular properties but in some cases it is useful to have plural, eg when the value might express several things in one go

see https://www.w3.org/wiki/WebSchemas/Singularity for history

[developerbuzz]

Can i ask that we consider a more international occupationalCategory. The O*NET-SOC taxonomy is very US orientated and doesn't map very well to some international occupational areas, particularity where there are cultural/social differences. Legal, Military and Government occupations being prime examples. I would favour a more country neutral standard such as ISCO/ESCO.

[WeaverStever]

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

[orvn]

@danbri It was not an oversight. We do indeed default to singular properties but in some cases it is useful to have plural, eg when the value might express several things in one go
see https://www.w3.org/wiki/WebSchemas/Singularity for history

Ah, I see. Seems a little odd to me. When an object or method accepts both single and multiple inputs in the form of an array, I usually see people sticking to the singular in other designs. Thought I saw this by-and-large in Schema as well.

[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

[RichardWallis]

Implemented in release 3.5