Suggestion for New Schema Property - "workedAt" about schemaorg HOT 15 OPEN

@WilkoMarketing

• It was already pointed out that Role (or OrganizationRole) can be used with worksFor
• You can express a past employment even if you don't have endDate by using eg Role.additionalType="past" or "inactive"
• However, there is also affiliation. Under #3374 I asked to make it a super-prop of worksFor because it sounds more general. Maybe you can use it to express the disjunction worksFor|workedAt? Then you can query in a semantic database like this:

select ?employee {
  ?employee s:worksFor <org>
}
select ?pastEmployee {
  ?pastEmployee s:affiliation <org>
  filter not exist {?pastEmployee s:worksFor <org>
}

from schemaorg.

Actually, we are already able to express as much, without having to add a new workedAt property, via Role (or any of its subtypes). An example of that would be:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Wile E. Coyote",
  "worksFor": {
    "@type": "OrganizationRole",
    "startDate": "1949-09-17",
    "endDate": "1966-11-05",
    "worksFor": {
      "@type": "Organization",
      "name": "Warner Bros."
    }
  }
}
</script>

from schemaorg.

Previous employment could already be represented with worksFor, Role, and endDate.

{
    "@type": "http://schema.org/Person",
    "http://schema.org/worksFor": {
        "@type": "http://schema.org/Role",
        "http://schema.org/startDate": "1998",
        "http://schema.org/endDate": "2011",
        "http://schema.org/roleName": "CEO",
        "http://schema.org/worksFor": {
            "@type": "http://schema.org/Corporation"
        }
    }
}

Although if you want to state only that the employment has ended, but without a specific date, then I suppose that doesn't fit.

from schemaorg.

Hi @jvandriel
Thanks for your reply.
On schema.org doc, the expected type for worksFor property is Organization. I see you are using OrganizationRole, which is an intangible. Im not sure is right.
Thanks

from schemaorg.

Hi @KalleOlaviNiemitalo
Thanks for your reply. I just replied @jvandriel that i dont think is right to use Role type for a worksFor property. It should be an Organization type. https://schema.org/worksFor
Thanks

from schemaorg.

According to http://blog.schema.org/2014/06/introducing-role.html, Role is a special class in that an instance of it can be used as the value of any property even if not declared as such.

I don't know whether that applies to properties in non-schema.org namespaces though.

from schemaorg.

Role is a bit of 'an odd one out' type of Class but it has been added to make expressions, like (not just) workedAt possible.

The trick is the repeating of the property, an instance of Role is applied to, under Role (or subType):

"worksFor": {
    "@type": "OrganizationRole",
    "workFor": {
      ...
    }
}

from schemaorg.

Thank you very much @jvandriel and @KalleOlaviNiemitalo . I think having a specific type such as the one I recommended initially, would make things much easier and updated to current needs.

from schemaorg.

I'm not really familiar with the process here but my hunch is that, with Role and related types having already been defined, extensions to those would be more likely to be approved than a separate way to represent the same concept.

Flexibility: It could be designed to include additional information such as the duration of employment,

Can be computed from startDate and endDate. But I imagine a new property could be defined for the duration itself, in case the dates are unknown.

the role held,

roleName. Does this need properties other than the name? JobPosting or Occupation seems a bit related even if not directly applicable.

and the department or division within the organization.

The role can have worksFor an Organization that is a department of another Organization.

from schemaorg.

I think we all understand the benefit of having a specific property such as workedAt for representing past employments.

At the same time Role already exists for representing affiliations in a generic way and it can even capture information about the relationship itself: eg. startDate, endDate or roleName.

Some context about the use of Role can be found here.

from schemaorg.

Hi @VladimirAlexiev

Thank you for your insights. Would you be able to provide a JSON-LD script example that demonstrates the use of the affiliation property along with Role.additionalType="past"? An example would greatly help in understanding the practical implementation of these properties.

Thank you in advance for your assistance.

from schemaorg.

This issue is being nudged due to inactivity.

from schemaorg.

Hi @WilkoMarketing !

The example is very similar to worksFor-Role-worksFor, we're just using affiliation instead.
Any node can have additionalType where you can be more specific about the nature of information in the node:

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Wile E. Coyote",
  "affiliation": {
    "@type": "OrganizationRole",
    "additionalType": "https://example.org/affiliations/pastEmployment",
    "startDate": "1949-09-17",
    "endDate": "1966-11-05",
    "affiliation": {
      "@type": "Organization",
      "name": "Warner Bros."
    }
  }
}

It is a schema.org best practice (cc @jvandriel ) to use Wikidata URLs for additionalType, so if you can find such Wikidata item, use that.

from schemaorg.

Thanks, @VladimirAlexiev. Why would you prefer 'affiliation' over 'worksFor'? Is there any reason you could suggest it's better?

from schemaorg.

I wrote above that affiliation sounds to me more general than the existing worksFor and the proposed workedAt.
A consumer is more likely to think that affiliation indicates current or past employment, while worksFor indicates current employmentt.

from schemaorg.