One year in [via Talent Marketplace Signaling Community Group]

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 RequirementProvide contact details for a JobPostingProvide an Employer OverviewProvide 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.



----------

This post sent on Talent Marketplace Signaling Community Group



'One year in'

https://www.w3.org/community/talent-signal/2020/02/05/one-year-in/



Learn more about the Talent Marketplace Signaling Community Group: 

https://www.w3.org/community/talent-signal

Received on Wednesday, 5 February 2020 10:27:14 UTC