Add a salary range properties

[siuc-nate]

Per #696, we need to be able to describe this.

Add:

URI: schema:baseSalary
Label: Base Salary
Definition: The base salary for the resource.
Domain: ceterms:Credential (and subclasses), ceterms:LearningOpportunityProfile
Range: TBD

We need a range for schema:baseSalary.

---

Option 1 - Use CostProfile
Pros:

• It already exists
• It is a proven structure for defining an amount, a currency, a frequency, and an applicable audience/residency
• It would allow recycling existing code/implementations

Cons:

• It's called "cost" profile
• The definition is a limiting factor

---

Option 2 - Use schema:QuantitativeValue
Pros:

• It's already in use in CTDL and QData
• It can already define currency (via unitText)

Cons:

• It's not an exact match to what schema.org wants (MonetaryAmount)
• We would probably need to add properties for applicable audience/residency ala CostProfile, which may dilute the meaning/use of this class over time
• We would need to add the existing ceterms:paymentPattern to it to define frequency, which is too specific to money payments to be used for other kinds of frequency, and would definitely dilute the meaning/use of this class

---

Option 3 - Use schema:MonetaryAmount
Pros:

• It matches the schema.org spec
• It matches our current proposal/plans for ProPath
• Adding the existing ceterms:paymentPattern property to it would not dilute the meaning of the class
• Adding the audience/residency-related properties would probably not be a problem (maybe we don't add them until it's called for?)

Cons:

• It would require adding a new class that would only be used by the schema:baseSalary property
• We would have to choose whether to add schema:currency or use the existing ceterms:currency instead
• We would have to choose whether to add schema:validFrom and schema:validThrough or use the existing ceterms:startDate and ceterms:endDate
• We risk basically reinventing CostProfile over time, at which point it might make more sense to dump CostProfile and use the fully-equipped schema:MonetaryAmount instead

---

Option 4 - Create a new class
Pros:

• Flexibility in what we add
• Can tailor it to the notion of a salary if it makes sense to do so

Cons:

• It would not match the schema.org spec
• It would probably end up just being CostProfile with a different definition

---

No clear winner in these options.

[mparsons-ce]

CostProfile seems to be a little unwieldy for this purpose, compared to MonetaryAmount:

• currently requires description and cost details uri
• using price is messy versus value
• there is no range

On the plus side

• the payment pattern is clearer than using UnitText from MonetaryAmount

[mparsons-ce]

Will we have any constraints on which credentials baseSalary can be referenced (e.g. apprenticeships) or allow for all credentials?
It would seem not applicable to:

• badges
• licences
• certificates, certifications
• any degree
• etc.

[mparsons-ce]

MonetaryAmount has the property UnitText. In the CTDL context, the latter has the conceptScheme CreditUnit which relates to Degree credit etc.
Will UnitText in the Monetary amount context be a different concept scheme, or just text. If the latter, should it be a lang string?
Especially if it will be used to indicate per hour, per years, etc.

[stuartasutton]

AS for a ceterms:paymentPattern, JDX has a property called jdx:payCycleInterval defined as:

Pay cycle interval specifies how often the pay cycle occurs or, in other words, how often a person is paid, e.g., "daily", "weekly", "monthly", "yearly" etc.; select from an existing enumeration of such types.

It suggests selection from HR Open's PayCycleIntervalCodeList which includes:

"Day",
"Week",
"TwoWeeks",
"HalfMonth",
"Month",
"TwoMonths",
"MonthWeek",
"MonthWeek2",
"MonthWeek3",
"MonthWeek4",
"MonthWeek5",
"MonthWeekLast",
"Quarter",
"HalfYear",
"Year"

[siuc-nate]

@stuartasutton For one-time payments, would you leave that field empty or is there/should there be an explicit concept for that?

[stuartasutton]

Well, a one-time, lump-sum payment is not a payment pattern.

[siuc-nate]

Yes, but, unless an explicit value is provided, you don't know for sure whether something is a one-time payment or if the pattern was just left out. If it's safe to assume a one-time payment when no pattern data is present, then that's fine - I just wanted to make sure that was the case.

This might be particularly relevant if we go with a property with "salary" in its name, since it may make people think that a one time payment will occur with some assumed interval (probably every two weeks).