Comments on JobPosting of Schema.org

Greetings,

I was thrilled to see JobPosting published. Currently I am investigating 
whether we can apply it on PeoplePerHour.com which is a job marketplace 
for freelancers and small businesses. So my comments are mainly from a 
non-full-time jobs' point of view.

First let me apologize for the length of this email, being really 
excited about this opportunity I tried to be as comprehensive as possible.

Here is a quick overview of the email:
(1) 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).
(2) The job can be done remotely how can you indicate that using 
jobLocation?
(3) Hiring organization could be a couple of things including a single 
Person instead of an Organization.
(4) How can you mark a job position as available or filled? A `vacancy` 
property would be ideal.


NRD being the main reason (great cause) of the creation of this schema, 
I assume that it was designed primarily for full-time jobs probably due 
to deadlines as well, but what happens with job postings of other job types?
Based on the presence of `employmentType` it looks that this schema is 
to be used for many job types other than full-time.

== 1. Payment: Amount Range, Time & Target  ==
The main issue is that the periodic payment (salary) is represented 
using a number through `baseSalary`. We are missing out on the price 
range and an additional dimension, e.x time, which is implied to be a year.
The following are cases that I would like to present using JobPosting:

  | Job Type  | Payment format | Ranged format
  ---------------------------------------------
  | Full-time | $40.000 per Year / per Annum
  | Fixed     | $500, $500 - $1500
  | Flexible  | $50 per Hour , $200 - $400 per Day
  | Commission| $100 per 1000 Sales

Full-time and Fixed jobs can be presented using the current schema, but 
I don't see how it would apply to flexible jobs or commissioned jobs.

-- Range
An already suggested option on the range issue is to add a `maxSalary` 
property and thus having:
<span itemprop="salaryCurrency">USD</span> <span 
itemprop="baseSalary">100000</span> - <span 
itemprop="maxSalary">125000</span>

-- Time
But what about time? Flexible jobs could have "per Hour", "per Day". 
Commission jobs are a bit similar but instead of time they usually have 
a target e.x: "per 1000 Sales".

Having in mind the nature of microdata and Schema.org I think it could 
be helpful to introduce a new property to JobPosting that indicates the 
checkpoint that the employee will need to reach to be awarded with the 
salary. Let's call it `salaryCheckpoint` for lack of a better name.

So we could have the following for Flexible jobs:
<span itemprop="baseSalary">250</span> - <span 
itemprop="maxSalary">400</span> <span itemprop="salaryCheckpoint">per 
Day</span>

and it could also work for Commission jobs (and maybe other more complex 
job types):
<span itemprop="baseSalary">100</span> <span 
itemprop="salaryCheckpoint">per 1000 Sales</span>

Basically end up with:
salaryCurrency baseSalary [maxSalary] [salaryCheckpoint]

== 2. jobLocation: Remote jobs ==
I would imagine that jobLocation is referring to the geographical 
location the employee will need to be in order to work, since we know 
the Organization's location through `hiringOrganization`.
This works for the majority of the postings but there is the case of 
Remote jobs where the employee can work from any place. What is the 
suggested way to represent this on jobLocation?

== 3. hiringOrganization ==
This property could be:
  (i) a human resources company
  (ii) the original company hiring
  (iii) or even an individual person hiring

Personally I'm hoping for the property to accept a Person as well as an 
Organization, instead of having to wrap them as an Organization.

== 4. Vacancy ==
Based on the NRD, I understand that job postings are taken down when the 
position is filled, but what happens if a job posting should remain 
online and accessible for historical reasons?
Currently (I guess) the aggregators will assume that the job is still 
available. I think there is a need for a way to mark if the job is still 
available for candidates to apply.

Thanks for your time and I would appreciate any feedback.

Best regards,
-Sevastos
______________________
Sevastos Mastrogiorgis
Skype: sevastos.m
Web Engineer @ PeoplePerHour.com

Received on Tuesday, 6 December 2011 12:39:20 UTC