Re: draft JobPosting addition for Schema.org

Dan,

I'm curious about the process here. http://schema.org/JobPosting has just
been added. It's slightly different from the latest draft on the wiki
http://www.w3.org/wiki/JobPostingSchema

Unless I missed it you didn't report back here about the thinking behind
the new properties.

So, now that this has been published, I have a couple of questions.

What is the difference between the 'name' and 'title' properties? Is
'title' in a JobPosting the same as' jobTitle' for a Person?

And having made the decision that JobPosting is distinct enough from a
potential Job type to model them separately  - what's the plan if an
industry group does want to add Job? Is there a mechanism to map between
equivalent properties (eg jobTitle)?

Peter Sefton




On Tue, Oct 25, 2011 at 10:09 AM, Peter Sefton <ptsefton@gmail.com> wrote:

>
> 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
>
>
>


-- 

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