- From: Phil Barker <phil.barker@pjjk.co.uk>
- Date: Sun, 5 May 2019 17:46:10 +0100
- To: public-talent-signal@w3.org
- Message-ID: <0e3c5d27-124a-f34f-7da2-afc8aa43c884@pjjk.co.uk>
Thanks Andrew. On Friday I drafted a very similar suggestion, but didn't quite finish it. So, yes, I think that your proposal would make sense. I think that it would discourage the use of free text as much as we can, though we should acknowledge that whatever the spec says we will still get values as free text. The only change I would make is to change the name of the immediate start indicator to jobImmediateStart -- this gives a bit more context for schema.org. Also I want to check on the exact wording though, at the moment it's quite tight: start immediately or start on a specific date. Isn't reality a bit more flexible than that? So I had drafted: *jobImmediateStart* *Defintion: *An indicator as to whether a position is available for an immediate start. *Expected type:* Boolean <https://schema.org/Boolean> Phil On 04/05/2019 19:19, Andrew Cunsolo wrote: > Hello, All > This is an interesting discussion. > > I think for the majority of use cases, a single date or an indicator > for immediate start should suffice. I don't like > the option for local interpretation for a string, so I like the idea > of an "immedidateStart" indicator which is more clear on interpretation. > > I would amend it to be something like the following: > > *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 immediateStartIndicator property. > > *Expected type:* ISO 8601 Date <https://schema.org/Date> > > *immediateStartIndicator* > > *Definition: *Set this indicator if the successful applicant for > this job would be expected to start immediately. Use jobStartDate > if the start date for the successful applicant is at a specific > future date. > > *Expected type:* Boolean > > > @Phil you are more familiar with the best practices of schema.org, > would the above make sense? > > Regards, > Andrew. > > > > Andrew Cunsolo > VP Product Development > Talemetry Inc. > +1 519-841-4334 > Acunsolo@talemetry.com <mailto:Acunsolo@talemetry.com> > > > > On Friday, May 3, 2019, 2:28:57 p.m. EDT, Joseph D. Marsh > <jmarsh@3storysoftware.com> wrote: > > > Agreed. > > Thanks, > > - Joseph > > *From:*Merrilea Mayo <merrileamayo@gmail.com> > *Sent:* Friday, May 3, 2019 2:23 PM > *To:* public-talent-signal@w3.org > *Subject:* Re: [TalentSignal] proposal for Job Start Date > > I've never seen it? Not common. > > Merrilea > > On 5/3/2019 1:06 PM, Phil Barker wrote: > > Just thinking some more about this: Is there any case for allowing > a range of dates? Are there examples of job being advertised to > start between "now and three weeks time" or "after 1 June but > before 15 June"? > > Phil > > On 02/05/2019 16:02, Phil Barker wrote: > > 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 <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) > -- 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.
Received on Sunday, 5 May 2019 16:46:36 UTC