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.
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:
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.
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 terms of service. 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.
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.
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.
