Talent Marketplace Signaling Community Group

Talent Marketplace Signaling Community Group
Skip to toolbar
Skip
My W3C Account
Talent Marketplace Signaling C...
Talent Marketplace Signaling Community Group
Much is said about the mismatch between the needs of employers for qualified employee candidates and a pool of available candidates. One major factor contributing to this mismatch is the signaling between the demand-side (i.e., employers) and supply-side (i.e., education, training and credentialing providers, students and workers) of the talent pipeline. This mismatch frequently results in neither party coming into view of the other. The goal of the Talent Marketplace Signaling (TalentSignal) Community Group is to assist Schema.org in improving workforce signaling by refining existing schema.org types serving the talent pipeline and suggesting new types and properties where improved signaling cannot otherwise be achieved. Currently, workforce signaling sits at the intersection of a number of existing schema.org types: Course, JobPosting, Occupation, Organization, Person and the proposed EducationalOccupationalCredential.
The TalentSignal Community Group will focus initially on refinement of the
JobPosting Schema
and related types as it survey's specifications from domain entities such as
HR Open Standards
and
PESC
as well as the US Chamber of Commerce Foundation's
Job Data Exchange (JDX)
and
T3 Innovation Network
initiatives for better means to strong, more effective supply- and demand-side signaling.
Group's public email, repo and wiki activity over time
Note: Community Groups are proposed and run by the community. Although W3C hosts these
conversations, the groups do not necessarily represent the views of the W3C Membership or staff.
Chairs, when logged in, may publish draft and final reports. Please see
report requirements
One year in
Phil Barker
Posted on:
February 5, 2020
It is one year since the initial call for participation in this
Talent Marketplace Signaling W3C Community Group
. That seems like a good excuse to reflect on what we have done so far, where we are, and what’s ahead.
I’m biassed, but I think progress has been good. We have
35 participants
in the group, we have had some expansive discussions to outline the
scope and aims
of the group, the detail of which we filled in with
issues and use cases
. We also had some illuminating discussions about how we conceptualize the domain we are addressing (see most of
August in the mail list archive
). Most importantly, I think that we have made good on the aim arising from our initial kick-off meeting to
identify issues arising from use cases and fix them individually with discrete enhancements to schema.org
. Here’s a list of the fixes we have suggested that have been accepted by schema.org, drawn from the schema.org
release log
Issue #2192
: Added
CategoryCode
to rangeIncludes for property
occupationalCategory
and
DefinedTerm
to rangeIncludes for property
jobTitle
Issue #2244
: Added
jobStartDate
and
jobImmediateStart
properties to
JobPosting
Issue #2294
: Added example for
JobPosting
Issue #2329
: Added property
totalJobOpenings
to
JobPosting
type.
Issue #2296
: Added property
employmentUnit
to
JobPosting
type.
Issue 2322
: Linked
skills
description to formal definitions of competencies.
Issue 2384
: Added three properties to
JobPosting
for requirements relating to
physical abilities
sensory abilities
and
security clearance
Issue #2396
: Improvements to provide more information about the employer in
JobPosting
. Adds properties for
applicationContact
employerOverview
and allows
DefinedTerm
to be used with the
industry
property.
Translating those back to our use cases / issues we can now:
Provide
better more flexible coding of Occupational Category
Provide a
start date for job
See an
example of JobPosting qualifications
as EducationalOccupationalCredential.
Show the
unit at which the job is based
Show the
total number of job openings
Refer skills requirements to competency definitions
from a standard framework and encoding such as CTDL-ASN in C.E. or CASE in CASE Registry .
Provide some
requirements other than competencies and credentials
, namely Physical Requirement Security Clearance Requirement and Sensory Requirement
Provide
contact details
for a JobPosting
Provide an
Employer Overview
Provide a means of giving the
industry a standard code
Looking forward…
First I want to note that many of those contributions have been accepted into what schema.org calls its
pending section
, which it defines as “a staging area for work-in-progress terms which have yet to be accepted into the core vocabulary”. While there are caveats about terms in pending being subject to change and that they should be used with caution, their acceptance into the core of the schema.org vocabulary relies on them being shown to be useful. So we have a task remaining of promoting and highlighting the use of these terms and showing how they are used. Importantly, “use” here means not just publishing data, but the existence of services built on that data.
Looking at the
remaining issues
that we identified from our use cases and examples, it seems that we have come to the end of those that can be picked off individually and dealt with without consequences elsewhere. Several are issues of choice, along the lines of “there’s more than one way to do X, can we clarify which is best?” Best practice is difficult to define and identify, and there will be winners and losers whatever option is picked. The choice will depend on analysis of whatever existing practice currently is as well as trade-offs such simplicity versus expressiveness. Another example where existing practice is important comes with issues that will affect how Google services such as Job Search work. Specifically, Google
recommends values
for employmentType that don’t seem to match all requirements, and these values are just textual tokens whereas we might want to suggest the more flexible and powerful DefinedTerm. However, we don’t want to recommend practice that conflicts with getting job postings listed properly by Google. While some Google search products leverage schema.org terms, the requirements that they specify for value spaces like the different employmentTypes are not defined in schema.org; and while schema.org development is open, other channels are required to make suggestions that affect Google products. The final category of open issue that I see is where a new corner of our domain needs to be mapped, rather just one or two new terms provided. This is the case for providing information about assessments, and for where we touch on providing information about the skills etc. that a person has.
So, there is more work to be done. I think starting with some further work on examples and best practice is a good idea. This will involve looking at existing usage, and mapping relevant parts of schema.org to other specifications (that latter task is happening in other fora, so probably something to report on here rather than start as a separate task). As ever, more people in the group and engagement from key players is key to success, so we should continue to try to grow the membership of the group.
Thank you all for your attention and contributions over the last year; I’m looking forward to more in the coming months.
Ackowledgement / disclosure
I (Phil Barker) remain grateful to the continued support of the US Chamber of Commerce Foundation, who fund my involvement in this group.
Summary of Talent Marketplace Signaling Kick-off webinar
Phil Barker
Posted on:
April 15, 2019
This is a summary of the community group’s kick-off webinar held on 4 April 2019. Recordings of the webinar are available:
video
(51MB) |
audio
(22MB); as are the
slides
used.
The
Talent Marketplace Signaling
W3C Community Group (TalentSignal) was proposed by Phil Barker and established in February 2019. At the time of this call it had 27 participants. The aim of this call was to initiate the work of the group.
Participants are encouraged to introduce themselves to the rest of the group with an email to the group’s mail list,
public-talent-signal@w3.org
1. Aims of the group
The goal of the TalentSignal community group is to improve workforce signaling. Some examples of workforce signaling were expanded.
The simplest is an organization creating a job posting to advertise that is has a position it wishes to fill; the job posting signals the requirements for this position. These may include Educational and Occupational Credentials and Competences expected of a successful applicant, but will also include much more.
A person might be interested in a certain type of job (or occupation) for their future career. Linking the Educational and Occupational Credentials and Competencies required for such jobs back to Assessments and Learning Opportunities signals to that person how they might become qualified to apply for such jobs.
Educational Organizations that offer Learning Opportunities will also be interested in the Educational Credential and Competence requirements that are currently in demand from relevant employers.
Many other signals will also be relevant, and they might be processed by many other actors, but these serve as illustrations.
The problems to be solved are:
deciding what is useful to signal, and expressing these signals in a manner that is mutually intelligible among all relevant actors.
Note:
there was some discussion of whether the
diagram in the slide deck
used for this illustration might be refined and expanded as a useful way of communicating our work.
The aim of the Talent Signal group is to improve how these signals can be communicated through use of the the schema.org vocabulary. This may include:
showing how existing schema.org terms can be used (e.g. with examples);
suggest refinements to term definitions for example where clarification is necessary;
suggest new terms where needed.
Note:
We should always be aware that while the group can make proposals to schema.org, it is not within the group’s power to insist that schema.org adopts these proposals. As an independent project, Schema.org has its own
steering group
(chaired by R.V.Guha) and site
.  A more general
overview of how the schema.org project works
is available.
The focus will initially be on Job Posting, but the group has been set up with a broader remit so that it can continue to work on other aspects later.
Background
The group is not starting from scratch. The following is some of previous work that is relevant
There are several relevant types already in schema.org (e.g.
JobPosting
EducationalOccupationCredential
Course
Occupation
). We have to work with these types, we cannot create a model that conflicts with these types; they should be seen as enablers, providing us with the framework on which we will build.
Competency structures are likely to be relevant to our work and there are several ways of  representing these already. We probably do not need to represent a competency structure in schema.org, however we will need a way of showing a relationship to a competency that has been described elsewhere.
HR Open
Standards Consortium defines standards for the communication of information related to HR.
Several organizations describe or catalogue various entities relevant to our work:
The
Credential Engine
is a non-profit whose mission is to “create credential transparency, reveal the credential marketplace, increase credential literacy, and empower everyone to make more informed decisions about credentials and their value”.
ESCO
(European Skills, Competences, Qualifications and Occupations) “works as a dictionary, describing, identifying and classifying professional occupations, skills, and qualifications relevant for the EU labour market and education and training”.
The
Job Data Exchange
is an initiative that aims to “improve how clearly employers communicate their hiring needs to workforce development partners and educators across the country”. JDX has a data model based on schema.org and HR Open Standards, which will be shared with this group.
The
Connecting Credentials
project produced frameworks and guides for the description of credentials in terms of levels and competences.
There are others. Part of the rationale for setting up a W3C Community Group for this work is to bring in as much input as possible from as wide a range of relevant groups as possible.
Note:
let’s keep a track of other relevant work as we progress through our work. (Phil Barker will set up a section on the wiki for this).
Note:
the group is always open to new members, please reach out to any organization that you think might be interested in contributing. Currently, members from outside the US are especially sought. The group should be proactive in soliciting input globally.
Processes
W3C
policies
require that we have a chair, currently Phil Barker. (Disclosure: PB is receiving payment from the US Chambers of Commerce Foundation for this.)
Anyone may join the community group. Members of the community group must sign the
W3C Contributor License Agreement
. Any work contributed to this group may be proposed for inclusion in schema.org, and so should also conform with the open license, disclaimer of warranty and limitation of liability granted by
their terms
We should leave an open record of our discussions: we can do this by having the discussions on the open email list
public-talent-signal@w3.org
and documenting decisions on a wiki provided by W3C and the community group blog.
Currently it is proposed that we work asynchronously and not have regular group calls after the kick-off call.
The group will primarily work in English. If work is being carried out in another language it would be useful to identify a liaison who can represent this work in English.
It is suggested that we work on a prioritized list of issues and address these individually, pushing the outcome to schema.org as we go. We have a
draft set of use cases
that came from the Job Data Exchange project, and some other issues that may be addressed.
Note:
we should build an agreed set of use cases on the wiki that ensure we work towards a coherent piece of work.
Note:
we should also try to find some issues that can be fixed quickly.
Phil Barker can prepare any technical submission required as a proposal for schema.org, whether that be a change to the code base or contributions to their wiki.
Call for Participation in Talent Marketplace Signaling Community Group
W3C Team
Posted on:
February 6, 2019
The
Talent Marketplace Signaling Community Group
has been launched:
Much is said about the mismatch between the needs of employers for qualified employee candidates and a pool of available candidates. One major factor contributing to this mismatch is the signaling between the demand-side (i.e., employers) and supply-side (i.e., education, training and credentialing providers, students and workers) of the talent pipeline. This mismatch frequently results in neither party coming into view of the other. The goal of the Talent Marketplace Signaling (TalentSignal) Community Group is to assist Schema.org in improving workforce signaling by refining existing schema.org types serving the talent pipeline and suggesting new types and properties where improved signaling cannot otherwise be achieved. Currently, workforce signaling sits at the intersection of a number of existing schema.org types: Course, JobPosting, Occupation, Organization, Person and the proposed EducationalOccupationalCredential.
The TalentSignal Community Group will focus initially on refinement of the
JobPosting Schema
and related types as it survey’s specifications from domain entities such as
HR Open Standards
and
PESC
as well as the US Chamber of Commerce Foundation’s
Job Data Exchange (JDX)
and
T3 Innovation Network
initiatives for better means to strong, more effective supply- and demand-side signaling.
In order to
join the group
, you will need a
W3C account
. Please note, however, that
W3C Membership
is not required to join a Community Group.
This is a community initiative. This group was originally proposed on 2019-02-04 by Phil Barker. The following people supported its creation: Phil Barker, Jeanne Kitchens, Joshua Westfall, James Goodell, Stuart Sutton. W3C’s hosting of this group does not imply endorsement of the activities.
The group must now
choose a chair
. Read more about
how to get started in a new group
and
good practice for running a group
We invite you to share news of this new group in social media and other channels.
If you believe that there is an issue with this group that requires the attention of the W3C staff, please email us at
site-comments@w3.org
Thank you,
W3C Community Development Team
Tools for this group
Learn about available Community Group tools and how to configure a group's site to include links to tools on w3.org or elsewhere.
Mailing List
@ public-talent-signal
@ internal-talent-signal
Wiki
RSS
Contact This Group
Get involved
Learn more about how to join a group.
Anyone may join this Community Group. All participants in this group
have
signed the
W3C Community Contributor License Agreement
Join or Leave this group
Chairs
Phil Barker
Participants (
35
View
all participants
Archives
February 2020
April 2019
February 2019
Categories
Announcements
Updates
Footer Navigation
Standards
Groups
Get involved
Resources
News & Events
About W3C
Contact W3C
Contact
Help
Support us
Legal & Policies
Corporation
Systems Status
W3C Updates