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

Proposal for new Occupation type #1698

Closed
vholland opened this issue Jul 13, 2017 · 30 comments
Closed

Proposal for new Occupation type #1698

vholland opened this issue Jul 13, 2017 · 30 comments
Assignees

Comments

@vholland
Copy link
Contributor

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:
    • 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.
@vholland vholland self-assigned this Jul 13, 2017
@thadguidry
Copy link
Contributor

+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
Copy link

jvandriel commented Jul 13, 2017

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
Copy link
Contributor Author

@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
Copy link
Contributor Author

vholland commented Aug 1, 2017

See PR #1709

@philbarker
Copy link
Contributor

philbarker commented Aug 1, 2017

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
Copy link
Contributor Author

vholland commented Aug 1, 2017

@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
Copy link
Contributor

@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
Copy link
Contributor

danbri commented Aug 30, 2017

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
Copy link
Contributor

@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
Copy link

mindyshaw33 commented Aug 31, 2017 via email

vholland added a commit that referenced this issue Sep 18, 2017
Issue #1698: Added Occupation and examples
@vholland
Copy link
Contributor Author

Merged into pending.

@danbri
Copy link
Contributor

danbri commented Sep 27, 2017

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
Copy link

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
Copy link

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
Copy link

@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
Copy link

tomj commented Feb 23, 2018

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
Copy link
Contributor

@tomj With JSON-LD format, sure.

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

@tomj
Copy link

tomj commented Feb 23, 2018

@thadguidry very appreciative for the speedy reply. Thanks!

@thadguidry
Copy link
Contributor

thadguidry commented Jun 15, 2018

@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
Copy link
Contributor Author

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
Copy link
Contributor

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

@orvn
Copy link

orvn commented Jul 6, 2018

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)

danbri added a commit that referenced this issue Feb 19, 2019
Fixed a bug - QuantitativeValueDistribution now has correct
supertype, it was mistakenly marked up as QuantitativeValue instead
of StructuredValue.

We also need to check #2058 here
@davux
Copy link

davux commented Mar 21, 2019

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

@orvn
Copy link

orvn commented Mar 21, 2019

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
Copy link
Contributor

danbri commented Mar 21, 2019

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
Copy link

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
Copy link

@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
Copy link

orvn commented Mar 29, 2019

@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
Copy link

@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
Copy link
Contributor

Implemented in release 3.5

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests