WebSchemas/JobMarket

A collection of extending Schema.org to cover the domain of job market.

There's an associated repository for this extension proposal, which contains:

RDF/Turtle serialization of the Schema.org extension proposal
examples describing existing JobPostings (in RDF/Turtle)
diagram of a data model for an application based on Schema.org + this extension
diagram of implementation of this data model using common vocabularies + newly minted vocabulary terms

There's a Czech project about applying semantic web technologies for the "long-tail" of job market, for which this extension will be used. The main goal of the extension is to clean some of the issues with original Schema.org and provide data structure that is:

easy to use for web developers to embed in HTML
provides sufficiently detailed structure for "intelligent" match-making between job postings and job seekers to be feasible

The initial proposal was made by Jindřich Mynarz, Richard Cyganiak, Eliška Hutníková, Josef Šlerka, Vojtěch Hýža and Jakub Fiala.

The extension proposal is licensed with the Creative Commons Attribution-ShareAlike 3.0 Czech Republic License, in order to comply with the Schema.org's licence.

Thing > Intangible > QuantitativeValue > Compensation

Compensation describes how the worker is paid for the work done.

Properties from QuantitativeValue:

minValue
maxValue
value

Properties from Compensation:

currency: Text (Currency (in 3-letter ISO 4217 format), in which compensation is paid.)
type: Text (Type of compensation. Recommended values are: annual, monthly, hourly, fixed.)

Notes:

PriceSpecification is close (a monetary value with a range), but the naming strongly implies its use as a price or charge for something, which seems inappropriate here.

Thing > Intangible > JobPosting

Properties from JobPosting:

availableVacancies: Integer (Number of persons sought for a job. Default value is 1.)
contact: ContactPoint (Contact information job seeker needs to respond to job posting.)
employer: Organization or Person (Property relating job postings to persons or organizations offering a job.)
experienceRequirements: WorkExperience
industry: (Amend the original description to include also private employment etc. Labelling this property industry is too restrictive. A possible option to broaden its range is to use a label like category.)
compensation: Compensation (Compensation paid by employer to employee as stated in job posting.)
isRemoteWork: Boolean (Indicates job postings for which location of execution does not matter (i.e. remote work).)
startDate: Date (Date when employment starts.)

Notes:

JobPosting has hiringOrganization, but we also want to allow individual-to-individual job postings. For this purpose we introduced the employer property.
Elsewhere, a property contactPoint exists. Calling it “contact” seems a bit more accurate than “contactPoint” here, but “contactPoint” could still be better to avoid a new property.
experienceRequirements would be either Text (current situation) or a structured value (our proposal).
The current JobPosting assumes salaried positions, which works poorly for fixed-payment contract employments or hourly pay.

Thing > Intangible > StructuredValue > WorkExperience

Job applicant's work history that demonstrates skills or competences.

Properties from Thing:

description

Properties from WorkExperience:

duration: Duration (Length of period during which job applicant acquired experience.)
references: Boolean (Indicates whether applicant is able to provide contact for references.)

Modelling issues

Handling of localities and street addresses

When adding a locality and/or street address to job postings, schema.org requires adding two intermediate resources, a Place and a Postal Address. This can result in awkward markup. There can be a markup guidance document that will state that the intermediate  and  can be omitted, so that  or  would be used directly on a JobPosting. However, this is considered a non-standard implementation detail and is not part of this extension proposal.

Handling of Boolean values

There is an issue against schema.org regarding the representation of booleans: http://www.w3.org/2011/webschema/track/issues/14

We should recommend the solution: <meta itemprop=”...” content=”true”> or simply true because the option with href is unnecessarily complicated.