Add closing date for JobPosting

[alexdutton]

It'd be useful to know when a job posting closes.

[mfhepp]

If we manage to integrate the GoodRelations meta-model also into the JobPosting usecase, which I hope, then a JobPosting would be a special form of a schema:Demand, and validFrom and validThrough would indicate the beginning an end of the job offer.

Just from the top of my head: We might solve this and other issues around JobPosting by making it a subtype of schema:Demand.

Martin

martin hepp http://www.heppnetz.de
mhepp@computer.org @mfhepp

On 15 Jan 2016, at 13:25, Alexander Dutton notifications@github.com wrote:

It'd be useful to know when a job posting closes.

—
Reply to this email directly or view it on GitHub.

[vickitardif]

I am not sure that JobPosting fits with Demand cleanly. At least in the USA, there are legal differences between providing a service (i.e. being a contractor) and being an employee.

To the immediate issue, it would seem easier to make datePosted a sub-property of validFrom and add validThrough to JobPosting.

[danbri]

Yeah, JobPosting feels close to JobDescription; and the vast majority of schema.org types fit that pattern. Person is a PersonDescription, Event is a EventDescription etc. The latter in particular is analagous in that events (especially those tentative ones in the future) as somewhat ephemeral, as are future unfilled job roles. So -0.5 on Demand, and +1 for adding validThrough and sub-propertying validFrom.

[mfhepp]

It fits Demand supercleanly ;-)

Demand:

"A demand entity represents the public, not necessarily binding, not necessarily exclusive, announcement by an organization or person to seek a certain type of goods or services. For describing demand using this type, the very same properties used for Offer apply."

Labor in any form is a good or service in the economic sense.

So a JobPosting is indeed a specialization of a Demand (and a JobSearch is a specialization of Offer).

Martin

martin hepp http://www.heppnetz.de
mhepp@computer.org @mfhepp

On 19 Jan 2016, at 16:20, vholland notifications@github.com wrote:

I am not sure that JobPosting fits with Demand cleanly. At least in the USA, there are legal differences between providing a service (i.e. being a contractor) and being an employee.

To the immediate issue, it would seem easier to make datePosted a sub-property of validFrom and add validThrough to JobPosting.

—
Reply to this email directly or view it on GitHub.

[vickitardif]

Right. At least in the USA, as an employee, I am not providing a "good or service". Contractors provide services.

I know this seems pedantic, but organizations have faced sanctions for labeling employees as contractors to circumvent certain labor laws.

[chaals]

In a narrow sense that is correct. But in the pragmatic world of "how do I describe what's in my Web content", I think a request - neither binding nor exclusive - for a person to do a job matches what normal people think of os services.

The use of "contractor" as a term somehow different from employee is itself jargon. Employees have contracts - express and/or implied. It happens that there are many ways of writing a contract to provide services. So a Call for Tenders, which is a common thing in many places, seems to me similar enough to a Job Offer from a schema perspective...

[mfhepp]

In the standard economics literature, labor and land and capital are the most basic production factors that can be traded on markets, and thus the notion of "demand" and "offer/supply" are conceptually perfect matches.

Note that I am not suggesting to put "HumanLabor" under "Product", because our current notion of "Product" in schema.org is a bit too narrow anyway.

But a JobPosting is a a public, not necessarily binding, not necessarily exclusive, announcement by an organization or person to seek a certain set of rights on a production factor, i.e. human labor.

I do not want to be too religious about design decisions in schema.org, but I see a bad tendency to sacrifice existing conceptual cleanliness in favor of quick fixes with unknown side-effects.

Such will backfire.

There is really no problem with using Demand for modeling the interest in finding a human being that gets a certain job done for a certain monetary compensation. Nothing is said about whether the form of contribution will be a contracted service or human labor with all of its legal constraints in most countries.

[chaals]

…or a volunteer effort to help someone do something. Which also strikes me as the same, although once again it happens under different legal frameworks.

[chaals]

(All this leaves me wondering if we have enough use case to justify a "contract jurisdiction" or similar, but I suspect the answer is "not in the real world".

[danbri]

To unblock this, I propose the following:

We add validThrough as applicable on JobPosting immediately.
I have created #1060 to continue the specific debate about whether to file JobPosting as a kind of Demand.
I'm cross-posting this to both #961 and #1054, and will close the latter as a duplicate of the former.

My thinking is that if we do decide that JobPosting should be marked as a Demand, then we will eventually add validThrough to JobPosting. Since that is the case and currently JobPosting lacks the ability to include when the posting closes, we may as well fix that problem immediately. If the Demand debate in #1060 reaches consensus quickly then we can publish both changes at the same time.

[danbri]

Proposed textual change is:

• previous: The end of the validity of offer, price specification, or opening hours data.
• now: The end of the validity of an offer, price specification, opening hours specification, demand or job posting.

Alongside adding "validThrough domainIncludes JobPosting."

Note that we had also previously also forgotten to mention in the definition text that validThrough is applicable to Demand.

[danbri]

Queued for review:

• draft site http://webschemas.org/JobPosting
• draft release notes http://webschemas.org/docs/releases.html

[danbri]

Closing per http://webschemas.org/docs/releases.html#g961