Re: draft JobPosting addition for Schema.org

Hi Peter,

On 8 November 2011 07:14, Peter Sefton <ptsefton@gmail.com> wrote:
> 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.

You're right. In terms of process, the situation with the jobs
vocabulary was somewhat unusual.

The driver to get something out there fast was the US initiative
announced yesterday,
http://www.whitehouse.gov/blog/2011/11/07/open-innovation-heroes-introducing-veterans-job-bank
http://googleblog.blogspot.com/2011/11/powering-new-job-search-engine-for.html
https://www.nationalresourcedirectory.gov/home/instructions_for_employer_participation

... schema.org was one piece of a larger collaboration, and the
feedback aired here (which was much appreciated, even if every comment
wasn't taken on board) was one of several channels of design feedback
on the schema. The documentation could well do with another round of
improvements.

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

Fair questions. Working backwards: the schema system we use is based
on W3C's RDF/RDFS, which does provide some basic machinery to support
mappings. RDFS has a built-in property 'subPropertyOf', and there are
others in common use (e.g. owl:equivalentProperty, skos:closeMatch).
So just as http://schema.org/docs/full_md.html shows the use of
microdata to express a class hierarchy, we can do similar with
properties as a way of documenting these relationships.

Re 'name' vs 'title' (I'll check) my guess is that this was more about
the choice of word; while they may be conceptually the same, it might
be a little too counter-intuitive to speak of a JobPosting's 'name'.

Re Person's jobTitle versus JobPosting's title, they are clearly
intimately related; and yes, if a class for 'Job' or work roles were
to be introduced, yes it would be natural to have a link between the
two. There is a limit to how much of someone's CV/resume can be
summarized in 'jobTitle'. For example, our current
http://schema.org/Person has both 'worksFor' and 'jobTitle'. When
someone has multiple roles, this doesn't capture the association, so
you might know someone is a 'Finance Manager'  but if they have
multiple 'worksFor', we don't know which job goes with which employer.
So there is clearly room to grow here. It wasn't feasible to  complete
a design for describing job roles, job adverts, CVs/Resumes in a
single pass. There will always be opportunities for more integrated,
elegant modeling.

We'll try to find a balance between that and pragmatism. For example,
there are arguably common patterns between advertising jobs, and
advertising of all other kinds of thing - so conversations about Good
Relations-style descriptions are scope. And describing skills,
experience, areas of expertise, kinds of training ... that relates to
the various efforts out there towards describing educational /
learning resources, e.g. http://wiki.creativecommons.org/LRMI "The
Learning Resource Metadata Initiative is a project co-led by the
Association of Educational Publishers and Creative Commons to build a
common metadata vocabulary for educational resources.". Those efforts
look at describing skills and abilities, amongst other interesting use
cases. I recommend http://wiki.creativecommons.org/LRMI/UseCases ...
which shows how such markup could help lesson planning, and be
integrated with digital library systems, etc. And from that topic it
is just a short hop to http://schema.org/ScholarlyArticle and a desire
to improve our description of scholarly articles - both as expressions
of expertise, and as sources of expertise (use in skills/training). If
we look too closely, any rigid boundaries between various of these
scenarios melt away. This is simultaneously a source of great
opportunity, but also a source for scoping difficulties. Sometimes the
right thing to do is a small incremental improvement, even while aware
that there is a bigger picture and many more related activities. I
think that's the best way to see JobPosting, and the best way to frame
the work of this group.

Another tricky piece of the puzzle is occupationalCategory. In
http://schema.org/JobPosting we currently have
"Category or categories describing the job. Use BLS O*NET-SOC
taxonomy: http://www.onetcenter.org/taxonomy.html. Ideally includes
textual label and formal code, with the property repeated for each
applicable value." ... and I expect we'll see other coding schemes
deployed in a similar fashion. The balance here is between simple
markup for publishers versus reliable links into structured
descriptive systems, where for example we can make use of hierarchy,
mappings and further codes.

Hope this helps.

Cheers,

Dan

> Peter Sefton

Received on Tuesday, 8 November 2011 08:44:45 UTC