Re: [TalentSignal] proposal for Job Start Date

In general, when these sorts of issues have arisen, 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> 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 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> <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
> 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)
>