New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add closing date for JobPosting #961

Closed
alexsdutton opened this Issue Jan 15, 2016 · 13 comments

Comments

Projects
None yet
5 participants
@alexsdutton

alexsdutton commented Jan 15, 2016

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

@mfhepp

This comment has been minimized.

Show comment
Hide comment
@mfhepp

mfhepp Jan 18, 2016

Contributor

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.

Contributor

mfhepp commented Jan 18, 2016

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.

@vholland

This comment has been minimized.

Show comment
Hide comment
@vholland

vholland Jan 19, 2016

Contributor

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.

Contributor

vholland commented Jan 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jan 19, 2016

Contributor

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.

Contributor

danbri commented Jan 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mfhepp

mfhepp Jan 19, 2016

Contributor

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.

Contributor

mfhepp commented Jan 19, 2016

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.

@vholland

This comment has been minimized.

Show comment
Hide comment
@vholland

vholland Jan 20, 2016

Contributor

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.

Contributor

vholland commented Jan 20, 2016

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

This comment has been minimized.

Show comment
Hide comment
@chaals

chaals Jan 20, 2016

Contributor

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

Contributor

chaals commented Jan 20, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mfhepp

mfhepp Jan 20, 2016

Contributor

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.

Contributor

mfhepp commented Jan 20, 2016

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

This comment has been minimized.

Show comment
Hide comment
@chaals

chaals Jan 20, 2016

Contributor

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

Contributor

chaals commented Jan 20, 2016

…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

This comment has been minimized.

Show comment
Hide comment
@chaals

chaals Jan 20, 2016

Contributor

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

Contributor

chaals commented Jan 20, 2016

(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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Mar 29, 2016

Contributor

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.

Contributor

danbri commented Mar 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Mar 29, 2016

Contributor

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.

Contributor

danbri commented Mar 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Mar 29, 2016

Contributor

Queued for review:

Contributor

danbri commented Mar 29, 2016

Queued for review:

@danbri

This comment has been minimized.

Show comment
Hide comment
Contributor

danbri commented Apr 28, 2016

@danbri danbri closed this Apr 28, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment