Ability to designate when a JobPosting expires

[vholland]

Some JobPostings are only valid for a certain set of dates. For example https://www.usajobs.gov lists both closing and ending dates for job postings.

JobPosting already has a "datePosted" property. We should add "validThrough" to this domain so authors can list the end date as well.

[mfhepp]

If JobPostings were properly modeled as subtypes of Demand, then all these aspects would fall in naturally. After all, JobPostings are indications of interest to transfer some rights or services for a compensation.

Martin

On 23 Mar 2016, at 16:49, vholland notifications@github.com wrote:

Some JobPostings are only valid for a certain set of dates. For example https://www.usajobs.gov lists both closing and ending dates for job postings.

JobPosting already has a "datePosted" property. We should add "validThrough" to this domain so authors can list the end date as well.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[vholland]

@mfhepp I disagree. If JobPosting were a subtype of Demand, it would suddenly inherit a large number of properties unrelated to JobPostings (gtin*, itemCondition, itemOffered, serialNumber, sku, etc.)

[mfhepp]

no, because they are properties of Product, not Offer

---

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

Am 24.03.2016 um 13:43 schrieb vholland notifications@github.com:

@mfhepp I disagree. If JobPosting were a subtype of Demand, it would suddenly inherit a large number of properties unrelated to JobPostings (gtin*, itemCondition, itemOffered, serialNumber, sku, etc.)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[vholland]

I don't understand. http://schema.org/Demand lists these as properties. Is that an error?

[danbri]

"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."

I can see this covers "ACME Inc. seeks the services of a [job details here]". And it is clear that JobPostings are vague and flexible compared to the eventual concrete jobs that they may lead to. If we ever add vocabulary to describe properties actual jobs (e.g. for resumes, modeling skills etc.) we will have a similar awkward fit there.

The current 32 properties on Demand aren't coming at this from the same angle as http://schema.org/JobPosting. Looking at http://schema.org/validThrough it seems a reasonable fit for the current JobPosting design. I'd suggest adding that association now, and postponing any redesign around demands, jobs, skills etc until we have clearer use cases. The symmetry of Demand and Offer is appealing in the abstract but could make http://schema.org/JobPosting needlessly cryptic.

[danbri]

To unblock this, I propose the following:

1. We add validThrough as applicable on JobPosting immediately.
2. I have created Proposal to make JobPosting a subtype of Demand #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]

Closing this as a duplicate of #961.