Re: [TalentSignal] proposal for Job Start Date

Thanks Martin,

*All: *any objection if we follow Martin and Vicki's advice and add Text 
back into the expected range for jobStartDate? It's largely an 
acknowledgement of what people will do anyway if they cannot express the 
information that they want as a date.

*Martin*, is this enough to address your concerns?

> *jobStartDate*
>
>     *Definition*: The date on which a successful applicant for this
>     job would be expected to start work. Choose a specific date in the
>     future or use the jobImmediateStart property to indicate the
>     position is to be filled as soon as possible.
>     *Expected type*:ISO 8601 Date <https://schema.org/Date> , Text
>     <https://schema.org/Text>
>
> *jobImmediateStart*
>
>     *Defintion*: An indicator as to whether a position is available
>     for an immediate start.
>     *Expected type*:Boolean <https://schema.org/Boolean>
>
Some examples would be useful for clarifying / setting guidance for 
difficult cases. Let me know if you have any text that might be the 
basis for such examples.

Phil

On 07/05/2019 09:29, Martin Solli wrote:
> I think HR hiring managers appreciate the nuance between “negotiable” 
> and “as soon as possible”, and would very much like to express this in 
> a free-form text field when posting a job. It is not hard to find 
> examples of job postings that would not be well-served under the 
> current proposal.
>
>>> - 14% have some variation of “As soon as possible” in the local 
>>> language.
>> We say to use jobImmediateStart for this
>
> It is not the same. Again, it’s nuance. “Immediate” according to 
> dictionaries mean “without delay or very soon", while “as soon as 
> possible” is more vague. It invites questions like “… as possible for 
> whom?” Other languages might have other words that suggest different 
> things to local readers. There might not be a one to one relationship 
> between “immediate” and any one word in a given language.
>
>>> - 5% have only the name of a month or two consecutive months 
>>> (“August/September”).
>> ISO 8601 allows values like these, e.g. 2019-06 and 2019-08-01/2019-09-30
>
> It does, but to a human reader in Norway “August/September” means 
> something like “after the sommer holiday sometime, there’s no rush, 
> but we need to fill this position before autumn really kicks in”.
>
> If the job requires a specific start date it can be expressed with an 
> ISO 8601 date. Software can trivially parse the string - if it’s a 
> well-formed ISO 8601 string, the software can use this structured 
> date, otherwise it is a string that humans (or more sophisticated 
> algorithms, perhaps backed by machine learning) can read and understand.
>
> I think Vicki Tardif said it best earlier in the thread:
>
>> If we don't allow for Text, people will do it anyway with no 
>> guidance, particularly on the open web. As an example, there are many 
>> cases where properties expecting a Person instead get a string like 
>> "Jane Doe". It is up to the reader to determine whether this is 
>> useful or not and act accordingly. If schema.org 
>> <http://schema.org> over prescribes behavior, folks will just go off 
>> and do their own thing.
>
> I can testify that this is what people do in our system, even when 
> steered towards providing a specific date or a value like “ASAP”.
>
> Martin Solli
> Developer & Co-Founder, Vilect
> https://www.vilect.com/
>
-- 

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.