W3C home > Mailing lists > Public > public-vocabs@w3.org > October 2011

Re: draft JobPosting addition for Schema.org

From: Dan Brickley <danbri@danbri.org>
Date: Fri, 21 Oct 2011 14:31:58 +0200
Message-ID: <CAFNgM+ZkZ__1mP8JkUcSNxvwPBUudgSLtOCE0_z+ZjEJ-Lr0mQ@mail.gmail.com>
To: public-vocabs@w3.org
Cc: Ramanathan Guha <guha@google.com>, aaranged@yahoo.com, ptsefton@gmail.com
On 18 October 2011 15:37, Dan Brickley <danbri@danbri.org> wrote:
> Below, I pass along a draft for a "JobPosting" addition to Schema.org's vocabulary.

I have updated the Wiki entry at
http://www.w3.org/wiki/JobPostingSchema with a summary of discussions
to date.

Excerpting from

"""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, ..."""

Taking these in turn,
Aaron - re 'dateClosing', it was suggested to me that the vast
majority of sites publishing this markup will be doing so directly
from a database and will likely retract the job listing entirely after
it has closed. This made me realise that I was assuming syndication /
redistribution of the markup to be likely, e.g. as HTML within Atom
feeds. However as that scenario is not particularly job-centric, I'd
suggest we hold off on 'dateClosing' at least for now, and consider
addressing it with some other indication of data freshness that might
apply more generally.

Remodeling as Job. Several people including  Peter Sefton in
suggested using a general and re-usable Job class, and then making the
job advert a kind of offer, so that the Job could be re-used e.g. in
resume/CV information.  Personally, I found this initially quite
appealing, but then looking into the specific fields we have in
http://www.w3.org/wiki/JobPostingSchema they are almost entirely
around the recruitment process. In addition, the particulars of many
jobs are pragmatically adapted to suit a role for the successful
candidate, limiting the practical usefulness of recycling general
purpose data from the job advert. So my inclination here is to note
the potential for a close relationship between job markup and resume
markup, but for now to stay with 'JobListing' as the class. I imagine
other controlled vocabularies (around skills and roles and topics)
will later strengthen this association between jobs and CVs, but
suggest for now it is premature to try to make a "Job" type that
serves both as a record of individual achievement, and as a
template/advert for using in recruitment.

Suggestion that veteranCommitment use case be addressed with a
slightly more general specialCommitment property. Comments?

4. occupationalCategory
I've made some investigations here into other schemes beyond BLS
O*NET-SOC; ESCO in particular looks promising, although there is not
much information about it publicly yet. A common structure seems to be
a pairing of a numeric code with a descriptive string. While it might
not be the purest structure in markup/semantic terms, the best I can
think for now (without making a property for each scheme) is just to
say that the text values are drawn from such schemes and typically
include a code and a label. Suggestions?

Thanks for any further advice,


Received on Friday, 21 October 2011 12:32:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:21 UTC