Re: [TalentSignal] proposal for Job Start Date

Vicki & Merrilea,

On the HROpen side of the equation, we have found it better to force a the field to specific format. Then you make it optional. This allows for an open ended posting without sacrificing the data integrity that fielded data grants.

HR Open Standards dealt with this situation in our version 3 specification. We added a “user defined” section in an attempt to be helpful and account for use cases that we hadn’t planned for. However, what ended up happening in practice is users were dropping their own structure in that field and saying they used the standard, even though no one receiving the file could do anything with it unless they knew the syntax of what was in user defined. It was an important lesson for us in maintaining the structure in structured data 😉

Granted, this is also a result of a different focus between the two standards. HROpen Standards is primarily focused on machine to machine data transfer. Computers are notoriously bad at context.  We need to consider both sides though, as the JDX will consist of both.  I’m not opposed to keeping it open ended, but we will need to account for machine to machine transfer and how it handles variable data types in the spec.

In addition, Merrilea, you are correct in that the data verification will be done outside the standard itself. The standard is what requires a particular format, but the software can allow for any sort of data input and validation it like, so long as the ending result matches the expectations of the standard. If we bake that in, we will restrict the usefulness of the standard.


Thanks,
Jason


Thanks,
Jason

From: Vicki Tardif <vtardif@google.com>
Date: Friday, May 3, 2019 at 9:12 AM
To: Merrilea Mayo <merrileamayo@gmail.com>
Cc: "public-talent-signal@w3.org" <public-talent-signal@w3.org>
Subject: Re: [TalentSignal] proposal for Job Start Date
Resent-From: <public-talent-signal@w3.org>
Resent-Date: Friday, May 3, 2019 at 9:12 AM

In general, when these sorts of issues have arisen, schema.org<http://schema.org> has leaned toward making things easier for writers rather than readers as some data is usually better than no data. I suggest allowing Date or Text and let readers determine how to handle values like "ASAP".

- Vicki


On Fri, May 3, 2019 at 9:03 AM Merrilea Mayo <merrileamayo@gmail.com<mailto:merrileamayo@gmail.com>> wrote:

I'm torn here between making this easy for people and making this easy for data collection.  "Easy for people" would be any old text field, including a date input as text but which could be back-converted to an actual date on someone's receiving end, if needed.  "Easy for data collection" would be to insist on a date-containing format, but preceded by "on or before."  What this forces, for the vague "ASAP" cases, is for people to figure out, well...how long is this hiring process actually likely to take, and so how soon could someone be feasibly expected to start?  That kind of planning doesn't come naturally to folks, but it is something that a data/software rule would force them into, and which would be helpful for all sorts of data collection and analysis.  Having those dates would help out economists calculating trends in labor shortages, hiring efficiency, and frictional unemployment (the employment that exists because people are between jobs; a lot of time, this is related to how long it takes employers to find and hire people).  There's less information to work with when it's an ad with a start date of "ASAP."  Job ads are often up for a month, long after someone was actually hired, because the major job boards have you pay by the month and allow you to keep a posted job up for that whole time.  Human laziness being what it is, the employer doesn't bother to take it down once the job is filled.  Having to specify a near-term start date, then keep changing it as the employer couldn't find someone, would send much stronger market signals and provide more useful economic information.  "ASAP" gives no distinction between employers needing someone in a week vs. employers needing someone in a month.  If US hiring were to plunge into crisis mode, economists wouldn't be able to tell for quite a while - not until BLS survey reports came in.

For the US, ASAP probably boils down to "within 2 weeks," (i.e., for today's date: "on or before" 5/17/2017"), just because most people in the US have to give 2 weeks' notice.  However, I would have no idea what "ASAP" meant for a job posting in another country whose time sense and customs were different.

So I see the benefits of requiring a date for all sorts of data-related reasons, but it does make life more annoying for the hiring managers posting job ads.  They'd have to think through what they really needed and estimate their process duration in order to supply a date.

Merrilea
On 5/3/2019 6:56 AM, Phil Barker wrote:

Thanks Joseph, I know what you mean. It is possible to stipulate values, but there's a trade-off in terms of in terms of ease of adoption and the amount of justification that schema.org<http://schema.org> might require for the changes we request. Also, there's more than one way of doing it

Option 1 (weakest, easiest): restate the the second sentence of the definition to be more assertive "Text values "Immediately", "As soon as possible", "Any time" must be used when a specific date is not appropriate.

-- one issue with this is that it's not friendly to non-English speakers

Option 2: add an enumeration to schema.org<http://schema.org> of jobStartDateTypes, these are URIs in the schema.org<http://schema.org> namespace that represent the values we want. As with option 1 we would need to define a set of values. (Option 2a, allow any URI or defined term so that the enumeration doesn't have to be in the schema.org<http://schema.org> namespace)

-- one issue with this is that, as far as I know, such enumerations in schema.org<http://schema.org> are rarely implemented, and perhaps not understood, by end users; we will still get people using text values. (BTW, that's probably going to be true what ever we do)

Option 3: add a second property to indicate immediateStart with a boolean T/F

-- one issue with this is that it is not extensible, we couldn't keep adding more and more properties for other special cases in the way that we could for the other options. FWIW, this is what the data model for the Job data exchange does. I think that 'immediate/asap' is the most important option

Thoughts everyone?

Phil
On 02/05/2019 16:12, Joseph D. Marsh wrote:
I like the idea of an “ASAP” option, but wonder if it’s possible to stipulate a single value to represent that idea, rather than leave it open to “local interpretation”?

Thanks,
- Joseph

From: Phil Barker <phil.barker@pjjk.co.uk><mailto:phil.barker@pjjk.co.uk>
Sent: Thursday, May 2, 2019 11:03 AM
To: public-talent-signal@w3.org<mailto:public-talent-signal@w3.org>
Subject: [TalentSignal] proposal for Job Start Date


Hello all, the second relatively simple issue that we prioritized, is that currently schema.org/JobPosting<http://schema.org/JobPosting> has no way to specify the expected start date for the job being advertised.

A simple way to fix this<https://www.w3.org/community/talent-signal/wiki/Provide_start_date_for_job> is a new property of JobPosting:

jobStartDate

Definition: The date on which a successful applicant for this job would be expected to start work. Text values such as "Immediately" or "As soon as possible" may be used when a specific date is not appropriate.

Expected type: ISO 8601 Date<https://schema.org/Date> or Text<https://schema.org/Text>



Please let me know if you wish to improve on this or have an alternative suggestion. In particular, is a text value to indicate an immediate start sufficient, or should this be handled more explicitly, for example as a separate property?

On that question, my own view (as exemplified in the proposal) is that, while an explicit indicator for immediate start may be useful for internal systems, a text value is adequate for advertising this on the web. If experience and demand show that this approach is not adequate, we would have evidence to provide to schema.org<http://schema.org> for a separate, explicit property.

Regards, 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.
--

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<mailto:merrileamayo@gmail.com>
https://merrileamayo.com/

240-304-0439 (cell)
301-977-2599 (landline)