Skip to content
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

OrganizationRole examples inconsistent with current schema #2787

Open
Eyas opened this issue Dec 10, 2020 · 7 comments
Open

OrganizationRole examples inconsistent with current schema #2787

Eyas opened this issue Dec 10, 2020 · 7 comments
Labels
no-issue-activity Discuss has gone quiet. Auto-tagging to encourage people to re-engage with the issue (or close it!).

Comments

@Eyas
Copy link

Eyas commented Dec 10, 2020

Two uses of Organization show examples using OrganizationRole in its place, but the schema does not allow for this:

aluminOf

https://schema.org/alumniOf can only be Organization or EducationalOrganization. OrganizationRole is not a subClassOf Organization. Yet Example 2 for role shows AlumniOf using OrganizationRole.

{
    "@context": "https://schema.org",
    "@type": "Person",
    "name": "Delia Derbyshire",
    "sameAs": "http://en.wikipedia.org/wiki/Delia_Derbyshire",
    "alumniOf": {
        "@type": "OrganizationRole",
        "alumniOf": {
            "@type": "CollegeOrUniversity",
            "name": "University of Cambridge",
            "sameAs": "http://en.wikipedia.org/wiki/University_of_Cambridge"
        },
        "startDate": "1959"
    }
}

alumniOf should have Role or OrganizationRole in its range. or perhaps Role/OrganizationRole should have multiple parents?

hasOccupation

Similarly, Example 2 for Occupation shows Role, but hasOccupation has only Occupation in its range.

{
  "@context": "https://schema.org/",
  "@type": "Person",
  "name": "Albert Einstein",
  "hasOccupation": [
    {
      "@type": "Role",
      "hasOccupation": {
      "@type": "Occupation",
      "name": "Patent examiner",
        "occupationalCategory": "23-2099.00"
      },
      "startDate": "1901",
      "endDate": "1906"
    },
    {
      "@type": "Occupation",
      "name": "Professor of Physics",
      "educationRequirements": "PhD in Physics"
    }
  ]
}

Initially filed in google/schema-dts#143

@RichardWallis
Copy link
Contributor

The questions, and comments, in issue #2777 are also very relevant here.

As referenced in the conformance section of the Data Model documentation, any property, in theory, can expect values Text, URL, Role in addition to those documented.

Following those guidelines, and noting that OrganizationRole is a subtype of Role, those examples are both valid.

However, that is not to say that these capabilities are understood by and obvious to developers.

I believe we could possibly make things a little simpler by adding the Role subtypes - OrganizationRole, EmployeeRole, PerformanceRole, and possibly LinkRole - to the range of appropriate properties (alumniOf, worksFor, memberOf, actor, etc.). Also based upon your second example, there may be a case for a new Role subtype of OccupationRole.

A general highlighting of the usage of Role, by adding it to the range of many properties, would probably increase confusion in return for very little benefit. However, highlighting the use of its already defined subtypes, to add date and other qualifications to certain relationships, would be helpful.

Dependant on support and comments, I would be prepared to draft a PR to apply the limited changes I describe and tweak associated examples.

cc @danbri

@gmeligio
Copy link

I'm using schema-dts with Schema.org for personal projects, and that's why I posted the issue there. I need to use this Role feature in order to express a time period in some properties like hasOccupation and alumniOf. As you said, I hope to see it possible through Role subtypes in the range of the appropriate properties.

I'm not familiar with the schema development process but I'm willing to test the PR.

@OR13
Copy link

OR13 commented Dec 23, 2020

I also found this confusing... consider the following:

{
  "@context": {
    "id": "@id",
    "type": "@type",
    "roles": {
      "@id": "https://schema.org/roleName",
      "@type": "@id",
      "@container": "@set"
    }
  },
  "id": "https://example.com/person/123",
  "roles": [
    "https://example.com/organizations/456/roles/admin",
    "https://example.com/organizations/789/roles/contributor"
  ]
}

This appears to produce "better" nquads than the examples that rely on the Role type and its subclasses... If this is cancer please tell me now :)

@github-actions
Copy link

This issue is being tagged as Stale due to inactivity.

@github-actions github-actions bot added the no-issue-activity Discuss has gone quiet. Auto-tagging to encourage people to re-engage with the issue (or close it!). label Feb 22, 2021
@irene459
Copy link

irene459 commented Jul 2, 2021

  • I know nothing about any of this but fix what needs to be fix . I just happened to accidentally log on to this by browsing through my phone . Which it has been hacked

@chrisspradling1980
Copy link

chrisspradling1980 commented Jul 2, 2021 via email

@Eyas
Copy link
Author

Eyas commented Sep 13, 2021

BTW, this issue was initially borne out someone using schema-dts and expecting to use Role types in any place it's expected. schema-dts uses TypeScript's type-system to automatically typecheck JSON-LD during development/build-time. The representation of a Role has been included in v1.0.0 which should hopefully help folks in this issue (and #2777) using IDEs and expecting the right code completions.

FWIW, the TypeScript representation of Roles is interesting, and can be written in a closed-form way (simplified):

type Role<TPropertyType extends Thing, TPropertyName extends string> = {
  "@type": "Role",
  // ... role properties,
  [property: TPropertyName]: TPropertyType
}

and any property can be represented as:

type SchemaValue<T, TProperty extends string> = T | Role<T, TProperty> | readonly (T | Role<T, TProperty>)[];

//
type Person {
  "@type": "Person",
  "name": SchemaValue<Text, "name">
//...
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
no-issue-activity Discuss has gone quiet. Auto-tagging to encourage people to re-engage with the issue (or close it!).
Projects
None yet
Development

No branches or pull requests

6 participants