- From: Phil Barker <phil.barker@pjjk.co.uk>
- Date: Fri, 21 Jun 2019 15:03:17 +0100
- To: public-talent-signal@w3.org
- Message-ID: <9aa036b2-1c18-e488-5660-3370153e9d03@pjjk.co.uk>
Interesting thoughts Merrilea, thank you. I think that you're right to say that no employer will publicise that they won't accept credentials from Institution X; and anyway, I can't think of a way of expressing that information in schema.org. So let's put that to one side. EducationalOccupationalCredential has a property provider <https://schema.org/provider> which might be useful for saying things about credentials from which institutions are acceptable. So you could say the provider must be memberOf the Ivy League, or say that only one or two institutions are acceptable. This might work where there is some sort of closed shop or monopoly for providing the credential, but I am not convinced that this really scales to many scenarios. (Tell me if I am wrong and I will make an example.) What I do think would work better is to show is that the credential should be recognised by <https://schema.org/recognizedBy> some accrediting organization: { "@context": "http://schema.org/", "@type": "JobPosting", "title": "Systems Research Engineer", "qualifications": { "@type": "EducationalOccupationalCredential", "credentialCategory": "Bachelor of Science", "about": "Computer Science", "name": "Bachelor of Science in Computer Science", "recognizedBy": { "@type": "Organization", "name": "British Computer Society", "url": https://www.bcs.org/ } } (using British Computer Society because I am not sure whether ACM / IEEE or who provides similar accreditation in the US or elsewhere; happy to show alternatives) Phil On 21/06/2019 13:58, Merrilea Mayo wrote: > > This is pretty good. The TL;DR version of my longer response below: > It would be nice to have a data element associated with a credential > that described an acceptable (to the employer) issuer/owner/source of > the credential. > > Why? > > I would like to fix one reason that credential listings as they exist > today are so poor at signaling requirements to candidates. That is, > that all sources of a given credential are not equally satisfactory to > employers. If I get a Bachelor of Science from a no-name university, > my resume will never be considered even though technically I have the > required credential. If I get a B.S. from MIT, my resume floats to > the top. This is particularly a problem in Computer Science, where, > In the US, 70,000 African-Americans currently remain employed > out-of-field (most in extremely menial jobs, like short-haul delivery > drivers and bellhops - see my LinkedIn posting on US Census data > showing this) because they have the BS degree in Computer Science, but > not from anywhere an employer is interested in, or recruiting from. > Meanwhile, employers are complaining that minority talent simply > doesn't exist. The signal that employers "need minority talent" is > getting out, but in a form that doesn't allow individuals to respond > correctly. The result is a colossal waste of many individuals' time, > and a profound accumulation of unnecessary debt, to pursue degrees no > one is interested in. > > Now, the real problem is of course that no employer really wants to > admit they won't hire you if your degree is from Institution X. But > there is also no way in current data schema to easily signal a > preferred credential issuer/owner/source even if employers *were* so > inclined. As a less incendiary example, there are at least 3 > different organizations handing out Six Sigma Black Belt > certifications. Which one(s) is the employer willing to accept? I > think in Credential Engine, the credential owner ended up being stored > in records completely separate from the other data regarding a > credential, which also made it difficult, when working with their > APIs, to extract listings of credentials that included the information > on who was issuing them. I can't be 100% certain of that last claim, > since I'm not a programmer, but I think that's what I heard from ours, > when they attempted it. > > So...long story short: It would be nice to have a data element > associated with a credential that described an acceptable > issuer/owner/source of the credential. It could be a specific > organization, a class of organizations (e.g., "Ivy League > Universities" or "Accredited higher education institutions"), or a > list containing several of the above ("Embry-Riddle University," "Pima > Community College"). At least that way, if employers ever did get > explicit about signaling acceptable credentials, they'd have a > mechanism for doing so. I will say that if employers ever specified > their preferred credential providers, it would dramatically shake up > higher education. Especially if such information were available in > structured form, it could easily be collated for national-level > reports on supply/demand, which typically utilize real-time labor > market information (job postings) as their data source. Particularly > if employers were willing to identify subsets of institutions less > than 50 in number (for example, something smaller than just > "accredited higher education institution"), Higher education would > then get an extremely strong signal about what was, and was not, > considered an "employable" educational pathway. > > Merrilea > > On 6/21/2019 7:27 AM, Phil Barker wrote:tthe qualifications property > of a JobPosting. >> >> It is based on an existing example in schema of anOccupation >> <https://schema.org/Occupation> requiring a PhD level qualification. >> >> { >> "@context": "http://schema.org/", >> "@type": "JobPosting", >> "title": "Systems Research Engineer", >> "qualifications": { >> "@type": "EducationalOccupationalCredential", >> "credentialCategory": "Bachelor of Science", >> "about": "Computer Science", >> "name": "Bachelor of Science in Computer Science" >> } >> } >> >> There's a full description on the wiki at >> https://www.w3.org/community/talent-signal/wiki/Example_of_JobPosting_qualifications_as_EducationalOccupationalCredential >> >> Any comments? >> >> Phil >> >> -- >> >> Phil Barker <http://people.pjjk.net/phil>. http://people.pjjk.net/phil >> CETIS LLP <https://www.cetis.org.uk>: a cooperative consultancy for >> innovation in education technology. >> PJJK Limited <https://www.pjjk.co.uk>: technology to enhance >> learning; information systems for education. >> >> CETIS is a co-operative limited liability partnership, registered in >> England number OC399090 >> PJJK Limited is registered in Scotland as a private limited company, >> number SC569282. >> > -- > > Merrilea J. Mayo, Ph.D. > Mayo Enterprises, LLC > 12101 Sheets Farm Rd. > North Potomac, MD 20878 > > merrileamayo@gmail.com > https://merrileamayo.com/ < > > 240-304-0439 (cell) > 301-977-2599 (landline) > -- Phil Barker <http://people.pjjk.net/phil>. http://people.pjjk.net/phil CETIS LLP <https://www.cetis.org.uk>: a cooperative consultancy for innovation in education technology. PJJK Limited <https://www.pjjk.co.uk>: technology to enhance learning; information systems for education. CETIS is a co-operative limited liability partnership, registered in England number OC399090 PJJK Limited is registered in Scotland as a private limited company, number SC569282.
Received on Friday, 21 June 2019 14:04:18 UTC