-
Notifications
You must be signed in to change notification settings - Fork 825
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
Comments
+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 ? |
The only thing I have difficulty with is |
@jvandriel Agreed. I have been trying to figure out a clean way to fix this for |
See PR #1709 |
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. |
@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? |
@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!) |
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... |
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>
.
|
Issue #1698: Added Occupation and examples
Merged into pending. |
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. |
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... |
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 |
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. |
Apologies for just blowing in on this one but I'm quite interested in the 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 😃 |
@tomj With JSON-LD format, sure. { |
@thadguidry very appreciative for the speedy reply. Thanks! |
@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 ? :) |
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. |
@vholland doh ! thanks ! hmm, how did I miss that. |
Unsure if this exists via another item, but it would be useful to associate an
|
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
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 |
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 |
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. |
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. |
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. |
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 |
Implemented in release 3.5 |
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.
New type QuantitativeValueDistribution: A subtype of QuantitativeValue for describing a statistical distribution of values. Properties include:
New type MonetaryAmountDistribution: A subtype of QuantitativeValueDistribution for describing a statistical distribution of monetary amounts. Properties include:
New property on JobPosting:
New property on Person:
The text was updated successfully, but these errors were encountered: