Re: draft JobPosting addition for Schema.org

Thanks Dan for the summary. I have a couple of comments on the open issues.

Re (3) - I still think that adding stuff about jobs without adding Job as a
type is going to cause confusion in the long run. If someone does add stuff
for CV, or for position descriptions, then what do you do with the (few)
common properties? I think it should be simple to add Job as a kind of
Event, and pick up any time-related properties from there, then still have
the offer. I am not sure I understand the Schema.org Way, but don't think
that you need to unify everything or anticipate what else might be added to
Job in the future, just build on what has already been modelled.


Re (1) Closing date (on the offer) seems to be sensible without making
assumptions about how HTML will be generated, but so would
time-constraints on the job itself, such as duration for contract jobs  or
fixed start and end dates for some kinds of positions. They've got to be
useful for search relevance, right?

Also, we already have the property jobTitle on person - so shouldn't the
title property on a job posting be  jobTitle? Or to be consistent with other
types, maybe it should be 'name' (Articles, for example have names, not
titles).

Peter


On Fri, Oct 21, 2011 at 10:31 PM, Dan Brickley <danbri@danbri.org> wrote:

> 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
> http://www.w3.org/wiki/JobPostingSchema#Comments_Summary_as_of_20th_Oct
>
> """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,
> 1.
> 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.
>
> 2.
> Remodeling as Job. Several people including  Peter Sefton in
> http://lists.w3.org/Archives/Public/public-vocabs/2011Oct/0068.html
> 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.
>
> 3.
> 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,
>
> cheers,
>
> Dan
>



-- 

Peter Sefton +61410326955 pt@ptsefton.com http://ptsefton.com
Gmail, Twitter & Skype name: ptsefton