Re: [Spam] Re: [TalentSignal] proposal for Job Start Date

Given that the schema.org structure is going to be driving the search
results we do need to decide how much noise we want to tolerate.  This is
our chance to lock down the results a little.  It may mean some results
won't show up because they weren't "tagged" properly, but I lean towards
making the schema.org tighter rather than looser.

***
Alexander Jackl
CEO & President, Bardic Systems, Inc.
alex@bardicsystems.com
M: 508.395.2836
F: 617.812.6020
http://bardicsystems.com


On Fri, May 3, 2019 at 10:02 AM Jason Sole <jason@directemployers.org>
wrote:

> Vicki,
>
>
>
> That is a very good point - rogue input is something we definitely want to
> avoid.
>
>
>
> I think this is a situation where the symbiosis between Schema.org and
> HROpen Stds will be able to solve the problem for the JDX.  If schema.org
> taxonomy is text, then the user can input either a date or a string. The
> system collecting the data can then parse the data and make a determination
> as to type. On the data exchange side, HR Open can articulate this in JSON
> as a “oneOf” property:
>
>
>
> “startDate”:{
>
>    “oneOf”: [
>
>         {
>
>             “type”:”date”
>
>         },
>
>         {
>
>             “type”:”string”
>
>         }
>
>         ]
>
> }
>
>
>
> The system can then transfer the information to the recipient with the
> correct format, which can be used to trigger different logic based on type.
> When the recipient displays that info, they will be able to do so with the
> Schema.org property regardless of the transmission type on the backend.
> This would allow the user to input whatever value they wanted on the front
> end and stay in alignment with the schema.org property, while allowing
> for disambiguation on the reader side.
>
>
>
> We do something similar to this with our durationType property, which
> allows for both an ISO format or a number as values.
>
>
>
> I know we aren’t discussing modifications to the JSON backbone here, but I
> want to make sure we are able to handle the rapid machine to machine
> transfer of data. If we don’t the JDX won’t be as successful.
>
>
>
> Thanks,
>
> Jason
>
>
>
> *From: *Vicki Tardif <vtardif@google.com>
> *Date: *Friday, May 3, 2019 at 9:37 AM
> *To: *"'Jason@directemployers. org'" <jason@directemployers.org>
> *Cc: *Merrilea Mayo <merrileamayo@gmail.com>, "public-talent-signal@w3.org"
> <public-talent-signal@w3.org>
> *Subject: *[Spam] Re: [TalentSignal] proposal for Job Start Date
>
>
>
> I appreciate that answer. And Dates are probably strongly preferred by
> most readers.
>
>
>
> But the reality is not everything will fit in ISO 8601 and a string like
> "ASAP" may be useful to certain readers. 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 over prescribes
> behavior, folks will just go off and do their own thing.
>
>
>
> - Vicki
>
>
>
>
>
> On Fri, May 3, 2019 at 9:27 AM Jason Sole <jason@directemployers.org>
> wrote:
>
> 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 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)
>
>