Initial draft as posted to list:
occupationalCategory: Text (use BLS O*NET-SOC taxonomy: http://www.onetcenter.org/taxonomy.html)
employmentType: Text (eg. full-time, part-time, contract, temporary, seasonal, internship)
workHours: Text (eg. 1st shift, night shift, 8am-5pm)
incentives: Text - a place for bonus and commission compensation
For occupationalCategory details e.g. see pdf
In Microdata (work-in-progress; currently un-realistic):
<div itemscope itemtype ="http://schema.org/JobPosting">
<h1 itemprop="title">Film Director vacancy</h1>
<dt>skills: <span itemprop="skills">Film making, 3d, budget management</span></dt>
<dt>date posted: <span itemprop="datePosted">2011-10-15</span></dt>
<dt>employer: <a href="http://example.org/SomeFilmCorp" itemprop="hiringOrganization">SomeFilmCorp</a></dt>
(...can we get some better real-world examples? move the Org description inline...)
How do BLS O*NET-SOC codes relate to ISCO codes? Are mappings available?
- should occupationalCategory contain both text of job title and numeric code? or just numeric code? Can Web URLs be used to indicate these codes?
- are mappings available?
Comments Summary as of 20th Oct
Notes from Dan Brickley summarising initial feedback; circulated with additional commentary.
1. Comments from Aaron Bradley http://lists.w3.org/Archives/Public/public-vocabs/2011Oct/0066.html
- suggests adding a dateClosing property. [Seems reasonable and useful to me.]
- also asks about 'hiringOrganization -> employer'; presumably whether by the former, we mean the latter (although often job postings obscure the real company).
- occupationalCategory - asks about specifics and flexibility; how precise to do want this field to be?
- veteranCommitment - "I don't understand this - does this mean the job is open to veterans? Preferential treatment for veterans? It seems a bit quixotic to me - might there be a property that expressed special commitments as a text type to make it more extensible?" [ I like 'specialCommitment' or similar; it should work fine for the veteran case, but allow statements about other groups, priorities too ]
2. Comments from Peter Sefton, Jason Douglas http://lists.w3.org/Archives/Public/public-vocabs/2011Oct/0068.html
- Peter Sefton suggests it would be useful to have common notion of a Job that could be shared with CV/Resume markup (a topic that was spontaneously discussed on the list recently, with links/pointers gathered in http://www.w3.org/wiki/CVSchemas ) - "from the point of view of the person who has the job it is an event with start and end dates", with a Job Posting being a related type.
- Jason Douglas notes some common structure with Product and Offer
3. Comments from Sevastos Mastrogiorgis (http://lists.w3.org/Archives/Public/public-vocabs/2011Dec/0014.html)
- Regarding the periodic payment, it could use a max salary property for amount range and another property to define the time of payment (e.x per Hour, per Day) or a target goal the employee must achieve to be awarded with money (e.x per 1000 Sales).
- The job can be done remotely how can you indicate that using jobLocation?
- Hiring organization could be a couple of things including a single Person instead of an Organization.
- How can you mark a job position as available or filled? A `vacancy` property would be ideal.
Substantial questions seem to be:
- Do we add something like closingDate?
- Should we remodel as Job, and relate Job Posting (a kind of Offer?) to Jobs, so they can be re-used in some later Resume/CV markup. I have no strong view; I can see the appeal, but a schema of this size will always have a few custom cases, and it might be more important to move quickly than to unify everything.
- Can veteranCommitment be expressed as 'specialCommitment' instead? If this suits the motivating scenarios, I'd recommend it; but nobody objected to the original formulation.
- occupationalCategory --- how *exactly* do we want this coded text field to work? Do we expect pairs of numeric codes + labels? Are sites with alternate codings out of luck? This seems the most slippery question. There are initiatives eg. ESCO in a European context - see http://www.destree.be/esco/report.pdf - which might not be widely adopted yet in job listing sites, but which it might be damaging to casually ignore or accidentally undermine. Pragmatic suggestion: the field takes a pair of an alphanumeric code and a string label, and for now all we say is that those pairs are matched against schemes 'such as' BLS O*NET-SOC, ESCO, ...
- Justin Boyan (Google/Needlebase) in http://lists.w3.org/Archives/Public/public-vocabs/2011Oct/0088.html "The job listing schema looks good to me"; suggests possibly adding email contact. Also notes 'description' and 'URL' general properties from Thing class will be useful, especially when descriptive fields are mixed up in a single line of text.
- Tantek notes via #schema IRC that "http://bestsecurityjobs.co.uk/ has repurposed hCard to post a job listing - not something I would have expected but perhaps something we can learn from"