Re: [TalentSignal] Example for JobPosting qualifications as EducationalOccupationalCredentials

Hi, Merrilea, just a couple of brief notes on your CredentialEngine
comments. You are correct that in Credential engine (i.e., in CTDL), the
offeror (as well as other related agents) of a credential are separate
entities from the credential offered. That mirror's schema.org practice.
The CTDL does have an array of properties that relate a particular
credential to an organization including accreditedBy, approvedBy,
offeredBy, ownedBy, recognizedBy renewedBy and revokedBy.

Bottom line, you are absolutely correct that the relationship between
offeror (etc) and credential is really important regardless of the
downstream motive of those wanting to have the information.

Stuart

On Fri, Jun 21, 2019 at 7:04 AM Phil Barker <phil.barker@pjjk.co.uk> wrote:

> 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/" <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 an Occupation
> <https://schema.org/Occupation> requiring a PhD level qualification.
> {
>   "@context": "http://schema.org/" <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.
>