I've also followed up in the TalentSignal thread.

@danbri, not to change the subject but wouldn't it also be likely that no experience is required? Could the property be more open like "notRequired" with or without suggested enumeration?

@stuartasutton "no experience required" frames a job as something that might also be seen as "unskilled", or "school leavers". My understanding is that the "no degree required" formulation could encourage applicants to apply for very demanding and challenging roles that could draw on a great diversity of skills, ... just not require a degree.

A degreeRequired property with a boolean value seems the easiest route, both in terms of definition and implementation. As you say, it could be refactored in the future when there's less urgency.

NO_DEGREE_REQUIRED would be best suited for EducationalOccupationalCredential/educationalLevel

How about NO_DEGREE_REQUIRED as a value for the educationRequirements property? That way you're not co-opting educationLevel and don't need to add any new property. A defined term or enumeration might overcome the language issues.

I'm worried that a boolean degreeRequired property hits problems with scaling to the different level of degree (associate, bachelor, master) and other qualifications.

A new property (e.g. qualificationNotRequired) has advantages that it could be defined to clarify some of the question arising such as "is it not required only when you have some alternative experience"

[Aside, it would be good to sort out the distinction between educationRequirements and qualifications properties]

+1 to Phil's suggestion, with emphasis on using a defined term or enumeration. Some known value for "Not Required" could potentially be used as the value for other properties to explicitly indicate when something isn't required.

Alternatively, would a value like false work? e.g.

{
  "qualifications": {
    "@type": "EducationalOccupationalCredential",
    "educationalLevel": false
  }
}

That may be too vague. I guess it depends partially on whether we're trying to say "No degree required, but something like a high school diploma or equivalent is" vs. saying "No education of any kind is required"

Perhaps some property like qualifications in terms of how it's used and the data it contains, but defined to mean "the things in here are all explicitly not required"? That would open the door to indicating when other kinds of things beyond just degrees aren't required using existing data structures:

{
  "@context": "http://schema.org/",
  "@type": "Occupation",
  "name": "Research Scientist",
  "nonQualifications": {
    "@type": "EducationalOccupationalCredential",
    "educationalLevel": "PhD or equivalent"
  }
}

The loose use of the word 'not' is going to cause problems. I'd suggest adopting the words "Mandatory" and "Preferred, but not mandatory" as an expression of the entity described however it's implemented.

Over the decades Job Descriptions have used Required and Preferred to as a part of individual bullet points, so I assume something needs to be included in the markup to allow that organic expression that is quite normalized. 'Mandatory' to me is just more clear than 'Required', but they are synonymous

Maybe a qualification "type" or "level" or some similar notion that could have values like "required" (or mandatory), "recommended" (or preferred), and "not required" to cover the use case for this thread?

{
  "@context": "http://schema.org/",
  "@type": "Occupation",
  "name": "Research Scientist",
  "qualifications": [
    {
      "@type": "EducationalOccupationalCredential",
      "educationalLevel": "PhD or equivalent",
      "qualificationLevel": "Not Required"
    },
    {
      "@type": "EducationalOccupationalCredential",
      "educationalLevel": "High school diploma or equivalent",
      "qualificationLevel": "Required"
    },
    {
      "@type": "EducationalOccupationalCredential",
      "educationalLevel": "Bachelor Degree or equivalent",
      "qualificationLevel": "Preferred"
    }
  ]
}

FYI see https://schema.org/docs/releases.html#v12.0 release candidate currently out for review includes the commit made here 23 days back, https://webschemas.org/docs/releases.html#g2681

Issue #2681: Added vocabulary around JobPosting and Occupation so that we can explicitly indicate when degree-level qualification is not required. Added a boolean experienceInPlaceOfEducation property for JobPosting. Also added a new OccupationalExperienceRequirements type as an additional possible value for the existing experienceRequirements property. Added a number-valued property monthsOfExperience for use on OccupationalExperienceRequirements.

I believe this approach avoids the logical issues around negation in an RDF-based schema system, and leaves the door open for subsequent improvements.

A comment on the plurality of https://webschemas.org/OccupationalExperienceRequirements btw, it is in the spirit that https://schema.org/keywords is plural. A single instance of that type could touch on several "requirements". By contrast the type https://webschemas.org/EducationalOccupationalCredential has a singular name, reflecting the more discrete and enumerable situations it covers.

As an aside, I arrived here while trying to understand why there isn't some form of skills prop within experienceRequirements.

We know that experienceInPlaceOfEducation:

Indicates whether a JobPosting will accept experience (as indicated by OccupationalExperienceRequirements) in place of its formal educational qualifications (as indicated by educationRequirements). If true, indicates that satisfying one of these requirements is sufficient.

But is a number of months sufficient for this? I would say absolutely not.
Time, unfortunately, does not correlate to skills and without skills explicitly listed then how could time relate to a matching skillset of general higher education items?

• high school
• associate degree
• bachelor degree
• professional certificate
• postgraduate degree

@BenRacicot is it sufficient to specify skills separately to experienceRequirements rather than as part of them? (because as you say, time does not equate to skills). The skills property lets you do that for JobPosting.

Yes! certainly, I just expected skills to exist within this defined place for them.
Since experienceRequirements exists at all then it would seem that skills would be part of that the same as generic experience, time or edu would. That's all.

I suppose tools that use this meta would look upwards to the root level skills if experienceInPlaceOfEducation:true?

@BenRacicot Perhaps it would be worth raising a separate issue concerning what should be properties of OccupationalExperienceRequirements