Re: [TalentSignal] proposal for Job Start Date

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 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 of jobStartDateTypes, these 
> are URIs in the 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 namespace)
>
> -- one issue with this is that, as far as I know, such enumerations in 
> 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>
>> *Sent:* Thursday, May 2, 2019 11:03 AM
>> *To:* 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 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 for a 
>> separate, explicit property.
>>
>> Regards, Phil.
>>
>> -- 
>>
>> Phil Barker <http://people.pjjk.net/phil>. 
>> 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
https://merrileamayo.com/ < >
240-304-0439 (cell)
301-977-2599 (landline)

Received on Friday, 3 May 2019 13:03:50 UTC